诊断缓慢的 Always On 提交

Question

两个节点 Always On 可用性组，一个同步副本。

我的同步副本经常不同步。我看到一种模式，当在辅助副本上进行日志备份时，会出现短暂的延迟，在此期间 redo_queue_size 会迅速填满，如下所示：

查看以下链接中的指南，似乎我的问题主要是由于尝试强化事务时重做线程遇到的争用：

https://technet.microsoft.com/en-us/library/dn135335(v=sql.110).aspx

当事务日志备份运行时，副本进一步不同步，并且在辅助副本上运行的报告也会加剧此问题。

一直以来，我的事务日志备份都很大——平均 1.2GB，但可以更大。

据我所知，我的日志备份会很大，因为我在数据库上启用了 TDE，但我真的没想到它们会这么大。我怀疑这是对辅助副本上的缓慢提交贡献最大的原因。

是否有推荐的性能计数器来诊断同步副本上的慢提交？我还能做些什么来验证我的理论？

我的问题似乎与此处描述的相同：https : //www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread

我可以只在辅助副本上启用此跟踪标志，还是需要应用于两个节点？

编辑：我在早上 6 点检查重做队列，发现一个巨大的数字，恢复时间为 15-20 分钟，并且一直在略有增加。然后我应用了跟踪标志，DBCC TRACEON (3459, -1)几分钟后发现，重做命令的数量下降得非常快。到目前为止，这个跟踪标志似乎已经缓解了这个问题，但据推测，这会将所有事务强化到单线程模式下的辅助副本日志，如 SQL Server 2014，因此，辅助副本仍有可能落后由于非并行线程，当主线程处于高写入负载时。

Answer 1

我遇到的问题：

1. 同步辅助副本半永久落后
2. 海量日志备份

这些问题可以通过启用跟踪标志 3459 来解决。在我的例子中，很容易看到该标志立即修复了等待类型，parallel_redo_flow_control dirty_page_table_lock parallel_drain_redo_worker并显示重做队列的大小快速减小。

我想知道为什么在错误报告中，微软称之为“断言”：https ://support.microsoft.com/en-us/help/3200975/fix-assertion-occurrs-when-you-use-parallel-redo-次要副本内

感谢来自 SQLServerCentral.com 的 Jason AKA CirqueDeSQLeil https://www.sqlservercentral.com/Forums/1871286/AlwaysOn-Missing-Redo-Thread