首先,您的问题所涉及的等待事件的描述是:
等待同步的辅助数据库的事务提交处理以加强日志。事务延迟性能计数器也反映了此等待。对于同步的可用性组,此等待类型是预期的,它指示向辅助数据库发送,写入和确认日志的时间。
https://msdn.microsoft.com/zh-CN/library/ms179984.aspx
深入研究这种等待的机制,您将传输并强化日志块,但是在远程服务器上恢复未完成。在这种情况下,并且考虑到您添加了其他副本,则可以认为由于带宽需求的增加,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