Solución:
Las cerraduras tienden a formar cadenas y siempre está interesado principalmente en lo que está haciendo el proceso a la cabeza de la cadena. Simplemente mirar los tiempos de espera de las cerraduras puede ser engañoso porque muchos procesos pueden esperar mucho tiempo (lo que aumenta las estadísticas de los tiempos de espera) pero todos se bloquean mediante un solo proceso lento. Lo que probablemente verá es un punto de fusión: porque los candados otorgados tienen que ser compatibles con todos los beneficiarios actuales y todos los camareros pendientes cada vez que un bloqueo de alto nivel (X o SCH_M) entra en la cola de espera de un recurso todos las solicitudes posteriores hacen cola detrás de esto.
Para dar un ejemplo: digamos que tiene una consulta ejecutando un informe en una tabla, digamos que toma 5 minutos. Tiene un candado IS en la mesa. Este IS es compatible con todas las operaciones normales (lee y escribe). Llega una solicitud que quiere SCH_M. Es incompatible con el IS, por lo que lo ponen en la cola. Ahora de repente todas las demás actividades en la mesa entra en la cola, porque todas las solicitudes, leídas o escritas, son incompatibles con este camarero. Entonces, de repente todos los tiempos de bloqueo aumentan. Después de 5 minutos, la consulta lenta finaliza (se ‘drena’ en la jerga de la base de datos), se otorga el SCH_M, hace su trabajo en 5 ms y todos los demás pueden continuar. Este es solo un ejemplo (extremo), no tiene que ser SCH_M. La idea es que los tiempos de espera no cuentan la historia completa.
Afortunadamente, el propio SQL Server puede informarle de cadenas de bloqueo a través de una función casi desconocida llamada blocked process threshold. Combine el Informe de proceso bloqueado y las notificaciones de eventos DDL y obtendrá una solución totalmente automatizada.
Para ver un ejemplo, vea mi respuesta en las herramientas de monitoreo de bloqueo de transacciones de terceros de MS SQL Server.
Otra observación: tiene un 22,30% de tiempos de espera en IX. Esto implica que se produjo un bloqueo de nivel de objeto. Los bloqueos de intención (IS, IX) son compatibles, por lo que el hecho de que IX estuviera bloqueado sugiere que alguien adquirió un bloqueo de nivel de objeto incompatible. Un escaneo que adquiere una S o una gran actualización que aumenta a X.
La recopilación de datos de sp_WhoIsActive en una tabla es una buena técnica para rastrear problemas de bloqueo y bloqueo.
El parámetro @get_locks se puede usar si desea ver los detalles más finos de los bloqueos involucrados. Alternativamente, @get_task_info y @get_additional_info generalmente capturarán lo suficiente para identificar la causa.
Si el resultado recopilado no es lo suficientemente claro para comprender el problema, no dude en agregar a su pregunta.