記一次ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []

qqmengxue發表於2010-12-31

環境介紹:

ORACLE10R2 64BIT

REDHAT 5.4。 64BIT

ERROR:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []

[@more@]

Fri Dec 31 17:48:36 2010
Errors in file /u01/app/oracle/admin/szpadb1/bdump/szpadb1_p013_13738.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []
Fri Dec 31 17:48:45 2010
Errors in file /u01/app/oracle/admin/szpadb1/bdump/szpadb1_p014_13740.trc:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], []
Fri Dec 31 17:48:53 2010
SMON: Parallel transaction recovery slave got internal error
SMON: Downgrading transaction recovery to serial
Fri Dec 31 17:51:13 2010

/u01/app/oracle/admin/szpadb1/bdump/szpadb1_p013_13738.trc:

/u01/app/oracle/admin/szpadb1/bdump/szpadb1_p013_13738.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: szpa-bak-db2
Release: 2.6.18-53.el5xen
Version: #1 SMP Wed Oct 10 16:48:44 EDT 2007
Machine: x86_64
Instance name: szpadb1
Redo thread mounted by this instance: 1
Oracle process number: 39
Unix process pid: 13738, image: (P013)

*** 2010-12-31 17:42:24.626
*** SERVICE NAME:(SYS$BACKGROUND) 2010-12-31 17:42:24.356
*** SESSION ID:(113.84) 2010-12-31 17:42:24.356
Parallel Transaction recovery server caught exception 10388
*** 2010-12-31 17:46:24.711
*** SERVICE NAME:(SYS$BACKGROUND) 2010-12-31 17:46:24.711
*** SESSION ID:(108.39) 2010-12-31 17:46:24.711
Parallel Transaction recovery server caught exception 10388
*** 2010-12-31 17:48:33.575
*** SERVICE NAME:(SYS$BACKGROUND) 2010-12-31 17:48:33.575
*** SESSION ID:(100.309) 2010-12-31 17:48:33.575
*** SESSION ID:(100.309) 2010-12-31 17:48:33.575
OBJD MISMATCH typ=32, seg.obj=-2, diskobj=55694, dsflg=4, dsobj=55220, tid=55220, cls=8Input data (nil), 0, 0
Formatted dump of block:
buffer tsn: 6 rdba: 0x0143fc0b (5/261131)
scn: 0x0a4e.dcffd6ff seq: 0x02 flg: 0x04 tail: 0xd6ff2002
frmt: 0x02 chkval: 0x9a40 type: 0x20=FIRST LEVEL BITMAP BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000001E40D6000 to 0x00000001E40D8000

diskobj 是物件的data object id

dsobj 是object id

根據objectid來查詢:

SQL> select t.object_id,t.data_object_id from dba_objects t where t.object_id = 55220;

OBJECT_ID DATA_OBJECT_ID
---------- --------------
55220 55697

SQL>

可以發現這個物件的data_object_id已經變了,而又由於此時PMON程式正在對這個表的資料進行事物的回滾操作,當PMON根據以上資訊檢查物件是發現物件不存在,於是就丟擲了以上錯誤。

透過排查,原來有人在操作這個55220做事物處理的時候,由於事物異常終止,就做了對這個表的truncate操作,而又由於事物DEAD後,後臺的PMON程式還需要對已經DEAD的事物進行回滾操作,於是就報了以上的錯誤。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10130206/viewspace-1043943/,如需轉載,請註明出處,否則將追究法律責任。

相關文章