Thomas Costers's questions

设置

3 节点 Alwayson 群集 - 1 个同步和 1 个异步辅助副本 - SQL Server 2012

情况

从异步辅助副本读取时，我们正在见证 PageIOLatches。这主要是由受到限制的 SAN 的吞吐量引起的。托管合作伙伴告诉我们，由于硬件限制，无法立即缓解此限制。
主副本和同步副本使用具有更高吞吐量的其他 SAN。虽然这种情况远非理想，但这是一个很快就会解决的临时情况，而不是我的问题的主题。

在调查 IO 等待时，我们注意到这些等待与检查点页面/秒数量的增加同时发生。

我的印象是检查点不会出现在 AG 中的辅助副本上，正如在此处讨论的那样。

为了验证这种行为，我设置了一个扩展事件来监视异步副本上的检查点事件。正如预期的那样，没有为该数据库捕获任何检查点，我也没有从其他数据库中找到与该模式匹配的任何检查点。

接下来，我在主副本上创建了相同的扩展事件并启动了一个 perfmon 来验证我们是否可以看到相同的行为。在这里，我们能够捕获（自动）检查点，它们大约发生。每分钟一次。这些检查点与我们的辅助（和主）副本上的检查点页面/秒增加同时发生。似乎在主要副本上生成检查点并在辅助副本上重做。这意味着检查点确实隐式发生在 AG 中的辅助副本上。

问题

我的假设是否正确，即在 AG 中，在主副本上生成检查点并在所有辅助副本上重做？
因此，如果TARGET_RECOVERY_TIME未设置数据库，recovery interval则主副本的设置将决定这些数据库的所有辅助副本上的检查点。

目前 SqlPackage.exe 与 BitBucket 一起用于部署数据库架构更改。

最近，基于 3 个源表创建了一个相当大的索引视图，这些表是应用程序的关键。在视图上创建聚集索引的过程以及随之而来的停机时间大约需要一个小时才能完成。

最近，必须将一列添加到索引视图的一个源表中。尽管视图具有模式绑定，但这应该不是问题，因为视图的定义中没有使用新列（呃！）。尽管如果我们查看 SqlPackage 生成的脚本，它会选择删除索引视图以应对模式绑定，尽管这完全没有必要。在我看来，SqlPackage 无法检查依赖关系，因此出于预防措施而放弃了视图。

如果我在本地机器（SQL Server 2017 Dev edition）上模拟类似的情况，比较 DacPac 总是会导致视图的删除和重新创建。

现在的问题是：有没有人知道任何解决方法或任何方法来防止 SqlPackage 删除视图？我检查了所有属性，但那里似乎没有任何可行的选择。