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

Question

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

DB 大约为 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 和“执行卷维护任务”。

Answer 1

由于昨天的事务日志已满，我有一个大事务失败，无法回滚，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

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