with - sql server xlock hint

¿La mala práctica NOLOCK(Sql Server Hint) es mala? (12)

Antes de trabajar en Stack Overflow, estaba en contra de NOLOCK en cuanto a la principal, que podría realizar un SELECT con NOLOCK y obtener resultados con datos que pueden estar desactualizados o inconsistentes. Un factor a considerar es cuántos registros se pueden insertar / actualizar al mismo tiempo que otro proceso puede seleccionar datos de la misma tabla. Si esto sucede mucho, existe una alta probabilidad de interbloqueos, a menos que use un modo de base de datos, como READ COMMITED SNAPSHOT .

Desde entonces, he cambiado mi perspectiva sobre el uso de NOLOCK después de ver cómo puede mejorar el rendimiento de SELECT , así como eliminar los bloqueos en un servidor SQL cargado masivamente. Hay ocasiones en las que puede que no le importe que sus datos no estén exactamente 100% comprometidos y que necesite resultados rápidamente aunque estén desactualizados.

Hágase una pregunta cuando piense en usar NOLOCK :

¿Incluye mi consulta una tabla que tiene un alto número de comandos INSERT / UPDATE y me preocupo si los datos devueltos de una consulta pueden perder estos cambios en un momento dado?

Si la respuesta es no, entonces use NOLOCK para mejorar el rendimiento.

Acabo de realizar una búsqueda rápida de la palabra clave NOLOCK dentro de la base de código para Stack Overflow y encontré 138 instancias, por lo que la usamos en bastantes lugares.

Estoy en el negocio de hacer un sitio web y aplicaciones que no son críticas para la misión -> por ej. software bancario, vuelo espacial, aplicación de monitoreo de cuidados intensivos, etc. Ya entendió la idea.

Entonces, con esa gran advertencia, ¿es malo usar la sugerencia de NOLOCK en algún enunciado Sql? Hace algunos años, un administrador Sql me sugirió que debería usar NOLOCK si estoy contento con una "lectura sucia" que me dará un rendimiento un poco más fuera de mi sistema porque cada lectura no bloquea el mesa / fila / lo que sea.

También me dijeron que es una gran solución si estoy teniendo problemas. Entonces, comencé a seguir ese pensamiento durante unos años hasta que un gurú Sql me estaba ayudando con un código aleatorio y noté todos los NOLOCKS en mi código sql. Me regañaron educadamente y él trató de explicármelo (por qué no es algo bueno) y me perdí. Sentí que la esencia de su explicación era ''es una solución de curita para un problema más serio ... especialmente si estás teniendo un bloqueo. Como tal, arregle la raíz del problema ''.

Recientemente hice un poco de google y encontré esta publicación .

Entonces, ¿pueden algunos sql db guru sensei aclararme?

Como desarrollador profesional, yo diría que depende. Pero definitivamente sigo los consejos de GATS y Ponies OMG. Sepa lo que está haciendo, sepa cuándo lo ayuda y cuándo le duele y

leer consejos y otras ideas pobres

lo que podría hacerte entender el servidor sql más profundo. En general, sigo la regla de que SQL Hints es MALA, pero desafortunadamente los uso de vez en cuando cuando estoy harto de forzar al servidor SQL a hacer cosas ... Pero estos son casos raros.

Lucas

Creo que virtualmente nunca es correcto usar nolock.

Si está leyendo una sola fila, entonces el índice correcto significa que no necesitará NOLOCK ya que las acciones de fila individuales se completarán rápidamente.

Si está leyendo muchas filas para cualquier cosa que no sea la visualización temporal, y se preocupa por poder repetir el resultado, o defender por el número producido, entonces NOLOCK no es apropiado.

NOLOCK es una etiqueta sustituta para "no me importa si esta respuesta contiene filas duplicadas, filas que se eliminan o filas que nunca se insertaron para comenzar debido a la reversión"

Errores que son posibles bajo NOLOCK:

