먼저 귀하의 질문과 관련된 대기 이벤트에 대한 설명은 다음과 같습니다.
동기화 된 2 차 데이터베이스가 로그를 강화하기 위해 트랜잭션 커미트 처리를 기다리는 중입니다. 이 대기 시간은 트랜잭션 지연 성능 카운터에도 반영됩니다. 이 대기 유형은 동기화 된 가용성 그룹에 예상되며 보조 데이터베이스에 로그를 보내고 쓰고 승인하는 시간을 나타냅니다.
https://msdn.microsoft.com/en-us/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
