ORA-600(ktsfbfmt:objdchk_kcbnew_3)錯誤

客戶的11.2.0.3 RAC環境出現ORA-600[ktsfbfmt:objdchk_kcbnew_3]錯誤。

[@more@]

錯誤資訊為：

Sat May 18 01:37:23 2013
Errors in file /oracle/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j009_13090.trc (incident=1002558):
ORA-00600: 內部錯誤程式碼, 引數: [ktsfbfmt:objdchk_kcbnew_3], [3], [5370496], [0], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_1002558/orcl1_j009_13090_i1002558.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

詳細TRACE資訊如下：

*** 2013-05-18 01:43:46.304
*** SESSION ID:(956.39309) 2013-05-18 01:43:46.304
*** CLIENT ID:() 2013-05-18 01:43:46.304
*** SERVICE NAME:(SYS$USERS) 2013-05-18 01:43:46.304
*** MODULE NAME:(DBMS_SCHEDULER) 2013-05-18 01:43:46.304
*** ACTION NAME:(G_JOB_MON) 2013-05-18 01:43:46.304

Dump continued from file: /oracle/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j009_13090.trc
ORA-00600: 內部錯誤程式碼, 引數: [ktsfbfmt:objdchk_kcbnew_3], [3], [5370496], [0], [], [], [], [], [], [], [], []
ORA-06512: 在 "C_T.T_P_T_M_IN", line 198
ORA-06512: 在 "C_T.P_T_MON", line 3
ORA-06512: 在 line 1

========= Dump for incident 1002559 (ORA 600 [ORA-00600: 內部錯誤程式碼, 引數: [ktsfbfmt:objdchk_kcbnew_3], [3], [5370496], [0], [], [], [], [], [], [], [], []
ORA-06]) ========

*** 2013-05-18 01:43:46.304
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+36 call kgdsdst() 000000000 ? 000000000 ?
7FFF70CA4588 ? 000000001 ?
000000001 ? 000000002 ?
ksedst1()+98 call skdstdst() 000000000 ? 000000000 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
ksedst()+34 call ksedst1() 000000000 ? 000000001 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
dbkedDefDump()+2741 call ksedst() 000000000 ? 000000001 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
ksedmp()+36 call dbkedDefDump() 000000003 ? 000000002 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
ksfdmp()+64 call ksedmp() 000000003 ? 000000002 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
dbgexPhaseII()+1764 call ksfdmp() 000000003 ? 000000002 ?
7FFF70CA4588 ? 000000001 ?
000000000 ? 000000002 ?
dbgexProcessError() call dbgexPhaseII() 2B1258896710 ? 2B1258C4C980 ?
+2675 7FFF70CB0900 ? 000000001 ?
000000000 ? 000000002 ?
dbgeExecuteForError call dbgexProcessError() 2B1258896710 ? 2B1258C4C980 ?
()+83 000000001 ? 000000000 ?
100000000 ? 000000002 ?
dbgePostErrorKGE()+ call dbgeExecuteForError 2B1258896710 ? 2B1258C4C980 ?
2138 () 000000001 ? 000000001 ?
000000000 ? 000000002 ?
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 00BAF3FA0 ? 2B1258E7B7F8 ?
66 000000258 ? 2B1258C4C980 ?
100000000 ? 000000002 ?
kgeade()+351 call dbkePostKGE_kgsf() 00BAF3FA0 ? 2B1258E7B7F8 ?
000000258 ? 2B1258C4C980 ?
100000000 ? 000000002 ?
kgereml()+83 call kgeade() 00BAF3FA0 ? 00BAF4150 ?
2B1258E7B7F8 ? 000000258 ?
100000000 ? 000000002 ?
jslvGetOCIError()+3 call kgereml() 00BAF3FA0 ? 2B1258E7B7F8 ?
31 000000258 ? 000000000 ?
100000000 ? 000000002 ?
jslvec_execcb()+226 call jslvGetOCIError() 00BAF3FA0 ? 2B1258E7B7F8 ?
8 000000258 ? 000000000 ?
100000000 ? 000000002 ?
jslvswu()+56 call jslvec_execcb() 7FFF70CB2EAC ? 2B1258E7B7F8 ?
2B1258D0D8D8 ? 000000000 ?
100000000 ? 000000002 ?
jslve_execute0()+22 call jslvswu() 000000053 ? 100000000 ?
48 000000002 ? 000000000 ?
100000000 ? 000000002 ?
jslve_execute()+327 call jslve_execute0() 7FFF70CB4DC4 ? 0000955DF ?
000000002 ? 7FFF70CB4DB0 ?
000000000 ? 28FFFFFFFF ?
rpiswu2()+1618 call jslve_execute() 7FFF70CB4C60 ? 000000002 ?
7FFF70CB4DC4 ? 0000955DF ?
7FFF70CB4DB0 ? 28FFFFFFFF ?
kkjex1e()+374 call rpiswu2() 7142C06C08 ? 000000000 ?
7FFF70CB4C80 ? 000000002 ?
7FFF70CB4CA0 ? 000000000 ?
kkjsexe()+706 call kkjex1e() 7FFF70CB4DC4 ? 0000955DF ?
000000002 ? 7FFF70CB4DB0 ?
723E996390 ? 7FFF70CB4D18 ?
kkjrdp()+689 call kkjsexe() 7FFF70CB4DC4 ? 0000955DF ?
000000002 ? 7FFF70CB4DB0 ?
723E996390 ? 7FFF70CB4D18 ?
opirip()+953 call kkjrdp() 7FFF70CB4DC4 ? 0000955DF ?
000000002 ? 7FFF70CB4DB0 ?
723E996390 ? 7FFF70CB4D18 ?
opidrv()+598 call opirip() 000000032 ? 000000004 ?
7FFF70CB6538 ? 7FFF70CB4DB0 ?
723E996390 ? 7FFF70CB4D18 ?
sou2o()+98 call opidrv() 000000032 ? 000000004 ?
7FFF70CB6538 ? 7FFF70CB4DB0 ?
723E996390 ? 7FFF70CB4D18 ?
opimai_real()+261 call sou2o() 7FFF70CB6510 ? 000000032 ?
000000004 ? 7FFF70CB6538 ?
723E996390 ? 7FFF70CB4D18 ?
ssthrdmain()+252 call opimai_real() 000000000 ? 7FFF70CB6700 ?
000000004 ? 7FFF70CB6538 ?
723E996390 ? 7FFF70CB4D18 ?
main()+196 call ssthrdmain() 000000003 ? 7FFF70CB6700 ?
000000001 ? 000000000 ?
723E996390 ? 7FFF70CB4D18 ?
__libc_start_main() call main() 000000003 ? 7FFF70CB68A0 ?
+244 000000001 ? 000000000 ?
723E996390 ? 7FFF70CB4D18 ?
_start()+36 call __libc_start_main() 000A0AF38 ? 000000001 ?
7FFF70CB6898 ? 000000000 ?
723E996390 ? 000000003 ?

--------------------- Binary Stack Dump ---------------------

根據MOS文件，關於這個ORA-600錯誤的已知bug只有Bug 12540788 - ORA-600 [ktsfbfmt:objdchk_kcbnew_3] / memory corruption fetching across commit from a TEMPORARY table [ID 12540788.8]，而客戶的環境中確實大量的使用臨時表，尤其是透過JOB進行批處理計算的時候。

唯一的疑點是，當前的資料庫版本就是11.2.0.3，而這個錯誤影響的版本是11.2.0.2，在11.2.0.3中應該被修復。這已經是最近碰到的第三個疑似在11.2.0.3上修復的bug再次重現了。