数据损坏恢复

针对数据损坏（块/页校验和错误、无法读取的表、损坏的 RDB/AOF）的分步决策树：先确认损坏范围，然后在块级恢复、基于备份的完整恢复/PITR 和最后手段的修复工具之间做出正确选择。

损坏范围有多大？

先运行完整性检查，确定损坏扩散的程度。是只有少数块/页损坏，影响单个对象（表/索引），还是大范围损坏？使用下面的命令扫描以确定范围，然后选择相应的分支。

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;  -- then: SELECT file#, block#, blocks, corruption_type FROM v$database_block_corruption;

• 只有少数块 / 页损坏
• 影响单个对象（表/索引）
• 大范围损坏 / 涉及多个对象
• 检查工具无法运行，数据库无法打开
• 损坏反复出现（怀疑存在根本原因）

根本原因：有限的块/页损坏 → 定向恢复

如果只有少数块/页损坏，无需恢复整个数据库。利用引擎的块/页级恢复功能，仅从备份/日志修复损坏部分，将数据丢失降到最低。

根本原因：对象级/大范围损坏 → 基于备份的完整恢复或 PITR

如果损坏已扩散到一个或多个对象，最安全的做法是从完好的备份恢复，并尽可能前滚到损坏发生的时刻（PITR）。这样可以避免修复工具造成的数据丢失。

没有备份 / 数据库无法打开 — 要采取最后手段吗？

修复工具（REPAIR_ALLOW_DATA_LOSS、innodb_force_recovery、--fix）可能导致数据丢失，并可能破坏完整性约束。只有在没有可用备份且数据库无法打开时，它们才是最后手段。首先确认确实没有可用的备份。

• 我找到了完好的备份，进行恢复
• 完全没有备份，只能使用修复工具

最后手段：有数据丢失风险的修复工具

这些工具会丢弃损坏的行/页，使数据库能够打开。仅在没有备份且已先复制现有文件的情况下使用。目标：打开到足以导出数据的程度，然后将数据迁移到干净的副本。

根本原因：硬件/基础设施 → 修复根源并启用校验和

如果损坏反复出现，真正的原因很可能是磁盘、控制器、内存（RAM）或不稳定的存储层。仅恢复数据是不够的；不修复根源，损坏还会再次出现。同时启用校验和/完整性验证，以便尽早发现。