主页 / dba / 问题 / 126711
Accepted
dwjv
Asked: 2016-01-20 23:38:51 +0800 CST

为什么数据库恢复需要这么长时间？

  • 772

在我的 SQL Server 2012 x64 Std 实例上，由于昨天事务日志已填满，我有一个大事务失败，它无法回滚，SQL Server 已重新启动特定数据库以执行恢复。

数据库大约 750GB，tlog 达到 170GB（非常大的 ETL 作业正在运行）。该作业只运行了几个小时，但到目前为止恢复已经花费了超过 24 小时（完成 70%，在第 3 阶段，共 3 阶段）。

什么我不明白为什么要花这么长时间？磁盘上似乎没有任何压力，sys.dm_exec_requests显示它正在等待PAGEIOLATCH_EX/SH，这是我所期望的。我本可以在这段时间内恢复整个数据库......

如果有人能提供任何启示，将不胜感激。

编辑：根据要求，获取错误日志的输出：

Recovery of database 'MyDB' (6) is 77% complete (approximately 28100 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28095 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28099 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28102 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
Recovery of database 'MyDB' (6) is 77% complete (approximately 28097 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.

此外，sys.dm_exec_requests您所追求的信息：

session_id  command status  percent_complete
35  DB STARTUP  background  86.06061

启用/授予 IFI 和“执行卷维护任务”。

sql-server sql-server-2012

1 个回答

  1. Best Answer

    由于昨天事务日志已填满，我有一个大事务失败，它无法回滚，SQL Server 已重新启动特定数据库以执行恢复。

    当事务在 SQL Server 中启动时，这并不完全正确，它会在事务日志中保留空间以防事务必须回滚。来自事务日志架构 BOL 文档

    还记录回滚操作。每个事务都会在事务日志上保留空间，以确保存在足够的日志空间来支持由显式回滚语句或遇到错误导致的回滚。保留的空间量取决于事务中执行的操作，但通常等于用于记录每个操作的空间量。事务完成时释放此保留空间

    所以我想你现在可以理解了。

    什么我不明白为什么要花这么长时间？

    查询回滚操作是mostly single threaded当执行相同的查询时，它可以使用并行性/多个线程来执行相同的操作，使其与回滚相比非常快。我建议您阅读Bob Dorr 所说的关于需要很长时间的回滚。要更深入地了解回滚过程中发生的情况，请阅读本文。重新启动 SQL Server 服务并没有太大帮助，重新启动 rollbak 进程后必须重新启动。您必须等待并让回滚过程完成。

    您还可以使用 sys.dm_exec_requests 来跟踪您的回滚。

    select    
session_id,     
command,     
status,     
percent_complete    
from sys.dm_exec_requests    
where command IN ('killed/rollback','rollback','db_startup')

    Remus 提到的另一个原因是VLF 太多。如果你有很多 VLF 的恢复可能需要很多时间。其他可能延迟恢复的因素是 SQL Server 服务帐户是否没有Perform Volume maintenacce task right or instant file initialization. 您可以使用此链接检查 IFI 是否存在。

    编辑：

    来自您发布的输出

    session_id  command status  percent_complete
35  DB STARTUP  background  86.06061

    启动过程就是86 % complete.一直监控它，最终它会完成。此外，如前所述，回滚过程可能会被阻止并导致等待，因此也要继续监控。

    2012 x64 标准 SP2

    您的标准版无法利用企业版中的快速恢复。使用快速恢复数据库可以在恢复的第二阶段（重做阶段）后上线，但情况并非如此，因此请阅读本文。作为补充阅读，您可以阅读何时使用快速恢复。标准版限制可能是数据库需要时间才能上线的另一个原因。

    另一件事，回滚会话 (35) 本身阻止另一个系统进程执行 CHECKPOINT

    是的，它可以而且你不能做任何事情，因为你无法控制系统进程，因为你不能杀死它。

    • 7

相关问题