Este error se produce cuando Microsoft® SQL Server™ encuentra un interbloqueo. Un interbloqueo se produce cuando dos (o más) procesos intentan tener acceso a un recurso que otro proceso mantiene bloqueado. Dado que cada proceso posee una solicitud para otro recurso, no se podrá procesar ninguno de los procesos. Cuando se detecta un interbloqueo, SQL Server revierte el comando con el menor tiempo de procesamiento y devuelve el mensaje de error 1205 a la aplicación cliente. Este error no es grave y podría no ser la causa de que finalice el lote.
Soluciones
En algunas instancias, una condición de interbloqueo dará lugar a que una función DB-Library (como dbsqlexec, dbsqlok, dbresults o dbnextrow) devuelva un error. Siempre es responsabilidad del programa comprobar los códigos de retorno de cada función DB-Library. Si alguna de estas funciones de DB-Library devuelve un error, el programa debe cancelar el lote y no intentar continuar. En algunos casos, es posible seguir con la ejecución de las funciones posteriores del lote. No obstante, ya que se ha producido una situación de interbloqueo y las funciones que la provocaron se han revertido, las funciones posteriores del lote devolverán un error más grave, como "objeto no encontrado".
En otras instancias, una condición de interbloqueo no provocará que la función DB-Library devuelva un error. En tales casos, el programa debe comprobar si existe algún mensaje de error 1205 en el controlador de mensajes y usar la función dbsetuserdata para comunicárselo a la aplicación. A continuación, el programa debe comprobar el indicador de interbloqueo después de cada llamada a DB-Library y deberá cancelar el lote si se detecta un interbloqueo.
Aunque puede parecer innecesario cancelar un lote después de recibir un mensaje de interbloqueo 1205, es necesario porque el servidor no siempre termina el lote cuando se produce una situación de interbloqueo. Si no se cancela el lote, cualquier intento de enviar un lote nuevo puede dar lugar a un error de DB-Library 10038 de resultados pendientes.
También puede usar la instrucción SET DEADLOCK_PRIORITY (LOW o NORMAL). SET DEADLOCK_PRIORITY controla cómo reacciona la sesión cuando se produce una situación de interbloqueo. Si se establece en LOW, el proceso será el objetivo preferido del interbloqueo. Si se define en NORMAL, la sesión usará un método de control de interbloqueos predeterminado.
Si una situación de interbloqueo persiste, suele ser útil usar una marca de seguimiento 1204 para recopilar más información. Esta marca imprime las cadenas y el sujeto de interbloqueo como se muestra a continuación:
Esta información de interbloqueo puede interpretarse del siguiente modo:
La primera sección muestra el sujeto y el tiempo del interbloqueo junto con las sesiones implicadas en el interbloqueo. Para cada sesión, se mostrará el SPID actual, el tipo de instrucción y una parte del búfer de entrada.
En la segunda sección se incluyen los detalles de los bloqueos implicados en el interbloqueo. En el ejemplo anterior, observe que el interbloqueo afecta a bloqueos de clave en la tabla t1, índice i1. El resultado del interbloqueo muestra cuáles son los procesos a los que pertenecen los bloqueos del interbloqueo y qué sesiones están a la espera de que se concedan los bloqueos así como los modos de bloqueo asociados.
El proceso que ha generado la cantidad inferior de volumen de registro se elegirá, de forma predeterminada, como el objetivo del bloqueo y se revertirá automáticamente. Para determinar qué sesión se revertirá, establezca DEADLOCK_PRIORITY para una sesión.
Home
ESN