1 초 미만 동안 발생하는 차단을 추적하는 방법-SQL Server

1 초 이내에 발생하는 차단 문제를 해결하려고합니다. OLTP 애플리케이션은 매우 민감하며 합의 된 SLA에 따라 일부 트랜잭션에 대해 200ms 미만의 응답 시간을 가져야합니다. 업데이트에서 배치 크기를 줄이면 해결할 수있는 새로운 코드 릴리스에서 잠금 에스컬레이션 문제가 발생했습니다. 배치 크기가 작더라도 새 sp가 OLTP 트랜잭션이 업데이트하는 동일한 행을 차단하고 있다고 의심합니다.

차단 된 세션과 대기중인 리소스를 찾아야합니다. 내 이해에 따라 "차단 프로세스 임계 값"은 최소 1 초 동안 설정할 수 있으므로 차단을 캡처하지 않습니다.

wait_info 및 wait_completed x 이벤트를 실험 중입니다.

우리가 이것을 추적 할 수있는 다른 방법이 있습니까? 감사

일반적이 아닌 잠금에 특히 관심이 있으므로 locks_lock_waits확장 된 이벤트 사운드가 더 적합 할 때 까지 기다립니다 .

필터를 켠 상태 increment >= 200

CREATE EVENT SESSION [locks_lock_waits] ON SERVER 
ADD EVENT sqlserver.locks_lock_waits(
        ACTION(sqlserver.sql_text)
            WHERE  ( [sqlserver].[is_system] = 0
                     AND [increment] >= 200
                     AND [counter] <= 1000 ) 
    )
ADD TARGET package0.ring_buffer;

GO

ALTER EVENT SESSION [locks_lock_waits]  
ON SERVER  STATE = start;  

위의 문은 임계 시간 동안 잠금을 기다리는 명령문을 수집하지만 특정 잠금 리소스를 제공하지는 않습니다.

이 이벤트를 사용한 적이 없으며이 세션이 프로덕션 서버에서 얼마나 많은 오버 헤드를 유발하는지에 대한 통찰력이 없습니다.

주제 에서이 비디오 를 찾았습니다 . counter수집되는 이벤트 수를 줄이려면 필터링을 사용하는 것이 좋습니다 .

또한 문서화되지 않은 오래된 레거시 명령에 대해서도 언급합니다.

dbcc lock(StallReportThreshold, 200) -- 200 is threshold in ms

(추적 플래그 3605가 활성화 된 경우) 다음과 같은 제한된 정보를 SQL Server 오류 로그에 덤프합니다.

프로세스 53은 RID에서 S 잠금을 위해 6844ms를 기다렸습니다 : 2 : 1 : 120 : 2 결과 : OKWAIT

어쨌든 확장 이벤트가 문서화되고 훨씬 강력하기 때문에 분명히 확장 이벤트가 바람직하기 때문에 이것을 언급합니다.

잠금에 관심이있는 경우 사용 가능한 몇 가지 확장 이벤트가 있습니다.

lock_acquired
lock_released
lock_escalation

처음 두 이벤트에는 duration임계 값으로 필터링 할 수 있는 열 (마이크로 초)이 있습니다. 또한 resource_description관련 리소스에 대한 세부 정보를 제공 하는 작업이 있습니다.

lock_escalation이벤트도 가지고 statement당신이 잠금 에스컬레이션을 트리거 한 T-SQL 문을 수집하기 위해 추가 할 수있는 조치를. 또한 있습니다 escalation_cause. 샘플 세션은 다음과 같습니다.

CREATE EVENT SESSION [locking] ON SERVER 
ADD EVENT sqlserver.lock_acquired( SET collect_resource_description = (1) ),
ADD EVENT sqlserver.lock_escalation( SET collect_statement = (1) ),
ADD EVENT sqlserver.lock_released( SET collect_resource_description = (1) )
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

차단 된 프로세스 보고서 임계 값을 1 초 미만으로 설정할 수없는 이유가있을 수 있습니다. RDBMS에서는 잠금이 완벽하게 정상입니다. 데이터베이스 엔진은이를 보호하기 위해 리소스를 잠 가야합니다. 잠금이 차단되는 순간에 대한 공식적인 정의는 없지만 1 초 미만의 잠금 틱은 정상적인 것 같습니다.