Las filas que coinciden no se devuelven en absoluto.
las filas únicas se devuelven varias veces (incluidas varias instancias de la misma clave principal)
Las filas que no coinciden son devueltas.

Cualquier acción que pueda causar una división de página mientras se está ejecutando la selección noLock puede provocar que esto ocurra. Casi cualquier acción (incluso una eliminación) puede causar una división de página.

Por lo tanto, si "sabes" que la fila no se cambiará mientras estás en funcionamiento, no uses nolock, ya que un índice permitirá una recuperación eficiente.

Si sospecha que la fila puede cambiar mientras se está ejecutando la consulta, y le importa la precisión, no use nolock.

Si está considerando NOLOCK debido a interbloqueos, examine la estructura del plan de consulta para escaneos de tabla inesperados, trace los interbloqueos y vea por qué ocurren. Las escrituras de NOLOCK en general pueden significar que las consultas que previamente se estancaron posiblemente escriban la respuesta incorrecta.

Cuando la aplicación de soporte quería responder consultas ad-hock desde el servidor de producción utilizando SSMS (que no se atendían a través de los informes) solicité que utilizaran nolock. De esta forma, el negocio "principal" no se ve afectado.

Duda que era un "gurú" que había tenido alguna experiencia en alto tráfico ...

Los sitios web suelen estar "sucios" cuando la persona está viendo la página completamente cargada. ¿Considera un formulario que carga de la base de datos y luego guarda los datos que se editan? Es idiota la manera en que las personas continúan leyendo cosas sucias diciendo que no, no.

Dicho esto, si tiene varias capas basadas en sus selecciones, podría estar construyendo una redundancia peligrosa. Si se trata de dinero o escenarios de estado, entonces no solo necesita leer / escribir datos transaccionales, sino una solución de concurrencia adecuada (algo que la mayoría de los "gurús" no se molestan).

Por otro lado, si tiene una búsqueda de productos avanzada para un sitio web (es decir, algo que probablemente no se almacenará en caché y sea un poco intensivo) y que alguna vez haya construido un sitio con más de unos pocos usuarios concurrentes (cantidad fenomenal "expertos" no), es ridículo embotellar cualquier otro proceso detrás de él.

Sepa lo que significa y úselo cuando sea apropiado. Su base de datos casi siempre será su cuello de botella principal en estos días y ser inteligente sobre el uso de NOLOCK puede ahorrarle miles de dólares en infraestructura.

EDITAR: No solo ayuda con los bloqueos, sino también con lo que harás que todos esperen hasta que hayas terminado, o viceversa.

¿Usando NOLOCK Hint en EF4?

En la vida real donde encuentra sistemas ya escritos y agrega índices a tablas, entonces ralentiza drásticamente la carga de datos de una tabla de datos de 14gig, en algún momento se ve obligado a usar WITH NOLOCK en sus informes y el procesamiento de fin de mes para que las funciones agregadas (suma , conteo, etc.) no haga fila, página, bloqueo de tabla y detenga el rendimiento general. Fácil de decir en un nuevo sistema, nunca use WITH NOLOCK y utilice índices, pero agregar índices reduce la carga de datos, y cuando me digan, bien, modifique la base de código para eliminar índices, luego cargue a granel y luego vuelva a crear los índices, que está todo bien si estás desarrollando un nuevo sistema. Pero no cuando tienes un sistema ya en su lugar.

Estoy de acuerdo con algunos comentarios sobre la pista de NOLOCK y especialmente con aquellos que dicen "Úselo cuando sea apropiado". Si la aplicación está mal escrita y utiliza una forma de concurrencia inapropiada, puede provocar un escalamiento de bloqueo. La tabla altamente transaccional también se bloquean todo el tiempo debido a su naturaleza. Tener una buena cobertura de índice no ayudará con la recuperación de los datos, pero sí lo hace establecer NIVEL DE AISLAMIENTO para LEER SIN COMPROMISO. También creo que usar la sugerencia de NOLOCK es seguro en muchos casos cuando la naturaleza de los cambios es predecible. Por ejemplo, en la fabricación cuando los trabajos con viajeros atraviesan diferentes procesos con muchas inserciones de mediciones, puede ejecutar la consulta de forma segura contra el trabajo finalizado con la sugerencia de NOLOCK y evitar colisiones con otras sesiones que pongan bloqueos PROMOCIONADOS o EXCLUSIVOS sobre la mesa /página. Los datos a los que accede en este caso son estáticos, pero pueden residir en una tabla muy transaccional con cientos de millones de registros y miles de actualizaciones / insertos por minuto. Aclamaciones

