数据库崩了，这事儿搁谁头上都得炸毛。上周我一个朋友公司，凌晨三点运维打来电话，说 SQL Server 突然挂掉，所有业务停摆，客户订单全卡在半空。他当时就慌了，第一反应是找外包公司，结果对方报价两万八，还说要等天亮才能处理。其实，SQL 数据库崩溃没那么玄乎，先别急着掏钱。我这些年处理过不下几十次数据库故障，有些经验值得分享。
先说最常见的场景：数据库突然打不开，提示“无法访问”或“文件损坏”。这时候千万别重启机器，很多人一慌就按电源键，结果数据文件彻底写死，神仙也救不回。正确的第一步是检查错误日志，SQL Server 的 ERRORLOG 文件会记录崩溃原因，比如日志文件满了、磁盘空间不足、系统内存压力过大。我见过最坑的一次，是有人把数据库文件放在 C 盘，C 盘只剩 200 MB，SQL Server 直接罢工。这种问题，清理磁盘空间、重启服务就能恢复，根本不需要修复工具。
如果错误日志显示“数据库标记为可疑”或“处于恢复挂起状态”，就得动真格了。先把数据库设为紧急模式，用 ALTER DATABASE 把状态改成 EMERGENCY，这样至少能读到表结构。然后运行 DBCC CHECKDB，带上 REPAIRALLOWDATA_LOSS 参数。注意，这个参数会删掉损坏的数据页，但总比整个库废掉强。我有个电商客户，订单表损坏了三个页，使用该命令后丢失了大概 50 条订单记录，其他 30 万条数据完好无损。事后他补录了那 50 条，业务照常运转。当然，如果有完整备份，最好用备份恢复，修复命令只是无备份时的备选方案。
说到备份，这才是保命符。我见过太多人，数据库跑了一年半载，从来没做过备份。崩了之后才想起来问：“备份文件在哪？”答案是根本没有。这类情况只能靠第三方修复工具。市面上像 Stellar Repair for SQL、ApexSQL Recover 之类的工具，能扫描损坏的 MDF 文件，尽可能提取可读数据，但价格不菲，一个授权要几千块。而且修复效果受限于物理损坏程度，例如硬盘坏道导致文件碎片化，工具也救不了多少。建议先把 MDF 和 LDF 文件复制一份，在副本上操作，别在原文件上折腾，免得二次损坏。
还有一种隐蔽的崩溃：逻辑损坏。这比物理损坏更让人头疼，因为数据库能正常打开，但查询时会报错，如“页面读取失败”或“索引损坏”。DBCC CHECKDB 会报告一致性错误，但不会直接让数据库挂掉。处理办法是用 DBCC CHECKTABLE 逐表检查，或者重建索引。我有个朋友的公司，财务系统跑了一年，突然发现某个月的对账单数据全乱码。排查后发现是索引碎片严重，加上磁盘 I/O 瓶颈，导致写入时数据页错位。他重建了所有索引，并加装 SSD 做数据盘，问题就解决了。记住，定期重建索引、更新统计信息，能大幅降低逻辑损坏的概率。
最麻烦的是日志文件损坏。SQL Server 的 LDF 文件记录了所有事务，如果它坏了，数据库可能启动不了。这时可以尝试强制启动数据库，把恢复模式改成 SIMPLE，随后分离数据库再重新附加。但这样会丢失未提交的事务数据，比如正在处理中的订单、转账记录。我处理过一家物流公司，他们的日志文件被勒索病毒加密，只能用 SIMPLE 模式启动，结果丢了当天下午两小时的数据，大约 3000 多票运单。后来他们上线了实时备份方案，每 5 分钟备份一次事务日志，再也没出现类似问题。所以，日志文件的重要性不亚于数据文件，备份时别忘了它。
日常运维中，有几个坑必须避开。第一，不要在生产库上直接运行 DBCC CHECKDB 的修复命令，它会锁表，影响线上业务。最好在非高峰期或备用服务器上操作。第二，不要轻易修改数据库文件的物理路径，很多人手贱改了路径，结果 SQL Server 找不到文件，直接报错。第三，不要忽略 Windows 事件查看器里的警告信息，比如磁盘坏道、内存错误，这些都是数据库崩溃的前兆。我有个客户，服务器事件日志连续三天报“磁盘读取延迟过高”，他没当回事，结果第四天硬盘挂了，数据库文件损坏。后来花了三天才恢复，损失了几十万的业务。
说到底，修复 SQL 数据库的核心就两件事：一是冷静分析错误原因，别盲目操作；二是靠备份兜底。没有备份，再牛的技术也只能看运气。我建议每个 DBA 都做三件套：每天全量备份、每小时差异备份、每 5 分钟备份事务日志。同时，定期测试恢复流程，别等到真崩了才发现备份文件也是坏的。数据这东西，平时不觉得珍贵，丢一次就知道疼了。下次遇到数据库崩溃，先深呼吸，按我说的步骤来，大概率能救回来。实在救不了，也别自责，就当交学费，赶紧上容灾方案。毕竟，数据安全不是靠运气，而是靠制度。
