Applies to:Oracle Server - Enterprise Edition - Version 10.2.0.1 to 22.214.171.124 [Release 10.2 to 11.2]
Information in this document applies to any platform.
This document describes a procedure to format a corrupt datablock using RMAN which is not part of any segment.
Typically, after a block corruption is found, we determine whether the corrupt block belongs to a table or index. If it's a index block, we can simply re-create the index. If it's a table block we can perform rman block recovery or datafile restore/recovery. If we do not have suitable backups, we salvage the table data into another table and then drop/truncate the corrupted table. So, if you have resolved the corruption using any means other then restore/recovery (or rman block media recovery), we will end up with the corrupt block which now does not belong to the original table/index i.e. it does not belong to any object.
In such situation, although the corrupt block does not belong to any object, it will still show as corrupt in DBV and you might want to format the same. For eg, say we found corruption as below:
After salvaging the table data, we dropped the corrupt table. Now, DBA_EXTENTS will show that this block does not belong to any segment. This is also confirmed by DBA_FREE_SPACE:
However, the block will still be seen as corrupt in DBV:
In such situation, we can use this procedure to format the corrupt block. However, note that this procedure can ONLY be used if RMAN backup does not fail for this corrupt block. Normally we expect that RMAN will not read this block due to it's unused block optimization algorithm. However, this is not always true. RMAN reads the bitmaps stored in a locally-managed datafile header to deduce whether a particular extent is free or used. Based on how these bitmaps are managed and read by rman, its not always guaranteed that RMAN will skip all extents which are currently un-used. Some extents might still be read by rman for backups even though they are currently un-used. So we cannot be sure if RMAN will skip the extent beloging to the corrupt block or try to read it. If RMAN reads it, it will fail with error ORA-19566 due to the corrupt block which means we cannot use this procedure. Instead we'd have to use below document:
Document 336133.1 How to Format Corrupted Block Not Part of Any Segment
As per above section, we can use this procedure if RMAN backup has not failed while reading the corrupt block. To determine the same, run a backup on the datafile having the corrupt block:
Ensure that the location where backup-piece will be created has sufficient space. You can change this destination using the FORMAT clause. Also, even though the backup seems successful, crosscheck using below query that the corrupt block is not contained in the backup:
If the above query returns rows showing the corrupt block, we cannot use this procedure. In above case, since it has not returned rows, we can be sure that RMAN has skipped the corrupt block due to unused block optimization algorithm described above. Now, if the datafile is restored from this backup, RMAN will format and restore a empty copy of the corrupt block which can then be used for rman block recovery as below.
1. Restore the datafile to alternate location:
2. Run DBV on the restored datafile to verify it is free from corruption:
3. Run BLOCKRECOVER command as below to repair the corrupt block. The corrupt block will be replaced by the empty, formatted block from the restored datafile:
4. Run DBV on the original file to confirm that it is now free from corruption:
5. Additionally, you can run VALIDATE in RMAN to verify further: