告警日志中包含ORA-600[15214]错误。
错误信息为:
Fri Feb 03 01:21:47 EAT 2012
Errors in file /oracle/app/admin/orcl/bdump/orcl2_p155_29897.trc:
ORA-00600: internal error code, arguments: [15214], [0], [2], [], [], [], [], []
Fri Feb 03 01:21:49 EAT 2012
Trace dumping is performing id=[cdmp_20120203012149]
很显然,这是一个并行执行导致的错误,进一步检查详细TRACE:
*** 2012-02-03 01:21:47.380
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [15214], [0], [2], [], [], [], [], []
Current SQL statement for this session:
alter index ONWER01.PK_TABLE_INDEX rebuild partition P1 nologging parallel online
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+64 call ksedst1() 000000000 ? 000000001 ?
ksedmp()+2176 call ksedst() 000000000 ?
C000000000000D20 ?
4000000003EC4A80 ?
000000000 ? 000000000 ?
000000000 ?
ksfdmp()+112 call ksedmp() 000000003 ?
9FFFFFFFFFFF0500 ?
60000000000AF0E0 ?
9FFFFFFFFFFF0AD0 ?
C000000000000999 ?
4000000003F0CAF0 ?
kgeriv()+336 call ksfdmp() 9FFFFFFFFFFF1060 ?
000000003 ?
9FFFFFFFFFFF0AE0 ?
60000000000AF0E0 ?
C000000000000695 ?
4000000009750DC0 ?
00002E217 ?
60000000000B9E08 ?
kgesiv()+192 call kgeriv() 60000000000318D0 ?
6000000000032988 ?
40000000019720C0 ?
000000002 ?
9FFFFFFFFFFF1098 ?
ksesic2()+192 call kgesiv() 60000000000318D0 ?
9FFFFFFFFD3B3720 ?
9FFFFFFFFD3B3730 ?
000000002 ?
9FFFFFFFFFFF1098 ?
$cold_kksfbc()+8800 call ksesic2() 000003B6E ?
60000000000B9E08 ?
9FFFFFFFFFFF1098 ?
60000000000BA580 ?
000000002 ?
9FFFFFFFFD3D7B68 ?
000000000 ?
9FFFFFFFFD3D7B60 ?
kkspsc0()+2176 call $cold_kksfbc() 9FFFFFFFFFFF2440 ?
4000000002F06BA0 ?
00002821B ?
9FFFFFFFFD3B4930 ?
000000061 ?
4000000000E1B9A0 ?
C00000119BF35118 ?
C00000119BF35118 ?
kksParseCursor()+35 call kkspsc0() 9FFFFFFFFFFF3710 ?
2 9FFFFFFFFD3B4930 ?
000000061 ? 000000003 ?
000000006 ?
4000000002F648E0 ?
000000000 ?
opiosq0()+4368 call kksParseCursor() 9FFFFFFFFFFF3880 ?
C000000000001838 ?
4000000002E23DE0 ?
9FFFFFFFFD3C1888 ?
0FFDFFFFF ?
60000000000BC520 ?
60000000000BC878 ?
60000000000BC810 ?
kpooprx()+416 call opiosq0() 000000003 ?
9FFFFFFFFFFF4370 ?
40000000029752C0 ?
00002F213 ?
C000000000000815 ?
kpoal8()+1152 call kpooprx() 000000001 ?
9FFFFFFFFD3B4930 ?
000000060 ?
9FFFFFFFFFFF43B0 ?
000000001 ? 0000004A0 ?
60000000000AF0E0 ?
600000000009EA00 ?
出错的语句是一个索引重建,不过条件复杂一点,是对于索引的一个分区执行在线的并行NOLOGGING的重建操作,总会话应该是重建所有的分区,使用并行后,当前的会话会尝试重建其中一个分区。
不幸的是,这个错误在MOS中并没有对应的记录,虽然几乎所有的ORA-600[15214]错误都指向了Bug 6404447 - Intermittend OERI[15214] [ID 6404447.8],但是这个BUG已经在10.2.0.5中被明确FIXED了。而当前的数据库版本就是10.2.0.5。
同样在MOS上查询大量的已经明确应用了Patch 6404447补丁但仍然出现这个错误的情况,Oracle目前还没有给出明确的说明。
如果不是这个错误在10.2.0.5中没有真正解决,就是另外的问题导致了这个错误的产生。一般这个错误似乎后并行或直接路径有关,因此对于OLTP环境中,这个错误到也不是很严重。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-716866/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-716866/