Validate the database and backups against corruption (VALIDATE)

Command

# Physical + logical block check (without producing a backup):
VALIDATE CHECK LOGICAL DATABASE;
# Scan large datafiles in parallel (11g+, needs multiple channels):
VALIDATE CHECK LOGICAL DATABASE SECTION SIZE 16G;
# A single datafile / tablespace:
VALIDATE DATAFILE 7;
VALIDATE TABLESPACE users;
# Read as if taking a backup and check (including archivelogs):
BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;
# Readability of a specific backup set:
LIST BACKUP SUMMARY;
VALIDATE BACKUPSET <bs_key>;
-- Corrupt blocks found and the affected segment (SQL):
SELECT file#, block#, blocks, corruption_change#, corruption_type
FROM   v$database_block_corruption ORDER BY file#, block#;
SELECT DISTINCT e.owner, e.segment_name, e.segment_type
FROM   dba_extents e
JOIN   v$database_block_corruption c
  ON   e.file_id = c.file#
 AND   c.block# BETWEEN e.block_id AND e.block_id + e.blocks - 1;

What it does

Reads datafiles and backup sets to detect physical and (with CHECK LOGICAL) logical block corruption, recording findings in v$database_block_corruption. The SQL query shows which table/index the corrupt block belongs to.

When to use it

After corruption errors such as ORA-01578/ORA-08103, after storage problems, and as a regular (weekly) integrity check; to prove backups are really restorable.

Caution

It performs a full read; on large databases it generates heavy I/O, so run it outside peak hours. The dba_extents query can be slow on large databases. If the corrupt block is in temporary (TEMP) or free space, no object match is returned.