SQL Server 数据库处于恢复模式？立即获取 10 个行之有效的修复方案！从简单修复到高级修复，一步步为您解答。
1.理解 SQL Server 数据库恢复模式
1.1 什么是恢复模式 SQL Server
当 SQL Server 数据库显示“恢复中”状态，这意味着 SQL Server 正在执行崩溃恢复或事务恢复以确保数据库一致性。此自动过程通过重放已提交的事务并回滚未提交的事务来维护数据完整性。
恢复模式通常在意外关机、电源故障或数据库还原期间发生。虽然这是一种正常的保护机制，但当 SQL Server 数据库恢复时间异常长或出现卡住的情况。
1.2 数据库恢复的三个阶段
SQL Server 恢复分为三个不同的阶段：
1.2.1 分析阶段
SQL Server 从上一个检查点开始扫描事务日志，以识别脏页和活动事务。它会创建脏页表 (DPT) 和活动事务表 (ATT) 来跟踪需要恢复的内容。
1.2.2 重做阶段（前滚）
系统会重放崩溃前未写入磁盘的所有已提交事务。这确保所有已提交的更改都正确应用于数据库文件。
1.2.3 撤消阶段（回滚）
任何未提交的事务都会被回滚，以维护数据库的一致性。一旦完成，数据库即可用于正常操作。
1.3 常见症状和错误消息
当你的 SQL Server db 正在恢复，您通常会看到：
- 数据库名称显示“（恢复中）” SQL Server 管理工作室
- 登录失败并显示“数据库正在恢复”消息
- 显示恢复进度百分比的错误日志条目
- 查询时数据库状态显示“RECOVERING”
2. 根本原因 SQL Server 恢复模式问题
2.1 不完整的还原操作
该米ost 常见原因发生在使用多个备份文件恢复时 无法恢复 没有最终决定权的选项 恢复 命令。这将使数据库等待其他恢复操作。
2.2 事务日志问题
大型事务日志文件或过多的虚拟日志文件 (VLF) 会显著降低恢复速度。当 MS SQL 数据库恢复时，如果 VLF 数量达到数千个，则恢复过程可能需要数小时甚至数天才能完成。
2.3 系统相关问题
硬件故障、断电或磁盘空间不足可能会中断正常的数据库操作，从而引发恢复过程中漫长的恢复过程。tart.
2.4 数据库损坏
损坏的数据库文件会阻止恢复成功完成，导致数据库无限期地停留在恢复模式。
3. 诊断ost修复前的步骤
3.1 检查 SQL Server 错误日志
在尝试修复之前，请检查 SQL Server 错误日志中查找恢复进度消息。查找显示完成百分比和预计剩余时间的条目。
- 可选 SQL Server 管理工作室
- 导航 管理学 -> SQL Server 日志
- 查看数据库名称的最近条目
- 寻找恢复阶段指标（第 1、2 或 3 阶段，共 3 阶段）
3.2 监测恢复进度
使用动态管理视图来跟踪主动恢复操作：
SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource FROM sys.dm_exec_requests WHERE command = 'DB STARTUP';
3.3 检查数据库状态
验证当前数据库状态以了解恢复状态：
SELECT name, state_desc FROM sys.databases WHERE name = 'YourDatabaseName';
4. 修复＃1：等待自然恢复完成
有时，当你 SQL Server 数据库正在恢复中。当恢复过程正常进行但耗时超过预期时，此方法有效。
4.1 何时需要耐心
在以下情况下允许自然完成：
- 错误日志显示进度稳定，时间估计减少
- 没有报告损坏错误
- 数据库最近经历了大量事务
- VLF 数量可控（低于 1,000）
4.2 监测恢复进度
错误日志中预估的恢复时间通常不准确。应关注进度百分比，而不是剩余时间。具有大量事务历史记录的大型数据库可能需要数小时才能完全恢复。
5. 修复 #2：使用 RESTORE DATABASE WITH RECOVERY
此修复解决了遗漏了最后恢复步骤的不完整还原操作。当您的 SQL Server 恢复中的数据库是使用 NORECOVERY 的还原过程导致的。
5.1 理解命令
此 使用恢复功能还原数据库 命令通过回滚未提交的事务并使数据库联机来完成恢复过程。
5.2 实施步骤
- 可选 SQL Server 管理工作室
- 连接到你的 SQL Server 例
- 点击 新建 > 使用当前连接进行查询
- 执行：
RESTORE DATABASE [YourDatabaseName] WITH RECOVERY; - 等待完成确认
警告： 仅当您确定没有其他待处理的恢复操作时才使用此命令。
6. 修复 #3：解决事务日志问题
事务日志问题是导致恢复时间延长的主要原因。此修复解决了日志已满、VLF 过多以及日志空间不足的问题，这些问题会导致 SQL Server 在恢复。
6.1 备份事务日志
通过创建事务日志备份释放日志空间：
- 可选 SQL Server 管理工作室
- 右键单击您的数据库-> 任务 -> 备份
- 更改 备份类型 至 事务日志
- 指定备份目标
- 点击 OK 执行
6.2 管理虚拟日志文件（VLF）
使用以下方法检查 VLF 计数：
DBCC LOGINFO('YourDatabaseName');
如果您有超过 1,000 个 VLF，请按以下方式减少它们：
- 备份事务日志
- 缩小日志文件：
DBCC SHRINKFILE(LogFileName, TRUNCATEONLY); - 以大块（1GB 或更多）的方式增加日志文件
6.3 安全地收缩日志文件
仅在维护时段内没有活动事务运行时收缩日志。收缩操作前务必备份数据库。
7. 修复 #4：运行 DBCC CHECKDB 并修复
数据库损坏可能会导致恢复无法成功完成。DBCC CHECKDB 是一个内置命令，可以识别并修复导致 MS SQL 处于恢复模式的轻微损坏问题。
7.1 检查数据库损坏
Start 使用标准方法来验证数据库完整性。首先直接尝试 DBCC CHECKDB：
- 执行：
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - 审查结果是否存在一致性错误
- 记录任何损坏消息
如果 DBCC CHECKDB 失败 如果出现类似“数据库正在恢复。正在等待恢复完成”的错误，则表示数据库正处于恢复模式并阻止访问。在这种情况下，请继续执行第 7.3 节以使用紧急模式。
7.2 可访问数据库的修复选项
如果 DBCC CHECKDB 成功运行并发现损坏，请使用以下修复步骤：
- 将数据库设置为单用户模式：
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - 尝试安全修复：
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - 如果不成功，请使用：
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - 返回多用户：
ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
7.3 数据库无法访问时使用紧急模式
仅当数据库卡在恢复阶段并拒绝正常的 DBCC CHECKDB 尝试时，才需要紧急模式。该模式将数据库标记为 READ_ONLY 并禁用日志记录。当标准访问失败时，请使用此方法：
- 设置紧急模式：
ALTER DATABASE [YourDatabaseName] SET EMERGENCY; - 设置单用户：
ALTER DATABASE [YourDatabaseName] SET SINGLE_USER; - 运行完整性检查：
DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS; - 如果发现损坏，请先运行安全修复：
DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD); - 如果失败，请使用数据丢失修复：
DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS); - 设置多用户：
ALTER DATABASE [YourDatabaseName] SET MULTI_USER; - 设置在线：
ALTER DATABASE [YourDatabaseName] SET ONLINE;
重要提示： 紧急模式会绕过正常的恢复过程，仅应在数据库完全无法访问时使用。在升级到紧急模式之前，请务必先尝试标准 DBCC CHECKDB 方法。
你可以找到 有关如何使用 DBCC CHECKDB 的更全面的指南.
8. 修复 #5：从备份恢复
当其他方法失败或数据完整性受到质疑时，从干净的备份中恢复通常是最有效的方法ost 可靠的解决方案 SQL Server 数据库恢复问题。
8.1 何时选择备份恢复
在以下情况下考虑备份恢复：
- 恢复已运行超过 24 小时，但无进展
- 损坏错误导致修复无法成功
- 您有最近已验证的备份
- 自上次备份以来的数据丢失是可以接受的
8.2 逐步恢复过程
- 可选 SQL Server 管理工作室
- 右键单击 数据库 -> 恢复数据库
- 从我们的数据库中通过 UL Prospector 平台选择 设备 在来源下
- 点击 添加 并浏览到您的备份文件
- 选择备份并单击 OK
- 选择 覆盖现有数据库 如果需要的话
- 点击 OK 是的tart 恢复
8.3 时间点恢复
为了最大限度地减少数据丢失，请使用事务日志备份还原到特定时间点。确保从完整备份到所需恢复点的日志备份链完整无损。
8.4参考
您可以从我们的[网站地址]了解更多信息。 备份和恢复的全面指南 SQL Server 数据库.
9. 修复 #6：禁用 AUTO CLOSE 属性
AUTO CLOSE 数据库属性可能会导致重复的恢复循环，使您的 SQL Server 数据库持续处于恢复状态。禁用此属性可解决此问题。
9.1 了解自动关闭问题
当启用自动关闭功能时， SQL Server 在最后一个连接结束后关闭数据库，然后重新打开数据库以连接新的连接。这种重复的打开操作每次都会触发恢复过程。
9.2 禁用自动关闭
- 可选 SQL Server 管理工作室
- 右键单击您的数据库-> 物业
- 从我们的数据库中通过 UL Prospector 平台选择 可选项 从左侧面板
- 米 自动关闭 至 假
- 点击 OK 应用更改
或者，使用 T-SQL：
ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;
10. 修复 #7：Restart SQL Server Service
服务资源tar它可以解决卡住的恢复过程，但应谨慎使用，因为它会tart 恢复。此修复适用于 SQL Server 在恢复过程中看起来完全冻结了。
10.1 服务恢复时tart 帮助
住宅tar在以下情况下使用该服务：
- 救援进程已停滞数小时
- 错误日志显示没有新条目
- 其他数据库运行正常
- 您可以承受延长停机时间
10.2 安全响应tar程序
- 可选 SQL Server 配置管理器
- 导航 SQL Server 服务范围
- 为您的 SQL Server 您想要恢复的实例tart，然后右键单击 SQL Server （实例名称）
- 从我们的数据库中通过 UL Prospector 平台选择 住宅tart
- 等待服务完全恢复tart
- 监视错误日志以了解恢复进度
请注意： 住宅tarting 将导致恢复从 s 开始tart，可能会延长总恢复时间。
11. 修复 #8：通过分离并重新连接来修复数据库
对于极端情况，请分离并重新连接数据库：
- 分离数据库：
EXEC sp_detach_db 'YourDatabaseName'; - 仅附加 MDF 文件：
CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG; - 这将重建一个新的事务日志
警告： 此方法可能会导致数据丢失。仅在其他方法都无效时才使用。
12. 修复 #9：处理数据库镜像问题
数据库镜像配置可能会导致独特的恢复问题。此修复解决了特定于镜像的问题，即使数据库保持恢复状态。
12.1 镜像特定的恢复问题
由于伙伴连接问题或端点问题，镜像数据库可能会卡在恢复过程中。主数据库和镜像数据库都可以显示恢复状态。
12.2 镜像恢复解决方案
住宅tart 镜像端点：
- 查找端点名称：
SELECT * FROM sys.endpoints WHERE type = 4; - 停止端点：
ALTER ENDPOINT [EndpointName] STATE = STOPPED; - Start端点：
ALTER ENDPOINT [EndpointName] STATE = STARTED;
如果端点 restart 失败，则中断镜像合作关系：
- 执行：
ALTER DATABASE [DatabaseName] SET PARTNER OFF; - 跑：
RESTORE DATABASE [DatabaseName] WITH RECOVERY; - 数据库上线后重新配置镜像
13. 修复 #10：使用专业恢复工具
内置第三方恢复工具可提供高级修复功能 SQL Server 方法失败。这些工具通常可以从严重损坏的数据库中恢复数据。
13.1 DataNumen SQL Recovery
DataNumen SQL Recovery 具有较高的恢复率，并有全面的选择。
以下是使用它的步骤：
- 停止 SQL Server 服务。
- 在恢复模式下复制数据库的文件，包括主 MDF 文件和辅助 NDF 文件。
- Starthe SQL Server 服务。
- Start DataNumen SQL Recovery.
- 选择副本（而不是原始文件）作为要恢复的数据库的源。
- 点击“Start 恢复”并按照说明恢复数据库。
- 恢复过程结束后，新的恢复数据库将出现在 SQL Server 其中包含所有恢复的数据。
13.2 何时考虑第三方工具
在以下情况下使用专业工具：
- 内置修复选项失败或报告严重损坏
- 没有可用的最新备份
- 尽管数据损坏，但必须恢复关键数据
- 标准恢复方法会导致大量数据丢失
14.预防最佳实践
14.1 定期维护任务
实施这些做法以防止 SQL Server 数据库恢复问题：
- 安排定期完整备份和日志备份： 维护完整的备份链
- 监测 VLF 计数： 将 VLF 保持在 100 以下以获得最佳性能
- 规划日志文件大小： 预先调整日志大小以避免过度自动增长
- 运行常规 DBCC CHECKDB： 及早发现腐败
14.2 监控和警报
设置主动监控：
- 配置数据库状态变化警报
- 监视日志文件驱动器上的磁盘空间
- 跟踪长期运行的事务
- VLF 计数过高时发出警报
14.3 硬件和基础设施
确保可靠的基础设施：
- 使用快速存储来存储事务日志（最好是 SSD）
- 实施冗余电源
- 将数据和日志文件放在不同的驱动器上
- 考虑 高可用性解决方案 喜欢 Always On 可用性组
15. 复杂场景故障排除
15.1 多个数据库问题
当多个数据库陷入恢复状态时：
- 检查系统范围的问题（磁盘空间、内存）
- 确定关键数据库的恢复优先级
- 考虑影响整个实例的硬件问题
- 查看最近的系统更改或更新
15.2 大型数据库注意事项
对于超过 1TB 的数据库：
- 预计恢复时间更长（可能需要几天）
- 确保足够的内存分配
- 考虑并行处理设置
- 恢复期间监视 tempdb 空间
15.3 何时联系 Microsoft 支持
联系 Microsoft 支持部门以获取以下信息：
- 没有备份选项的关键生产系统
- 嫌疑 SQL Server 软件错误
- 需要保证恢复的企业环境
- 复杂的 Always On 或群集场景
16. 常见问题解答
问：应该多长时间 SQL Server 数据库恢复通常需要多长时间？
答：恢复时间取决于数据库大小、事务量和硬件性能。小型数据库通常只需几分钟即可恢复，而包含大量事务日志的大型数据库则可能需要数小时。错误日志中显示的预估时间通常不准确，因此请关注进度百分比。
问：我可以停下来吗 SQL Server 恢复期间不会丢失数据？
答：停止 SQL Server 在恢复期间通常是安全的，但会恢复tar从服务恢复时开始恢复过程tarts。这会延长总恢复时间，但不会导致原始事件期间发生的额外数据丢失。
问：“恢复中”和“待恢复”之间有什么区别？
答：“恢复中”是指 SQL Server 正在积极执行恢复操作。“恢复待处理”表示恢复过程失败tart，通常是由于文件丢失、权限不足或磁盘空间问题造成的，必须先解决这些问题才能进行恢复。
您可以在我们的[链接]中找到有关“待处理恢复”的更多详细信息。 综合指南.
问：如果我使用 REPAIR_ALLOW_DATA_LOSS，我会丢失数据吗？
答：是的，REPAIR_ALLOW_DATA_LOSS 可能会移除损坏的数据以恢复数据库一致性。请务必先尝试 REPAIR_REBUILD，它可以修复结构问题而不会丢失数据。只有在没有其他恢复选项的情况下，才将 REPAIR_ALLOW_DATA_LOSS 作为最后的手段。
问：当一个数据库处于恢复状态时，我可以访问其他数据库吗？
答：是的，同一服务器上的其他数据库 SQL Server 实例在恢复期间仍可访问。只有正在恢复的数据库不可用。但是，恢复操作可能会影响服务器的整体性能。
问：什么原因导致数据库陷入恢复模式？
答：常见原因包括使用 NORECOVERY 的还原操作不完整、虚拟日志文件 (VLF) 过多、大量未提交事务、数据库损坏、磁盘空间不足以及硬件问题。启用 AUTO CLOSE 的数据库也可能持续进入恢复状态。
问：我如何知道恢复是否正在取得进展或陷入停滞？
A：监视器 SQL Server 错误日志中显示恢复进度消息，显示完成百分比。使用 sys.dm_exec_requests 检查活动数据库TARTUP 命令。如果百分比随时间推移而增加，则表示恢复正在进行。几个小时内没有新的日志条目可能表示进程卡住了。
问：重新tart SQL Server 恢复期间的服务？
答：Restarting 是安全的，但应谨慎使用。它会tar从一开始就进行恢复，可能会使恢复时间加倍。只有tar如果恢复看起来完全冻结，并且几个小时内没有任何进展，或者您怀疑该过程确实卡住了。
问：AUTO CLOSE 和恢复模式有什么区别？
答：AUTO CLOSE 会在没有连接时自动关闭数据库，然后重新打开数据库以建立新连接。这种反复打开的操作每次都会触发短暂的恢复过程，使数据库看起来一直处于恢复状态。禁用 AUTO CLOSE 可以解决此问题。
问：事务日志备份在恢复过程中有帮助吗？
答：如果日志驱动器已满，事务日志备份可以释放日志空间，从而可能允许恢复继续进行。但是，您无法备份当前处于恢复模式的数据库的日志。日志备份更适用于预防和ost-恢复维护。
问：我应该何时联系 Microsoft 支持？
答：当您怀疑内置恢复方法失败时，请联系 Microsoft 支持部门 SQL Server 软件错误，适用于复杂的 Always On 或集群场景，或者当企业环境需要以最少的停机时间保证数据恢复时。
问：如何防止数据库陷入恢复状态？
答：实施定期完整备份和日志备份，监控和管理 VLF 计数，确保足够的磁盘空间，使用正确的关机程序，维护硬件可靠性，在生产数据库上禁用 AUTO CLOSE，并运行定期 DBCC CHECKDB 操作以尽早发现损坏。
问：什么是 VLF？为什么它们会影响恢复？
答：虚拟日志文件 (VLF) 是事务日志文件中的内部段。过多的 VLF（超过 1,000 个）会显著降低恢复速度，因为 SQL Server 必须单独处理每一个日志文件。适当的日志文件大小和增长设置有助于维持最佳的 VLF 计数。
问：数据库正在恢复时我可以从备份中恢复吗？
答：您无法恢复当前处于恢复模式的数据库。您必须等待恢复完成，或者停止 SQL Server 服务，或还原到其他数据库名称。紧急情况下，请考虑还原到新的数据库名称，然后在恢复问题解决后重命名。
17. 结论和后续步骤
17.1 主要解决方案总结
当你的 SQL Server 数据库正在恢复中，star按顺序使用这些方法：
- 检查错误日志并监控进度
- 如果进展稳定，等待自然完成
- 使用 RESTORE WITH RECOVERY 进行不完整的恢复
- 解决事务日志问题
- 运行 DBCC CHECKDB 或专业工具来检查损坏情况
- 对于严重情况，请考虑备份恢复
Most SQL Server 使用这些经过验证的方法，数据库恢复问题可在数小时内得到解决。对于复杂的情况，请毫不犹豫地使用先进的技术或专业的工具。
17.2 其他资源
为进一步协助：
- Microsoft SQL Server 文件记录
- SQL Server 社区论坛
- 数据库管理博客和技术资源
- 专业数据库恢复服务
定期维护和监控可以防止ost 恢复问题。实施本指南中概述的预防措施，以最大限度地减少未来 MS SQL 恢复问题的发生。
关于作者
袁盛 是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。
袁专长于 SQL Server 数据库恢复、高可用性解决方案和性能优化。他拥有丰富的实践经验，包括管理多TB数据库、实施Always On可用性组以及为关键业务系统开发自动备份和恢复策略。
通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。
有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎 反馈和建议 用于改进这些技术资源。