ORA-600 kcbzpbuf_1 坏块的恢复案例一则

昨晚，某客户的数据库出现ORA-600错误，数据库无法启动：

Tue Jan 12 17:49:02 2010
Errors in file /db/oracle/app/oracle/diag/rdbms/eygle/eygle/trace/eygle_dbw0_9450.trc  (incident=240166):
ORA-00600: internal error code, arguments: [kcbzpbuf_1], [4], [1], [], [], [], [], []

这里的错误代码kcbzpbuf，猜测是Kenerl Cache Buffer上的验证错误。应当是在应用Redo前滚时在Buffer中校验数据时出了问题。

这是一个Oracle 11g 的环境：

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /db/oracle/app/oracle/product/11.1.0.6
System name:    SunOS

这个错误之前，会给出一个坏块提示：

Hex dump of (file 13, block 3603328) in trace file /db/oracle/app/oracle/diag/rdbms/eygle/eygle/trace/eygle_dbw0_9450.trc
Corrupt block relative dba: 0x0376fb80 (file 13, block 3603328)
Bad header found during preparing block for write
Data in bad block:
 type: 211 format: 0 rdba: 0xcbbe16d6
 last change scn: 0x0000.f14443ff seq: 0x4 flg: 0xa0
 spare1: 0xb9 spare2: 0xab spare3: 0xeedb
 consistency value in tail: 0x43ffd304
 check value in block header: 0x0
 block checksum disabled
Completed redo application

提示指出文件13，数据块3603328出现损坏，损坏出现在during preparing block for write，也就是说，在数据库进行前滚恢复时，准备写一个数据块时发现了块损坏。
那么具体是什么损坏呢？看一下跟踪文件可以发现一些端倪：

BH (0x404ff6368) file#: 13 rdba: 0x0376fb80 (13/3603328) class: 1 ba: 0x404f2e000
  set: 20 bsz: 8192 bsi: 0 sflg: 2 pwc: 0 lid: 0x00000000,0x00000000
  dbwrid: 1 obj: -1 objn: -1 tsn: 8 afn: 13
  hash: [0x43a60f538,0x43a60f538] lru-req: [0x4389f3028,0x4389f3028]
  lru-flags: on_auxiliary_list
  ckptq: [0x43aa90200,0x43aa90200] fileq: [NULL] objq: [NULL]
  st: INST_RCV md: NULL rsop: 0x43aa90158
  flags: buffer_dirty being_written block_written_once recovery_read_complete
  cr pin refcnt: 0 sh pin refcnt: 0
  buffer tsn: 8 rdba: 0xcbbe16d6 (814/4069078)
  scn: 0x0000.f14443ff seq: 0x04 flg: 0xa0 tail: 0x43ffd304
  frmt: 0x00 chkval: 0x0000 type: 0xd3=unknown

注意这个BH（Buffer Header）信息，这个Header上出现了不一致，BH头上记录的rdba是0x0376fb80 (13/3603328)，而内部是rdba: 0xcbbe16d6 (814/4069078)，这种情况是不应该出现的，数据库里也没有814号文件。

这也许就是坏块出现的原因，由于这是一个逻辑损坏，同样被传递到了备库上，DataGuard的备库出现同样的问题。
当时没有过多时间去研究这个问题。

急于帮客户恢复了这个数据库，使用几个常用的隐含参数，屏蔽了这个事务，启动了数据库。
注意在告警日志中，可以找到存在问题的事务及对象信息：

Tue Jan 12 18:54:28 2010
Checker run found 1 new persistent data failures
SMON: Restarting fast_start parallel rollback
SMON: ignoring slave err,downgrading to serial rollback
ORACLE Instance ora234 (pid = 13) -
Error 376 encountered while recovering transaction (9, 30) on object 84358.

