ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-600(15214)错误

ORA-600(15214)错误

原创 Linux操作系统 作者:yangtingkun 时间:2012-02-19 23:59:08 0 删除 编辑

告警日志中包含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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10503220