问题描述
客户的11.2.0.3 RAC环境出现ORA-600[ktsfbfmt:objdchk_kcbnew_3]错误。
错误信息为：
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再次重现了。
最后修改时间：2019-04-14 10:53:40
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
