估计加速数据库恢复引起的数据库增长

Question

默认情况下，Azure中启用加速数据库恢复(ADR)，Server 2019中有一个选项。它有一些非常有趣的潜力。

我通过在静态测试数据库中打开ADR进行了实验，如果没有发生任何事情，就不会有任何增长。似乎只有在活动数据库上才会出现增长。因此，除非您有一个测试系统，允许您完全再现您的生产工作量，否则您将在生产中进行增长实验。

更重要的是，打开或关闭ADR本质上需要一个停机时间，因为有一个“独占锁定”的要求来改变状态，并且您有一个职业转换事件的配方。

如果您有一个有50 If可用的10 If数据库，可能不是什么大问题。但是，如果您有一个3.5TB数据库，并且只有4TB的可用空间，这可能是一个大问题。

来自管理加速数据库恢复文档：

如果PVS明显大于基线，或者接近数据库大小的50%，那么PVS就被认为是大的。

###Question

在实施之前，如何准确估计使用ADR的增长？

Answer 1

实际上，确保的唯一方法是对数据库的测试副本运行具有代表性的工作负载。

如果您没有一个现实的测试环境，您可以考虑在云中测试这个环境。例如，在Azure中，复制备份并还原备份是相对快速和简单的。您可以使用数据库实验助理，您可以直接使用它，也可以通过包含的RML实用程序来捕获和重放生产跟踪。

否则，只要运行您希望生成大量PVS (持久化版本存储)使用的部件，就可以获得可接受的信任级别。

PVS还从tempdb接管了通常的用户版本存储使用，用于行版本控制隔离级别、触发器和火星。您可能期望相应地减少对tempdb的使用。

使用ADR时，您应该期望日志卷有所增加，但不一定是日志记录的数量。在任何给定的时间，日志的大小都应该比由于主动日志截断而启用ADR之前更小，甚至可能更小。

在ADR中，为了恢复目的需要版本，所以它们必须被保存，直到提交的行版本被带回到源页面。这是由后台清理线程执行的，因此，如果您当前启用了RCSI和/或SI，那么PVS将比tempdb版本存储区大。

有很多移动部件到ADR，这在很大程度上取决于您的工作负载的详细特性。除非您能够事先执行实际的测试，否则建议您在启用PVS之前确保为PVS增长提供相当大的数据库空间。

启用ADR所需的独占数据库锁与启用RCSI所需的锁相同，应相应地进行计划。启用RCSI对tempdb也有很难评估的影响。对数据库配置的每一项重大更改都需要对好处和风险进行评估，并制定强有力的实施和备份计划。

如果您对ADR (内部命名为常数时间恢复)的更深层次的细节感兴趣，请参见此微软研究论文 (pdf)。