Cómo rastrear el bloqueo que ocurre por menos de un segundo - SQL Server

Estoy tratando de solucionar un problema de bloqueo que ocurre por menos de un segundo. La aplicación OLTP es muy sensible y debe tener un tiempo de respuesta de menos de 200 ms para algunas transacciones según el acuerdo de nivel de servicio acordado. Tuvimos algunos problemas de escalada de bloqueo con la nueva versión del código que pudimos resolver reduciendo el tamaño del lote en las actualizaciones. Incluso con el pequeño tamaño de lote, sospechamos que el nuevo sp está bloqueando las mismas filas que las transacciones OLTP están actualizando.

Necesito encontrar la sesión que se está bloqueando y el recurso está esperando. Según mi entendimiento, el "umbral de proceso bloqueado" puede establecerse por un mínimo de 1 segundo, por lo que esto no capturará el bloqueo.

Estoy experimentando con wait_info y wait_completed x eventos.

¿Hay alguna otra forma de rastrear esto? Gracias

Como está específicamente interesado en bloquear en lugar de esperar en general, el locks_lock_waitsevento extendido suena más adecuado.

Con un filtro encendido 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;  

Lo anterior reúne las declaraciones que esperan en los bloqueos durante el umbral de tiempo, pero no proporciona el recurso de bloqueo específico.

Nunca he usado este evento y no tengo idea de cuánto sobrecargaría esta sesión en su servidor de producción.

Encontré este video sobre el tema. Eso recomienda encarecidamente filtrar counterpara reducir la cantidad de eventos recopilados y lo he hecho anteriormente.

También menciona un antiguo comando indocumentado heredado

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

Que (si el indicador de seguimiento 3605 está habilitado) volca información limitada, como la siguiente, en el registro de errores de SQL Server.

El proceso 53 esperó 6844 ms para el bloqueo S en RID: 2: 1: 120: 2 resultado: OKWAIT

Solo menciono esto de pasada, ya que los eventos extendidos serían claramente preferibles de todos modos, ya que está documentado y es mucho más poderoso.

Si está interesado en bloquear, hay varios eventos extendidos disponibles:

lock_acquired
lock_released
lock_escalation

Los primeros dos eventos tienen una durationcolumna en (microsegundos) que puede filtrar para sus umbrales. También tienen una resource_descriptionacción que le dará algunos detalles sobre los recursos involucrados.

El lock_escalationevento también tiene una statementacción que puede agregar para recopilar la instrucción T-SQL que desencadenó la escalada de bloqueo. También tiene escalation_cause. Aquí hay una sesión de muestra:

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

Sospecho que probablemente haya una razón por la que no puede establecer el umbral del informe de proceso bloqueado en menos de un segundo: el bloqueo es perfectamente normal en un RDBMS: el motor de la base de datos debe bloquear los recursos para protegerlos. Aunque no existe una definición oficial de cuándo el bloqueo se convierte en bloqueo, el bloqueo del tic-tac en menos de un segundo me parece algo normal.