DBAtlas · Atlas d'exploitation des bases de données

Corruption de données

Symptôme

'ORA-01578', 'page corruption', 'checksum mismatch', 'MISCONF', erreurs de cohérence E/S lors des lectures.

1. Restez calme et stoppez la propagation

Une intervention dans la précipitation aggrave la situation. Déterminez d'abord l'étendue et, si possible, stoppez les écritures sur l'objet concerné. Si c'est matériel (disque/contrôleur), vérifiez aussi les logs OS/matériel : réparer la base ne répare pas le disque.

2. Déterminez l'étendue : quelle part est corrompue

S'agit-il d'un seul bloc/d'une seule page/d'un seul objet, ou est-ce généralisé ? Lancez une vérification d'intégrité.

Oracle

RMAN> VALIDATE DATABASE;  -- or: SELECT * FROM v$database_block_corruption;

PostgreSQL

-- With data_checksums enabled it shows up in the logs; check indexes/heap with pg_amcheck:
-- pg_amcheck --heapallindexed -d mydb

MySQL

CHECK TABLE customer;  -- for InnoDB, innodb_force_recovery is the last resort

SQL Server

DBCC CHECKDB ('MyDB') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Redis

redis-check-rdb dump.rdb
# AOF (Redis 7+ multi-part: under appendonlydir/, pass the manifest file):
redis-check-aof appendonlydir/appendonly.aof.manifest
# --fix TRUNCATES everything after the corrupted point (writes in that part are lost); back up the directory first:
# redis-check-aof --fix appendonlydir/appendonly.aof.manifest

3. Priorité : la restauration depuis une sauvegarde

En cas de corruption, la voie la plus sûre est la restauration depuis une bonne sauvegarde. Si la récupération au niveau bloc/page est prise en charge, ne récupérez que la partie corrompue (Oracle RMAN BLOCKRECOVER, MSSQL page restore). Les outils de réparation (DBCC REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery) ENTRAÎNENT UNE PERTE DE DONNÉES : ils sont le dernier recours.

4. Vérifiez l'intégrité

Après la récupération, relancez la vérification (DBCC CHECKDB / RMAN VALIDATE / CHECK TABLE) et confirmez qu'elle revient propre. Vérifiez aussi la cohérence des données côté application (nombre de lignes, totaux critiques).

5. Cause profonde : généralement matérielle

La corruption provient généralement d'une défaillance disque/mémoire/contrôleur. Testez/remplacez le matériel, activez les checksums (data_checksums, PAGE_VERIFY CHECKSUM) et renforcez la routine sauvegarde + vérification. Planifiez des DBCC CHECKDB / RMAN VALIDATE réguliers.

Ouvrir dans DBAtlas →