Deadlock en tablas temporales de SQL Server

Seguramente ya viste nuestras publicaciones respecto a Qué es un deadlock en SQL Server y ahora te preguntas si es posible que se generen estos eventos en tablas que se encuentran en la base de datos tempdb. En el enlace anterior ya viste el concepto de los escenarios en los que aparece un error de este tipo, entonces ahora es posible generar la duda por si pueden suceder errores de Deadlock en tablas temporales.

– ¿Cuándo dijimos que se genera un deadlock?

– Cuando dos (o más) procesos pelean por un recurso.

– ¿Pueden dos procesos diferentes pelear por una tabla temporal?

Detente en la última pregunta y vuelve a leerla. Aquí empieza la duda.

Alternativas

Una inicial que se me viene a la cabeza y posiblemente a ti también, es que se hayan utilizado tablas temporales globales y no locales. Estas que tienen dos símbolos de numeral ##.

Podemos verificar que si creamos tablas temporales locales desde diferentes sesiones, en la base de datos tempdb tenemos una codificación diferente para cada una de ellas.

No pasa lo mismo cuando revisamos tablas temporales globales como se ve en la siguiente imagen.

¿Entonces cuál es la posibilidad de que suceda un deadlock en tablas temporales?

Si hablamos de tablas locales (no globales), podríamos deducir de acuerdo a lo mostrado que la posibilidad es prácticamente nula.

Las tablas temporales locales nunca serían vistas por procesos diferentes por lo que el concepto del deadlock no aplicaría respecto a recursos compartidos.

Revisando el XML generado de un DEADLOCK

Un error que encontré entre los varios que me toca analizar.

Fíjate que según el XML, el error se origina durante la inserción en una tabla temporal.

¿O sea…qué? ¿El error pasó con una tabla temporal?

Pues parece que sí.

¿Ahora qué?

Tenemos diferentes posibilidades para evitar este tipo de acciones, pero es importante que puedas ver cada detalle de tus procedimientos.

Revisa estos detalles.

1. ¿Reutilizas tu tabla temporal?
2. ¿Existen otros objetos involucrados en las consultas?
3. ¿Será que es un caso con Lock Partitioning?

Evita usar la misma tabla temporal a lo largo del SP para diferentes operaciones para reducir su uso. Esto no es un factor decisivo, pero he visto en muchos lugares la costumbre de llevar todo a una tabla temporal y realizar múltiples UPDATES en todo el código siguiente. Revisa si es posible agrupar los bloques para mejorar el rendimiento.

No quiero que pierdas de vista un pequeño detalle pero muy importante en la descripción del error de deadlock en el XML que te mostraba más arriba. Fíjate las flechas.

Se está realizando un JOIN con una tabla física y la misma también puede afectar en la generación de LOCKS durante las transacciones.

Finalmente, si tienes habilitado el LOCK Partitioning es posible que necesiten algunas actualizaciones en tu servidor. Mira el detalle de la documentación oficial, este es un documento no muy conocido.

No olvides siempre tener activo cualquiere sistema de monitoreo de errores. Aquí te dejamos una idea de cómo monitorear eventos de deadlock.