控制文件对于Oralce数据库的作用，就好像微软操作系统中注册表的作用一样。控制文件是一个比较小的二进制文件，记录着数据库的结构信息。如果数据库控制文件发生孙华的话，则Oracle将无法正常启动。通常情况下，在创建数据库时会自动创建控制文件;并且当数据库的结构发生变化时，也会自动修改自动文件的内容。
但是，当数据库遇到一些故障导致控制文件发生损坏时，数据库管理员可能需要手工重新创建控制文件，以解决数据库的启动故障。笔者在这里就谈谈手工创建控制文件的相关策略。希望能够帮助大家解决控制文件损坏导致的数据库故障问题。

一、什么情况下要手工重新创建控制文件?

通常情况下，在数据库创建过程中，系统就会自动创建控制文件。不过在遇到一些比较特殊的情况是，数据库管理员就需要手工重新创建新的控制文件。这些特殊情况，据笔者所知，主要有如下两种情况。

一是希望改变某个数据库参数的永久性设置。

在创建数据库的时候，数据库管理员需要设置一些永久性的参数，如数据库的名字等等。有时候在一些特殊的情况下，需要修改这些永久性的参数。如企业后来随着规模的扩大，一台数据库服务器已经不能够满足企业日常作业的需要。为此，数据库管理员决定采用分布式环境来改善数据库的性能。可是，在刚创建数据库的时候，由于没有考虑到这种情况，所以给数据库命名的时候比较简便。现在需要创建多个数据库，管理员为了统一各个数据库的命名策略，即可能需要更改数据库的名字，以符合这个命名规则。遇到这种情况，数据库管理员必须要手工重新建立控制文件，才能够更改数据库名字。

二是所有数据库的控制文件都遭受到永久性损坏。

通常情况下，数据库处于Archivelog模式时，ARCH进程会自动用归档日志文件名和日志序列号之类的信息修改控制文件。而当管理员利用RMAN执行备份操作时，RMAN的备份信息也会被记录到控制文件中。所以，如果当控制文件发生永久性损坏时，那么对于数据库的影响是致命的。如此此时，数据库管理员因为一时疏忽，没有做好数据库控制文件的备份(或者说备份文件比较早)，那么此时数据库管理员不得不手工创建新的控制文件。

二、如何创建控制文件?

手工创建新的控制文件比较麻烦。不过数据库管理员若按照下面的步骤一步步来的话，还是可以创建一个完好无损的控制文件。

第一步：制作一个包含数据库据所有数据文件和重做日志文件的列表。

因为数据库启动时必须要有数据文件的相关信息。为此要创建新的控制文件，数据库管理员首先就需要收集数据库所有数据文件和重做日志文件的列表。这个列表可以从两个地方取得。一是如果对控制文件进行了备份的话，则可以从备份的控制文件中获取这些数据文件与重做日志文件的相关信息。如果没有控制文件的备份或者控制文件备份损坏的话，则可以从动态性能视图中查询相关的信息。如利用查询语句SELECT NAME FROM V$DATEFILE语句来查询所有的数据文件信息。此时的一个前提条件就是存在控制文件的最新备份文件或者数据库仍然可以正常启动。也就是说，如果需要改变数据库的永久性参数则可以利用这种方式获取所需要的信息。
但是如果此时数据库已经无法启动无法找到这些信息，或者控制文件已经受到严重破坏又没有合适的控制文件备份的话，那么上面这些方法就不适用了。此时数据库管理员只有人工定位构成数据库的所有数据文件和重做日志文件。也就是说，数据库管理员要根据日常工作中的笔记来整理这些记录。通常情况下，笔者新建数据文件的时候，都会有书面的记录。当遇到这个意外情况时，这些书面的记录就起到作用了。
注意如此此时数据库管理员收集到的数据文件不全，那么在数据库启动的时候就会发生错误。此时管理员就需要根据系统提供的错误信息来查找原因。在创建新的控制文件并且使用它打开数据库之后，Oracle会对数据字典和控制文件的内容进行检查。如果发现数据字典包含了某个数据文件、而控制文件中则没有列出这个数据文件，Oracle数据库就会报错。 Oracle将会在新的控制文件中创建一个名为Missingnnn占位符入口。这里最后面的NNN是十进制的文件编号。此时数据库管理员就可以凭借这个信息来判断是否缺少必要的数据文件。找到数据文件之后，可以通过修改这个值，让数据库找到相对应的真正数据文件。

