主页 / dba / 问题 / 175039
Accepted
Peter
Asked: 2017-06-01 06:32:52 +0800 CST

诊断缓慢的 Always On 提交

  • 772

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

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

在此处输入图像描述

[1]：https://i.sta

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

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 分钟，并且一直在略微增加。然后我应用了 traceflagDBCC TRACEON (3459, -1)并在几分钟后发现，重做命令的数量下降得非常快。到目前为止，这个跟踪标志似乎已经缓解了这个问题，但大概这会将所有事务强化到辅助副本的日志中，例如 SQL Server 2014，因此，辅助副本仍有可能落后作为非并行线程的结果，当主要的写入负载很重时。

performance availability-groups

1 个回答

  1. Best Answer

    我遇到的问题：

    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-occurs-when-you-use-parallel-redo-次要副本中

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

    • 3

相关问题