译者 | 李睿
审校 | 重楼
SQL Server数据库偶尔会陷入“恢复中”（In Recovery）模式，这通常会让数据库管理员感到措手不及。这种状态通常发生在数据库重启、恢复或意外关闭期间，因为SQL Server需要重放或撤销不完整的事务以保持数据完整性。虽然这个过程通常是自动执行的，但有时可能会比预期花费更长时间，甚至看起来停滞不前，这导致数据库管理员不知所措。
如果遇到了这个问题，不要担心。本文将帮助他们了解幕后发生的事情，并提供应对策略。以下是需要了解的内容：
- “恢复中”模式意味着什么——为什么数据库会进入这种状态，以及SQL Server在后台执行的操作。
- SQL Server数据库恢复的三个阶段——详细分析SQL Server在恢复过程中遵循的分析、重做和撤销阶段。
- 导致延迟的常见原因——从大型事务日志到过多的虚拟日志文件（VLF），查看可能减缓进程的原因。
- 如何恢复在线状态——学习将数据库恢复到一致状态的实用步骤，从等待到使用SQL修复工具。
- 何时寻求高级帮助——如果恢复过程看似停滞不前且没有取得任何进展，可以了解应该怎么做。
通过阅读这一指南，将全面了解SQL Server的恢复过程以及可用于尽快将数据库恢复在线的工具。
理解SQL Server中的“正在恢复”模式
当SQL Server重启或从备份中恢复数据库时将会进入“恢复中”模式，以保持数据的完整性。在这个阶段，SQL Server重放或撤销不完整的事务，以防止数据损坏并确保事务一致性。
在重启SQL Server之后，数据库进入“恢复中”模式。SQL Server数据库在启动时或从备份中恢复时也可能处在“恢复中”状态。
图1 SQL数据库陷入“恢复中”模式
数据库处在“正在恢复”状态意味着正在执行恢复过程，并在这一过程完成后自动联机。但是，可能会遇到恢复缓慢且数据库陷入“恢复中”状态。数据库可能仍然处于恢复状态，因为SQL数据库要经历三个恢复阶段，而这一过程的恢复时间取决于数据库文件的大小。
SQL数据库恢复的三个阶段
通常情况下，当SQL Server重启时数据库没有正确关闭时，它会进行崩溃恢复，以确保数据库保持一致。SQL数据库需要经历三个恢复阶段：
第一阶段：分析
这个阶段从“最后一个检查点开始，直到事务日志结束”。它创建一个“脏页表”（DPT）表，帮助确定崩溃时的所有“脏页”。此外，它还创建一个“活动事务表”（ATT）来标识SQL Server停止时未提交的事务。
第二阶段：重做
在这个阶段，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数据库修复工具来恢复数据。
原文标题：How to Fix SQL Database Stuck in Recovery Mode，作者：Daniel Calbimonte
