客户的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, sid=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中备库等环境，基本上可以确认问题了。
这个问题本身没有必要过多关注，因为在只读库上进行事务本身就存在问题。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-707757/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-707757/
1591
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
