Oracle数据恢复:6008 及事务回滚错误恢复

近日，帮助某用户恢复了一个重要的生产数据库。数据库由于异常宕机导致故障，重启后无法正常运行，出现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表空间，切换过去，彻底删除当前的故障表空间，数据库即恢复了正常。