Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > MS SQL Server
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 30-06-2020
APO APO is offline
Miembro
 
Registrado: feb 2008
Posts: 121
Poder: 17
APO Va por buen camino
Error: La transacción (id. de proceso #) quedó en interbloqueo

Buenos días a todos,

Desde hace unos días, me está apareciendo muy a menudo el siguiente mensaje de SQL SERVER:

Cita:
La transacción (id. de proceso #) quedó en interbloqueo en bloqueo recursos con otro proceso y fue elegida como sujeto del interbloqueo. Ejecute de nuevo la transacción
He visto en internet que se podría solucionar reduciendo el nivel de aislamiento (poniendo "Set transaction isolation level read uncommitted" en el punto anterior a iniciar la transacción o poniendo "with (nolock)" tras las consultas).

¿Os habéis encontrado con este problema alguna vez? ¿Cómo lo habéis solucionado? Gracias!

Última edición por Neftali [Germán.Estévez] fecha: 03-07-2020 a las 11:00:11.
Responder Con Cita
  #2  
Antiguo 30-06-2020
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.233
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
El error está claro y se produce porque varios procesos se están bloqueando entre ellos.

Cita:
Empezado por APO Ver Mensaje
...se podría solucionar reduciendo el nivel de aislamiento (poniendo "Set transaction isolation level read uncommitted" en el punto anterior a iniciar la transacción o poniendo "with (nolock)" tras las consultas).
Son 2 cosas distintas.

Lo segundo -WITH (NOLOCK)- debería ser algo "casi-obligatorio" a realizar en todos las consultas de la aplicación, para evitar bloqueos.

Lo primero, es un cambio que conlleva más cosas. Tal vez solucione ese problema concreto, pero cambiar el nivel de aislamiento de las transacciones tiene más implicaciones y hay que saber bien, porqué se hace y qué va a cambiar cuando lo hagas.

Usa lo primero, y de paso revisa el resto de consultas (SELECT) y se lo añades.
Si con eso no se soluciona, yo revisaría las consultas que están provocando el bloqueo (utiliza el SQL Server Profiler), porque eso te puede indicar dónde está el problema del bloqueo.
Es posible que estés lanzando varias transacicones cuando debes lanzar sólo una, que las estés anidando,...

Lo que quiero decir es que intentes ver dónde está el bloqueo y solucionarlo antes de cambiar cosas, porque es posible que esos cambios te lo enmascaren.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #3  
Antiguo 30-06-2020
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
Lo segundo -WITH (NOLOCK)- debería ser algo "casi-obligatorio" a realizar en todos las consultas de la aplicación, para evitar bloqueos.
.
No. Un bloqueo NO ES para "evitar". Es algo necesario para que todo el andamio de las transacciones funcione correcto!

Este error esta gritando algo muy serio. Una ENORME falla en la forma de hacer las consultas. Es como cuando el compilador te da un error: No es para "darle la vuelta", es para que corrijas el código, que esta MALO*.


Cuando miras los docs acerca de esto, veras que pa que suceda hay que usar la BD con uno o varios anti-patrones.

Se podrían resumirse en "Hago de cuenta que yo soy el único usuario y que esta es una BD local y que ademas la trato sin misericordia como con dbase".

----

*PD: El uso de "hints" como NOLOCK es para uso limitado en casos muy especiales donde has PROBADO que la BD esta siendo *mas* precavida de lo necesario, pero NO ES para quitarle lo precavida! Si le reduces la fiabilidad al motor arriesgas un problema mayor en cualquier momento (como los animales que le quitan el fsync disque pa que sea "rapidísima"!).

En otras palabras: Es muy dudoso que el programador promedio que le da lio armar un SQL y que ni sabe usar el query planer venga y haga esto bien. Lo malo es que el compilador/motor ASUME que REALMENTE eres MAS listo que el y le hace mas caso a lo que digas.

Una forma de hacer una burrada de lo lindo (ie: Cuanto se te corrompa la BD no llores):

https://support.microsoft.com/en-us/...-a-complex-upd
__________________
El malabarista.
Responder Con Cita
  #4  
Antiguo 30-06-2020
luisgutierrezb luisgutierrezb is offline
Miembro
 
Registrado: oct 2005
Ubicación: México
Posts: 925
Poder: 19
luisgutierrezb Va por buen camino
Como te dicen arriba, usa el profiler sobre todo porque mencionas que tienes poco con el problema, tal vez sea una tabla que le falte indices y se tarde mucho al buscar información, etc, etc
Responder Con Cita
  #5  
Antiguo 01-07-2020
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.233
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por mamcx Ver Mensaje
No. Un bloqueo NO ES para "evitar". Es algo necesario para que todo el andamio de las transacciones funcione correcto!

Este error esta gritando algo muy serio. Una ENORME falla en la forma de hacer las consultas. Es como cuando el compilador te da un error: No es para "darle la vuelta", es para que corrijas el código, que esta MALO*.

No estoy de acuerdo con eso.

Decir que no debemos evitar bloqueos (1) o que un bloqueo significa que el diseño es incorrecto (2), no me parece acertado.


(1) Dentro de un entorno multiusuario si sabemos lo que hacemos, debemos "ayudar" en lo posible a evitar bloqueos (porque en un entorno multiusuario se producirán).

(2) Un simple SELECT de una tabla puede producir un bloqueo y eso no significa que estemos haciendo nada mal.


Por defecto un SQL Server está diseñado para que cada consulta adquiera su propio bloqueo, para asegurar de esa forma que los datos que leemos sean "consolidados". Cuando utilizamos un WITH (NOLOCK) lo que estamos diciendo al SGBD es que no queremos ese bloqueo previo. Si nos interesa, de esa forma, podemos evitar algunos bloqueos (no todos). Además reducimos la memoria utilizada y obtenemos más velocoidad.

¿A cambio de qué? En este caso, podemos obtener "lecturas sucias" (en casos concretos).
Por eso me refiero que debemos saber lo que estamos haciendo.

En mi caso prefiero lo segundo a lo primero, dado que el caso de lecturas sucias es muy raro y los problemas son mucho menores. A eso me refería a que hay que saber lo que esos cambios conllevan.
De todas formas repito lo dicho antes.


Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
... yo revisaría las consultas que están provocando el bloqueo (utiliza el SQL Server Profiler), porque eso te puede indicar dónde está el problema del bloqueo.
Es posible que estés lanzando varias transacicones cuando debes lanzar sólo una, que las estés anidando,...
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #6  
Antiguo 01-07-2020
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
No estoy de acuerdo con eso.

.... no me parece acertado.
https://docs.microsoft.com/en-us/sql...l-server-ver15

Cita:
Because the SQL Server Query Optimizer typically selects the best execution plan for a query, we recommend that hints be used only as a last resort by experienced developers and database administrators.

Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
¿A cambio de qué? En este caso, podemos obtener "lecturas sucias" (en casos concretos).
Por eso me refiero que debemos saber lo que estamos haciendo.
Obtener lecturas sucias es por mucho una forma de decir "me gustan datos corruptos". Cuando eso es una posibilidad valida? En MUY pocas ocasiones.

Esto es de las opciones que no se deben recomendar a la ligera, porque a menos que "be used only as a last resort by experienced developers and database administrators." hay muchas mejores maneras de resolver los problemas.

Y reitero: Los bloqueos NO son malos y NO son para "evitar". Esto es una falla en el entendimiento de como funciona un rdbms.
__________________
El malabarista.
Responder Con Cita
  #7  
Antiguo 02-07-2020
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.233
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Para mi la documentación lo que viene a decir es que lo utilices si sabes lo que estás haciendo, que me parece correcto y es lo que yo he comentado. En ningún caso dice que no se use.

Por otro lado, la probabilidad de obtener una lectura sucia en una transacción (si el sistema está bien diseñado) es muy pequeña, mucho menor que la posibilidad de obtener un bloqueo.
Y por otro lado, una "lectura sucia" no es un dato "corrupto", simplemente es un dato que "no está actualizado".
Lo mismo que pasaría con la siguiente situación:

(1) Usuario 1 hare SELECT del registro A
...mientras lo modifica...
(2) Usuario 2 hace UPDATE del registro A
...el usuario 1 acaba sus modificaciones...
(3) Cuando el usuario 1 hace un UPDATE del registro A, los datos que él tiene son "obsoletos" o "no-actualizados". No son "corruptos".
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.

Última edición por Neftali [Germán.Estévez] fecha: 02-07-2020 a las 12:49:37.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Error Transaccion ANCELMO Varios 4 18-04-2017 21:37:49
Transaccion, captura de error vmorillos MySQL 4 20-01-2011 17:43:07
Error en alta masiva de datos en una sóla transacción afxe Firebird e Interbase 3 07-05-2007 11:27:38
controlar error en transacción kikodelphi MS SQL Server 2 12-05-2006 03:53:09
Devolver código de error de una transacción kikodelphi MS SQL Server 7 18-10-2005 15:41:49


La franja horaria es GMT +2. Ahora son las 12:56:14.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi