如何解决SQL数据库卡在恢复模式的问题

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 数据库恢复的3个阶段

通常，在 SQL Server 重新启动时，若数据库未正确关闭，则会经历崩溃恢复，确保数据库保持一致。SQL 数据库需要经历三个恢复阶段：

阶段1：分析

这个阶段从“最后一个检查点到事务日志结束”开始。它创建了一个“脏页表”（DPT）表，帮助确定在崩溃时所有脏页。另外，它创建了一个“活动事务表”（ATT）表，以识别在SQL服务器停止时未提交的事务。

阶段2：重做

在这个阶段，SQL服务器将在检查点之后崩溃之前发生的所有更改向前回滚。实质上，在重做阶段，所有已提交但尚未通过检查点写入SQL数据文件（.mdf/.ldf）的事务都需要向前回滚。

阶段3：撤销

如果在数据库恢复时存在未提交的事务，则它们必须在撤销阶段回滚，使数据库达到一致状态。

如果您的数据库陷入恢复模式怎么办？

检查SQL服务器错误日志，查看数据库中可能看起来类似于以下的第一条消息：

Starting up database ‘DatabaseName’

这意味着数据库文件已打开，并且恢复过程已经开始。稍后，您应该看到SQL服务器正在进行3个恢复阶段。如果您正在寻找有关如何备份和还原数据库的指导，请查看这篇有关备份和还原Azure SQL数据库的指南。

数据库恢复的第1阶段如下所示：

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.

在完成第1阶段后，SQL Server将经历第2和第3阶段的恢复：

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.

完成第2和第3阶段后，您将看到类似于：

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或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数据库被卡在“恢复中”模式时意味着什么，恢复的三个关键阶段（分析、重做和撤销），以及您可以采取的措施将数据库恢复在线。我们还讨论了可能的原因，从大型事务日志到太多的虚拟日志文件（VLFs）。

如果您的SQL数据库仍然被卡在恢复模式中，请记住耐心是关键。避免运行RESTORE命令，因为这会重新启动恢复过程。对于严重问题，手动干预失败的情况，考虑使用专业的SQL数据库修复工具来恢复您的数据。

如果您发现本指南有帮助，请与您的团队分享，或留下您的SQL恢复经验的评论。