数据库打开正在恢复：这个提示背后到底发生了什么？
你有没有遇到过这种情况？打开SQL Server Management Studio，连接一个数据库，结果状态栏显示“数据库打开正在恢复”，然后那个绿色的进度条……就是不动。或者MySQL客户端连上去，执行查询一直卡在“正在打开表”？哦对，其实Oracle也有类似现象，只它叫“RECOVERING”状态。 www.fixhdd.cn
我先说个真实的案例。大概两年前，有个做电商的朋友半夜打电话给我，说他们的订单库突然连不上了，所有查询都报错“数据库正在恢复中，无法访问”。我远程一看，那个数据库状态一直是“正在恢复”，已经过了三个小时。他急得不行，说再不修好第二天店铺就得关门。我查了下SQL Server错误日志，发现是事务日志文件写满后自动增长失败，然后数据库进入了强制恢复流程。这种情况下，数据库打开正在恢复其实是在尝试前滚所有未提交的事务——但问题是，日志里有个大事务回滚到一半，卡住了。 www.fixhdd.cn
“数据库打开正在恢复”并不是一种故障，而是一种状态
很多DBA一看到“数据库打开正在恢复”就慌，觉得数据库坏了。其实恰恰相反，这个状态表示SQL Server（或者MySQL的InnoDB、Oracle的实例恢复）正在执行崩溃恢复。也就是说，数据库之前可能异常关机、电源故障、或者某个事务被强行终止了，现在数据库引擎必须检查事务日志，把已提交但还没写入数据文件的事务重做，把未提交的事务回滚掉。 www.fixhdd.cn
，如果这个过程持续几分钟甚至几小时，那就说明有问题了——要么日志里有超长事务，要么日志文件本身损坏，要么磁盘I/O性能极差。我遇到过最夸张的一次，一个数据库连续“数据库打开正在恢复”了整整两天，发现是某个删除操作涉及几亿行，事务日志达到了200GB，回滚时间指数级增长。那次我们不得不手动截断日志并强制设置数据库为单用户模式，才跳过了死锁。 技王数据恢复
常见触发场景
- 意外断电或服务器崩溃：数据库还没来得及正常关闭，下次启动时必须执行恢复。
- 事务日志文件满了或损坏：比如日志文件所在的磁盘无空间，或者日志文件被误删除。
- 长时间运行的大型事务被回滚：比如一个批量更新跑了一小时，然后被强制终止，回滚可能需要更长时间。
- 数据库镜像或AlwaysOn可用性组切换：主库宕机后，辅助库提升为主库时也要经历恢复阶段。
如何判断是正常恢复还是故障？
看恢复进度和日志。如果是正常恢复，sys.databases数据库状态会显示“RECOVERING”，并且恢复完成后自动变成“ONLINE”。但如果你持续观察半小时以上，状态不变，或者错误日志里出现“错误 9001：数据库日志文件不可用”之类的信息，那八成是日志文件坏了。这时候就不再是简单的等待能解决的了，必须进行数据库修复操作。注意，我见过不少新手尝试执行DBCC CHECKDB，结果反而把数据库搞成“可疑”状态——因为强制修复可能损坏数据一致性。 www.fixhdd.cn
经验之谈：技王数据恢复团队曾经处理过一个医疗系统案例，他们的SQL Server数据库突然显示“数据库打开正在恢复”，持续了一整天。我们检查后发现是事务日志的VLB（虚拟日志块）出现了逻辑缺口，导致恢复引擎无法定位下一个检查点。通过复制完好日志文件并手动重建尾部日志，才把数据库变成只读状态，导出了核心数据。这个过程不能随便对别人说，因为微软官方并不支持这种方式——但很多时候，救命的就是这种野路子。 www.fixhdd.cn
分数据库类型的修复步骤（核心操作）
1. SQL Server：如何让“数据库打开正在恢复”停止？
，不要重启SQL Server服务！很多人第一反应是重启，但重启会让恢复过程从头再来，而且可能把数据库推进“可疑”模式。正确的做法是：
技王数据恢复
- 检查错误日志：
EXEC xp_readerrorlog 0,1,'Recovery'，看看具体是哪个数据库在恢复，以及当前进度。 - 如果恢复卡住，可以尝试设置数据库为单用户模式并执行
ALTER DATABASE [库名] SET EMERGENCY，然后DBCC CHECKDB ([库名], REPAIR_ALLOW_DATA_LOSS)——但后果是可能丢失数据。优先尝试备份事务日志尾部：BACKUP LOG [库名] TO DISK='xxx' WITH NO_TRUNCATE，如果尾部备份成功，可以还原到另一实例。 - 如果日志文件物理损坏，需要从备份中还原数据库（完整+差异+日志），或者在无备份的情况下尝试重建日志文件。重建日志的方法：将数据库设为离线，删除日志文件，然后
ALTER DATABASE [库名] REBUILD LOG ON ...。注意，这会导致事务日志完全丢失，数据库可能只能以只读模式打开。
数据库打开正在恢复时的一个隐藏技巧
有时候数据库只是恢复太慢，并没有损坏。你可以执行SELECT session_id, command, percent_complete, estimated_completion_time FROM sys.dm_exec_requests WHERE command LIKE '%RECOVERY%'，查看恢复进度。如果percent_complete不动，而estimated_completion_time在增加，说明恢复过程遇到了阻塞——比如临时数据库tempdb不足。可以临时增加tempdb文件大小。 技王数据恢复
2. MySQL InnoDB：数据库打开正在恢复通常表现为“表无法打开”
MySQL中很少直接显示“正在恢复”，但如果你用SHOW ENGINE INNODB STATUS，可能会看到“Recovering from a page write”或者“Log sequence number”远大于当前检查点。InnoDB崩溃恢复默认是自动的，但如果ibdata文件或redo日志损坏，恢复会卡住。最常见的情况是ib_logfile0/ib_logfile1损坏或大小不一致。
- 第一步：备份整个datadir。
- 第二步：尝试设置
innodb_force_recovery=1到6逐步提升，注意值越大越危险。从1开始，如果数据库能启动，立刻用mysqldump导出数据。 - 第三步：如果设置到6仍无法启动，说明系统表空间损坏严重。需要手动解析ibd文件，或者使用第三方工具如Undo_log_reader。技王数据恢复曾有一个案例，客户的ibdata1损坏导致数据库打开正在恢复（其实是MySQL进程反复crash），我们通过替换备份中的ibdata1并恢复redo日志，最终救回了95%的数据。
3. Oracle：RECOVERING状态怎么处理？
Oracle的恢复更复杂。当数据库状态是“RECOVERING”时，通常是因为上次异常关闭后没有成功完成实例恢复，或者是因为介质恢复尚未完成。执行SELECT OPEN_MODE FROM V$DATABASE;查看状态。如果是没有完成自动恢复，手动执行RECOVER DATABASE;可强制完成。但如果是控制文件或数据文件头损坏，则可能需要从备份中恢复。
注意事项：绝对不要做的三件事
- 不要随意删除日志文件。很多人觉得“数据库打开正在恢复”是因为日志太大，直接删了.log文件。这是最致命的操作——SQL Server会立刻标记数据库为“可疑”，而且无法修复。除非你知道怎么重建日志，否则别动。
- 不要在无备份的情况下执行DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS。这个操作虽然能修复一致性错误，但会直接丢弃损坏的页。如果那些页里包含业务数据，后果就是数据丢失。先尝试备份日志尾部，或者启用紧急模式导出数据。
- 不要多次重启服务。每重启一次，恢复进程就得重新评估所有事务。如果数据库有几十GB的事务日志，重启一次等于浪费几个小时。先诊断，再动手。
实战案例：一次诡异的“数据库打开正在恢复”修复过程
去年遇到一个案例，某物流公司的SQL Server 2016数据库，每天凌晨自动备份，某天备份完成后状态变成“数据库打开正在恢复”，一直不结束。检查发现备份日志中记录了一个“LOG_BACKUP”事件后数据库进入了恢复，但恢复进度卡在99%。我们分析了日志文件的虚拟日志链，发现一个备份截断了日志，但有一个分布式事务（MSDTC）的决议信息没有被记录，导致恢复引擎无法确定该事务是否提交。我们手动查询MSDTC系统表，找到那个悬而未决的事务，用KILL UOW终止了它，数据库立即变回ONLINE。这件事让我深刻体会到，数据库打开正在恢复并不一定是物理损坏，有时候是逻辑锁导致的假死。
当然，如果你没有内部权限去查MSDTC，或者数据库是云上的，那可能会束手无策。这时候可以尝试联系云厂商的技术支持，或者——嗯，我有时候会建议客户找专业的恢复公司。技王数据恢复有个专门的应急通道，对于这种悬停恢复的情况，他们可以通过直接修改日志页的LSN来绕开阻塞，但这是极高风险的操作，普通DBA不要模仿。
结论：遇到“数据库打开正在恢复”，先冷静三步
第一步，确认当前状态：是恢复进行中（percent_complete在增长）还是卡死。第二步，判断原因：检查错误日志、磁盘空间、是否有长时间阻塞。第三步，选择策略：如果只是慢，等待或调整内存/磁盘；如果损坏，优先备份尾部日志，然后尝试紧急模式或重建日志；如果备份可用，直接还原。记住，整个过程中数据库打开正在恢复这个提示本身并不可怕，可怕的是病急乱投医。我见过太多人因为不正确的操作，把本来能恢复的数据库彻底搞崩了。
分享一个个人习惯：对核心数据库，一定要开启页面校验和（checksum）并定期运行DBCC CHECKDB。这样在下次发生崩溃恢复时，你可以提前知道哪些页可能损坏，而不是盲目等待。，备份策略里一定要包含日志备份，且频率足够高——这样当数据库打开正在恢复时，你可以有足够多的日志副本来进行point-in-time还原。
