- Dealing with Database Block Corruption in Oracle
- Use DB_VERIFY
- Using Oracle Checksum Facilities
- Salvaging Data from a Corrupt Oracle Database
Using Oracle Checksum Facilities
Oracle provides a number of checksum facilities that you can use to identify corrupt blocks. Checksum facilities are enabled by setting parameters and events in the init.ora file:
-
Setting db_block_checksum to TRUE causes checksums to be calculated for all data blocks on their next update. The database writer performs the task of calculating checksums. The checksum for a data block is stored in its cache header when writing it to disk.
NOTE
After a checksum is generated for a block, the block always use checksums even if the parameter is later removed.
-
Setting log_block_checksum to TRUE causes checksums to be calculated for all redo log blocks.
-
Setting events 10210, 10211, 10212, and 10225 can be done by adding the following line for each event in the init.ora file:
Event = "event_number trace name errorstack forever, level 10"
When event 10210 is set, the data blocks are checked for corruption by checking their integrity. Data blocks that don't match the format are marked as soft corrupt.
When event 10211 is set, the index blocks are checked for corruption by checking their integrity. Index blocks that don't match the format are marked as soft corrupt.
When event 10212 is set, the cluster blocks are checked for corruption by checking their integrity. Cluster blocks that don't match the format are marked as soft corrupt.
When event 10225 is set, the fet$ and uset$ dictionary tables are checked for corruption by checking their integrity. Blocks that don't match the format are marked as soft corrupt. -
Setting _db_block_cache_protect to TRUE protects the cache layer from becoming corrupted. It might crash the database instance, but the corruption isn't written to the disk.