业内新闻

SqlServer 数据库重启后一直处在恢复中？别急，先看这几步

上个周末半夜接到客户电话，说他们核心业务库重启后一直卡在“正在恢复……”状态，整整三个小时没动静。项目经理急得差点要打飞的了。我让他先别重启、别做任何操作，远程过去一看，SSMS 里那个数据库显示“正在恢复”，而且 transaction log 文件已经撑到 200GB 了。 www.fixhdd.cn

这种“sqlserver数据库重启后一直处在恢复中”的故障其实挺常见，尤其出现在意外断电、强制关机或者日志文件异常增长之后。SQL Server 在启动时会对所有未完成的事务做前滚或回滚，如果恢复操作太慢，或者某些 checkpoint 卡住，数据库就会一直显示“恢复中”状态，甚至持续数天。

技王数据恢复

先判断：是真恢复还是死锁住了？

有的人一看到“恢复中”就以为是数据损坏，其实不一定。我常用的快速判断方法是：

技王数据恢复

执行 SELECT * FROM sys.dm_exec_requests WHERE session_id = (SELECT session_id FROM sys.dm_exec_sessions WHERE program_name = 'Microsoft SQL Server Management Studio') 之类的查询，但更直接的是用 DBCC SQLPERF(LOGSPACE) 看看日志空间使用情况。
观察 sys.dm_exec_requests 里 wait_type 是什么。如果是 LCK_M_* 等待，那可能是锁冲突导致恢复阻塞；如果是 WRITELOG 或 IO_COMPLETION，那多半是磁盘性能问题。
最粗暴的方式：看 errorlog。打开 SQL Server 错误日志，搜 “Recovery of database”，它会告诉你正在做什么，比如 “Rolling back transaction X” 或 “Analysis of database”。

有一次客户说数据库一直恢复，我分析 errorlog 发现它在回滚一个长达 48 小时未提交事务，这种大事务回滚需要的时间可能比事务运行时间还长。没办法，只能等，或者——如果业务允许——用 KILL 杀掉那个事务然后恢复 checkpoint？不行，那是找死，还是老实等。 www.fixhdd.cn

常见原因和解决思路

1. 大事务回滚 / 前滚

重启前有未提交的长时间运行事务，恢复时数据库引擎必须把它回滚（或者如果崩溃后需要前滚）。日志文件巨大时，这个过程可能几个小时甚至几天。我在一次处理一个电商数据库时，它因为某个报表事务占用了大量资源，断电后重启，sqlserver数据库重启后一直处在恢复中。通过 DBCC OPENTRAN 查到一个活动事务，估算回滚时间大约 15 小时。客户等不了，我们（技王数据恢复团队）建议先做日志尾部备份（如果可能）然后尝试强制恢复（设置恢复间隔等），但业务允许我们等到次日凌晨做完。 www.fixhdd.cn

2. 日志文件损坏导致恢复卡死

更严重的情况：重启时 SQL Server 读取日志文件时发现 I/O 错误，比如坏扇区、文件系统问题。这种情况下恢复进程会反复重试，看起来永远在“恢复中”。需要提前判断：
用 SELECT physical_name, state_desc FROM sys.master_files WHERE database_id = DB_ID('你的库') 看文件状态。如果 state_desc 是 SUSPECT 或 RECOVERY_PENDING，那已经严重了。这时可以考虑从备份还原，或者用第三方工具（比如技王数据恢复的底层读取）提取日志再重建。技王数据恢复

3. 磁盘 I/O 瓶颈 / 内存不足

特别是虚拟化环境下，存储延迟高或 CPU 被抢占，恢复过程非常慢。检查磁盘队列长度和平均等待时间。可以把数据库单独放到更快的磁盘上，或者增加 SQL Server 的 -T 1118 之类的跟踪标记？不对，那是针对 tempdb 的。我一般建议先确认硬件不是瓶颈，然后调整恢复行为——例如设置 RECOVERY INTERVAL 为很短的值？但不一定有效，因为恢复是内部过程。技王数据恢复

紧急情况下的抢救步骤

不要重启！ 重复重启只会让恢复进度归零。
打开 SQL Server 错误日志，看几行，找到正在进行的恢复操作。搜索 “Starting up database”，留意它是否指定了 RestoreWithNoRecovery 或 Recovery with redo/undo。
查看 sys.dm_exec_requests 中恢复线程的 wait_type 和 wait_resource。如果 wait_type = RECOVERY，那是正常等待。
如果日志没有损坏，且只是慢，唯一的办法是等待。可以临时给数据库设置 RECOVERY_SIMPLE？不行，必须在一次 recovery 过程中改不了。除非你手动杀掉恢复进程？那不是找死吗。
如果怀疑日志损坏，并且有最近完整备份，考虑 从备份还原并使用 STANDBY 模式，但这意味着丢失一部分数据。没有备份的话，就要用底层工具了，我们技王数据恢复曾处理过一个案例，用十六进制编辑器修复了日志文件头的一处损坏扇区，然后数据库顺利恢复。

经验小贴士：如何避免这个问题

定期 CHECKPOINT 并 BACKUP LOG，避免日志无限增长。
尽量让大事务拆分成小批次，避免长时间运行事务导致重启后恢复巨慢。
配置 服务器硬重启保护（UPS + 正常关机脚本）。
监控 log_reuse_wait_desc，如果一直显示 ACTIVE_TRANSACTION 要警惕。

一个奇怪的案例

有一次客户说他们的数据库在正常重启后一直处在恢复中，但错误日志里没有任何回滚或前滚信息。我用 DBCC CHECKDB 调试——当然，在恢复中的库上不能运行 CHECKDB。后来发现是某个第三方备份软件在重启时锁住了文件句柄，SQL Server 无法完成的恢复确认。杀掉那个进程后，数据库瞬间恢复正常。遇到 sqlserver数据库重启后一直处在恢复中，别忘了检查是否有其他进程占用了数据库文件。技王数据恢复