Cómo capturar eficazmente la información de BLOQUEO de SQL Server

SQL Server permite operaciones concurrentes. BLOQUEO significa que antes de que se complete una operación, otras operaciones deben esperar para garantizar la integridad de los datos. La solución al BLOQUEO es comprobar qué es el encabezado BLOQUEO y por qué las declaraciones en el encabezado BLOQUEO se ejecutan muy lentamente. En términos generales, siempre que podamos encontrar la declaración en el encabezado BLOQUEO, siempre podemos encontrar varias formas de mejorar el rendimiento y aliviar o resolver el problema BLOQUEO.

Pero la clave del problema es que no sabemos cuándo ocurrirá el BLOQUEO. Los usuarios se quejaron de que el rendimiento de la base de datos era deficiente. Cuando nos conectamos a la base de datos para verificar, es posible que el BLOQUEO ya haya pasado. El rendimiento ha vuelto a mejorar. O debido a la urgencia del problema, directamente reiniciamos el servidor para reanudar las operaciones. Pero el problema no se resuelve finalmente y no sabemos cuándo volverá a ocurrir.

Las consecuencias del problema de BLOQUEO son graves. Porque los usuarios finales pueden experimentarlo directamente. Cuando envían un pedido, no se puede enviar pase lo que pase. Un envío de pedido que generalmente se puede completar en unos pocos segundos puede incluso tener que esperar más de diez minutos antes de que se complete el envío. Es más, un BLOQUEO extremadamente grave puede provocar que SQL Server deje de funcionar. Como se muestra en el siguiente ERRORLOG de SQL, en solo unos minutos, los datos SPID aumentaron de 158 a 694, lo que inmediatamente provocó que SQL Server realizara un volcado y dejara de funcionar. Podemos inferir fácilmente que la causa del problema es el BLOQUEO, pero no podemos saber qué es el ENCABEZADO DE BLOQUEO. Debemos esperar hasta la próxima vez que el problema se repita y complementarlo con herramientas para saber qué está haciendo el ENCABEZADO DE BLOQUEO. Si la información se captura en el momento equivocado, es posible que tengamos que esperar a que el problema ocurra varias veces antes de poder detectarlo. En este momento, los clientes y gerentes se quejarán. Debido a que nuestro sistema es un sistema de producción, cada vez que ocurre un problema, causará pérdidas a los clientes.

2011-06-01 16:22:30.98 Alerta spid1931 Hay 158 sesiones de base de datos activas, lo cual es demasiado alto.

2011-06-01 16:23:31.16 Alerta spid3248 allí hay 342 sesiones de base de datos activas, lo cual es demasiado alto.

2011-06-01 16:24:31.06 Alerta spid3884 Hay 517 sesiones de base de datos activas, lo cual es demasiado alto.

2011-06 -01 16:25:31.08 Alerta spid3688 Hay 694 sesiones de base de datos activas, lo cual es demasiado alto.

2011-06-01 16:26:50.93 Servidor usando 'dbghelp.dll' versión '4.0.5'

2011-06-01 16:26:50.97 Servidor ** Hilo de volcado - spid = 0, EC = 0x0000000000000000

2011-06-01 16:26:50.97 Servidor ** *El volcado de pila se envía a D:\MSSQL10.INSTANCE\MSSQL\LOG\SQLDump0004.txt

2011-06-01 16:26:50.97 Servidor * *********** ** ************************************************* *** *******************

2011-06-01 16:26:50.97 Servidor *

2011-06 -01 16 :26:50.97 Servidor * COMENZAR VOLCADO DE PILA:

2011-06-01 16:26:50.97 Servidor * 01/06/11 16:26:50 spid 4124

2011- 06-01 16:26:50.97 Servidor *

2011-06-01 16:26:50.97 Servidor * Programadores estancados

2011-06-01 16:26: Servidor 50.97*