Del boletín técnico de SQL Server: cómo resolver un interbloqueo

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 832524

Boletín técnico de SQL Server

Trata el tema de este problema: cómo resolver un interbloqueo
Objetivo
Para identificar, solucionar problemas y recomendar una solución para resolver un interbloqueo.
Introducción
Este artículo examina una situación de interbloqueo y proporciona los pasos necesarios para resolver el interbloqueo. Cada interbloqueo puede ser diferente y puede deberse a varias variables de entorno diferente. La información proporcionada en este artículo puede ayudarle a identificar y resolver un interbloqueo.
Estudio de caso
En un estudio de caso, examinaremos un sistema 911 que tiene seis operadores. Durante la actividad pico, experiencias de la aplicación front-end de Microsoft Visual Basic que utilizan las conexiones interrumpidas. Debido a las conexiones interrumpidas, los operadores deben volver a ingresar los datos. Para un sistema 911 que funciona 24 horas al día, siete días a la semana, este comportamiento es inaceptable.
¿Qué es un bloqueo?
Un interbloqueo se produce cuando dos procesos de servidor de sistema IDs(SPIDs) está esperando un recurso y ningún proceso puede avanzar porque theother proceso impide obtener el recurso.

Subproceso de lockmanager comprueba si hay interbloqueos. Cuando detectionalgorithm de un administrador de bloqueos interbloqueo detecta un interbloqueo, el Administrador de bloqueos selecciona uno de los SPID como avictim. El Administrador de bloqueos inicia un mensaje de error 1205 que se envía a Elcliente y el Administrador de bloqueos mata el SPID. Matando el SPID libera los recursos y permite que los otro SPID continuar. Matando el SPID que es víctima de thedeadlock es lo que hace que la conexión rota que experimenta la aplicación final de Basicfront Visual.

En una aplicación bien diseñada, la aplicación cliente debe interceptar el error 1205, volver a conectarse a SQL Server y, a continuación, volver a enviar la transacción.

Althoughdeadlocks puede ser minimizada, no puede evitarse completamente. Por esta razón aplicación posición final debe estar diseñado para controlar los interbloqueos.
Cómo identificar un interbloqueo
Paso 1

Para identificar un interbloqueo, primero debe obtener loginformation. Si sospecha que un interbloqueo, debe recopilar información sobre the(SPIDs) y los recursos que participan en el interbloqueo. Para ello, addthe-T1204 - T3605 inicio parámetros y a SQL Server. Para agregar estos parámetros twostartup, siga estos pasos:
  • Inicie el Administrador corporativo de SQL Server.
  • Seleccione y, a continuación, haga clic en el servidor.
  • Haga clic en Propiedades.
  • Haga clic en parámetros de inicio.
  • En el cuadro de diálogo Parámetros de inicio , escriba -T1204 en el texto de parámetros de cuadro y, a continuación, haga clic en Agregar.
  • En el cuadro de texto de parámetros , escriba -T3605y, a continuación, haga clic en Agregar.
  • Haga clic en Aceptar.

Los parámetros de inicio surtirán efecto cuando SQL Server se detiene y, a continuación, vuelva a iniciar.

-Parámetro de inicio de T1204 collectsinformation sobre el proceso y los recursos cuando el detectionalgorithm de interbloqueo encuentra un interbloqueo. -Thisinformation T3605 inicio parámetro escribe los registros de errores de SQL Server.

-Recopila de startupparameter T1205 información cada vez que se comprueba el algoritmo de bloqueo para un interbloqueo, interbloqueo de cuando no se encuentra. No es necesario utilizar el T1205 inicio parámetro-.

Si utiliza el T1205 inicio parámetro-, el siguiente es un sampleof el resultado que se incluirá en el registro de errores de SQL Server:

2003-05-14 11:46:26.76 spid4     Starting deadlock search 12003-05-14 11:46:26.76 spid4     Target Resource Owner:2003-05-14 11:46:26.76 spid4      ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x43CAB580) Value:0x42bdf3402003-05-14 11:46:26.76 spid4      Node:1       ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x43CAB580) Value:0x42bdf3402003-05-14 11:46:26.76 spid4     2003-05-14 11:46:26.76 spid4     End deadlock search 1 ... a deadlock was not found.2003-05-14 11:46:26.76 spid4     ----------------------------------2003-05-14 11:46:31.76 spid4     ----------------------------------2003-05-14 11:46:31.76 spid4     Starting deadlock search 2


En ocasiones, podría no ser capaz de detener y reiniciar SQL Server. En ese caso, podráutilizar analizador de consultas para ejecutar el siguiente comando para habilitar los indicadores deadlocktrace.

Nota: De esta forma que puede recopilar información acerca de la deadlocksimmediately. "-1" indica todos los SPID.

dbcc traceon (1204, 3605, -1)godbcc tracestatus(-1)go

Paso 2

A continuación, debe recopilar una traza del analizador de SQL. Sino activar el indicador de traza de interbloqueo, obtendrá la mayoría de lo requiredinformation, pero no siempre. Por ejemplo, en el estudio de acase el identifiedthat de salida de indicador de traza un sistema sp_cursoropen procedimiento almacenado y un "UPDATE tblQueuedEvents setnotifyid = 3, ResynchDate" instrucción implicados en la adeadlock. Por desgracia, no sabe thedefinition del procedimiento almacenado del sistema sp_cursoropen . Tambiénhacer no tiene la instrucción de actualización completa porque lo wastruncated.

Analizador de SQL puede obtener las instrucciones completas además de los planes de ejecución de las instrucciones. Una traza del analizador de SQL también tiene un lockevent para "interbloqueo" y "cadena de interbloqueos". "Interbloqueo" corresponde al indicador de la T1204 y "cadena de interbloqueos" corresponde al indicador - T1205. Activación de los indicadores de traza de interbloqueo y ejecutando una traza del analizador de SQL durante la occurrenceof un interbloqueo deben proporcionarle los datos que debe tener para solucionar adeadlock. En este caso y en otros, ejecutando el analizador de SQL cambia la ejecución de timingof suficiente para evitar el interbloqueo. Por lo tanto, le typicallycapture la información de interbloqueo con los indicadores de traza y, a continuación, ejecutar SQLProfiler.
Solucionar problemas de un interbloqueo
Una vez que se produce un interbloqueo, Captiva recopilar información sobre el interbloqueo mediante la utilidadsqldiag y con el analizador de SQL. En la salida del archivo theSQLDiag.txt, busque una entrada "Espera para gráfico". A "espera-gráfico" entryindicates que se encontró un interbloqueo.

El siguiente es un resultado que puede aparecer en el registro de errores de SQL Server cuando se utiliza el T1205 inicio parámetro sampleof.

2003-05-05 15:11:50.80 spid4    Wait-for graph2003-05-05 15:11:50.80 spid4    Node:12003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x33AE1538) Value:0x1932003-05-05 15:11:50.80 spid4    Victim Resource Owner:2003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: X SPID:60 ECID:0 Ec:(0x1F1BB5B0) Value:0x1932003-05-05 15:11:50.80 spid4    Requested By: 2003-05-05 15:11:50.80 spid4    Input Buf: RPC Event: sp_cursoropen;12003-05-05 15:11:50.80 spid4    SPID: 55 ECID: 0 Statement Type: EXECUTE Line #: 12003-05-05 15:11:50.80 spid4    Owner:0x1937f2a0 Mode: S        Flg:0x0 Ref:1 Life:00000000 SPID:55 ECID:02003-05-05 15:11:50.80 spid4    Grant List 0::2003-05-05 15:11:50.80 spid4    KEY: 8:1653632984:2 (da00ce043a9e) CleanCnt:1 Mode: U Fl ags: 0x0 2003-05-05 15:11:50.80 spid4    Node:22003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x33AE1538) Value:0x1932003-05-05 15:11:50.80 spid4    Requested By: 2003-05-05 15:11:50.80 spid4    Input Buf: Language Event: Update tblQueuedEvents Set NotifyID = 2, ResynchDate2003-05-05 15:11:50.80 spid4    SPID: 60 ECID: 0 Statement Type: UPDATE Line #: 12003-05-05 15:11:50.80 spid4    Owner:0x1936e420 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:60 ECID:02003-05-05 15:11:50.80 spid4    Grant List 0::2003-05-05 15:11:50.80 spid4    KEY: 8:1653632984:1 (2d018af70d80) CleanCnt:1 Mode: X Flags: 0x0


