哪些因素会影响 SQL Server 恢复完成的时间

Question

在最近的 AWS RDS 故障转移计划中，我们经历了大约 20 分钟的长时间恢复。AWS 提供了一些关于原因的提示。

大型事务或冗长的恢复过程会增加故障转移时间。

数据库本身并没有大量使用大型事务，所以我认为这不是罪魁祸首。因此，我有兴趣了解哪些因素可能导致漫长的恢复过程？

• SQL Server 版本是否有影响（我们在 2016 年）
• 数据库的大小有影响吗？

恢复过程大约需要 20 分钟，我们希望采取措施将其减少到大约 10 分钟。

更新：

我没有提到的一件事是，由于多年的糟糕设计，大约 50% 的数据库大小是由于存储了大量文件，例如 html 或 XML。这会对恢复时间有任何影响吗？

Answer 1

由于您未使用 SQL Server 2019，因此 ADR 将不适用。几乎在所有情况下都应考虑的一般准则很少，如下所示：

1. 保持交易尽可能小。
2. 控制与应用程序团队或供应商联系的长时间运行的事务。
3. 尽可能频繁地备份事务日志以减少分析阶段。

可以选择更改目标恢复时间，但也有一些缺点。在启用它们之前，您应该考虑它们。

从 MS 站点，如果您避免以下情况，则不需要 ADR：

谁应该考虑加速数据库恢复 以下类型的客户应该考虑启用 ADR：

• 具有长时间运行事务的工作负载的客户。
• 见过活动事务导致事务日志显着增长的情况的客户。
• 由于 SQL Server 长时间运行恢复（例如 SQL Server 意外重启或手动事务回滚）而导致数据库长时间不可用的客户。

从关于在数据库中使用 blob 类型的问题的评论和新增内容来看，是的，拥有这些数据类型会显着延迟数据库的任何检查点。相反，您应该使用 Brent Ozar 先生很好地解释的 CAS 存储类型：

https://www.brentozar.com/archive/2015/03/no-more-blobs/

希望这有助于您做出正确的决定。

Answer 2

只是在其他答案中添加一点：

恢复分三步完成。分析、REDO（前滚）和UNDO（回滚）。

检查点随频率发生，因此 REDO 阶段不应超过您在实例 (sp_configure) 或数据库 (ALTER DATABASE) 级别配置的任何内容。默认情况下，这是（我记得的）一分钟。即，您最多可以看到大约一分钟的 REDO。

因此，要么您遇到了奇怪的事情，要么发生了大量回滚。

为您的 ldf 使用许多 VLF 会增加恢复时间，但我怀疑这会导致这种严重的情况。我的猜测是一个长期运行的事务被滚动备份。或者一个非常古老的开放事务，即使该事务本身没有修改太多数据，也会导致从 ldf 读取大量数据。

错误日志文件中有一些来自恢复过程的反馈。那将是我的起点，并从那里确定哪个阶段花了这么长时间。还要检查您是否有大量的 VLF（考虑到您在 2016 年，我对此表示怀疑）。