第二步：关闭数据库。

如果数据库仍然处于启动状态，需要把数据库先关闭掉。在关闭的时候，如果能够采用正常模式关闭的，则最好采用正常模式关闭。而其他关闭模式，则是不得已而为之的做法。采用正常模式关闭，可以减少数据库重新启动过程中可能出现的问题。
另外为安全起见，关闭数据库之后，最好把数据库中所有的数据文件、重做日志文件、参数文件备份到其他地方。这主要是为了不小心而给数据库造成无法挽回的损失。虽然这不是必须的，但是笔者强烈建议这么做。

第三步：开始创建新的控制文件。

数据库管理员备份好所有的数据文件、重做日志文件、参数文件之后，就需要启动一个新的例程。但是不要加载数据库或者打开数据库。也就是说，此阿如STARTUP NOMOUNT命令。数据库启动分三个步骤，分别为启动例程、加载数据库、打开数据库。此时数据库管理员一定要注意只要启动一个进程即可，不需要加载数据库或者打开数据库。否则的话，控制文件就无法创建成功。
启动例程后，数据库管理员要采用Create Controfile语句来创建一个新的控制文件。如果除了控制文件外，还丢失了某些重做日志组的话，还需要使用Resetlogs参数。也就是说，需要恢复丢失的重做日志。另外，跟数据库控制文件损害不同，如果只是更改数据库的名字，则也需要使用这个参数。建立好这个控制文件后，还没有全部完工。因为此时的控制文件中还没有初始化参数。数据库管理员还需要手工修改控制文件中的初始化参数。为了防止后续的工作导致新建的控制文件重新损坏，在配制控制文件的初始化参数的之前，最好对这个控制文件先进行备份。如此的话，即使手工修改控制文件初始化参数有错的话，也不用重头来过。而只需要把新建立的控制文件还原即可。

第四步：编辑控制文件初始化参数。

创建了新的控制文件之后，数据库管理员还需要根据实际的情况来修改控制文件的初始化参数。如数据库管理员需要更改数据库名字的话，就需要更改 DB_NAME参数。在修改这个控制文件的时候，一定要小心。他跟微软操作系统的注册表一样，一个字符都不能够差的。为此，对于这些初始化参数，如果能够通过复制、粘贴等手段取得的，最好直接通过复制粘贴来修改初始化参数。手工输入的话，难免为出现错误。另外，再强调一次，跟修改注册表一样，对控制文件中的内容进行修改之前，最好先对这个控制文件进行备份。那么即使控制文件的初始参数有什么不准确的地方，也可以尽量采取一些弥补措施。

第五步：有选择的恢复数据库。

数据库管理员可以根据实际需要，选择是否需要恢复数据库。一般来说，这个步骤不适必须要进行的。即使控制文件重新建立后没有重新恢复数据库，此时也已经可以正常打开数据库了。
虽然Oracle数据库可以通过手工建立控制文件的方式来修复控制文件的错误。但是，笔者还是不建议采用这种方式来挽回控制文件损害而造成的损失。笔者建议，最好在数据库部署的时候采用磁盘阵列技术或者控制文件多路复用技术，在提高控制文件的安全性。并且，最好控制文件的日常备份工作，也可以免去手工建立控制文件的麻烦。手工重新建立控制文件只是一种不得已而为知的方法。而且，收集的资料如果不全的话，还可能会造成一些异常的错误。为此，数据库管理员应该尽量避免这种情况的发生。多采取一些预先防治的措施。而不是等到控制文件损坏了再临阵抱佛脚，这是非常不负责任的方法。总之手工创建新的控制文件是一种应急的方法，不可多行