记一次redo损坏导致ora-600[4000]的恢复

据说今天是光棍节,逢年过节,必有大事。快下班的时候,一位朋友碰到了一个大问题,数据库服务器异常断电重启以后,数据库无法启动,报ora-600[4000]错误,尝试了使用隐藏参数,还是无法打开。

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []

ora-600内部错误的类型可以看到,4000是trasaction undo相关的内部错误。搜索一下可以发现,logzgh同学已经两次碰到过该问题了(第一次第二次)。看来在异常宕机的情况下,这个问题出现的机率还是比较高的。既然是有先例的,恢复起来应该是没有问题的,这个案例和logzgh的第一个案例基本一样,trace文件里显示也是obj$上有异常事务:

ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1

将trace文件往下翻,可以看到出现问题的block的dump信息,在block的itl中果然有一条活动事务存在。用bbed找到对应块,设置offset到61,将itl的flag从20改为80,重新计算block的checksum并apply。然后尝试重新启动数据库,这次ora-600[4000]错误没有了,报的是ora-600[2662]错误,数据库无法open。2662就比较容易了,网上相关的处理案例已经一大堆了,将数据库启动到mount状态,设置10015事件来调整scn即可

alter session set events '10015 trace name adjust_scn level 1';

如果数据库已经处于open状态,则可以使用如下语句来调整SCN:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';

再次重新打开库,报ora-600[2256],继续使用10015事件,这次level设置为(ora-600错误的第三个参数+1)*4

alter session set event '10015 trace name adjust_scn level 20';

重启,报ora-600[4097]错误,好了,现在基本上恢复已经接近尾声了,使用下面几个隐藏参数,可以正常将数据库打开了。接下来就是告诉朋友做全库export/重建库/import了。

_allow_resetlogs_corruption=true
_allow_terminal_recovery_corruption=true
_corrupted_rollback_segments=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$,
 _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

年关将近,事故高发时期,阿弥陀佛,多求个平安吧。话说这个案例还没来得及些写呢,晚上回家的路上又接到说有人truncate了一张表。。。

无觅相关文章插件,快速提升流量