HADR_SYNC_COMMIT等待的奇怪案例

Question

我们注意到了HADR_SYNC_COMMIT在我们的环境中等待的一个有趣的模式。我们有三个副本；数据中心中有一个主副本、一个同步辅助副本和一个异步辅助副本，我们刚刚在另一个数据中心中添加了另外三个async副本(大约相隔2400英里)。

从那以后，我们开始注意到HADR_SYNC_COMMIT等待量的大幅增加。当我们查看活动会话时，我们看到一堆COMMIT TRANSACTION查询在等待同步副本。

从截图中，我们可以清楚地看到6月29日的HADR_SYNC_COMMIT等待中有一次跳转，我们最终在7月1日中午的某个时候在远程数据中心丢弃了三个异步副本中的两个。这样就大大缩短了等待时间。

到目前为止，我们检查的是日志发送队列、重做队列、上一次强化时间和远程副本上的最后提交时间。我们在营业时间内有连续的小事务，因此在给定的时间戳(在60 1MB到1MB之间)，发送队列非常小。

远程副本几乎是同步的，对于副本上的任何单个lsn来说，上一次提交时间和最后一次强化时间之间的差别很小。

网络管道是10G，我们将传输缓冲器的大小从256 megs修改为2‘t，这是在假定网络丢弃并重新传输数据包的前提下进行的；不管是哪种方式，这似乎都没有多大帮助。

所以，我想知道ASYNC副本与HADR_SYNC_COMMIT等待有什么关系？同步副本不应该仅仅依赖于这个等待类型，我在这里遗漏了什么？

Answer 1

首先，您的问题所涉及的等待事件的描述是：

等待事务提交处理，以便同步辅助数据库来增强日志。事务延迟性能计数器也反映了此等待。此等待类型用于同步可用性组，并指示向辅助数据库发送、写入和确认日志的时间。https://msdn.microsoft.com/en-us/library/ms179984.aspx

深入研究这一等待的机制，您可以传输日志块并使其硬化，但远程服务器上的恢复尚未完成。在这种情况下，并考虑到添加了额外的副本，您的HADR_SYNC_COMMIT可能会因为带宽需求的增加而增加。在这种情况下，亚伦·伯特兰对这个问题的评论是完全正确的。

来源：http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

深入了解您问题的第二部分:这个等待与应用程序减速有什么关系。我相信这是一个因果关系问题。您正在查看您的等待增加和最近的用户抱怨，得出的结论可能是错误的，这两者之间的关系，而这可能是完全不可能。您添加了tempdb文件，并且您的应用程序对我的响应更强，这表明您可能存在一些潜在的争用问题，当数据库处于可用性组时，隐式快照隔离级别开销的额外开销可能会加剧这些问题。这可能与您的HADR_SYNC_COMMIT等待几乎没有或根本没有关系。

如果您想测试这一点，您可以利用一个扩展事件跟踪来查看主副本上的hadr_db_commit_mgr_update_harden XEvent，并获得一个基线。一旦您有了基线，您就可以一次将副本添加回一个中，并查看跟踪是如何变化的。我强烈鼓励您使用驻留在不包含任何数据库并设置滚动和最大大小的卷上的文件。请根据需要调整工期筛选器，以收集与等待匹配的事件，以便进一步排除故障并将其与需要参与的任何其他团队相关联。

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO