Validar la base de datos y los backups frente a corrupción (VALIDATE)

Comando

# 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;

Qué hace

Lee los datafiles y los backup sets para detectar corrupción física y (con CHECK LOGICAL) lógica de bloques, y registra los hallazgos en v$database_block_corruption. La consulta SQL muestra a qué tabla/índice pertenece el bloque corrupto.

Cuándo usarlo

Tras errores de corrupción como ORA-01578/ORA-08103, tras problemas de almacenamiento y como comprobación de integridad periódica (semanal); para demostrar que los backups son realmente restaurables.

Precaución

Realiza una lectura completa; en bases de datos grandes genera mucha I/O, así que ejecútelo fuera de las horas pico. La consulta a dba_extents puede ser lenta en bases de datos grandes. Si el bloque corrupto está en espacio temporal (TEMP) o libre, no se devuelve ningún objeto.