Error: La transacción (id. de proceso #) quedó en interbloqueo

[Neftali [Germán.Estévez]]

Empezado por mamcx

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.

Empezado por Neftali [Germán.Estévez]

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

[mamcx]

Empezado por Neftali [Germán.Estévez]

No estoy de acuerdo con eso.

.... no me parece acertado.

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

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.

Empezado por Neftali [Germán.Estévez]

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

[Neftali [Germán.Estévez]]

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