Deadlocks en SQL Server: del gráfico a la causa raíz

Un deadlock es un ciclo donde varias sesiones retienen recursos que otras necesitan. SQL Server finaliza una sesión, pero la víctima no siempre es la causa.

Por qué este tema requiere atención deliberada

Un problema de este tipo rara vez existe aislado. Un cambio que mejora una consulta puede aumentar escrituras, registro, bloqueos, recuperación o complejidad en otro punto. Trata el trabajo como una decisión de ingeniería con objetivo medible, restricciones conocidas y responsable claro.

La solución duradera elimina o acorta el ciclo. Los reintentos protegen al usuario, pero no sustituyen la corrección de la causa.

Qué medir

Captura el XML mediante Extended Events. Revisa procesos, recursos, modos de bloqueo, instrucciones, transacciones y víctima, y relaciona cada instrucción con la operación de la aplicación.

Flujo de diagnóstico

• Define exactamente el síntoma, carga afectada, inicio, frecuencia e impacto visible.
• Captura evidencia durante periodos normales y degradados para la misma operación de negocio.
• Separa correlación de causa revisando planes, esperas, recursos, bloqueos, configuración y cambios recientes.
• Prueba grupos representativos de bases, consultas o parámetros, no solo el ejemplo más sencillo.
• Conserva configuración, plan, definición y contadores actuales antes de cambiar nada.
• Expresa numéricamente el resultado esperado: latencia, CPU, lecturas, rendimiento, cola o recuperación.

Cómo elegir la intervención

Prefiere el cambio más limitado que trate la causa demostrada. La configuración del servidor afecta muchas cargas, mientras que consultas, índices, estadísticas u horarios pueden ser más precisos. Considera licencia, versión, alta disponibilidad, ventanas y capacidad del equipo para supervisar.

Enfoque práctico

Accede a los objetos en orden coherente, acorta transacciones, mejora rutas de acceso cuando esté justificado e implementa reintentos limitados para el error 1205.

Secuencia segura de implementación

• Reproduce el comportamiento en un entorno seguro con datos a escala de producción.
• Cambia una variable importante cada vez y conserva la definición original para revertir.
• Mide duración, CPU, lecturas, escrituras, esperas, memoria, registro y efectos posteriores.
• Prueba entradas normales, picos y extremos, además de reinicio o failover cuando corresponda.
• Despliega en una ventana adecuada con operador, propietario de aplicación y decisor conectados.
• Revisa el resultado de inmediato y durante el siguiente pico representativo.

Ejemplo de SQL Server

El siguiente ejemplo es un punto de partida para investigar o implementar de forma controlada. Adapta nombres, límites, retención y permisos antes de producción. Conserva la salida junto con la cronología del incidente y no trates una sola muestra como diagnóstico completo.

CREATE EVENT SESSION CaptureDeadlocks ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.event_file
(
    SET filename = N'D:\XEvents\deadlocks.xel',
        max_file_size = 100,
        max_rollover_files = 5
);
ALTER EVENT SESSION CaptureDeadlocks ON SERVER STATE = START;

Qué evitar

No uses NOLOCK como solución universal, no culpes solo a la víctima y no conserves únicamente una captura del gráfico.

Supervisión después del cambio

Vigila la métrica que debía mejorar y al menos dos posibles efectos secundarios. Compara ventanas y volúmenes equivalentes. Observa el tiempo suficiente para incluir mantenimiento, copias, informes, failover y tareas periódicas. Documenta si la mejora persiste y si el cambio debe mantenerse, ajustarse o retirarse.

Reversión y responsabilidad

La reversión debe indicar el valor o definición anterior, quién decide y qué señal la activa. Conserva el plan y script originales para cambios de planes o metadatos. Para infraestructura, confirma capacidad y tiempo de mantenimiento antes de empezar.

Resultado operativo

La solución duradera elimina o acorta el ciclo. Los reintentos protegen al usuario, pero no sustituyen la corrección de la causa.

Lista de producción

Captura una línea base y define la mejora esperada. Prueba con datos y concurrencia representativos. Conserva la configuración o el plan original, prepara una reversión, despliega en una ventana adecuada y observa el siguiente pico normal de carga.

Preguntas antes de cerrar

• ¿Mejoró el síntoma original bajo la misma carga?
• ¿Aparecieron costes de escritura, almacenamiento, bloqueo, memoria o disponibilidad?
• ¿Sobrevivirá el resultado a reinicios, failover, estadísticas y crecimiento?
• ¿Las alertas detectarán una regresión antes que los usuarios?
• ¿Quedaron registrados la decisión, el responsable y la fecha de revisión?

Si quieres aplicar este método a un entorno SQL Server concreto, usa el formulario inferior e incluye la versión, el tamaño de la base, el patrón de carga y las evidencias ya recopiladas.