ORA-600[kdsgrp1]

In this Document

Purpose

Troubleshooting Steps

References

---

Applies to:

Oracle Server - Enterprise Edition - Version 10.1.0.2 to 11.1.0.6 [Release 10.1 to 11.1]
Information in this document applies to any platform.
***Checked for relevance on 23-Mar-2012***

Purpose

The error is raised when we fail to find a row piece, i. e., the block is fine, but the row does not exist. 
This error is new in 10g, in 9i we didn't raise this error and the corruption was unnoticed.

We raise ORA-600[kdsgrp1] assert during table/index full scans if a row piece is not found. 
The error is raised only if Event 10231 or SKIP_CORRUPT_BLOCKS is not set. 

/* Check table number, whether the row slot exists, whether row exists */ 
/* if row doesn't exist, and neither 'skip corrupt block' nor 
** 'user rowid' bits are set, then raise error kdsgrp1.

Note: the block is good and because of that DBV, RMAN, analyze will not fail.

Troubleshooting Steps

Error may be caused if:

1. A row referenced in an index does not exist in the table. 

    In this case 'analyze table validate structure cascade' will fail with an ora-1499, and trace file  generated will show the index that causes the error. You will have to drop and recreate that index in order to solve the error.

 2. An unexistent rowid pointed by a chained row.

     In this case analyze will not fail.

In this case error can be eliminated by skipping the "corruption", however 
before doing anything like this you should verify if there is actually any data in the 
referenced blocks that are getting errors and will be skipped. 
Please involve Oracle Support to see if it's possible to extract the data.

Trace file generated by ora-600[kdsgrp1] will show at the beginning something similar to:

*** 2007-04-26 19:53:57.671 
*** SERVICE NAME:(HARTLEY) 2007-04-26 19:53:57.671 
*** SESSION ID:(304.20) 2007-04-26 19:53:57.671 
            row 0826817f.ffffffff continuation at 
            file# 32 block# 2523519 slot 0 not found 
**************************************************

Please dump the block in order to retrieve the data:

SQL> alter system dump datafile 32 block 2523519;

WORKAROUND:

In order to skip the error one of these two w/a can be used: 

1) set event 10231 and export the good rows or use 'create table as select ..' 

        Setting the event in a Session 
        ~~~~~~~~~~~~~~~~~~~

SQL> alter session set events '10231 trace name context forever, level 10'; 
SQL> create table salvage_table as select *  from corrupt_table; 

        Setting the event at Instance level 
        ~~~~~~~~~~~~~~~~~~~~~~

        Edit your init.ora add the following event and bounce database: 
    

event="10231 trace name context forever, level 10" 

        export the table or use 'create table .. as select ..' 

or 

2) run DBMS_REPAIR.SKIP_CORRUPT_BLOCKS() procedure on the table 

        Connect as a SYSDBA user and mark the table as needing to skip corrupt blocks thus: 

SQL> execute dbms_repair.skip_corrupt_blocks('',''); 

       After this you can export the table or run 'create table .. as select ..'. 


You can find the lost rows from the corrupted blocks by comparing the corrupted table with the new table. 
Once you have the rowid of the skipped rows you can use DBMS_ROWID package to find the file# and block#, and dump the block to retrieve the data:

SQL> alter system dump datafile block ; /** a trace file will be generated under udump

References

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

转载于:http://blog.itpub.net/15747463/viewspace-736168/