搞数据库的人最怕什么？不是数据丢了，也不是服务器宕机，而是打开 SQL Server Management Studio 一看，数据库状态栏明晃晃挂着四个字——“正在恢复”。更让人抓狂的是，这个“正在恢复”可能持续好几个小时，甚至好几天。你点刷新、重启服务器，它还是纹丝不动。遇到这种情况，千万别慌，也别傻等。今天咱们就聊聊 SQL 2008 数据库卡在“正在恢复”状态时，五个真正管用的解决步骤，按顺序操作，大概率能把你从苦海里捞出来。
先搞清楚一件事：数据库为什么会卡在“正在恢复”？说白了，就是 SQL Server 在启动时，需要把事务日志里未完成的操作回滚或前滚，才能让数据库恢复可用状态。正常情况下，这个过程几秒到几分钟就结束了。但如果事务日志特别大、磁盘 I/O 性能差，或者系统非正常关机导致日志里积压了海量未完成事务，恢复过程就会变成一场马拉松。我见过最夸张的案例：一个 100 GB 的日志文件，恢复跑了整整 40 小时。所以，别指望它自己突然变快，得主动干预。
第一步，也是最简单的一步：检查是否有其他进程锁住了数据库。打开 SQL Server Management Studio，执行看看有没有正在执行的恢复操作。如果有，记录下它的 sessionid，然后执行 。注意，这个操作只对非系统进程有效。如果恢复进程是系统自带的（比如 sessionid ≤ 50），就不能直接杀。这时，你需要检查是否有其他用户连接或备份作业占用数据库。用 看看所有连接，把那些无关的进程都杀掉，说不定数据库就自己活过来了。
第二步，如果杀进程不管用，那就试试把数据库设为紧急模式。这个操作相当于告诉 SQL Server：“别管那些乱七八糟的恢复逻辑了，先把数据库给我弄出来。”执行语句很简单：设置成功后，数据库状态会变成“紧急”。这时你可以看到表结构，但数据可能不完整。接下来把数据库设为单用户模式，然后执行注意，这一步有数据丢失的风险，它会丢弃因恢复卡住而损坏的页。如果你有完整备份，这是最快的解决方案；如果没有备份，就要格外谨慎。
第三步，如果紧急模式也不管用，或者你不想冒数据丢失的风险，就得从日志文件下手。有时候问题出在日志文件本身太大或已损坏。你可以尝试把日志文件分离，让数据库重新创建一个新日志。操作步骤如下：1. 将数据库设为脱机：2. 找到对应的 .ldf 文件，重命名或移动到别处。3. 再把数据库设为联机：SQL Server 会发现日志文件缺失，自动创建一个新的空日志文件。此方法的好处是不会丢数据，前提是数据文件（.mdf）本身完好。如果数据文件也有问题，这个办法就无效了。
第四步，如果以上三步都无效，就得动用“核武器”——重建事务日志。这个方法适用于日志文件超大（几十 GB 甚至上百 GB）导致恢复卡住的情况。先把数据库切换到单用户模式：然后尝试收缩日志：如果命令成功，说明日志可以被压缩，问题可能就解决了。如果报错提示“无法收缩日志文件因为正在使用”，可以先备份数据文件，然后执行该操作不会丢失数据，只会清理一些非关键的一致性错误，让数据库能够启动。若仍不行，只能使用 ，但请务必先做好完整备份，因为这一步会导致数据丢失。
第五步，也是最无奈但最保险的一步：从备份恢复。如果前面四个步骤都试过了，数据库仍卡在“正在恢复”，就别再浪费时间了。找最近的完整备份，加上相应的日志备份，进行还原。还原时选择 选项，恢复完成后数据库即可直接使用。如果没有备份，只能求助第三方修复工具，如 ApexSQL Recover、Stellar Repair for MS SQL 等。这类工具可以扫描损坏的 MDF/ LDF 文件，尽可能提取出可读数据。虽然价格不菲，但比起数据彻底丢失要划算得多。建议平时一定要开启定期备份，哪怕每天只备份一次，也比硬扛恢复强一万倍。
说句实在话，SQL 2008 已经是个老古董，微软早在 2019 年就停止了对它的主流支持。如果你的生产环境仍在使用这个版本，强烈建议尽早升级到 2016 或 2019。新版本在恢复机制上做了大量优化，卡恢复的概率低得多。实在没法升级，也可以关闭自动关闭功能：这能减少数据库在频繁开关机时出问题的几率。另外，监控日志文件大小，避免它超过数据文件的三分之一，超过后及时备份日志并收缩。记住，预防永远比修复省心。下次再看到“正在恢复”，别慌，按这五步走，大概率能把数据库救回来。如果实在救不回来，也别自责，数据库这东西，谁没遇到过几个坑呢？
