数据库损坏是每位DBA的噩梦，但并非无计可施，本文总结了数据库损坏的应对策略与修复技巧。
一、损坏发生时的“三不”原则
- 不随意操作：损坏的数据库如同犯罪现场，任何修改都可能加剧数据丢失。
- 不轻易使用DBCC修复：DBCC的“fix”选项可能直接截断表或删除数据，且不记录更改，无法回滚。
- 不依赖默认备份：标准
DUMP命令可能跳过损坏页，应使用原始二进制拷贝（如dd命令）备份。
二、安全检测与备份
- 使用
DBCC ... NOFIX选项进行只读检查，避免自动修复。 - 保存所有DBCC输出，以便后续追溯。
- 强烈建议在测试服务器上验证修复方案，再应用于生产环境。
三、损坏的常见原因
- 硬件故障：磁盘、内存、CPU、电源等，尤其是磁盘坏道或控制器错误。
- 操作系统或软件Bug：虽罕见，但可能引发持久性损坏。
- 未及时检测：损坏可能在备份中潜伏数周，导致所有备份均不可用。
四、标准恢复方法的局限性
表格
| 方法 | 问题 |
|---|---|
| 重启服务器 | 仅对缓存中的临时损坏有效 |
| BCP或SELECT导出 | 可能因页链断裂而丢失数据 |
| 重建索引/表 | 可能误释放其他对象的页，造成二次损坏 |
| 从备份恢复 | 损坏可能已存在于备份中，且恢复时间长 |
| 从复制库恢复 | 复制库也可能独立损坏 |
五、高级修复技巧
对于APL（全页锁定）表，需修复数据页的双向链表；对于DOL（数据页锁定）表，则需修复OAM页和分配映射。
- 页链断裂：可使用专业工具（如Disaster Recovery Toolset）定位断裂点，手动修复指针。
- 索引损坏：若损坏范围小，可考虑删除并重建索引；否则需修复或重建整个索引。
- 零页错误（Error 692）：通常由硬件或系统写零导致，建议从备份恢复该页数据。
- 页号错误（Error 695/697）：可能因写入错误页或缓存混乱，需检查硬件并修复页链。
六、数据恢复的最终手段
当内置工具无法修复时，可使用能直接读取数据库文件的工具，扫描所有页（包括不可访问的碎片页），导出为SQL脚本，再重新导入。
七、预防建议
- 定期运行带
NOFIX的DBCC，并保存日志。 - 不要启用“truncate log on checkpoint”，否则无法回滚到损坏前状态。
- 使用第三方工具补充检测，但不能替代DBCC。
- 建立完善的备份与恢复计划，并定期演练。
总结：数据库损坏虽可怕，但通过冷静分析、安全备份、分步修复，完全可以最小化数据丢失与停机时间。关键在于：不盲目操作，先隔离、再诊断、后修复。
