¿Puedo ser una víctima de interbloqueo si no estoy ejecutando una consulta dentro de una transacción?

Digamos que abro una transacción y ejecuto consultas de actualización.¿Puedo ser una víctima de interbloqueo si no estoy ejecutando una consulta dentro de una transacción?

BEGIN TRANSACTION 
UPDATE x SET y = z WHERE w = v

La consulta devuelve con éxito y la operación se mantiene abierta deliberadamente por un período de tiempo antes de que decida comprometerse.

Mientras estoy sentado en la transacción es posible que la máquina MSSQL interbloquee mi transacción abierta que en realidad no está ejecutando nada para eliminar un interbloqueo o liberar recursos a medida que se alcanzan los límites de memoria/recursos del sistema ?

Conozco SET DEADLOCK_PRIORITY y he leído los artículos de MSDN sobre el tema de interbloqueos. Lógicamente, dado que no estoy buscando activamente reclamar recursos adicionales, no puedo imaginar un escenario que pueda desencadenar un sano algoritmo para evitar interbloqueos.

¿Alguien sabe a ciencia cierta si es posible que el simple hecho de tener cerraduras pueda convertirme en un objetivo válido? Del mismo modo, ¿podría una condición de bajo recurso desencadenar la muerte de mi SPID?

Fuente

2010-01-13 Einstein

No sé a ciencia cierta (por eso esto es un comentario), pero yo creo que si está simplemente dando vueltas con las cerraduras se abren que sería más probable que se seleccione como sujeto del interbloqueo (no menos probable) Los bloqueos ocurren cuando dos procesos necesitan el mismo recurso y ninguno se va a rendir. Si está sosteniendo bloqueos, entonces está haciendo un punto muerto con su proceso más probable, no menos. En cuanto a qué spid es la víctima, nunca escuché que el proceso de selección es determinista en el nivel de usuario. De cualquier manera, tus probabilidades empeoran cuanto más tiempo tienes las cerraduras. – Vaccano

Para un punto muerto que se produzca todos los participantes en la cadena de punto muerto debe ser esperando para un recurso (una cerradura). Si su conexión está inactiva, significa que no ejecuta una solicitud, lo que implica que no puede estar esperando.

En cuanto a otras condiciones que pueden matar a la sesión de que se me ocurre de por lo menos tres: las operaciones

administrativos que utilizan CON ROLLBACK_IMMEDIATE
una conmutación por error reflejo
intencional KILL <yourspid>, tal vez como una broma por su amigable DBA

Fuente

2010-01-13 07:37:42

Tengo que amar a esos amigables DBA ... – Rory

¿Estás seguro de que tiene que estar esperando? ¿Qué pasa si está bloqueando otro hilo y sentado en un WAITFOR? –

@John: Sí, * debe * estar esperando un recurso. Si T1 espera que el recurso A propiedad de T2 y T2 se encuentre en WAITFOR, entonces * habrá progreso * cuando se reanude T2. Para que la cadena de interbloqueo cierre T2 tiene que estar esperando un recurso, de lo contrario la detección de punto muerto no verá un círculo completo y no intervendrá. Además, el círculo completo debe estar dentro de SQL, si T2 espera en un semáforo de aplicación propiedad de T1, el círculo se completa fuera de SQL y no se detectará nuevamente. –

-1

El hecho de que no esté en una transacción no significa que no tenga cerraduras.

Fuente

2010-01-13 07:32:54

Puedo ver por qué ha publicado esto, el título está mal redactado. Sin embargo, quiere decir que, mientras está en una transacción, en realidad no está ejecutando una consulta. (Él está en una transacción, pero no está haciendo SQL). Al menos así es como lo leí. – Vaccano

Como dije, lo importante no es que esté en una transacción o no, lo que importa son los bloqueos que tiene y los bloqueos que puede estar esperando. Dependiendo de los detalles del algoritmo de detección de punto muerto, me parece que podría considerarse parte del punto muerto si tiene un bloqueo y "no hace nada" durante demasiado tiempo. –

En cuanto al algoritmo de detección en sí, traté de encontrar cualquier cosa que indique que el tiempo de retención del bloqueo sea parte del proceso de decisión de los algoritmos de detección. ¿Hay alguna experiencia o referencia de primera mano que pueda seguir? La mayor parte de mi información proviene de: http://msdn.microsoft.com/en-us/library/ms178104.aspx Afirma el proceso de detección de estancamiento se ejecuta a intervalos de 5 segundos, pero eso es todo lo que era capaz de encontrar. – Einstein

