Datenbank und Backups auf Korruption prüfen (VALIDATE)

Befehl

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

Was es tut

Liest Datafiles und Backup Sets, um physische und (mit CHECK LOGICAL) logische Blockkorruption zu erkennen, und hält Befunde in v$database_block_corruption fest. Die SQL-Abfrage zeigt, zu welcher Tabelle/welchem Index der korrupte Block gehört.

Wann einsetzen

Nach Korruptionsfehlern wie ORA-01578/ORA-08103, nach Storage-Problemen und als regelmäßige (wöchentliche) Integritätsprüfung; um nachzuweisen, dass Backups wirklich wiederherstellbar sind.

Vorsicht

Führt einen vollständigen Lesevorgang aus; auf großen Datenbanken erzeugt das hohe I/O-Last, daher außerhalb der Spitzenzeiten ausführen. Die Abfrage auf dba_extents kann auf großen Datenbanken langsam sein. Liegt der korrupte Block in temporärem (TEMP) oder freiem Platz, wird kein Objekt zugeordnet.