SQL:Luchando contra los interbloqueos en Sql Server


La bases de datos utilizan los bloqueos para asegurar las propiedades ACID de las transacciones. Son un mecanismo imprescindible que tienen una cara oculta, un peaje necesario que muchas veces nos complica la vida: los interbloqueos.

Los interbloqueos son una situación a la que todo desarrollador de aplicaciones que manejan un volumen elevado de datos o de peticiones concurrentes se enfrenta en alguna ocasión. Desde el punto de vista de proceso de desarrollo, el antidotó es simple: hacer pruebas de carga y tener en cuenta las prácticas remendadas para evitar los interbloqueos.

Las recomendaciones para evitar los interbloqueos, que deben ser conocidas por todo desarrollador son:

  • Acceder a los objetos en el mismo orden en los diferentes procesos de nuestra aplicación.
  • Evitar que los usuarios tengan que intervenir durante el proceso de una transacción.
  • Mantener las transacciones lo más cortas y eficientes posible.
  • Elegir índices adecuados.
  • Utilizar el mínimo nivel de aislamiento posible (recordad que Sql Server por defecto utiliza Read Commited como nivel de aislamiento, sin embargo muchas veces será sufiente usar Read Uncommited como nivel de aislamiento).

Pero la tozuda realidad, según mi experiencia, es que por muchas pruebas de carga que hagas y por mucho que sigas las recomendaciones es dificil no sufrir interbloqueos la primera vez que pones tu aplicación en producción. Es muy dificil reproducir en un entorno de laboratorio las condiciones reales a las que se enfrentará nuestra aplicación. El problema es que los interbloqueos afectan seriamente al rendimiento de la aplicación y además se manifiestan a menudo como errores funcionales en la aplicación.

La pregunta que debemos contestar y el mótivo de escribir este post es: una vez que sabemos que estamos sufriendo interbloqueos ¿cómo sabemos en que situación concreta se están producciendo?. Dilucidar que consultas están es vital para deshacer el entuerto. Es aquí donde una característica muy poco conocida del profiler de Sql Server no es de tremenda ayuda.

Entre los numerosísimos eventos que podemos recolectar hay uno especialmente útil a la hora de diagnosticar interbloqueos, el evento Deadlock graph (gráfico de interbloqueo):

Evento deadlock graph

Si creamos una traza del profiler de Sql Server en la que incluyamos este evento, cada vez que se produzca un interbloqueo el profiler capturará toda la información relativa al evento, incluidas las consultas que causaron el interbloqueo y nos la mostrará gráficamente:

Deadlock Graph

En la imagen de encima de estas líneas podéis ver el resultado de probocar un interbloqueo intencionado en la base de datos AdventureWorks.

Otra caracterísca interesante es que el profiler nos permite exportar este evento a un archivo XDL (Deadlock XML file) para, por ejemplo, poder enviarlo por correo.

Extraer datos del evento

¡Espero que estas características del Profiler de Sql Server os sean útiles a la hora de luchar contra los interbloqueos!

Acerca de albertoarceti
Administrador de sistemas informáticos, y erps en la industria farmacéutica.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: