数据库现在正在恢复？别慌，先看看系统到底在干什么
你有没有遇到过这种情况：连接数据库报错，打开管理工具一看，状态栏赫然写着“数据库现在正在恢复”…… 后台跑着业务盯着你，领导催着要数据。说实话，这种时候心跳加速是正常的。但先别急着重启或者卸载重装，我们得先搞清楚这个“正在恢复”到底是个什么状态。 技王数据恢复
我是干数据恢复的，老碰到这种问题。其实“数据库现在正在恢复”本身是数据库引擎的一个常规状态——崩溃恢复、日志回滚或前滚、或是在应用日志里的未完成事务。大部分情况下它会自己完成，但有时候它就卡死了，几个小时纹丝不动。这时候很多人会慌，然后误操作。今天我就把自己的一些判断经验、实际案例和操作步骤拆给大家。 www.fixhdd.cn
第一阶段：判断是“真恢复”还是“死锁恢复”
，看到“数据库现在正在恢复”这个提示，先别急着动。我通常会做两件事：第一，检查错误日志；第二，看系统进程里是谁占了资源。SQL Server 的话，可以用 DBCC OPENTRAN 或 sys.dm_exec_requests 看看有没有长时间运行的回滚。如果是 MySQL，SHOW ENGINE INNODB STATUS\G 里能看到事务回滚进度。Oracle 则看 V$RECOVERY_PROGRESS。
www.fixhdd.cn
案例一：去年一家电商公司，凌晨做索引重建时服务器断电。早上开机，DBA 发现核心数据库一直显示“数据库现在正在恢复”，卡了快两小时。他们差点要强制恢复备份。我远程看了一眼，日志里有个巨大的回滚事务，回滚完成度才 12%。我建议他们再加一台服务器做日志传送备用，耐心等待。结果又等了 4 个小时，恢复完成，数据没丢。你看，这种情况下“数据库现在正在恢复”其实是数据库自己在保护数据的完整性，强行中断可能造成更严重的逻辑损坏。 www.fixhdd.cn
，也有一种情况是假象——数据库其实已经恢复完，但某个进程锁住了状态更新。我遇到过一次，SQL Server 版本 2016，重启后一直显示“数据库现在正在恢复”，但错误日志里没有任何回滚记录。后来用 SELECT * FROM sys.databases WHERE state_desc = 'RECOVERING' 发现数据库实际已在线，只是元数据卡了。杀掉那个残留的监控进程就好了。别全信界面，多看底层。
技王数据恢复
第二阶段：尝试手动干预的快慢选择
当你确定“数据库现在正在恢复”是卡住了且长时间没进度的，那么你可以选择以下几步，但一定要按顺序来，别跳。 技王数据恢复
1. 检查日志文件是否爆满或损坏
很多情况下，恢复卡住是因为日志文件空间不足或者日志链断裂。SQL Server 里可以查看 sys.database_files，如果日志文件大小达到上限且没有自动增长，恢复进程会等待空间释放。快速增加日志文件大小或添加新日志文件能救急。但注意：如果日志本身损坏，增加空间没用，得换方法。 www.fixhdd.cn
2. 使用紧急模式或单用户模式
如果上述无效，且数据库非常重要，我会考虑将数据库设置为紧急模式（EMERGENCY）并单用户模式，尝试以只读方式访问数据，把关键表先导出来。比如在 SQL Server 里：ALTER DATABASE [YourDB] SET EMERGENCY; ALTER DATABASE [YourDB] SET SINGLE_USER; 但注意这可能导致丢失未提交事务，备份当前事务日志再操作。曾经帮一家金融公司恢复数据，他们数据库一直“数据库现在正在恢复”，用紧急模式查到了大部分业务表，除了最近5分钟的数据丢失，但比全部丢失强多了。 技王数据恢复
这里提一嘴，我们团队（技王数据恢复）处理过不少类似案例，其中一次是超大型医院系统，数据库文件有900多GB，恢复卡了3天。当时我们直接使用底层文件解析工具，绕开SQL引擎直接从mdf和ldf碎片里提取数据，最终恢复了98%的记录。但那个级别难度太大，一般用户不建议自己尝试。
第三阶段：常见误区与防坑提醒
“数据库现在正在恢复”这个问题最怕的就是瞎操作。我见过有人直接重启 SQL 服务，结果重启后恢复状态重置，等于重新跑了一遍从头开始；也有人直接删掉日志文件用 DBCC REBUILD_LOG，但没先备份，结果日志链断了，数据库直接进入可疑状态。记住一条铁律：在任何操作前，至少备份一次当前事务日志（如果还能备份的话）。
- 错：看到“数据库现在正在恢复”就立即重启服务器。恢复进度会重置，而且可能造成数据不一致。
- 错：直接分离或附加数据库。恢复中的数据库不允许分离，强制分离会导致元数据损坏。
- 对：先查询动态管理视图，确认是回滚还是前滚，估算剩余时间。例如 SQL Server 里
SELECT percent_complete, estimated_completion_time FROM sys.dm_exec_requests WHERE command LIKE '%ROLLBACK%'。 - 对：如果时间耗不起，且数据极其重要，及时寻求专业数据恢复服务，比如之前提到的技王数据恢复那种级别，他们有专用工具处理卡死的恢复状态。
真实的案例：一个让我记忆犹新的周末
两年前的一个周五晚上，一家连锁超市的数据库（SQL Server 2014）因为 IO 子系统缓慢，导致 checkpoint 超时，重启后状态变为“数据库现在正在恢复”。IT 人员等了两个小时没变化，就手动重启了 SQL 服务——结果状态变成“RECOVERY PENDING”，更糟了。之后他们尝试用 DBCC CHECKDB，但数据库连检查都不允许。连夜找到我。
我让他们先检查了磁盘队列和日志文件大小。发现事务日志（ldf）已经增长到 200GB，而且磁盘剩余空间只有 10GB。恢复进程需要回滚一个巨大的删除操作，但因为日志文件无法继续增长，回滚被挂起了。我们没有直接删除日志（那等于自杀），而是先压缩了日志文件尾部的空闲空间，然后用 DBCC SHRINKFILE 把日志缩小到 50GB，腾出磁盘空间。接着让恢复继续，大约40分钟后状态变成“正在处理”，然后又过了1小时，数据库终于上线。全程数据零丢失。
你看，这个案例里面，每一步的判断都是基于“数据库现在正在恢复”背后的真实原因——日志空间不足。如果当时贸然重启或分离，后果会很严重。遇到这个问题，先冷静，走排查流程，别让恐慌代替理性。
总结：当“数据库现在正在恢复”出现时，你的检查清单
为了方便你记忆，我整理了一个简短的决策列表，你可以打印出来贴在机房。
- 确认状态真实情况：查看错误日志、DMV视图，判断是回滚还是前滚，进度百分比。如果进度在动，等。超过30分钟不动，进入下一步。
- 检查磁盘空间和日志大小：确保有足够空间让恢复完成。必要时清理临时文件或扩展日志文件。
- 评估能否接受部分数据丢失：如果可以，尝试紧急模式导出数据。如果不能，考虑专业数据恢复服务。
- 在专业人员指导下操作：别用网上搜来的“一招解决”博客，很多都是邪招。比如
REBUILD_LOG虽然能快速让数据库上线，但会造成数据丢失，且不可逆。 - ，永久解决：恢复后立即检查系统健康，调整自动增长设置、优化索引、做完整备份。避免下次再次陷入“数据库现在正在恢复”的困境。
回到开头那个问题：数据库现在正在恢复，到底该怎么办？记住，大多数时候它只是一个信号——数据库正在自己修复。给点耐心，用对工具，看对日志，多数问题都能解决。实在搞不定，找专业人士，别拿生产环境试错。这篇分享就到这，希望下次你看到“数据库现在正在恢复”时，心里有底。
本文作者系资深数据恢复工程师，长期从事SQL Server、MySQL、Oracle等数据库故障处理与数据抢救，部分案例经验来自技王数据恢复团队的真实项目。
