Valider la base et les sauvegardes contre la corruption (VALIDATE)

Commande

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

Ce que fait la commande

Lit les datafiles et les backup sets pour détecter la corruption de blocs physique et (avec CHECK LOGICAL) logique, en consignant les résultats dans v$database_block_corruption. La requête SQL montre à quelle table/quel index appartient le bloc corrompu.

Quand l'utiliser

Après des erreurs de corruption comme ORA-01578/ORA-08103, après des problèmes de stockage, et comme contrôle d'intégrité régulier (hebdomadaire) ; pour prouver que les sauvegardes sont réellement restaurables.

Attention

Il effectue une lecture complète ; sur les grosses bases il génère beaucoup d'E/S, exécutez-le donc hors des heures de pointe. La requête sur dba_extents peut être lente sur les grosses bases. Si le bloc corrompu se trouve dans l'espace temporaire (TEMP) ou libre, aucun objet correspondant n'est renvoyé.