Data corruption
Symptom
'ORA-01578', 'page corruption', 'checksum mismatch', 'MISCONF', I/O consistency errors during reads.
1. Stay calm and stop the spread
Panicked intervention makes things worse. First determine the scope and, if possible, stop writes to the affected object. If it is hardware-related (disk/controller), also check OS/hardware logs — fixing the DB does not fix the disk.
2. Determine the scope: how much is corrupted
Is it a single block/page/object, or widespread? Run an integrity check.
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 mydbMySQL
CHECK TABLE customer; -- for InnoDB, innodb_force_recovery is the last resortSQL 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.manifest3. Priority: recovery from backup
With corruption, the safest path is restoring from a good backup. If block/page-level recovery is supported, recover only the corrupted part (Oracle RMAN BLOCKRECOVER, MSSQL page restore). Repair tools (DBCC REPAIR_ALLOW_DATA_LOSS, innodb_force_recovery) CAUSE DATA LOSS — they are the last resort.
4. Verify integrity
After recovery, rerun the check (DBCC CHECKDB / RMAN VALIDATE / CHECK TABLE) and confirm it comes back clean. Also verify data consistency on the application side (row counts, critical totals).
5. Root cause: usually hardware
Corruption usually comes from disk/memory/controller failure. Test/replace the hardware, enable checksums (data_checksums, PAGE_VERIFY CHECKSUM), and tighten the backup + verification routine. Schedule regular DBCC CHECKDB / RMAN VALIDATE.