En la entrada de "Espera para gráfico" tiene nodo 1 y nodo 2. Cada nodo tiene una sección de concesión y una solicitud. El grantsection es la "lista de concesión" y la sección de la solicitud es "RequestBy".
En cada nodo, puede identificar lo siguiente:
  • El SPID.
  • El comando que se estaba ejecutando el SPID.
  • El recurso.
  • El modo de bloqueo en el recurso.

Por ejemplo, en el nodo 1, la lista Grant, SPID 55 habían concedido un bloqueo de actualización, modo: U, en recurso clave: 8:1653632984:2. 8 = DBID, 1653632984 = ObjectID y 2 = Indid. Para obtener el número de identificación de la base de datos, ejecute el procedimiento sp_helpdb almacenados. Para obtener la tabla, ejecute el siguiente código:
select * from sysobjects where id = 1653632984


Para obtener el índice, ejecute el siguiente código:
select * from sysindexes where indid = 2 and id = 1653632984

Si IndexId es igual a 2, sabrá que el índice es un nonclusteredindex. El comando que se estaba ejecutando el SPID 55 era el procedimiento sp_cursoropen almacenados.

En el nodo 2, la lista Grant, 60 SPID se concedió un bloqueo exclusivo, modo: X, en recurso clave: 8:1653632984:1.8 = DBID, 1653632984 = ObjectID, 1 = Indid. Esto es en la misma tabla pero 1 es el índice agrupado. El comando que se estaba ejecutando el SPID 60 era:
Update tblQueuedEvents Set NotifyID = 2, ResynchDate

Un IndexId que es igual a 1 es un índice agrupado.

AnIndexId que es igual a 2 es un índice no agrupado.

Nota: Los interbloqueos son dependiente del tiempo.

A continuación, en el nodo 1, solicitar por 55 SPID solicita un bloqueo compartido, modo: S, en IndexId = 1. En el nodo 2, solicitar por 60 SPID solicita un bloqueo exclusivo, modo: X, en IndexId = 2. Becausethese las solicitudes de bloqueo se producen al mismo tiempo, se produce el interbloqueo. Cada SPID'sgranted bloqueos que impiden continuar los bloqueos solicitados.

Tabla Thefollowing muestra la tabla de compatibilidad de bloqueo. Compatibilidad de aboutlock más información, vea el tema "Compatibilidad de bloqueo" en SQL Server 2000 BooksOnline.

Tabla de compatibilidad de bloqueo
RequestedmodeISSUIXSEISX
Shared(IS) por intenciónNo
Compartido (S)NoNoNo
Actualización (U)NoNoNoNo
Exclusive(IX) por intenciónNoNoNoNo
Compartido con intención exclusivo (SIX)NoNoNoNoNo
Exclusive(X)NoNoNoNoNoNo


A continuación, examinando la salida, identifyObjectId 1653632984 como la tabla tblQueuedEvents y obtenga un procedimiento almacenado sp_help para la tabla de salida. Existían dos índices en la tabla. Los dos índices eran ix_tblQueuedEvents y PK_tblQueuedEvent. ix_tblQueuedEvents es un índice agrupado en ResynchDate y PK_tblQueuedEvent es una clave principal, el índice no agrupado único en EventSID.

La traza del analizador de SQL no pudo capturar la deadlockoccurrence. Recuerde, los interbloqueos son depende del tiempo. La sobrecarga de SQLProfiler probablemente se agrega algún tiempo a la ejecución de uno de lo y de procesos que impide que se dé una situación de interbloqueo SQL Profiler. Sin embargo, ocurriera proporcionan información recomiendautilizar puede utilizar para solucionar el problema. Encontrar total update tblQueuedEvents instrucción sea similar al siguiente:

