首页 > Linux操作系统 > Linux操作系统 > ORA-600[kdsgrp1]


原创 Linux操作系统 作者:renjixinchina 时间:2012-07-20 17:29:18 0 删除 编辑

In this Document

Troubleshooting Steps

Applies to:

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


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;


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 ..' 


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


来自 “ ITPUB博客 ” ,链接:,如需转载,请注明出处,否则将追究法律责任。

下一篇: oracle dump 命令
请登录后发表评论 登录


  • 博文量
  • 访问量