ORA-600(qertbFetchByRowID)错误-CSDN博客

以前也碰到过这个错误，不过由于无法直接连接数据库，没有办法深入分析。这次虽然同样没有办法连接数据库，但是获取了更详细的信息，基本确定导致问题的原因。

错误信息如下：

Wed May 09 10:41:32 2012
Errors in file /oracle/admin/orcl/udump/orcl_ora_423466.trc:
ORA-00600: internal error code, arguments: [qertbFetchByRowID], [], [], [], [], [], [], []

其实从错误信息不难分析，导致问题的原因和索引有关，错误信息明确指出了问题发生在通过ROWID信息读取表时，而通过ROWID读取是索引扫描的标志。

一般来说这种问题是索引和表上数据的逻辑损坏造成的，如果问题出现在索引上，那么最简单的办法莫过于删除重建索引，或者使用ONLINE方式重建索引。

将索引删除后，问题果然不再出现，但是尝试重建索引时，引发了另一个ORA-600错误：

SQL> analyze table tab_a validate structure cascade online;
analyze table tab_a validate structure cascade online
ORA-01499: table/index cross reference failure - see trace file

SQL> alter index ind_a rebuild online parallel 4;
alter index ind_a rebuild online parallel 4
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []

告警日志中信息为：

Errors in file /oracle/admin/orcl/udump/orcl_ora_618990.trc:
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []

详细TRACE中信息为：

*** 2012-05-09 13:52:41.518
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []
Current SQL statement for this session:
alter index ind_a rebuild online parallel 4
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              00000FFFF ? 000000000 ?
ksedmp+0290          bl       ksedst               104A557A8 ?
ksfdmp+0018          bl       03F4CD24
kgerinv+00dc         bl       _ptrgl
kgeasnmierr+004c     bl       kgerinv              70000002F81807C ? 0000000B8 ?
                                                   1F400000000 ? 110546478 ?
                                                   110546068 ?
kdsgrp+0460          bl       01FB9490
kdsgnp+0444          bl       kdsgrp               70000002F8184ED ? 000000000 ?
                                                   110546070 ?
kdstf0011101km+0c24 bl       03F4A5C0
kdsttgr+5244         bl       kdstf0011101km       110546068 ? 000010266 ?
                                                   70000022DCBB510 ?
                                                   FFFFFFFFFFF54F8 ? 0FFFFFFFF ?
                                                   000001FE8 ? 000000000 ?
                                                   000000000 ?
qertbFetch+09b8      bl       kdsttgr              110546068 ?
                                                   4842208000000001 ?
                                                   804000007BFB0 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? C4FB00000000 ?
qergiFetch+02a4      bl       03F49A98
qertqoFetch+01f0     bl       01FB9488
qertqiFetch+0158     bl       01FB9488
qersoFetch+0110      bl       03F49A98
qerliFetch+0188      bl       03F49A98
qertqoFetch+01f0     bl       01FB9488
qerpxFetch+0210      bl       01FB9488
kdicrws+16e8         bl       01FB9488
kdicdrv+09b8         bl       kdicrws              70000022DFE4DC0 ?
                                                   70000022DFE5500 ?
                                                   70000022DFE5500 ?
opiexe+28c4          bl       kdicdrv              B00000009 ? 100000001 ?
                                                   11043C340 ?
opiosq0+19f0         bl       opiexe               FFFFFFFFFFF8E70 ?
                                                   2824424042420820 ?
                                                   FFFFFFFFFFF8F30 ?
kpooprx+0168         bl       opiosq0              33C0D81A0 ? 1101957F8 ?
                                                   1100098E0 ? A4000110199810 ?
kpoal8+0400          bl       kpooprx              FFFFFFFFFFFB784 ?
                                                   FFFFFFFFFFFB508 ?
                                                   3B0000003B ? 100000001 ?
                                                   000000000 ? A40000000000A4 ?
                                                   000000000 ? 1103A0018 ?
opiodr+0ae0          bl       _ptrgl
ttcpip+1020          bl       _ptrgl
opitsk+1124          bl       ttcpip               1100CAB28 ? 000000000 ?
                                                  000000001 ? FFFFFFFFFFFB8B0 ?
                                                   000000001 ? 1100DFE78 ?
                                                   FFFFFFFFFFFB830 ? 11046F998 ?
opiino+0990          bl       opitsk               0FFFFD7C0 ? 000000000 ?
opiodr+0ae0          bl       _ptrgl
opidrv+0484          bl       01FBA8D8
sou2o+0090           bl       opidrv               3C02ABCD9C ? 4A039F928 ?
                                                   FFFFFFFFFFFF6C0 ?
opimai_real+01bc     bl       01FB868C
main+0098            bl       opimai_real          000000000 ? 000000000 ?
__start+0090         bl       main                 000000000 ? 000000000 ?

--------------------- Binary Stack Dump ---------------------

可以看到，数据的损坏出在表块上，因此重建索引会导致错误。如果问题出现在表块上，那么除了利用DBMS_REPAIR包之类的进行修复外，还可以通过简单的PL/SQL将正常的数据导出。由于数据存在坏块，直接CREATE TABLE AS SELECT采用直接路径方式，会绕过数据的校验，因此错误数据仍然会插入。而EXP和EXPDP在导出的时候同样会报错，因此只有通过PL/SQL单条记录读取，如果正常就插入到目标表，如果出现读取异常，那么通过异常判断来过滤该错误。

ORA-600[kdsgrp1]错误：http://yangtingkun.itpub.net/post/468/524144

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-723438/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-723438/