搞数据库的人，最怕遇到的场景之一就是半夜被电话吵醒，说某个系统打不开了，一查日志，SQL数据库报了一致性错误。这种错误说白了，就是数据库里的数据逻辑对不上号了，可能是一张表里的索引指向了不存在的数据页，也可能是系统表里记录的某个对象状态跟实际存储的数据不匹配。遇到这种情况，很多人的第一反应是慌，其实只要冷静下来，按步骤来处理，多数情况下数据都能抢救回来。下面这5个方法，都是我这些年实际踩坑后总结出来的。
第一个方法，也是最常用的，就是利用SQL Server自带的DBCC CHECKDB命令。这个命令就像给数据库做一次全身CT扫描，它会逐页检查数据库的物理和逻辑一致性。具体操作很简单，打开SQL Server Management Studio，连上出问题的实例，新建一个查询窗口，输入“DBCC CHECKDB('你的数据库名')”然后执行。如果运气好，检查结果可能只是几个小警告，比如某些索引的碎片率偏高，这种问题直接重建索引就行。但如果报的是严重错误，比如“表错误：对象ID 123456，索引ID 1，页（1:234）上的键值与下一页不匹配”，那就说明数据页之间出现了链接断裂。这时候别急着用修复选项，先分析一下错误类型。如果是非聚集索引的问题，可以尝试先删除再重建；如果是聚集索引或堆表的问题，就需要用到带修复参数的命令了。注意，在生产环境执行修复前，一定要先做完整备份，这是铁律。
第二个方法是使用DBCC CHECKDB的修复选项，但这里有个讲究。很多新手一看到错误，就直接敲“DBCC CHECKDB('数据库名', REPAIRALLOWDATALOSS)”，结果数据是恢复了，但某些行被删除了，业务方找上门来质问。实际上，这个命令有三个级别：REPAIRREBUILD、REPAIRFAST和REPAIRALLOWDATALOSS。REPAIRREBUILD是最安全的，它只重建索引和系统表，不会动用户数据；REPAIRFAST基本没用，只是检查一些元数据；而REPAIRALLOWDATALOSS是最后的手段，因为它会删除损坏的数据页来保证整体一致性。正确的做法是：先执行“DBCC CHECKDB('数据库名', REPAIRREBUILD)”，如果修复后检查还有错误，再考虑升级到REPAIRALLOWDATALOSS。而且一定要在单用户模式下操作，避免其他连接干扰。具体命令是先把数据库设为单用户模式：“ALTER DATABASE 数据库名 SET SINGLEUSER WITH ROLLBACK IMMEDIATE”，然后执行修复，修复完再切回多用户模式：“ALTER DATABASE 数据库名 SET MULTIUSER”。这个过程需要DBA全程盯着，因为一旦数据丢失，你可能要跟业务方解释几个小时。
第三个方法是从备份中恢复受损的数据页。这是我最推荐的做法，因为它能最大程度减少数据丢失。SQL Server的企业版和标准版都支持页级还原，也就是说，你不需要还原整个数据库，只需要把损坏的那几个数据页从最近的完整备份中提取出来替换掉。具体步骤是：先用“DBCC CHECKDB”找到损坏的页号，比如页（1:234），然后执行“RESTORE DATABASE 数据库名 PAGE='1:234' FROM DISK='备份文件路径' WITH NORECOVERY”。这里要注意，页级还原后数据库会处于恢复状态，你还需要再还原后续的日志备份才能让数据库上线。如果备份链很完整，这个方法几乎可以做到零数据丢失。我遇到过最极端的情况是，一个客户的数据库有300多G，只坏了两页，用页级还原只花了20分钟就搞定了，要是全库还原，至少得6个小时。所以，养成定期做完整备份和日志备份的习惯，关键时刻能救命。
第四个方法是利用第三方工具进行数据抢救。当官方工具搞不定，或者你不想冒数据丢失的风险时，可以考虑用像ApexSQL Recover、Stellar Repair for MS SQL这类专业工具。这些工具的原理是直接解析数据库文件（MDF和NDF）的底层数据页，即使系统表损坏、元数据丢失，它们也能通过数据页上的页头信息、行偏移数组等结构，把能读到的数据尽可能提取出来。操作上一般是个图形界面，选择损坏的MDF文件，设置输出格式（比如导出成SQL脚本或直接连接到新数据库），然后等它扫描完成。我试用过几款，发现它们对某些特定类型的损坏，比如页撕裂（Page Split导致的页级损坏）或系统表损坏，恢复效果比DBCC好得多。但缺点也很明显，一是价格不便宜，一套授权可能要几千块；二是扫描大数据库很慢，几百G的库可能要跑十几个小时。所以，这个方法适合作为最后手段，或者当数据价值远高于工具成本时使用。
第五个方法，也是最容易被忽视的，就是检查硬件和存储系统。很多数据库一致性错误的根因其实是磁盘坏道、内存故障、RAID卡缓存电池耗尽或者文件系统碎片化。我见过一个案例，某公司数据库每隔两周就报一次一致性错误，每次都用DBCC修好了，但过段时间又复发。排查发现，是存储阵列上的某个硬盘存在坏道，SQL Server在写入数据页时恰好写到坏道上，导致数据页校验和错误。换了硬盘后，问题再没出现过。所以，当你频繁遇到一致性错误时，别光盯着数据库本身，要同时检查Windows系统日志、SQL Server错误日志里的硬件相关告警，以及用CHKDSK检查磁盘健康状态。另外，SQL Server的即时文件初始化功能如果配合不当，也可能导致数据页分配时出现逻辑错误，必要时可以关闭这个功能试试。记住，数据库只是软件，它依赖的硬件环境才是根本。
说到底，修复SQL数据库一致性错误这件事，核心不在于你会敲几条命令，而在于你有没有一个清晰的应对流程。我自己的习惯是：第一反应永远是做全库备份，哪怕数据库已经报错无法正常访问，也要用“WITH COPYONLY”选项做一个快照备份；然后根据错误类型和业务容忍度，决定是用页级还原还是DBCC修复；如果数据非常重要，宁可停机用第三方工具慢慢扫，也不冒险用REPAIRALLOWDATA_LOSS。修复完成后一定要做一次完整的DBCC CHECKDB确认一致性，然后重建所有索引和更新统计信息，因为修复过程可能会打乱索引结构。数据库一致性错误并不可怕，可怕的是没有预案、盲目操作。
