前两天有个做电商的朋友半夜给我打电话，说公司数据库突然崩了，客户订单数据全没了，急得差点哭出来。我跟他说别慌，SQL数据库修复这事儿，其实没那么玄乎，只要方法对，三步就能搞定。他按我说的操作完，数据全回来了，后来还专门请我吃了顿饭。
做技术的都知道，数据库这东西就像家里的保险箱，平时看着挺结实，但真出事的时候，谁都可能碰上。从服务器断电、硬盘坏道、病毒感染，到操作失误删了关键表，再到数据库文件莫名其妙报错，这些状况我这些年都见过。最惨的一次是个创业公司，数据库损坏后找了外包公司，花了五万块还没修好，是我用这三步给救回来的。
第一步，先别急着操作，停掉所有对数据库的写入。很多人一看数据库报错，第一反应就是重启服务或者乱点修复按钮，结果把原本还能抢救的数据彻底搞死。SQL Server在损坏时，系统会生成错误日志，告诉你具体是哪个文件、哪个页有问题。你要做的第一件事，就是把这日志找出来，看清楚错误代码。比如常见的823错误，说明物理文件损坏；824错误则是逻辑错误，可能是页校验失败。根据错误类型，你才能判断下一步该怎么走。我那个朋友就是，一看报错就想重装系统，被我拦住了——重装完，数据可就真没了。
第二步，根据错误类型选择修复模式。如果是非关键数据所在的表损坏，而且你有最近的完整备份，最稳妥的办法就是直接还原备份。但如果你像我朋友那样，备份已经过时，或者损坏的是核心交易表，那就只能用SQL Server自带的DBCC CHECKDB命令来修复。这个命令有三种模式：REPAIRREBUILD用于修复非关键性错误，不会丢数据；REPAIRALLOWDATALOSS会尝试修复，但可能丢失部分数据；REPAIRFAST只是快速检查，不干活。我的建议是，先试REPAIRREBUILD，不行再考虑ALLOWDATALOSS。具体操作就是在SSMS里打开新查询，输入“ALTER DATABASE 库名 SET SINGLEUSER WITH ROLLBACK IMMEDIATE”，把数据库设为单用户模式，然后跑“DBCC CHECKDB(库名, REPAIRREBUILD)”。跑完之后再用“DBCC CHECKDB(库名)”检查一遍，看错误是不是都修好了。
第三步，如果DBCC修复后还有问题，或者你不想冒丢数据的风险，那就得上第三方修复工具。市面上像Stellar Repair for MS SQL、ApexSQL Recover这些工具，我基本都试过。它们的工作原理是直接读取MDF和NDF文件，绕过损坏的页，把能提取的数据都捞出来。用的时候注意，先把你损坏的数据库文件复制一份到安全位置，然后在新机器上操作，免得二次破坏。这些工具一般都有试用版，你先跑一遍试试效果，满意了再买。我那个朋友用的就是Stellar，花了不到一千块，把99%的数据都救回来了，比他找外包公司划算多了。但记住，工具只是辅助，关键还是前两步的判断要准。
修复完成后，别急着欢呼，还有几件事必须做。第一，立即重新建立完整备份，把修复后的数据库备份到另外的硬盘或云存储上，防止再出问题。第二，检查数据完整性，比如跑一些关键查询，对比修复前后的数据量，确保没有遗漏。第三，分析损坏原因，是硬盘坏道、电源不稳，还是SQL Server配置问题。我那朋友后来查出来是服务器硬盘有坏道，换了个SSD后，再也没出过事。对了，还有个细节：修复过程中，如果数据库里有大量索引或视图，可能会影响修复速度。你可以先暂时禁用非必要的索引，等修复完再重建，能省不少时间。
说实话，数据库损坏这事儿，预防永远比修复重要。我见过太多人，平时不备份，出了事才急得跳脚。现在云服务这么方便，每天自动备份一次，成本低得很。再不济，至少每周手动备份一次，存到异地。另外，SQL Server的Always On高可用性组也值得考虑，主库坏了自动切换到备库，用户几乎无感知。但如果你已经摊上事了，也别慌，按这三步来：先停写入、看日志；再用DBCC CHECKDB修复；用第三方工具兜底。大多数情况下，数据都能找回来。
说个真实案例。去年有个做在线教育的公司，数据库被勒索病毒加密了，黑客要十万比特币才给解密。他们找到我，我一看，病毒只是加密了文件头，MDF文件的内容还在。我用上面的三步法，先停掉所有写入，然后用DBCC CHECKDB检查，发现只是文件头损坏，用十六进制编辑器手动修复了文件头，数据全回来了，一分钱没花。所以，数据库损坏真的不用慌，只要你懂方法，就能跟数据较劲到底。