Las mejores soluciones, cuando sea posible son:

Replica tus datos (usando log-replication) a una base de datos de informes.
Use instantáneas de SAN y monte una versión coherente de la base de datos
Use una base de datos que tenga un nivel de aislamiento de transacción fundamental mejor

El nivel de aislamiento de la transacción SNAPSHOT se creó porque MS estaba perdiendo ventas a Oracle. Oracle usa registros de deshacer / rehacer para evitar este problema. Postgres usa MVCC. En el futuro, Heckaton de MS usará MVCC, pero faltan años para estar listos para la producción.

NOLOCK a menudo se explota como una forma mágica de acelerar las lecturas de la base de datos, pero trato de evitar usarlo siempre que sea posible.

El conjunto de resultados puede contener filas que aún no se han confirmado, que a menudo se retrotraen.

Un conjunto de error o resultado puede estar vacío, faltar filas o mostrar la misma fila varias veces.

Esto se debe a que otras transacciones están moviendo datos al mismo tiempo que lo estás leyendo.

READ COMMITTED agrega un problema adicional donde los datos están corruptos dentro de una sola columna donde varios usuarios cambian la misma celda simultáneamente.

Ninguna de las respuestas es incorrecta, sin embargo un poco confuso tal vez.

Al consultar valores individuales / filas, siempre es una mala práctica usar NOLOCK; probablemente nunca desee mostrar información incorrecta o incluso realizar alguna acción con datos incorrectos.
Cuando se muestra información estadística aproximada, NOLOCK puede ser muy útil. Tome SO como ejemplo: no tendría sentido tomar bloqueos para leer el número exacto de vistas de una pregunta, o el número exacto de preguntas para una etiqueta. A nadie le importa si declara incorrectamente 3360 preguntas etiquetadas con "sql-server" ahora, y debido a una reversión de transacción, 3359 preguntas un segundo después.

Si no le importan las lecturas sucias (es decir, en una situación de LECTURA predominante), entonces NOLOCK está bien.

PERO , tenga en cuenta que la mayoría de los problemas de bloqueo se deben a no tener los índices "correctos" para la carga de trabajo de su consulta (suponiendo que el hardware está a la altura de la tarea).

Y la explicación del gurú fue correcta. Por lo general, es una solución de curita a un problema más grave.

Editar : Definitivamente no sugiero que se use NOLOCK. Creo que debería haberlo dejado claro. (Solo lo usaría, en circunstancias extremas donde había analizado que estaba bien). Como ejemplo, hace un tiempo trabajé en algunos TSQL que habían sido rociados con NOLOCK para tratar de aliviar los problemas de bloqueo. Los eliminé todos, implementé los índices correctos y TODOS los bloqueos se fueron.

Con la sugerencia NOLOCK, el nivel de aislamiento de transacción para la instrucción SELECT es READ UNCOMMITTED . Esto significa que la consulta puede ver datos sucios e incoherentes.

Esta no es una buena idea para aplicar como regla. Incluso si este comportamiento de lectura sucia está bien para su aplicación basada en la web de misión crítica, un escaneo NOLOCK puede causar un error 601 que terminará la consulta debido al movimiento de datos como resultado de la falta de protección de bloqueo.

Sugiero leer Cuando el aislamiento de instantáneas ayuda y cuando duele , el MSDN recomienda usar LEER INSTANTÁNEA COMPROMETIDA en lugar de INSTANTÁNEA en la mayoría de los casos.