业内新闻

SQL SERVER 数据恢复：从崩溃到重生的真实记录

你经历过那种绝望吗？——凌晨三点，系统警报炸响，SQL Server 日志文件突然写满，数据库直接进入“可疑”状态，所有业务停摆。这时候你第一反应是什么？重启服务？还是开始祈祷？ www.fixhdd.cn

我干数据恢复这行快十年了，碰到过 SQL SERVER 数据恢复 的案例少说也有上百个。说实话，每次接手新项目，心里仍然会咯噔一下——因为没有任何两个损坏场景是完全一样的。今天我就把几个印象深刻的案例掰开揉碎，说说我是怎么一步步判断、操作、最终把数据捞回来的。不保证能解决你手上所有问题，但至少能让你少走一些弯路。 www.fixhdd.cn

一、先别慌，搞清楚“伤”在哪

接到求助电话，我通常先问三个问题：
1. 数据库能不能启动？报什么错误？
2. 是数据文件（.mdf）坏了，还是日志文件（.ldf）出了问题，还是两个都崩了？
3. 有没有最近的完整备份？

www.fixhdd.cn

这三个问题直接决定了恢复方向。比如有一次，某电商公司主库因为磁盘坏道导致 .mdf 文件头页损坏，SQL Server 直接拒绝附加数据库，错误提示“文件头不是有效页”。这时候如果盲目尝试 detach/attach，很可能连残余的可用数据都堵死。正确的做法是先用 DBCC CHECKDB 或者底层扇区读取工具确认损坏范围——但要注意，在“可疑”状态下直接跑 DBCC 可能把数据库彻底搞死，我一般建议先做文件级镜像，再对镜像操作。技王数据恢复

案例一：误删除表数据，幸好日志还在

去年有个朋友的公司员工手滑，在 production 环境执行了 DELETE FROM Orders WHERE OrderDate —— 没写事务，直接提交，二十万条订单瞬间蒸发。还好当时 SQL Server 是完整恢复模式，日志文件没被截断。我远程过去用技王数据恢复的日志解析工具（其实我们自己研发的底层解析脚本）读了 LDF 文件里未提交前的 undo 记录，把被删除的数据一步步还原到一张临时表，整个过程大概花了三小时。这里有个关键点：发现误操作后，第一时间要停掉所有可能触发 checkpoint 的定时任务，否则日志活跃部分会被截取，事后恢复难度指数级上升。 www.fixhdd.cn

经验教训：完整恢复模式下的日志文件就像黑匣子，只要不大面积覆盖，很多“已删除”数据其实还能捞回来。但别指望第三方工具能100%完美，很多时候需要手动拼接事务序列。技王数据恢复

操作步骤（基于日志恢复误删数据）

第一步：立即备份当前的日志尾部（BACKUP LOG ... TO DISK WITH NORECOVERY），保留的未提交事务。
第二步：将数据库恢复到误删除之前的时间点，利用完整备份和差异备份，再配合日志备份（如果有）。如果没有备份，则需直接通过 fn_dblog 读取活跃日志。
第三步：解析日志记录中的 'LOP_DELETE_ROWS' 操作，提取每一行被删除数据的前镜像（Before Image）。这一步通常需要写 T-SQL 或借助专业工具，手动拼 SQL 插入语句。
第四步：将恢复的数据插入到临时数据库，验证完整性后再迁回原库。

注意：fn_dblog 在 SQL Server 2008 以上版本里默认只返回少量信息（需要开启跟踪标志 2537 或其他方式解锁），而且读取大量日志可能导致性能飚升。对于几百 GB 的日志，更推荐用底层解析引擎直接扫描 LDF 文件，这是技王数据恢复内部团队在处理超大库时的标准做法。

www.fixhdd.cn

二、MDF 数据文件损坏：更棘手的局

比起误删，数据文件物理损坏才是真正的噩梦。比如：电源掉电导致 SQL Server 写入过程中崩溃，或者存储阵列 RAID 卡坏了重建后文件出现坏块。这时候你可能会看到类似“错误 823”、“无法读取页 (1:345)”这样的消息。 www.fixhdd.cn

我的原则是：能不打开数据库就不打开，能挂载副本绝不碰原文件。然后分三步走：

先判断损坏范围：用小工具查看每个 GAM、SGAM、PFS 页的完整性，确认有多少个分配单元受到波及。
尝试 DBCC CHECKDB 的 REPAIR_ALLOW_DATA_LOSS 选项——，这句话我说得很犹豫，因为这个选项会直接删除损坏的页和关联记录，导致数据丢失。只有在业务能承受部分损失，且无更好方法时才用。
逐页提取可用数据：用底层读取方式把未损坏的数据页导出来，再重建表结构和索引。这就像在废墟里捡还能用的砖头。

案例二：某金融系统 MDF 文件头损坏，但数据页完整

那次更玄妙。客户的 SQL Server 2012 数据库无法启动，错误提示“数据库文件头无效”。通过二进制查看，发现 .mdf 文件前 64KB 全部被写成了零——估计是存储层的误操作。文件大小没有变，后面的数据页扇区看起来完好。我复制了一份文件，然后手动构造了一个模拟的文件头，再从同版本 SQL Server 里导出一个空的数据库模板，把它的文件头复制过来，再调整一些元数据偏移量。反复试了四次才成功附加。最终恢复率大概 98%，丢失的恰好是 sys.sysdbreg 里的几个系统记录，不影响业务主表。这种修复手动操作要求极高，普通工具基本做不了。

提示：如果你没有十足的把握，千万别在源文件上动手。很多“修复工具”宣称一键修复，背后往往是直接 truncate 掉损坏页，数据说没就没。先做完整镜像，再在镜像上测试。

三、日志文件损坏或丢失怎么办？

SQL SERVER 数据恢复 中另一个高频场景就是日志文件失踪或者日志链断裂。比如有人误删了 .ldf 文件，或者重建日志时把旧日志覆盖了。这时候数据库会处于“恢复挂起”状态。

处理思路其实就两条线：

如果数据库是简单恢复模式，可以直接重建日志文件，因为简单模式不依赖日志链。方法：将数据库设为紧急模式，分离后删除旧日志引用，再附加时让 SQL Server 自动创建新日志。但风险是可能会丢失一次检查点之后未写入数据文件的事务。
如果数据库是完整或大容量日志恢复模式，又没做日志备份，那麻烦大了。这种情况下，唯一可能的是尝试从 MDF 文件扫描所有已提交事务的记录（MDF 本身也包含部分已提交的数据），然后通过模拟一个空日志让数据库认为一致性达到某个点。成功率很低，通常需要专业的数据恢复公司介入。

2022 年我处理过一个案例，客户误删了全部 .ldf 文件（日志文件），但 .mdf 是 1.2TB，数据量巨大。客户公司的 IT 想尝试直接用“附加数据库”勾选“删除日志文件” —— 结果附加失败，又用 DBCC REBUILD_LOG 命令手动重建日志，导致 MDF 内部结构被降级。最终转到我手里时，MDF 文件已经多处不一致。花了整整四天，用底层扇区扫描把每张表的行数据提取出来，重新搭建了一个数据库。那次之后，我对 技王数据恢复 的团队说：以后凡接到日志丢失的案例，必须先问客户是否执行过任何重建操作，操作顺序几乎决定生死。