数据损坏

症状

读取时出现 'ORA-01578'、'page corruption'、'checksum mismatch'、'MISCONF' 等 I/O 一致性错误。

1. 保持冷静，阻止扩散

慌乱的干预只会让情况更糟。首先确定影响范围，并尽可能停止对受影响对象的写入。若与硬件有关（磁盘/控制器），还要检查操作系统/硬件日志——修好数据库并不能修好磁盘。

2. 确定范围：损坏了多少

是单个块/页/对象，还是大范围损坏？运行完整性检查。

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. 优先事项：从备份恢复

出现损坏时，最安全的做法是从可靠的备份还原。若支持块/页级恢复，只恢复损坏的部分（Oracle RMAN BLOCKRECOVER、MSSQL 页还原）。修复工具（DBCC REPAIR_ALLOW_DATA_LOSS、innodb_force_recovery）会导致数据丢失——它们是最后手段。

4. 验证完整性

恢复后，重新运行检查（DBCC CHECKDB / RMAN VALIDATE / CHECK TABLE），确认结果干净。同时在应用端验证数据一致性（行数、关键汇总值）。

5. 根本原因：通常是硬件

损坏通常源于磁盘/内存/控制器故障。测试/更换硬件，启用校验和（data_checksums、PAGE_VERIFY CHECKSUM），并强化备份 + 验证流程。定期安排 DBCC CHECKDB / RMAN VALIDATE。