0

ORA-600: [15214]

老杨 2019-04-18
26
摘要:告警日志中包含ORA-600[15214]错误。错误信息为:FriFeb0301:21:47EAT2012ErrorsINfile/ora...

问题描述

告警日志中包含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环境中,这个错误到也不是很严重。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
Oracle
订阅
欢迎订阅Oracle频道,订阅之后可以获取最新资讯和更新通知。
墨值排行
今日本周综合
近期活动
全部
相关课程
全部