客户的11.2的DATA GUARD数据库出现了这个错误。
一般DATA GUARD数据库出现错误的可能性不大，而ORA-600错误的可能性就更小了，而且一旦出现，多半意味着DATA GUARD环境损坏，轻则需要恢复，重则需要重建。
不过这个错误并没有那么大危害：
Fri Sep 16 17:57:13 2011 Errors IN file /u01/app/oracle/diag/rdbms/ora190/ora190/trace/ora190_ora_18743334.trc (incident=288185): ORA-00600: 内部错误代码, 参数: [4415], [], [], [], [], [], [], [], [], [], [], [] Incident details IN: /u01/app/oracle/diag/rdbms/ora190/ora190/incident/incdir_288185/ora190_ora_18743334_i288185.trc USE ADRCI OR Support Workbench TO package the incident. See Note 411.1 at My Oracle Support FOR error AND packaging details. System State dumped TO trace file /u01/app/oracle/diag/rdbms/ora190/ora190/incident/incdir_288185/ora190_ora_18743334_i288185.trc Errors IN file /u01/app/oracle/diag/rdbms/ora190/ora190/trace/ora190_ora_18743334.trc (incident=288186): ORA-00603: ORACLE 服务器会话因致命错误而终止 ORA-00600: 内部错误代码, 参数: [4415], [], [], [], [], [], [], [], [], [], [], [] Incident details IN: /u01/app/oracle/diag/rdbms/ora190/ora190/incident/incdir_288186/ora190_ora_18743334_i288186.trc Fri Sep 16 17:57:20 2011 Dumping diagnostic DATA IN directory=[cdmp_20110916175720], requested BY (instance=1, osid=18743334), summary=[incident=288185]. Fri Sep 16 17:57:21 2011 Sweep [inc][288186]: completed Sweep [inc][288185]: completed Sweep [inc2][288185]: completed opiodr aborting process UNKNOWN ospid (18743334) AS a RESULT OF ORA-603 |
查询metalink，发现导致问题的原因是对只读打开的STANDBY数据库执行了COMMIT操作，详细内容可以参考ID 9531380.8，这个Bug 9531380在11.2.0.3中将被解决。
查询详细信息，验证是否由于这个问题所致：
bash-3.2$ more incident/incdir_288186/ora1_ora_18743334_i288186.trc Dump file /u01/app/oracle/diag/rdbms/ora1/ora1/incident/incdir_288186/ora1_ora_18743334_i288186.trc Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production WITH the Partitioning, Automatic Storage Management, OLAP, DATA Mining AND REAL Application Testing options ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1 System name: AIX Node name: node1 Release: 1 Version: 6 Machine: 00F6D0DF4C00 Instance name: ora1 Redo thread mounted BY this instance: 1 Oracle process NUMBER: 23 Unix process pid: 18743334, image: oracle@node1 *** 2011-09-16 17:57:20.043 *** SESSION ID:(1634.93) 2011-09-16 17:57:20.043 *** CLIENT ID:() 2011-09-16 17:57:20.043 *** SERVICE NAME:() 2011-09-16 17:57:20.043 *** MODULE NAME:(TOAD 9.7.2.5) 2011-09-16 17:57:20.043 *** ACTION NAME:() 2011-09-16 17:57:20.043 Dump continued FROM file: /u01/app/oracle/diag/rdbms/ora1/ora1/trace/ora1_ora_18743334.trc ORA-00603: ORACLE 服务器会话因致命错误而终止 ORA-00600: 内部错误代码, 参数: [4415], [], [], [], [], [], [], [], [], [], [], [] ========= Dump FOR incident 288186 (ORA 603) ======== *** 2011-09-16 17:57:20.051 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()+40 bl 107c8d960 FFFFFFFFFFF1DF8 ? 000002004 ? 000000001 ? 000000003 ? 000000000 ? 000000002 ? 000000001 ? 000000000 ? ksedst1()+104 CALL skdstdst() FFFFFFFFFFF0E00 ? 000002004 ? 110A45A80 ? 109FD7514 ? 110A45A80 ? 000000000 ? FFFFFFFFFFF0F30 ? 700000007 ? ksedst()+40 CALL ksedst1() 3030000000000 ? 002050033 ? 109FD7508 ? 700000000025C ? 000000000 ? 000000000 ? 109FD6B68 ? 000000000 ? dbkedDefDump()+2828 CALL ksedst() FFFFFFFFFFF0FE0 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 300000003 ? ksedmp()+76 CALL dbkedDefDump() 310A45A80 ? 110001050 ? FFFFFFFFFFF15E0 ? 28404040FFFF17BC ? 100148408 ? 109651628 ? FFFFFFFFFFF1630 ? 11064B0D8 ? ksfdmp()+88 CALL ksedmp() 000000000 ? 000000000 ? 009651643 ? 10A7D6B10 ? 200000000000000 ? 000000000 ? 110C0C3D8 ? 110A45A80 ? dbgexPhaseII()+1212 CALL ksfdmp() 000002004 ? 110A45A80 ? 000000000 ? FFFFFFFFFFF17A8 ? FFFFFFFFFFF16D0 ? FFFFFFFFFFF1DF8 ? 1001D0358 ? 110C0C3D8 ? dbgexProcessError() CALL dbgexPhaseII() 110A45A80 ? 110C0A5E8 ? +3604 0000465BA ? 200000000 ? FFFFFFFFFFF23A8 ? 00000007F ? FFFFFFFFFFF4FB0 ? 2480442200000000 ? dbgeExecuteForError CALL dbgexProcessError() 110A45A80 ? 110C0C3D8 ? ()+72 14FB82240 ? 02EDA2378 ? 70000054FB820D0 ? 7000005232EA080 ? 000000000 ? 110C0E120 ? dbgePostErrorKGE()+ CALL dbgeExecuteForError FFFFFFFFFFF5830 ? 000000000 ? 1152 () 100135724 ? 000000000 ? 000000000 ? 11064B0D8 ? FFFFFFFFFFF5840 ? 000000000 ? dbkePostKGE_kgsf()+ CALL dbgePostErrorKGE() FFFFFFFFFFF63D0 ? 1100010F8 ? 64 25BFFFF6450 ? 2820402800000000 ? 1000CC71C ? 000000002 ? 02424A228 ? 02424A228 ? kgeade()+812 CALL dbkePostKGE_kgsf() 100047FA0 ? FFFFFFFFFFFA634 ? 10980D050 ? 000000048 ? FFFFFFFFFFFA230 ? 10969BAE8 ? FFFFFFFFFFF6698 ? 10A0626E8 ? kgefec()+208 CALL kgeade() FFFFFFFFFFF65A0 ? 11067C838 ? 000000001 ? 11064B0D8 ? FFFFFFFFFFF65A0 ? 11064B0D8 ? 70000054FB820D0 ? 7000005232EA080 ? ktc_die()+168 CALL kgefec() 1100010F8 ? 110CA2518 ? 0FFFF6BA0 ? 10A0626E8 ? 70000054C772AD0 ? 10A0626E8 ? 10A06274C ? 000000000 ? k2send()+9004 CALL ktc_die() 218B2B4B0 ? 100000000 ? 1103870F8 ? 110CB8608 ? 110CB8008 ? 110CB8648 ? FFFFFFFFFFF6AE0 ? 11010AD68 ? xctRollbackTxn()+11 CALL k2send() 300000001 ? 10975AC10 ? 48 000000000 ? 000000000 ? FFFFFFFFFFF7768 ? FFFFFFFFFFF773C ? 700000000003660 ? 000000080 ? kpoltxen()+228 CALL xctRollbackTxn() 000000000 ? FFFFFFFFFFF87D0 ? 000000000 ? 000000000 ? 000000001 ? 000000000 ? 000000006 ? 07FFFFFFF ? kpotxen()+2016 CALL kpoltxen() FFFFFFFFFFF8770 ? 000000048 ? FFFFFFFFFFF8800 ? 1100F88B8 ? 0000003CF ? 000000000 ? 700000518B2B4B0 ? 000000000 ? opiodr()+3608 CALL kpotxen() 100000000 ? 1103757E8 ? FFFFFFFFFFF89D0 ? 4820402000000000 ? 100D7C570 ? 9001000A0082608 ? 9001000A000D4C8 ? 11064B0D8 ? ttcpip()+4628 CALL opiodr() 68FFFF9F30 ? C00000438 ? FFFFFFFFFFFA480 ? 000200048 ? FFFFFFFFFFF9F00 ? 000000000 ? FFFFFFFFFFF9E50 ? 1101042F8 ? opitsk()+6956 CALL ttcpip() 1101041A8 ? 110A49138 ? FFFFFFFFFFFA400 ? 4224244400000000 ? 100113A34 ? 000000000 ? FFFFFFFFFFFA460 ? 1100056F8 ? opiino()+3000 CALL opitsk() 110043D10 ? 000000000 ? 110A45A80 ? FFFFFFFFFFFC560 ? FFFFFFFFFFFE5AC ? 000000101 ? FFFFFFFFFFFDF30 ? FFFFFFFFFFFE5AC ? opiodr()+3608 CALL opiino() 3C00000000 ? FFFFFFFFFFFD065 ? FFFFFFFFFFFE9D0 ? 110AC738D ? FFFFFFFFFFFD0C0 ? 000000000 ? 90000000001094C ? 0E0DDF00D ? opidrv()+1200 CALL opiodr() 3C08456C78 ? 47530312F ? FFFFFFFFFFFE9D0 ? 01064B0D8 ? 7264626D732F6F72 ? 11064B0D8 ? 3139302F74726163 ? 652F6F7261313930 ? sou2o()+192 CALL opidrv() 3C06401934 ? 400000000 ? FFFFFFFFFFFE9D0 ? 2B00CF0000 ? 0001A9F48 ? 000000000 ? 9001000A0071F98 ? 11064B0D8 ? opimai_real()+428 CALL sou2o() FFFFFFFFFFFEA40 ? BADC0FFEE0DDF00D ? 90000000004D38C ? BADC0FFEE0DDF00D ? 000000002 ? 9001000A0082608 ? A0000000A000000 ? 10ACFAA60 ? ssthrdmain()+340 CALL opimai_real() FFFFFFFFFFFFFFFF ? 9001000A0399148 ? FFFFFFFFFFFEB30 ? 9001000A0082608 ? 900000000001368 ? 9001000A00091C0 ? FFFFFFFFFFFEB50 ? 9001000A0082608 ? main()+216 CALL ssthrdmain() 2F00035C0 ? FFFFFFFFFFFEE88 ? FFFFFFFFFFFEEF0 ? 9FFFFFFF000C4C0 ? 9FFFFFFF0000A30 ? 000000000 ? 000000000 ? 9FFFFFFF000C4C0 ? __start()+112 CALL main() 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? 000000000 ? --------------------- Binary Stack Dump --------------------- |
从连接信息可以看出，是通过TOAD连接到数据库实例的，这说明事务可能是人为操作所致，虽然在SQL语句处没有任何信息，但是从Stack的dump中可以看到xctRollbackTxn函数，虽然Oracle并没有执行COMMIT，但是运行了ROLLBACK。在只读数据库中，COMMIT会导致错误的产生，那么回滚很可能导致相同的问题，在加上版本已经DATA GUARD中备库等环境，基本上可以确认问题了。
这个问题本身没有必要过多关注，因为在只读库上进行事务本身就存在问题。