Update tblQueuedEvents Set NotifyID = 2, ResynchDate = '5/7/2003 10:44:16' where eventSID = 73023
También se encuentra el plan de ejecución. Todavía no tiene la instrucción del procedimiento completo sp_cursoropen almacenado, pero tiene suficiente información torecommend una solución que resuelva el interbloqueo.

Este es el plan de ejecucion.

Nota: Este plan de ejecución concreto se lee de derecha a izquierdo y abajo a arriba.

StmtText                                                      				                                                                           				   				                                  --------------------------------------------------------------------------------------------------------------------------------------------------------------------				Update tblQueuedEvents Set NotifyID = 2, ResynchDate = '5/7/2003 10:44:16'				where eventSID = 73023                                                     				   				                    |--Clustered Index				Update(OBJECT:([SOTS].[dbo].[tblQueuedEvents].[ix_tblQueuedEvents ]),				SET:([tblQueuedEvents].[NotifyID]=[@1],				[tblQueuedEvents].[ResynchDate]=[Expr1004]))       |--Top(1)                                                                 				                                                                           				   				                          |--Compute Scalar(DEFINE:([Expr1004]=Convert([@2])))                				                                                                           				   				                                 |--Index				Seek(OBJECT:([SOTS].[dbo].[tblQueuedEvents].[PK_tblQueuedEvents]),				SEEK:([tblQueuedEvents].[EventSID]=[@3]) 
Recomendar una solución para resolver thedeadlock
Tenga en cuenta que la instrucción UPDATE es realizar una "actualización de índice agrupado" en el índice agrupado. Por lo tanto, la nonclusteredindex y el índice agrupado deben ambas se actualizan. El índice agrupado es ix_tblQueuedEvents y el índice no agrupado es PK_tblQueuedEvents. Para realizar las actualizaciones, la instrucción UPDATE debe obtainexclusive bloqueos en ambos índices. Estos dos índices son los índices que areinvolved en el interbloqueo. De revisar las trazas del analizador de SQL, se hicieron seeany no las consultas que utilizan el ResynchDate en la cláusula WHERE. Todos los statementswere muy específico, y utilizan la EventSID en la cláusula WHERE. Una mejor elección de un clusteredindex sería EventSID. Con esta información y una discusión con thecustomer, descubrimos que el índice ResynchDate era antiguo y no era necesario. Se recomienda que el cliente, colocar el índice ix_tblQueuedEvents en ResynchDate y que realizan PK_tblQueuedEvent un índice agrupado. Esto resuelve el deadlocksituation.

Esto es sólo un ejemplo de un interbloqueo que involveslocks del caso. Interbloqueos también pueden implicar paralelismo e implican subprocesos. Se caninvolve uno, dos, tres o más SPID y recursos. Con cualquier caso de interbloqueo, debe obtener – T1204 inicio parámetro output y el traceto de SQL Profiler identificar, solucionar y resolver el interbloqueo. Su deadlocksituation implicarán diferentes procesos y recursos. Por lo tanto, solutionswill varían de un caso a otro. Métodos típicos que se pueden utilizar para resolver deadlocksinclude:
  • Agregar y quitar índices.
  • Agregar sugerencias de índice.
  • Modificar la aplicación para tener acceso a los recursos en un modelo similar.
  • Eliminación de actividad de la transacción como desencadenadores. De forma predeterminada, los desencadenadores son transaccionales.
  • Mantener transacciones lo más cortas posible.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 832524 - Última revisión: 01/02/2016 05:49:00 - Revisión: 3.0

Microsoft SQL Server 2000 Standard Edition

  • kbsqlsetup kbtypenonkb kbpubtypett kbresource kbquery kbperformance kbserver kbdatabase kbhowto kbinfo kbcode kbmt KB832524 KbMtes
Comentarios