咱们搞数据库的，最怕屏幕弹出“正在恢复”这几个字。就像你正开车，仪表盘突然亮起红灯，心里咯噔一下。我见过太多运维兄弟，一看到 SQL Server 显示这个状态，就慌了神，赶紧重启服务，结果反而把问题搞得更复杂。其实这东西没那么玄乎，就是 SQL Server 在启动时要检查事务日志，看看哪些数据已经写到硬盘，哪些还在内存里没来得及存。这个过程就像你早上起床，先翻翻手机，看看昨晚有没有漏接重要电话。
先说个真实案例。上个月一个做电商的朋友半夜打电话，说他们的订单数据库挂了，显示“正在恢复”已经快一个小时了。我让他先别慌，查查日志文件有多大。他一看，事务日志竟然有 200 多 GB。这就是典型的问题——数据库在启动时，需要把日志里记录的所有未完成事务从头到尾重放一遍。日志越大，恢复时间就越长。就像你要整理一堆发票，票据越多，对账的时间自然就越久。这种情况下，最忌讳的就是反复重启服务，每次重启都会让恢复过程重新开始，白忙活一场。
那具体怎么判断这个问题是正常还是异常呢？关键看两个指标：数据库文件大小和恢复进度。如果是小数据库，比如日志文件只有几百兆，几分钟内恢复完都算正常。但要是日志文件几十 GB，恢复时间超过半小时，就得留个心眼了。我教大家一个土办法：打开 SQL Server Management Studio，右键点击数据库，选择“任务”→“收缩”→“文件”，看看日志文件的实际大小和已用空间。如果已用空间接近总大小，说明日志文件确实需要较长时间才能恢复。
还有一种更隐蔽的情况：数据库明明已经恢复完了，但状态仍显示“正在恢复”。这通常是因为有其他进程占用了数据库文件。我遇到过一次，运维同事为了备份，手动复制了 MDF 文件，却忘了释放文件句柄。结果 SQL Server 再启动时发现文件被锁住，就一直卡在恢复状态。排查这种问题，用系统自带的“资源监视器”最管用，看看是哪一个进程在占用数据库文件。
再说说怎么安全地处理“正在恢复”。如果确认是正常的恢复过程，就耐心等着。但如果实在等不及，或者数据库太大、恢复时间太长影响业务，可以尝试“紧急模式”。具体操作是：先用单用户模式启动 SQL Server，然后执行 。这样数据库会进入紧急模式，虽然只能读不能写，但至少能先把数据查出来。不过要注意，这招是治标不治本，紧急模式下数据库的完整性可能会受影响。
真正的高手都是提前预防。我建议每个 DBA 养成两个习惯：一是给事务日志做定期备份，防止它无限增长；二是每次重启 SQL Server 服务前，先检查数据库状态，确认没有未完成的事务。一个小技巧是使用 命令，查看当前是否有打开的事务。如果发现有长时间未提交的事务，先处理掉再重启，能大幅减少恢复时间。
说句掏心窝的话：很多人遇到“正在恢复”就慌，是因为不懂背后的原理。其实 SQL Server 的恢复机制非常成熟，大多数情况下，你什么都不做，它自己就能恢复。真正需要警惕的是那些反复恢复失败的情况。这时就要检查硬盘是否有坏道、内存是否有问题，甚至考虑是否该换服务器。数据库这东西，跟人一样，小病不治，大病难医。平时多留点心，关键时刻才能不慌不忙。
