Azure SQL Database에서 높은 WRITELOG 대기
Azure SQL Database의 WaitStats 분석은 가장 높은 대기 카운터로 WRITELOG 및 HADR_SYNC_COMMIT를 표시합니다. 이것은 Premium 250 eDTU 리소스입니다.
스크립트
SELECT TOP (10) wait_type,
CAST (([wait_time_ms] / 1000.0) AS DECIMAL (16, 2)) AS [WaitS],
CAST (100.0 * [wait_time_ms] / SUM([wait_time_ms]) OVER () AS DECIMAL (16, 2)) AS [Percentage]
FROM sys.dm_db_wait_stats
ORDER BY [Percentage] DESC;
AZure SQL 데이터베이스에서이 문제를 해결하는 방법에 대한 많은 정보를 찾을 수 없습니다.
도움을 주시면 감사하겠습니다.
감사
답변
WRITELOG는 트랜잭션의 로그 레코드가 디스크로 강화 될 때까지 커밋을 기다리고 있으며 HADR_SYNC_COMMIT는 트랜잭션의 로그 레코드가 네트워크를 통해 보조 복제본으로 전송되고 디스크로 강화 될 때까지 커밋을 기다리고 있습니다. 그래서 그들은 매우 매우 유사한 기다림입니다.
둘 다 애플리케이션이 너무 많은 트랜잭션을 커밋하고 있음을 나타냅니다.
프리미엄에서 로그 파일은 대기 시간이 매우 짧은 로컬 플래시 드라이브에 있으므로 WRITELOG 대기 시간이 많으면 애플리케이션에서 수정해야 할 사항이 있음을 알 수 있습니다.
타이트 루프에서 단일 행의 INSERT, UPDATE 또는 DELETE를 실행하는 프로세스가있는 경우 명시 적 트랜잭션으로 래핑하는 것을 고려하여 트랜잭션 로그가 끝에서 플러시 될 때까지 기다리면됩니다.
항상 쿼리 저장소 는 친구이며 쿼리 별 대기를 표시 할 수 있으며 sys.dm_exec_session_wait_stats 에서도 세션 별 대기를 분석하여 이러한 대기를 겪고있는 워크로드 부분을 확인할 수 있습니다.
세션 경과 시간과 CPU 시간을 대기 시간과 비교하여 클라이언트가 얼마나 대기하고 있는지 더 잘 이해할 수 있습니다. EG
select s.session_id,
w.wait_type,
w.wait_time_ms,
w.signal_wait_time_ms,
s.total_elapsed_time,
s.cpu_time,
w.wait_time_ms/cast(nullif(s.total_elapsed_time,0) as float) wait_percent_of_elapsed
from sys.dm_exec_sessions s
join sys.dm_exec_session_wait_stats w
on s.session_id = w.session_id
where w.wait_time_ms > 0
order by wait_percent_of_elapsed desc