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:

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!

El error está claro y se produce porque varios procesos se están bloqueando entre ellos.

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.

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

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

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.

https://docs.microsoft.com/en-us/sql...l-server-ver15


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.

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".