Podría alguien darme alguna orientación sobre cuando debería utilizar WITH (NOLOCK) en contraposición a SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDCON (NOLOCK) vs SET TRANSACTION ISOLATION LEVEL lectura no comprometida
¿Cuáles son las ventajas/desventajas de cada uno? ¿Hay alguna consecuencia no deseada con la que te hayas topado al usar una en lugar de la otra?
Ellos son la misma cosa. Si usa la declaración set transaction isolation level, se aplicará a todas las tablas de la conexión, por lo que si solo desea nolock en una o dos tablas, use eso; de lo contrario, usa el otro.
Ambos le darán lecturas sucias. Si estás de acuerdo con eso, entonces úsalos. Si no puede tener lecturas sucias, entonces considere las sugerencias snapshot o serializable.
CON (NOLOCK) es una pista en el nivel de la mesa. Establecer el nivel de aislamiento de la transacción en READ_UNCOMMITTED afecta la conexión. La diferencia está en términos de alcance. Ver READUNCOMMITTED y NOLOCK en la documentación de SQL Server aquí:
http://technet.microsoft.com/en-us/library/ms187373.aspx
para la transacción NIVEL DE AISLAMIENTO: http://technet.microsoft.com/en-us/library/ms173763.aspx
Que yo sepa la única diferencia es el alcance de los efectos como dijo Strommy. NOLOCK insinúa sobre una mesa y LEE NO COMPROMETIDO en la sesión.
En cuanto a los problemas que pueden ocurrir, se trata de consistencia. Si le importa, tenga en cuenta que podría obtener lo que se denomina lecturas sucias que podrían influir en otros datos manipulados con información incorrecta.
Personalmente, no creo haber visto ningún problema con esto, pero eso puede deberse más a la forma en que uso nolock. Debe tener en cuenta que hay situaciones en las que se podrá utilizar. Escenarios en los que, en general, agrega datos nuevos a una tabla, pero tiene otro proceso que viene detrás para verificar un escenario de datos. Eso probablemente sea correcto ya que el flujo principal no incluye retroceder y actualizar filas durante una lectura.
También creo que en estos días debe consultar el Control de Concurrencia de varias versiones. Creo que lo agregaron en 2005 y ayuda a evitar que los escritores bloqueen a los lectores al brindarles a los lectores una instantánea de la base de datos que deben usar. Voy a incluir un enlace y dejo más investigaciones para el lector:
+1 Aunque no entré en el aspecto "should you" de READ_UNCOMMITTED ", Sean lo cubre muy bien. También hay casos en los que puede leer la misma fila dos veces en SQL Server (debido a divisiones de página). – Anon246
En cuanto a las directrices ... una búsqueda aleatoria de StackOverflow y la interweb eléctrica ...
Como usted tiene que utilizar CON (NOLOCK) para cada tabla que puede ser molesto para escribir en cada FROM o JOIN cláusula. Sin embargo, tiene una razón por la que se llama lectura "sucia". Entonces, realmente debería saber cuándo hace uno, y no establecerlo como predeterminado para el alcance de la sesión. ¿Por qué?
Olvidarse de un WITH (NOLOCK) puede no afectar su programa de una manera muy dramática, sin embargo, hacer una lectura sucia donde no quiere puede marcar la diferencia en ciertas circunstancias.
Por lo tanto, use WITH (NOLOCK) si se permite que los datos actuales seleccionados sean incorrectos, ya que podrían retrotraerse más tarde. Esto se usa principalmente cuando desea aumentar el rendimiento, y los requisitos en el contexto de la aplicación le permiten correr el riesgo de que se muestren datos incoherentes. Sin embargo, usted o alguien a cargo tiene que sopesar los pros y los contras de la decisión de usar WITH (NOLOCK).
No puede usar Establecer nivel de aislamiento de transacciones Leer No confirmado en una vista (de hecho, solo puede tener un script allí), por lo que tendría que usar (nolock) si se deben incluir filas sucias.
Considere "REPEATABLE READ" en lugar de "SERIALIZABLE" si no le importan los datos fantasma. 'SERIALIZABLE' es REALMENTE restrictivo y casi nunca debe usarse (excepto, por ejemplo, en algunas aplicaciones financieras críticas). – Kryptos