Análisis del bloqueo de SQL Server

Los bloqueos se producen cuando dos (o más) procesos necesitan acceder al mismo recurso de forma simultánea. Cuando un proceso solicita acceso a un recurso, se genera un bloqueo que obliga a otros procesos que necesitan ese mismo recurso a esperar hasta que finalice el primer proceso. En la mayoría de los casos, el segundo proceso espera a que el primero libere el bloqueo. Luego, todo continúa con normalidad. En general, esto demora pocos segundos.

Sin embargo, a veces, el primer proceso puede demorar más de lo esperado, lo que hace que el segundo proceso (y posiblemente otros procesos) se apile detrás de él mientras se espera el recurso. Esto puede afectar el desempeño de la aplicación y la experiencia del usuario final. La duración de una consulta y el contexto de la transacción determinan el tiempo durante el que se mantienen los bloqueos.

Es importante considerar que no todos los bloqueos de SQL Server son malos. De hecho, son normales. Después de todo, SQL Server es un sistema de simultaneidad basado en bloqueos, y solo se puede acceder a los recursos de un proceso por vez. Es probable que existan superposiciones en algún momento. El problema ocurre cuando los bloqueos tardan en solucionarse y se crean cadenas de bloqueos.

Además, no todos los tipos de bloqueos bloquean automáticamente a otros. Algunos tipos de bloqueos tienen más restricciones y, por lo tanto, generan más bloqueos. Entre los tipos de bloqueos se incluyen los siguientes:

• Bloqueos exclusivos: Estos bloqueos ocurren cuando un proceso necesita modificar datos. Esto impide que dos procesos puedan modificar datos al mismo tiempo.
• Bloqueos de esquema: Los bloqueos de esquema se otorgan a los procesos que dependen de un esquema coherente durante las operaciones.
• Bloqueos compartidos: Estos bloqueos se otorgan a las operaciones de lectura. Tienen menos restricciones que muchos otros tipos de bloqueos y, por lo tanto, no suelen generar bloqueos.
• Bloqueos de actualización: Los bloqueos de actualización se otorgan a las actualizaciones y, en general, se usan durante aquellas que conllevan varios pasos.

Algunos tipos de bloqueos tienen mayor compatibilidad con otros. Por ejemplo, mientras que los bloqueos exclusivos no son compatibles con ningún otro tipo de bloqueo y generan bloqueos si otro proceso requiere el recurso en cuestión, los bloqueos compartidos y de actualización pueden ocurrir en el mismo recurso al mismo tiempo.

Es posible que se confundan los deadlocks y los bloqueos, ya que ambos ocurren cuando dos procesos necesitan recursos específicos, pero no pueden acceder a ellos para completar una consulta. Sin embargo, los bloqueos y los deadlocks no son lo mismo.

Los bloqueos en SQL Server ocurren cuando dos (o más) procesos necesitan el mismo recurso. Después de todo, solo un proceso puede acceder a un recurso por vez. Esto significa que si un proceso usa un recurso, el siguiente proceso no podrá acceder al mismo recurso hasta que el primer proceso termine de usarlo.

Por otro lado, los deadlocks ocurren cuando los procesos intentan acceder a diferentes recursos. Por ejemplo, el primer proceso bloquea al Recurso A, mientras que el segundo proceso bloquea al Recurso B. Si el primer proceso necesita bloquear al Recurso B para completarse y el segundo necesita bloquear al Recurso A, ambas operaciones se detendrán abruptamente dado que estarán esperándose la una a la otra. Básicamente, se trata de un callejón sin salida.

Por suerte, SQL Server puede con frecuencia solucionar los deadlocks, ya que permite que un proceso se revierta para que el otro pueda continuar sin obstáculos. SQL Server reiniciará, luego, ese segundo proceso cuando el primero haya dejado de usar el recurso.

Es probable que dos procesos necesiten el mismo recurso en algún momento, y los bloqueos en general se resuelven solos tan pronto como el primer proceso finaliza. Sin embargo, los bloqueos pueden representar un problema en ciertas instancias.

Para verificar los bloqueos en SQL Server, puede usar una consulta a fin de identificar el SPID del bloqueo. Solo debe usar las DMV de SQL Server y ejecutar una consulta con la DMV sys.dm_exec_requests. Esto devolverá una lista de SPID de bloqueo, los SPID que estén bloqueados, y el tipo de espera y su duración.

También puede usar SQL Server Management Studio para verificar los bloqueos en SQL Server e identificar el inicio de la cadena de bloqueos. Deberá seleccionar Objeto del servidor, Informes, Informes estándar y, luego, Actividad — Todas las transacciones con bloqueos. SQL Server Management Studio devolverá un informe en el que se muestra la transacción que encabeza la cadena de bloqueos y las transacciones que actualmente están bloqueados por esa transacción principal.

SQL Sentry facilita aún más la identificación de los bloqueos problemáticos ya que monitorea constantemente los bloqueos de SQL Server. Con el calendario de eventos de SQL Sentry, puede ver bloqueos junto con otros eventos. Además, SQL Sentry incluye sólidos análisis de bloqueos y puede recopilar los detalles de bloqueo en función de los umbrales específicos de duración. Por ejemplo, si busca información sobre los bloqueos que duren más de diez segundos, SQL Sentry automáticamente registra datos (como la instrucción ejecutada, el host, el inicio de sesión, la base de datos, y los tipos y recursos de espera) de aquellos bloqueos que duren más de diez segundos y le ofrecerá la opción de ver esos detalles en tiempo real o más tarde.

