问题描述
恢复了一个重要的生产数据库。数据库由于异常宕机导致故障,重启后无法正常运行,出现ORA-00600 6008错误,数据库Open之后,很快会Crash。6008错误通常出现在索引块上。
专家解答
用户数据库定期做了逻辑备份,但是在这样的时候,并不认可通过逻辑备份的恢复,因为会损失较多数据。值得我们借鉴的是,逻辑备份绝对不能作为唯一的数据库备份手段,这是相当危险的。
Fri Jun 10 17:38:53 2011 SMON: Parallel transaction recovery slave got internal error SMON: Downgrading transaction recovery to serial Fri Jun 10 17:39:13 2011 Errors in file d:\oracle\product\10.2.0\admin\v3x\bdump\v3x_smon_2964.trc: ORA-00600: internal error code, arguments: [6008], [11], [], [], [], [], [], []
以下的提示说明不一致的事务存在于第56号回滚段:
Fri Jun 10 17:39:14 2011 ORACLE Instance v3x (pid = 9) - Error 600 encountered while recovering transaction (56, 3) on object 52045. Fri Jun 10 17:39:14 2011 Errors in file d:\oracle\product\10.2.0\admin\v3x\bdump\v3x_smon_2964.trc: ORA-00600: internal error code, arguments: [6008], [11], [], [], [], [], [], []
以及以下错误:
Sat Jun 11 00:18:48 2011 Errors in file d:\oracle\product\10.2.0\admin\v3x\udump\v3x_ora_6068.trc: ORA-00600: 内部错误代码, 参数: [kddummy_blkchk], [2], [10449], [38508], [], [], [], []
转储回滚段头,发现在56号回滚段的第三个Slot,存在一个活动事务需要回滚:
TRN CTL:: seq: 0x0436 chd: 0x002d ctl: 0x0018 inc: 0x00000000 nfb: 0x0000 mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe) uba: 0x0080787e.0375.0d scn: 0x0000.2098e794 Version: 0x01 FREE BLOCK POOL:: uba: 0x00000000.0375.0c ext: 0x2 spc: 0x19fe uba: 0x00000000.0375.22 ext: 0x2 spc: 0x302 uba: 0x00000000.0372.54 ext: 0x2 spc: 0x39e uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0 uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0 TRN TBL:: index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x061f 0x0020 0x0000.2098f933 0x0080787a 0x0000.000.00000000 0x00000001 0x00000000 1307675689 0x01 9 0x00 0x061f 0x0002 0x0000.20992d29 0x0080787d 0x0000.000.00000000 0x00000001 0x00000000 1307676614 0x02 9 0x00 0x0620 0x000e 0x0000.2099303d 0x0080787d 0x0000.000.00000000 0x00000001 0x00000000 1307676660 0x03 10 0x90 0x061f 0x00c0 0x0000.209940cb 0x0084327c 0x0000.000.00000000 0x0002f50e 0x00000000 0 0x04 9 0x00 0x061f 0x000c 0x0000.209901e1 0x0080787b 0x0000.000.00000000 0x00000001 0x00000000 1307675801 0x05 9 0x00 0x061f 0x000d 0x0000.2098eb0d 0x0080787a 0x0000.000.00000000 0x00000001 0x00000000 1307675434 0x06 9 0x00 0x0620 0x001b 0x0000.20991f2f 0x0080787c 0x0000.000.00000000 0x00000001 0x00000000 1307676159
接下来我们只要暂时屏蔽56号回滚段,就可以暂时阻止事务回滚,正常启动数据库:
_offline_rollback_segments= _SYSSMU56$ _corrupted_rollback_segments= _SYSSMU56$
启动数据库之后,可以删除该回滚段:
SQL> drop rollback segment "_SYSSMU56$";
回退段已删除。
然后可以重建一个新的Undo表空间,切换过去,彻底删除当前的故障表空间,数据库即恢复了正常。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。