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