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

Question

在最近的一个计划中，AWS RDS故障转移，我们经历了大约20分钟的长恢复时间。AWS提供了一些暗示为什么。

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

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

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

恢复过程大约花了20分钟，我们想采取措施把这个时间减少到10分钟左右。

更新：

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

Answer 1

由于您没有使用SQLServer2019，ADR将不适用。在几乎所有情况下都应考虑的一般准则很少，它们如下：

1. 把交易保持在尽可能小的水平。
2. 控制长期运行的事务，并酌情与应用程序团队或供应商联系。
3. 尽可能频繁地进行事务日志备份，以减少分析阶段。

有一个选择，改变目标恢复时间，但这也有一些不利的一面。在启用它们之前，你应该考虑它们。

在MS-site中，如果您避免了下面的场景，则不需要ADR：

卫生组织应考虑加速数据库恢复，以下类型的客户应考虑启用ADR：

• 具有长时间运行事务的工作负载的客户。
• 已经看到活动事务导致事务日志显著增长的情况的客户。
• 由于Server长时间运行恢复而导致数据库长期不可用的客户(例如意外的Server重新启动或手动事务回滚)。

从您关于在数据库中使用blob类型的问题中的注释和新添加来看，是的，拥有这些数据类型可以显著延迟数据库中的任何检查点。相反，您应该使用CAS存储类型，Brent Ozar先生解释得很清楚：

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

希望这能帮助你做出正确的决定。

Answer 2

只想在其他答案中加入一点：

恢复分三个步骤完成。分析、重做(前滚)和撤消(回滚)。

检查点的发生频率使重做阶段不应超过在实例(sp_configure)或数据库(ALTER )级别上配置的内容。默认情况下，这是(据我所记得)一分钟。也就是说，你最多可以看到大约一分钟的重做。

所以，要么你遇到了一些奇怪的事情，要么你出现了一个大的回滚。

有很多的VLF为你的ldf可以增加恢复时间，但我怀疑它会导致这种严重的情况。我猜是一个长期运行的事务正在滚动备份。或者是一个非常旧的开放事务，导致从ldf读取大量数据，即使事务本身并没有修改太多数据。

错误日志文件中有一些来自恢复过程的反馈。这将是我的出发点，并从那里确定哪个阶段花了这么长时间。此外，你还有大量的VLFs (考虑到你是2016年的)，我对此表示怀疑。

Answer 3

如果更改为Server 2019，则可以启用加速数据库恢复，这将使您获得迄今为止最大的速度。https://learn.microsoft.com/en-us/sql/relational-databases/accelerated-database-recovery-concepts?view=sql-server-ver15