SQL数据库修复工具

凌晨三点，据库报表系统突然报错，修复日志里跳出一行红字：“Page checksum mismatch in database 'OrderDB'。工具”我盯着屏幕，据库心里清楚——这不是修复简单的死锁或超时，是工具数据库文件物理损坏了。SQL Server 的据库页面校验和验证失败，意味着磁盘上某个 8KB 的修复数据页已经和内存里的预期值对不上。这时候，工具任何应用层的据库重试都是徒劳，必须上修复工具。修复

很多人第一反应是工具打开 SSMS，右键数据库，据库找“修复”选项。修复但 SQL Server 自带的工具修复命令只有两个：`DBCC CHECKDB` 和 `ALTER DATABASE ... SET EMERGENCY` 之后配合 `DBCC CHECKDB (…, REPAIR_ALLOW_DATA_LOSS)`。那个 `REPAIR_ALLOW_DATA_LOSS` 名字起得一点不委婉，它就是在告诉你：能修，但可能丢数据。我见过一个客户，跑完这条命令后订单表少了三百多行，因为损坏的页正好落在聚集索引的中间层。修复工具把坏页直接删了，索引是能重建，但那些行没了。

所以真正干活的时候，没人敢直接在生产库上跑 `REPAIR_ALLOW_DATA_LOSS`。常规做法是：先做完整备份，再把备份还原到另一台机器，在还原副本上尝试修复。如果 `CHECKDB` 报的是索引不一致，那好办，`REBUILD` 索引就能解决，不丢数据。但要是报“数据页损坏”或者“文本指针无效”，就得看运气了。

第三方工具在这时候往往比微软自带的更实用。比如 Stellar Phoenix SQL Database Repair 或者 SysTools SQL Recovery，它们的工作方式不太一样：不依赖 SQL Server 引擎去解析页面，而是直接扫描 MDF 文件的二进制结构，把还能识别的记录抽取出来，导出成 SQL 脚本或 CSV。我试过用 SysTools 恢复一个 40GB 的库，坏页集中在非聚集索引上，工具花了两个小时把表数据全部导出，然后我新建一个库，把脚本跑进去，除了几个 `nvarchar(max)` 字段被截断，其他都回来了。

但这类工具也有坑。它们对 SQL Server 新版本的页结构支持往往滞后。比如 SQL Server 2022 引入了新的数据页校验方式，有些老版本工具扫出来的记录会乱序，或者把 `datetime2` 解析成错误的值。另外，如果数据库启用了 TDE（透明数据加密），大部分第三方工具直接歇菜——它们读不懂加密后的页。这时候只能回到微软自己的修复路径，或者找专业的数据恢复公司，用底层扇区读取的方式碰运气。

还有一个容易被忽略的点：修复之前先检查存储硬件。我遇到过两次，`CHECKDB` 报错，结果发现是 RAID 卡电池失效导致写缓存丢失，换了电池再跑 `CHECKDB` 就正常了。所以别急着上工具，先看 Windows 事件日志里有没有 `disk` 或 `storahci` 的错误。硬件问题不解决，修完还会坏。

说回那个凌晨三点的 OrderDB。我最后没用 `REPAIR_ALLOW_DATA_LOSS`，而是从备份里还原了前一天的完整备份，再把当天的事务日志尾部备份出来，做了一次尾日志还原。丢失的只是最后几分钟未提交的事务。代价是停机四十分钟，但数据一行没少。修复工具是最后的手段，不是第一选择。平时把备份策略做扎实，比任何修复工具都管用。