问题描述
某客户的数据库出现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之后的恢复,搞不好就会恢复的很艰苦,而事实上,很多情况下都还是有办法可想的,启动数据库并不会太困难。