前几天一个老客户半夜给我打电话，说他那套跑了快20年的 SQL Server 2000 数据库突然崩了，系统报错“一致性错误”，数据查不出来，订单也下不了。我当时就头大。SQL 2000 现在连微软都懒得管，官方支持早已停止，网上能找到的修复资料大多是十年前的论坛帖子。但偏偏很多老制造企业、医疗机构、甚至政府机关的业务系统还在使用它，换不了。这就像家里那台老式缝纫机，虽然慢，但用顺手了，真的要扔掉还得重新学踩踏板。
一致性错误说白了就是数据库内部的数据逻辑对不上号。可以把 SQL 2000 的数据库想象成一个巨大的图书馆，每本书都有编号、目录，但某天管理员发现，有一本书的内容和它的索书号不匹配，或者借阅记录显示“已借出”而书实际上还在书架上。这时系统就会“炸毛”，拒绝提供服务。触发原因五花八门，最常见的是突然断电或服务器强制关机，导致正在写入的数据文件只写了一半，索引和数据的对应关系全乱套。还有硬盘坏道，这在老服务器上尤其致命，硬盘转着转着某个扇区读不出来，数据库文件就缺了一块。病毒攻击、甚至是不规范的 SQL 脚本执行被中断，也会留下这种烂摊子。
修复的第一步永远不是直接动手，而是先做好备份。听起来像废话，但太多人在这一步栽了。我见过一个工程师，看到报错就急着用 DBCC CHECKDB 去修，结果命令跑到一半卡住，系统锁死，连原始数据都取不出来。正确的做法是先停掉 SQL 服务，把整个数据库的 MDF 和 LDF 文件复制到安全的地方，最好再拷贝到另一台机器上。这一步花不了几分钟，却能保住你的数据。如果数据特别重要，比如医疗记录或财务账目，建议直接做物理备份——把硬盘拆下来做镜像，别偷懒。
接下来才是使用工具。SQL 2000 自带的 DBCC CHECKDB 命令是首选，它就像体检医生，能扫描出具体哪里出了毛病。在查询分析器里运行时，记得加上 WITH NOINFOMSGS 参数，否则屏幕上会刷出一堆无关紧要的警告信息，让人头皮发麻。如果报错是“表错误：数据库 ID 8，对象 ID 5575058，索引 ID 0”，说明该对象的数据页有问题。这时可以尝试 DBCC CHECKTABLE 针对单个表修复，别一上来就全库检查，那太慢，生产环境受不了。但要注意：SQL 2000 的 DBCC 修复选项非常有限，只有 REPAIRALLOWDATALOSS 和 REPAIR_REBUILD 两种。前者会直接删掉损坏的数据，后者会重建索引但可能丢失关联记录。选哪个得看数据重要性，宁可丢几条记录也别让整个库瘫痪。
如果 DBCC 修不好，或者报错说“无法修复此错误”，就需要第三方工具了。市面上有个叫 ApexSQL Recover 的软件，专门针对老版本 SQL Server，能从损坏的 MDF 文件里把数据捞出来。它的原理不是修复数据库文件，而是直接解析磁盘上的二进制数据，跳过损坏的部分，把能读的表、视图、存储过程导成 SQL 脚本，你再重新建库并执行这些脚本。这招成功率挺高，但有前提：MDF 文件不能烂得太彻底，比如整个文件头都坏了，那就救不回来。另外，这软件价格不便宜，一个授权几千块，但相比数据丢失的损失，这点钱算不了什么。
还有一种“野路子”，适合实在没钱买工具的情况。可以把 MDF 文件附加到更高版本的 SQL Server 上，比如 SQL 2008 R2 或 2012。新版本的数据库引擎对旧文件有一定兼容性，有时低版本报的一致性错误，在高版本里反而能忍过去，让你把数据导出来。操作很简单：停掉 SQL 2000 服务，把 MDF 和 LDF 复制到装有 SQL 2008 的机器上，用 ATTACH 命令附加。但要注意，附加成功后立刻用导入导出向导把数据倒到新库里，别在那个附加的库上跑业务，因为高版本会改变文件格式，之后再也回不去 SQL 2000。此方法不保证 100% 成功，但大约有七成概率能把核心业务表救回来。
修复完数据后，更头疼的问题来了：怎么防止下次再崩？对于仍在使用 SQL 2000 的老系统，最现实的方案不是立刻升级，因为业务系统本身可能无法兼容新版本。可以考虑给服务器配一个 UPS，解决断电问题；把硬盘换成企业级 SSD，降低坏道风险；定期手动备份数据库，备份文件放到另一台机器上。还有个“骚操作”：写个计划任务，每天凌晨用 BCP 命令把核心表导出为 CSV 文件，即使数据库真的炸了，也还有一份原始数据。别指望自动备份软件，老系统上很多都不兼容，手动最靠谱。
说点心里话。SQL 2000 已经是二十多年前的技术，它跑在 Windows Server 2000 或 2003 上，这些操作系统本身漏洞众多，连微软都不再提供补丁。你花大力气修复一次一致性错误，可能过几天又会出现别的问题。我见过最惨的案例是一家医院，病历数据库硬撑了五年，每次出问题就找外包修，修一次几千块，数据库最终被迫设为只读，所有写操作全部失败，病人挂号都挂不了。所以我的建议是：这次修复完后，赶紧把数据迁移到 SQL Server 2019 或直接上云，别跟老古董死磕。技术这东西，该扔就得扔，情怀换不回数据安全。
