HADR_SYNC_COMMIT 等待的奇怪案例
Aru*_*ath 11 sql-server sql-server-2014
我们注意到HADR_SYNC_COMMIT我们环境中的一个有趣的等待模式。我们有一个三副本；数据中心中的一个主、一个同步辅助和一个异步辅助，我们刚刚在另一个数据中心（相距约 2400 英里）中添加了另外三个ASYNC副本。
从那以后，我们开始注意到HADR_SYNC_COMMIT等待的人数大幅增加。当我们查看活动会话时，我们会看到一堆COMMIT TRANSACTION查询在 SYNC 副本上等待
从截图中，我们可以清楚地看到HADR_SYNC_COMMIT6 月 29 日的等待时间有所增加，我们最终在 7 月 1 日中午的某个时间丢弃了远程数据中心的三个异步副本中的“两个”。这大大减少了等待时间。
到目前为止我们检查过的内容 - 远程副本上的日志发送队列、重做队列、上次强化时间和上次提交时间。我们在工作时间有连续的小事务爆发，因此在给定的时间戳（60KB 到 1MB 之间的任何地方）发送队列非常小。
远程副本几乎同步，副本上任何单个 lsn 的上次提交时间和上次强化时间之间几乎没有差异。
网络管道是 10G，我们将传输缓冲区大小从 256 megs 修改为 2 gigs，这是在假设网络正在丢弃数据包并重新传输它们的情况下做出的；无论哪种方式，这似乎都没有多大帮助。
所以，我想知道ASYNC副本与HADR_SYNC_COMMIT等待有什么关系？SYNC副本不应该单独依赖于这种等待类型，我在这里遗漏了什么？
小智 8
首先，您的问题所涉及的等待事件的描述是：
等待同步的辅助数据库的事务提交处理以强化日志。此等待也反映在事务延迟性能计数器上。此等待类型适用于已同步的可用性组，并指示向辅助数据库发送、写入和确认日志的时间。
深入研究此等待的机制，您可以传输和强化日志块，但未在远程服务器上完成恢复。在这种情况下，并且考虑到您添加了额外的副本，您的 HADR_SYNC_COMMIT 可能会因带宽需求的增加而增加。在这种情况下，Aaron Bertrand 对这个问题的评论完全正确。
来源：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