ORA-600 [kdBlkCheckError] [file#] [block#] [code]

來自METALINK 轉載一下

Description


Note: This fix causes the problem reported in bug 9711859. 
      ** Please use the fix of <Bug 9711859> instead of this fix ** 
 
ORA-600 [5467] may be reported by SMON while recovering an aborted 
transaction of allocating extents.  
 
Rediscovery Notes
 In the trace file segment header dump extent map shows
 rdba=0x00000000 and length=0 in "Block Image after recovery".
 
 eg:
  Block image after block recovery
 Extent Map
 --------------------------------------
 0x05c188c9  length:16
 0x00000000  length: 0    <---- Invalid zero rdba/length
 
 The affected blocks are type 0x23/0x24 as they contain Extent Map:
 
       0x23=PAGETABLE SEGMENT HEADER
       0x24=PAGETABLE EXTENT MAP BLOCK
 
 Additional symptoms are:
    ORA-600 [25012] [ts#] [0]  
    ORA-600 [25027] [ts#] [0] 
 
    due to dba=0x00000000 in the extent map.
 
    ORA-600 [5400]
    ORA-600 [5463]
 
    In 10g+ or when db_block_checking is enabled errors are:    
    ORA-600 [kddummy_blkchk]  [file#] [block#] [code]
    ORA-600 [kdBlkCheckError] [file#] [block#] [code]
 
    Where code can be 18009, 18038.
 
    The trace file has an Operation related to extent map with the invalid zero dba:
 
       Block Checking: DBA = <decimal dba>, Block Type = Pagetable extent map block
       Incorrect extent map entry at offset <offset#>. DBA value is 0x00000000
       TYP:0 CLS: 7 AFN:<file#> DBA:<hex dba> OBJ:<obj#> SCN:<scn> SEQ:  <seq#> OP:14.4
       kteop redo - redo operation on extent map
 
  Testcase example:
 
  drop table TC.T purge;
  drop tablespace tc including contents and datafiles;
  rem Disabling the checksum is optional and it is to reproduce the problem more easily:
  alter system set db_block_checksum=false;
  grant CONNECT, RESOURCE to TC identified by tc;
  create tablespace TC datafile 'TC.dbf' size 100M autoextend off segment space management auto;
  create table TC.T (i int, c clob) tablespace TC lob (c) store as (disable storage in row);
  insert into tc.t select rownum,rownum from all_objects where rownum<=100;
  commit;
  alter table TC.T modify lob (C) (allocate extent (size 100M));
 
IMPORTANT
========
This fix is to prevent the issue to be introduced.
It does not repair existent corruption.
The corruption in a LOB segment does not avoid the segment to be read; e.g., lob segment can be read (exported).
========
 
Workaround
 Retrieve the data and Drop/Create the affected Segment:
 
A. Get the data from the segment:
 
The most common cause of this bug is for a LOB so next examples are LOB focused:
 
 - Move the lob segment:
  alter table &table_owner.&table_with_lob move LOB (&&lob_column) store as (tablespace &tablespace_name);
 
- Create a new lob segment by creating the table with create table as select (CTAS) and drop the original table.
 
  create table &new_table as select * from &table_with_lob; <- use parallel,etc for faster performance.
  drop table &table_with_lob purge; (The purge option is necessary to avoid the same errors in recycle bin).
 
- Export the table and recreate it.  
  if using datapump, set db_block_checking=MEDIUM and export with estimate=statistics. Example:
  
  expdp tc/tc tables=t estimate=STATISTICS reuse_dumpfiles=y directory=<dirname>
  
 
B. Drop the segment (only if MOVE was not used to retrieve the data)
 
 If errors ORA-600 with ora-600 [kdBlkCheckError]  or ORA-600 [kddummy_blkchk] 
 are produced by the drop, disable checksum, drop the segment and
 re-enable the checksum by executing:
 
   alter system set db_block_checksum=false;
   Open a new session and drop table purge.
   alter system set db_block_checksum=true;
 
 If the error is still produced by SMON while cleaning the temporary segment
 use the next procedures from dbms_space_admin to clear it:
 
  segment_corrupt
  segment_drop_corrupt
  tablespace_rebuild_bitmaps
 
Note:
 This fix causes the problem reported in bug 9711859. 
 * Please use the fix of <Bug 9711859> instead of this fix *