记录一个意外断电导致控制文件损坏的case

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE  昨天早上省厅有同事说备装科用的oracle数据库不能访问了,需要这边看看,我就远程过去是在windows32位机器上安装的,以下记录恢复步骤：

 

          1. sqlplus进去,查看实例的状态为started, 执行alter database open,报错：ORA-00600: ??????, ??: [kccpb_sanity_check_2], [170630], [170629], [0x0], [], [], [], []

 

          2. 经了解此机器经常被硬重启,数据库无人做维护,近期做备装软件的公司对此数据库做过升级,我判断为控制文件在数据库没有关闭的情况下被破坏。

         

          3. 备份了下控制文件,通过trace找到创建控制文件的脚本,在mount状态重建了控制文件,此时open数据库报错ORA-01113:数据文件1需要介质恢复 ORA-01110:system01.dbf,

             执行recover database until cancel，数据库完成介质恢复,alter database open resetlogs报错：ORA-01092：oracle实例终止。强制断开连接

        

          4.查看数据库警告日志文件报如下错误：

Errors in file d:\oracle\product\10.2.0\admin\bzdb\udump\bzdb_ora_5008.trc:

ORA-00704: 引导程序进程失败

ORA-39700: 必须用 UPGRADE 选项打开数据库

 

Mon May 23 16:53:06  2011

Error 704 happened during db open, shutting down database

USER: terminating instance due to error 704

Instance terminated by USER, pid = 5008

ORA-1092 signalled during: alter database open...

 

                   

          5.按照提示执行startup  upgrade报错ORA-00600 [kddummy_blkchk] 。此时修改db_block_checksum 和 db_block_checking为false,然后执行

 

         alter system set event='10513 trace name context forever,level 2'scope=spfile;  使用10513来进一步阻止数据库打开后smon进程的事务恢复。

        再次尝试startup upgrade报错：ORA-600[4193], 可以肯定undo和redo不一致造成。 把undo_management的参数改成manual,然后startup upgrade

        数据库正常open！

数据库起来后并不能被其他用户访问,因为此时数据库状态为migrate,所以必须执行升级的脚本,shutdown数据库在startup正常启动后才可以. 即：

SQL>@D:\oracle\product\10.2.0\db_1\rdbms\admin\catupgrd.sql

SQL>@D:\oracle\product\10.2.0\db_1\rdbms\admin\catalog.sql

SQL>@D:\oracle\product\10.2.0\db_1\rdbms\admin\catproc.sql

SQL>shutdown immediate

SQL>startup

数据库启动成功

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22878696/viewspace-696127/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22878696/viewspace-696127/