Oracle 11gR2 for Windows遭遇ora-600[4194]的恢复案例

某客户的数据库出现异常,非归档环境。Instance crash之后正常open,然而数据库很快就crash 掉。我们来简单分析一下:

上面的错误对于大家来讲或许并不陌生,ora-00600 [4194]是一个非常常见的错误。然而,细心的人或许注意到了,
这里有一点不同的是:[4194]后面的2位都是空的。

对于ora-00600 [4194] 错误,Oracle MOS文档有个标准的解释,如下:

简单的讲,就是Oracle SMON进程在进程事务rollback时,发现redo block中对应的undo record 编号和
undo block中的undo record 编号不一致,进而导致事务无法进行正常回滚,最后抛出这个错误。

我们来看下smon 进程的trace,里面提到了异常的事务信息:

UBA应该是:0x00c000e9.0x12bf.0x25,即:0x00c000e9.12bf.25,这里的XID为:xid:  0x0006.010.000033dd

说明是第对应的第16个事务槽(SLOT:0x10). record 编号为0x25。 opcode为5.7,标示Begin transaction (transaction table update)
那么我们定位到这个record(0x25),来看看undo block的实际dump是什么:

我们可以看到该事务(0x10)回滚到0x25就结束了,因为rci值为0,说明这里就是结束的位置。 大家注意看这里的opcode代码,layer为11,opc为1.
那么也就是说undo block这个record实际上的opcode为:11.1.

大家应该都知道11.1标示什么?  11.1 标示:Interpret Undo Record (Undo)。同时看下面的信息也可以知道这里应该是进行了update操作。(URP)。

因此,很明显redo和undo block(file 3 block 233)的信息是不一致的。
上面的信息不够完整,下面我将recover失败的block(file 3 block 233)的信息贴出来:

我们可以看到,最新的一个事务事务XID为:0x0006.002.000033d9。seq为seq: 0x12bf 整个undo block 一共包含cnt: 0x3b(即59)个undo record记录;其中 irb: 0x3b 标示最新的一个事务
如果进行rollback,那么第0x3b的事务将是rollback的起点。

那么一个事务进行rollback,到什么时候结束呢? 当对应的rci值为0时,即表示结束。很明显,最新的事务的SLOT为0x002。而出问题的事务的slot是0x010(转换为10进制为16)。

当然,最后要处理这个case是比较容易的,通过屏蔽第6号回滚段即可,这里不在累述。

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注