Gracias a su vista por jerarquía y a los nodos codificados por color, SQL Sentry permite comprender una cadena de bloqueo de inmediato. Sabrá al instante si una instrucción se está ejecutando, se completó o está bloqueada. Además, puede ver las relaciones entre los bloqueos y los SPID bloqueados en la cadena, lo que acelera mucho el análisis.

Cuando se identifica un bloqueo que genera problemas, estos deben detectarse y solucionarse. Entre las situaciones de bloqueo y las soluciones comunes que puede encontrar se incluyen las siguientes:

• Una consulta con un tiempo de ejecución largo: Si una consulta presenta un tiempo de ejecución excesivamente largo y genera bloqueos agresivos para evitar que otros procesos lean o modifiquen los mismos datos, eso puede generar bloqueos de SQL Server que representarán un problema. Para solucionar este problema, primero deberá ubicar la consulta que genera bloqueos de SQL Server mediante el análisis de las DMV o a través de la verificación de la plataforma de monitoreo. Luego, puede optimizar su consulta y los planes de ejecución.
• Una aplicación que usa una transacción compleja que lleva adelante instrucciones o lotes antes de completarse: Si una aplicación lleva adelante múltiples instrucciones o lotes antes de completarse (guarda los datos), los demás procesos no podrán acceder al recurso durante ese período. En este caso, también, deberá identificar la consulta que encabeza la cadena de bloqueos y, luego, ajustar su desempeño.
• Se abandona una transacción y no se liberan los bloqueos: Si se cancela una aplicación o se vence el tiempo de espera de su consulta, el SPID finalizará la consulta y el lote. Sin embargo, no se revertirá ni se completará automáticamente la transacción, lo que podría ocasionar bloqueos. A fin de detectar y solucionar este problema, debe identificar el SPID que mantiene abierta la transacción y hacer que esta se revierta o usar el comando kill de T-SQL.
• Un SPID cuya aplicación cliente no recuperó todas las filas de resultados: Cuando una aplicación no busca de inmediato todas las filas de resultados, quedan los bloqueos en las tablas, lo que genera un bloqueo general. Para solucionar este problema, deberá reescribir la aplicación a fin de que busque todas las filas de resultados. Si desea evitar este problema en primer lugar, restrinja las aplicaciones con mal comportamiento en un informe separado o en una base de datos que respalde las decisiones.

Lo bueno es que SQL Sentry puede ayudar, sin importar la situación de bloqueo a la que se enfrente. SQL Sentry recopila y retiene datos de bloqueos y deadlocks. No solo le ofrece una vista integral del desempeño actual, sino que además le permite mirar hacia atrás. Además, puede observar los problemas de bloqueo en tiempo real y eliminar los procesos que generan bloqueos de SQL Sentry en un solo clic. Gracias a la ayuda de SQL Sentry, puede comprender los motivos por los que ocurren los bloqueos y volver a diseñar sus consultas y transacciones a fin de evitarlos en el futuro.

SQL Sentry incluso puede actuar de forma automática contra las condiciones de bloqueo de SQL en los momentos en que usted no está presente. Solo debe configurar previamente SQL Sentry para que realice determinadas acciones ante ciertas condiciones.

Es fundamental que los administradores de base de datos sepan cómo encontrar los bloqueos de SQL Server, ya que estos pueden impedir que los DBA lleguen a los recursos críticos para el negocio y evitar que administren las bases de datos con eficiencia. Sin embargo, los bloqueos pueden resultar complejos y consumir tiempo al momento de detectar y solucionar problemas. Estas son cinco de las causas más comunes de bloqueos:

1. Instrucciones SQL ineficientes ejecutadas cuando la sesión de la base de datos estaba bloqueada
2. Sesiones en espera que se pierden a nivel del anidamiento de la transacción
3. Aplicaciones que no pueden recuperar los resultados de las filas
4. Sesiones que revierten datos
5. Sesiones que se abandonan porque la aplicación cliente dejó de funcionar o se desconectó

Aun así, en una empresa grande con bases de datos incluso más grandes, existen muchos más motivos por los cuales podría bloquearse una sesión. Sería todo un desafío que un administrador de base de datos llegara al inicio de la cadena de bloqueos y expusiera estos motivos de forma manual.

Las herramientas estándar de monitoreo de SQL Server mostrarán los bloqueos de la base de datos y sus esperas, pero no identificarán al bloqueador de raíz que es responsable de la cadena de bloque. A mayor cantidad de bloqueos, más aplicaciones lentas, pero ¿cómo puede el administrador de base de datos determinar si los crecientes bloqueos indican que la base de datos no es eficiente o si son el motivo por el que los tiempos de respuesta de las aplicaciones es bajo?

Las herramientas como SQL Sentry ayudan a los DBA a llegar al final de una cadena de bloqueos de SQL Server, a solucionar los bloqueos con rapidez y a regresar al trabajo.

Detectar los bloqueos no solo es importante cuando los bloqueadores afectan de forma activa el desempeño de la base de datos. Dado que los bloqueos son derivados necesarios del trabajo con SQL Server, los DBA deben hacer todo lo que está en su poder para monitorear de forma proactiva los problemas de bloqueos o reparar el código que genera bloqueadores inactivos. Una parte clave de las mejores prácticas de la administración de base de datos es usar software que esté diseñado para ayudar a detectar bloqueadores incluso durante sus primeras etapas.