ORA-00600: internal error code, arguments: [3020], [21], [803053]

yiyufeng1986

数据库版本：10.2.0.2.0
alert日志：
Errors in file /oracle/admin/phonecrm/bdump/phonecrm_p002_14395.trc:
ORA-00600: internal error code, arguments: [3020], [21], [803053], [88883437], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 21, block# 803053)
ORA-10564: tablespace PHONECRM
ORA-01110: data file 21: '/oracle/oradata/phonecrm/phonecrm05.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 51546
Tue Aug  7 14:51:07 2012

trace记录：
在附件中

[ 本帖最后由 yiyufeng1986 于 2012-8-7 20:30 编辑 ]

yiyufeng1986

忘了说了，之前已经遇到过2次了。都是采取重做备库的方式。但是没几天又报错了。

Maclean Liu(刘相兵

ODM FINDING:

Linux+ 10.2.0.2.0

KCOX_FUTURE: CHANGE IN FUTURE OF BLOCK
*** 2012-08-07 14:51:07.329
RECOVERY STUCK AT BLOCK 803053 OF FILE 21
Redo record scn: 0x0012.93f96aab
CHANGE #1 TYP:0 CLS: 1 AFN:21 DBA:0x054c40ed OBJ:4294967294 SCN:0x0012.93f96aab SEQ:  1 OP:10.4
buffer tsn: 6 rdba: 0x054c40ed (21/803053)
scn: 0x0012.85d7171e seq: 0x03 flg: 0x04 tail: 0x171e0603
frmt: 0x02 chkval: 0x323e type: 0x06=trans data
Dumping log files for redo thread# 0
Dumped 0 log files for redo thread# 0
Dumping log files for redo thread# 1
Dumping archive log file /oracle/arch_dest/xxxxxxxx/1_238665_665082036.dbf for redo thread# 1

DUMP OF REDO FROM FILE '/oracle/arch_dest/xxxxxxxx/1_238665_665082036.dbf'
Opcodes *.*
DBAs (file#, block#):
      (21, 803053)
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff


Dumped 1 log files for redo thread# 1
*** 2012-08-07 14:51:07.457
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [3020], [21], [803053], [88883437], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 21, block# 803053)
ORA-10564: tablespace xxxxxxxx
ORA-01110: data file 21: '/oracle/oradata/xxxxxxxx/phonecrm05.dbf'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 51546
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFF7F642A0 ? 7FFFF7F64300 ?
                                                   7FFFF7F64240 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFFF7F642A0 ? 7FFFF7F64300 ?
                                                   7FFFF7F64240 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFFF7F642A0 ? 7FFFF7F64300 ?
                                                   7FFFF7F64240 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFFF7F642A0 ? 7FFFF7F64300 ?
                                                   7FFFF7F64240 ? 000000000 ?
kgesiv()+119         call     kgeriv()             0064FE740 ? 00FD2B6D0 ?
                                                   000000000 ? 000000000 ?
                                                   7FFFF7F64240 ? 000000000 ?
ksesic3()+215        call     kgesiv()             0064FE740 ? 00FD2B6D0 ?
                                                   000000BCC ? 000000003 ?
                                                   7FFFF7F65020 ? 000000000 ?
kcbr_mapply_change(  call     ksesic3()            000000BCC ? 000000000 ?
)+2514                                             000000015 ? 000000000 ?
                                                   0000C40ED ? 000000000 ?
kcbrapply()+1502     call     kcbr_mapply_change(  0C157DEE8 ? 06DF84B18 ?
                              )                    2000000000000014 ?
                                                   0054C40ED ? 0C02AD538 ?
                                                   0C02AD538 ?
kcbr_apply_pending(  call     kcbrapply()          0BF96ED18 ? 06DF84B18 ?
)+1063                                             00162AC50 ? 2B2965871228 ?
                                                   00FD2E4F0 ? 7FFFF7F653C0 ?
kcbr_media_apply()+  call     kcbr_apply_pending(  000000000 ? 00FD2E4F0 ?
1513                          )                    000000000 ? 2B2965871228 ?
                                                   00FD2E4F0 ? 7FFFF7F653C0 ?
kcrpap()+1555        call     kcbr_media_apply()   2B29655CDBA8 ? 000000078 ?
                                                   7FFFF7F65A68 ? 000000000 ?
                                                   00FD2E4F0 ? 000000000 ?
kcrpdv()+1400        call     kcrpap()             00FD2E3C0 ? 000000000 ?
                                                   2B29655CDBA8 ? 000000078 ?
                                                   000000000 ? 000000000 ?
Cannot find symbol
Cannot find symbol
Cannot find symbol
kxfprdp()+1186       call     kcrpdv()             00FD2E3C0 ? 000000000 ?
                                                   0BF96ED18 ? 000000078 ?
                                                   000000000 ? 000000000 ?
opirip()+743         call     kxfprdp()            00FD2E3C0 ? 000000000 ?
                                                   0BF96ED18 ? 000000000 ?
                                                   000000000 ? 000000000 ?
opidrv()+582         call     opirip()             000000032 ? 000000004 ?
                                                   7FFFF7F66CB8 ? 000000000 ?
                                                   000000000 ? 000000000 ?
sou2o()+114          call     opidrv()             000000032 ? 000000004 ?
                                                   7FFFF7F66CB8 ? 000000000 ?
                                                   000000000 ? 000000000 ?
opimai_real()+317    call     sou2o()              7FFFF7F66C90 ? 000000032 ?
                                                   000000004 ? 7FFFF7F66CB8 ?


ORA-10567 + ORA-00600: [3020]

data object# 51546  file# 21, block# 803053

Maclean Liu(刘相兵

针对该问题

建议：

workaroud:

1. 重启 standby 实例 继续观察           restart the standby DB,  
2. 将 file# 21, 从primary  端拷贝到standby 取代原standby 上的数据文件 copy the data file to standby to bypass the redo applying
3. 对file# 21做一个dbv检查

yiyufeng1986

我试了一下，还是按照刘大给的建议中的第二步操作后，能顺利恢复下去。谢谢~