FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
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. |
#2
|
||||
|
||||
Cita:
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:
__________________
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. |
#3
|
||||
|
||||
Cita:
Cita:
Cita:
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. |
#4
|
||||
|
||||
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 11:49:37. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Error Transaccion | ANCELMO | Varios | 4 | 18-04-2017 20:37:49 |
Transaccion, captura de error | vmorillos | MySQL | 4 | 20-01-2011 16:43:07 |
Error en alta masiva de datos en una sóla transacción | afxe | Firebird e Interbase | 3 | 07-05-2007 10:27:38 |
controlar error en transacción | kikodelphi | MS SQL Server | 2 | 12-05-2006 02:53:09 |
Devolver código de error de una transacción | kikodelphi | MS SQL Server | 7 | 18-10-2005 14:41:49 |
|