Las transacciones pueden expirar, eso es lo que está sucediendo.

que tenga al menos 1 (o más) bloqueos de actualización llevado a cabo y hacer que sea algunos bloqueos de lectura y una mesa de exploración, que puede matar a ayudar a liberar bloqueos creados por otros transacciones. El código de recuperación de interbloqueo en SQL Server es poco probable que esté totalmente libre de errores y es no es normal mantener una transacción abierta durante mucho tiempo en SQL Server. Sin embargo, no esperaría que eso sucediera a menudo.

Algunas sistema cuando se desprenden estancamiento tipo de problema, acaba de empezar a matar a las transacciones “período largo” que no han hecho el trabajo partido con el fin de liberar los bloqueos. El hecho de que no seas parte del bucle de interbloqueo no impide que el sistema te moleste.

para entender lo que está pasando en su caso , tendrá que utilizar el Analizador de SQL Server a recoger todo el bloqueo y estancamiento eventos relacionados, así como de eventos sobre la conexión y las transacciones abortadas etc. Buena falta esto llevará tiempo y un buen nivel de comprensión de los eventos de perfiladores que estás viendo ...

El detalle de este tipo de cosas es diferente entre los proveedores de bases de datos y las versiones de su base de datos. Sin embargo, como se considera que la mayoría de los proveedores de bases de datos tienen un diseño incorrecto para tener una transacción abierta durante mucho tiempo, hacerlo tiende a generar problemas y afectar las rutas de los códigos que no han tenido el mayor esfuerzo de prueba.

Fuente

2010-01-13 08:09:28

Este es el tipo de cosa que estoy buscando ... ¿Puedo preguntar qué lo lleva a decir que los procesos que no están directamente involucrados en un punto muerto pueden ser eliminados para resolver uno? ¿Existe alguna referencia o experiencia específica? – Einstein

problemas posibles: sólo se

SQL Server tiene un número finito de cerraduras. Es posible quedarse sin cerraduras.
Otros recursos son finitos (por ejemplo, memoria, tempdb). Aferrarse a estos recursos podría hacer que esos recursos se agoten.
Registros de transacciones: los registros de transacciones lógicas no se pueden liberar para su reutilización si una transacción está abierta. El resultado podría ser un registro que se llena. Este problema podría detener su proceso porque detendría toda la instancia.

a considerar:

CASCADE: Eliminar sólo puede tener una tabla en el comando, pero la relación de una cascada puede tocar otras tablas.
Disparadores: Disparadores en la tabla modificada pueden afectar a otras tablas.
Los comandos DELETE y UPDATE pueden usar la cláusula FROM que toca otras tablas. Nunca he visto esto, pero no lo descartaría.

Fuente

2010-01-13 13:19:07

Para responder a su pregunta: ¿Puede usted ser víctima estancamiento si no está ejecutando una consulta en una transacción.

Es contrario a la intuición, pero puede ser una víctima de interbloqueo ejecutando una declaración SELECT.

Puede ocurrir si ejecuta una consulta que utiliza un índice:

escanear índices en busca de filas que coincidan con
otra proceso se inicia la actualización de páginas de datos
ahora desea obtener los datos de las páginas de datos de las filas coincidentes

otros proceso que contienen bloqueos en las páginas de datos

espera bloqueos de página de datos para liberar otra
proceso finalizado la actualización de páginas de datos, quiere actualizar los índices

tiene cerraduras de lectura en los índices
otra
proceso espera bloqueos de índice para liberar
DEADLOCK

Por lo tanto, en sentido estricto, se puede ser víctima estancamiento, cuando no se está ejecutando una consulta en una transacción. El otro tipo tampoco estaba ejecutando su declaración UPDATE en una transacción.

Nadie está utilizando explícitamente una transacción, pero hay un punto muerto.

Fuente

2011-08-08 21:41:11

Un select ** es ** una consulta en una transacción de todos modos ... ya que autocommit es 1. – Pacerier

¿Puedo ser una víctima de interbloqueo si no estoy ejecutando una consulta dentro de una transacción?

Respuesta

Cuestiones relacionadas