白手起家,重建Oracle控制文件

    半夜11:30分,接了个电话,说是有关部门的Oracle挂了,无法登录.其实与我没什么关系,因为我不负责有关部门的Oracle数据库.出于好奇心,我过去看了下,是Oracle9的库,shutdown immediate后,再startup,报告说是CONTROL01.CTL和CONTROL03.CTL的版本不符合,因此pending(挂起)在那里了.简单的说,控制文件挂了.

    因为有关部门没有DBA,所以冷备份什么的就不找他们要了,肯定是没有滴.令人大吃一斤(大吃一惊)的是,他们的软件设计了导出dmp文件的功能,因此数据备份(*.dmp)倒是有.不过,在本案例里,用不上啊.-_-.

    由于以前我也没遇到过控制文件损坏的情况,所以也只有去google了.不过,可以肯定的是,问题不严重,毕竟数据文件健在.去网上找了一圈,明白了:原来在一个Oracle的数据库里,默认会有3个控制文件,一般就是CONTROL01.CTL、CONTROL02.CTL和CONTROL03.CTL了.将数据库shutdown后,用MD5工具效验,在正常的数据库上,会发现3个文件的MD5值居然是一样的,也就是说,这三个控制文件是一模一样的.可能是Oracle出于容灾的考虑,设计了3个相同的控制文件.到这里问题一下明朗了.保护现场,将Oracle数据库shutdown,再把目前的数据库冷备份一下,也就是把ordata/orcl目录里的所有东东复制到其他地方去.把那个与众不同的MD5值的控制文件KO掉,从剩下的两个MD5值相同的文件里随便找个来Copy一下就行了.

    烂文章到这里似乎就该结束了,但是,如果3个控制文件都挂掉了,该怎么办?再去google一下,原来通过这样的语句可以凭空重建控制文件.也所谓白手起家了.
create   controlfile   reuse   database   orcl   noresetlogs   archivelog
maxdatafiles 50 
Logfile  
  group   1   'H:/oradata/orcl/redo01.log',  
  group   2   'H:/oradata/orcl/redo02.log',  
  group   3   'H:/oradata/orcl/redo03.log'  
datafile  
'H:/oradata/orcl/system01.dbf',  
'H:/oradata/orcl/rbs01.dbf',  
'H:/oradata/orcl/users01.dbf',  
'H:/oradata/orcl/temp01.dbf',  
'H:/oradata/orcl/tools01.dbf',  
'H:/oradata/orcl/indx01.dbf',  
'H:/oradata/orcl/dr01.dbf'
CHARACTER SET US7ASCII;
    这里,如果你的数据文件(*.dbf) 超过了32个,那就需要明确指出maxdatafiles参数了,否则会创建失败.后面的结构就很简单了,指定日志文件logfile和数据文件datafile的位置即可,有特殊需要的可以设置字符集,不然最好还是别写character set US7ASCII这行.注意最后以分号结束.在maxdatafiles那里还有些其他参数,但似乎用不到.具体的操作是,先关闭数据库,再启动到nomount状态,然后执行上面蓝色的语句.

SQL> shutdown immediate;
SQL>startup nomount;

ORACLE instance started.
Total System Global Area  237856796 bytes    (不要嘲笑SGA小,俺的本本,装的工业机的库)
Fixed Size                    75804 bytes
Variable Size              80416768 bytes
Database Buffers          157286400 bytes
Redo Buffers                  77824 bytes
SQL>(把上文蓝色的语句粘过来-_-)
SQL>alter database mount; (这里应该不需要mount,因为控制文件创建后,库就已经mount了,如果意外没有mount的,可以执行下此语句)
Database altered.
SQL>alter database open resetlogs;
Database altered.

    到这里控制文件重建完成,但有的时候可能还有其他问题,在我们尝试打开数据库时,有的倒霉蛋可能会遇到Oracle提示需要进行介质恢复.我第一次在自己本本上试遇到了,第二次没遇到.-_-.在这里,不确定介质恢复是否真的需要归档日志(*.arc文件),但愿上帝保佑你的工业机Oracle开启了归档日志.

    介质恢复,如果数据库没有mount(挂载),可以直接执行recover datafile 'h:/oradata/orcl/system01.dbf';这种语句.如果mount了,就需要先将dbf文件下线,再恢复,再上线.语句如下:
alter database datafile 'h:/oradata/orcl/xxxx.dbf' offline;
recover datafile 'h:/oradata/orcl/system01.dbf';
alter database datafile 'h:/oradata/orcl/xxxx.dbf' online;

    在本文的情况下,数据库应该是没有mount起来的,直接恢复就可以了.system01.dbf应该是不能offline的.如果嫌一个文件一个文件的恢复麻烦,也有必杀技可用.

SQL>recover database until cancel;
    数据库尝试打开,ok,小功告成.

    数据库起来后,如果对生成控制文件的其他参数还有兴趣,可以执行alter database backup controlfile to trace;备份控制文件.然后到我的e:/oracle/admin/orcl/udump下可找到最新生成的TRACE文件.比如ORA03924.TRC.打开它,就可以看到本文没有介绍的稀罕的参数了.

    试验环境:Oracle8.1.7.4+winXP 32bit professional.有关部门的环境是Oracle9.2.0.1.0的,在本案中,恢复控制文件后,还遇到了ora-00600和ora-00607错误,这是由undotbs1表空间损坏引起的,但不在本文讨论范围内,需要的可以参考创建undo表空间的相关资料,或者我的这篇文章《控制文件损坏后，遭遇ora-00607错误(undo表空间错误)》http://blog.csdn.net/squallleonheart/archive/2011/01/26/6165524.aspx

    控制文件恢复的烂文章到此真正结束.