在这个阶段，SQL Server会前滚在检查点之后和崩溃之前发生的所有更改。实际上，在重做（Redo）阶段，所有已经提交但尚未通过检查点写入SQL数据文件（.mdf/.ldf）的事务都需要前滚。
第三阶段：撤销
如果在数据库恢复时存在任何未提交的事务，则必须在撤消阶段回滚这些事务，以使数据库恢复到一致状态。
如果数据库陷入“恢复中”模式应该怎么办？
检查SQL Server错误日志，查看数据库中可能类似以下内容的第一条消息：
复制
Starting up database ‘DatabaseName’
这意味着已经打开数据库文件，并且恢复过程已经开始。在一段时间后，将会看到SQL Server正在经历三个恢复阶段。如果正在寻找有关如何备份和恢复数据库的指导，可以查看有关备份和恢复Azure SQL数据库的指南。
数据库恢复的第一阶段如下所示：
复制
Plain Text
Recovery of database ‘DatabaseName’ (9) is 0% complete (approximately 95 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
Recovery of database ‘DatabaseName’ (9) is 3% complete (approximately 90 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
在第一阶段完成炎后，SQL Server数据库将会继续执行恢复流程的第二和第三阶段。
复制
Recovery of database ‘DatabaseName’ (9) is 5% complete (approximately 85 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required…
Recovery of database ‘DatabaseName’ (9) is 95% complete (approximately 40 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
Phase 3 of 3. This is an informational message only. No user action is required.
一旦第二阶段和第三阶段完成，将会看到类似以下的信息：
复制
3807 transactions rolled forward in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
0 transactions rolled back in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery is writing a checkpoint in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.
Recovery completed for database DatabaseName (database ID 9) in 30 second(s) (analysis 1289 ms, redo 29343 ms, undo 72 ms.) This is an informational message only. No user action is required.
在错误日志中，注意“不需要用户操作”的消息，这表明数据库处于恢复状态。但是，恢复可能需要比预期更长的时间，导致数据库一直陷入“恢复中”模式中。
SQL数据库陷入“恢复中”模式的原因
以下是可能导致SQL数据库陷入“恢复中”模式的一些原因：
长时间运行的事务正在回滚
事务日志文件非常大
数据库事务日志中包含过多的虚拟日志文件（VLF）
SQL Server存在bug，现在已经修复。
如何使数据库恢复到一致状态？
解决方法1：等待数据库恢复完成
使数据库重新联机的最直观的解决方案是耐心等待恢复过程完成；这可能需要几个小时或几天的时间。如果SQL Server 2008或SQL Server 2008 R2中的数据库恢复时间比预期的长，那么应用Microsoft修复程序可能会有所帮助。
注：避免运行RESTORE命令使数据库处于一致状态，因为SQL Server已经在尝试执行相同的任务。然后，运行“RESTORE with..Recovery”意味着让数据库再次执行相同的步骤。
解决方案2：使用专业的SQL数据库修复工具
如果恢复过程完成，但未能将数据库恢复到一致状态，则使用专门的SQL修复工具可以帮助将数据库恢复到原始状态。
Stellar Repair for MS SQL——这款专业的工具可以帮助在SQL数据库损坏或发生故障后将其恢复到原始状态。
ApexSQL Recover——这款工具可以恢复已经删除、截断或损坏的SQL Server数据库中的数据。
dbForge SQL Complete——虽然它主要是一款IDE扩展工具，但它提供了有用的错误处理和故障排除功能。
Redgate SQL Data Recovery——Redgate提供了一系列SQL Server工具，包括数据恢复功能。
SysTools SQL Recovery Tool——这款工具可恢复损坏的SQL数据库文件（.MDF和.NDF）到可用状态。
Kernel for SQL Database Recovery——这款工具可以从损坏和意外关闭的情况中恢复和还原SQL Server数据库。
Aryson SQL Database Recovery——这款工具可以修复和还原SQL Server中的MDF和NDF文件。
结论
本文介绍了SQL数据库陷入“恢复中”模式时的含义、恢复的三个关键阶段（（分析、重做和撤消），以及如何使数据库重新联机。此外还讨论了可能的原因，从大型事务日志到过多的虚拟日志文件（VLF）。
如果SQL数据库仍然陷入“在恢复中”模式，至关重要的是要保持耐心。避免运行RESTORE命令，因为这会重新启动恢复过程。至于那些无法通过人工干预解决的严重问题，可以考虑使用专业的SQL数据库修复工具来恢复数据。返回搜狐，查看更多