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