这个信息可以帮助我们判断出问题的对象，以决定重要与否。这个信息说明在回滚段9，事务槽30上存在一个未提交事务，恢复遇到障碍。转储这个回滚段头可以找到这个事务信息：

  TRN TBL::
  index  state cflags  wrap#    uel         scn            dba     
  ------------------------------------------------------------------
   0x00    9    0x00  0x73bd0  0x0005  0x0000.f13fee10  0x00ceb65a  1263286870
   0x01    9    0x00  0x78712  0x0019  0x0000.f1404c83  0x00000000  1263286910
   0x02    9    0x00  0x7961f  0x0006  0x0000.f13ff374  0x00ceb6bd  1263286871
   0x03    9    0x00  0x7964c  0x0017  0x0000.f13ff100  0x00ceb691  1263286870
   0x04    9    0x00  0x74788  0x001d  0x0000.f1404c7f  0x00000000  1263286910
   0x05    9    0x00  0x79410  0x000e  0x0000.f13fee1f  0x00ceb65d  1263286870
   0x06    9    0x00  0x7938c  0x0016  0x0000.f13ff4f2  0x00ceb6d5  1263286871
   0x07    9    0x00  0x795f6  0x0013  0x0000.f1404c7d  0x00000000  1263286910
   0x08    9    0x00  0x79279  0x0014  0x0000.f1404c6f  0x00000000  1263286910
   0x09    9    0x00  0x7399b  0x001c  0x0000.f1404c77  0x00000000  1263286910
   0x0a    9    0x00  0x79614  0x0021  0x0000.f1404c73  0x00000000  1263286910
   0x0b    9    0x00  0x79600  0xffff  0x0000.f1451114  0x00000000  1263305722
   0x0c    9    0x00  0x79518  0x0010  0x0000.f13ff7cc  0x00ceb70a  1263286871
   0x0d    9    0x00  0x74fe6  0x001b  0x0000.f144f6fc  0x00000000  1263295042
   0x0e    9    0x00  0x79535  0x0003  0x0000.f13fef7a  0x00ceb675  1263286870
   0x0f    9    0x00  0x78d53  0x0002  0x0000.f13ff216  0x00ceb6a8  1263286870
   0x10    9    0x00  0x73356  0x0011  0x0000.f13ff87f  0x00ceb718  1263286871
   0x11    9    0x00  0x79643  0x0008  0x0000.f1400b25  0x00cebefa  1263286900
   0x12    9    0x00  0x795b7  0x0000  0x0000.f13fecdb  0x00ceb644  1263286869
   0x13    9    0x00  0x78fbf  0x0004  0x0000.f1404c7e  0x00000000  1263286910
   0x14    9    0x00  0x79296  0x000a  0x0000.f1404c72  0x00000000  1263286910
   0x15    9    0x00  0x78c4a  0x0020  0x0000.f1404c7a  0x00000000  1263286910
   0x16    9    0x00  0x79383  0x001f  0x0000.f13ff532  0x00ceb6dc  1263286871
   0x17    9    0x00  0x79223  0x0018  0x0000.f13ff113  0x00ceb694  1263286870
   0x18    9    0x00  0x79310  0x000f  0x0000.f13ff1c8  0x00ceb6a2  1263286870
   0x19    9    0x00  0x78e6f  0x000d  0x0000.f1449dcd  0x00000000  1263293675
   0x1a    9    0x00  0x7962c  0x0009  0x0000.f1404c75  0x00000000  1263286910
   0x1b    9    0x00  0x79211  0x000b  0x0000.f1450fb9  0x00000000  1263305662
   0x1c    9    0x00  0x79648  0x0015  0x0000.f1404c78  0x00000000  1263286910
   0x1d    9    0x00  0x7957d  0x0001  0x0000.f1404c82  0x00000000  1263286910
   0x1e   10    0x90  0x7890b  0x0020  0x0000.f1400b26  0x00c7ef4d  0
   0x1f    9    0x00  0x7964e  0x000c  0x0000.f13ff5b2  0x00ceb6e7  1263286871
   0x20    9    0x00  0x79274  0x0007  0x0000.f1404c7b  0x00000000  1263286910
   0x21    9    0x00  0x79625  0x001a  0x0000.f1404c74  0x00000000  1263286910

明确了所有的细节之后，处理起来就有底了。
标记回滚段为损坏，防止其回滚可以使用隐含参数：_corrupted_rollback_segments ，具体参考以前的文章：
http://www.eygle.com/archives/2006/02/howto_resolve_ora_600_4194.html

在现场遇到了blue_stone同学，这是意外的收获，在越来越多的场合可以遇到ITPUB里熟悉的ID，这是网络生活给我们的馈赠与惊喜。blue_stone准备好了DUL，准备在最坏的情况下进行数据抽取。而我现在越来越少使用DUL、AUL、ODUL了，因为一遇到这样的恢复就会抵触，特别是在失去SYSTEM之后的恢复，搞不好就会恢复的很艰苦，而事实上，很多情况下都还是有办法可想的，启动数据库并不会太困难。

今天理了一下细节，权作记录，供参考。

-The End-