¿Qué es "with (nolock)" en SQL Server?
https://stackoverflow.com/questions/686724
-
22-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Puede alguien explicar las implicaciones del uso de with (nolock) en las consultas, cuando debería/no debería usar?
Por ejemplo, si usted tiene una aplicación de banca con altas tasas de transacción y una gran cantidad de datos en ciertas tablas, en qué tipos de consultas sería nolock a estar bien?Hay casos cuando se debe utilizar siempre que/nunca la uso?
Solución
CON (NOLOCK) es el equivalente de la utilización de LEA uncommited como un nivel de aislamiento de transacción. Así, se pone de pie el riesgo de leer una fila no comprometidos que, posteriormente, se deshace, es decir, datos que nunca llegó a la base de datos. Así, mientras que puede evitar que se lee en un punto muerto por otras operaciones, viene con un riesgo. En una aplicación de banca con tasas altas de transacción, es probable que no va a ser la solución adecuada al problema que estamos tratando de resolver con ella en mi humilde opinión.
Otros consejos
La pregunta es ¿qué es peor:
- un punto muerto, o
- un valor erróneo?
Para bases de datos financieros, los puntos muertos son mucho peores que los valores incorrectos. Sé que suena al revés, pero escúchame. El ejemplo tradicional de transacciones de base de datos se actualiza dos filas que, restando de uno y añadiendo a otro. Eso está mal.
En una base de datos financieros que utilizan las transacciones comerciales. Eso significa que la adición de una fila a cada cuenta. Es de suma importancia que estas transacciones completas y las filas se escriben correctamente.
Obtener el saldo de la cuenta temporalmente incorrecto no es un gran problema, que es lo que al final del día es para la reconciliación. Y un descubierto de una cuenta es mucho más probable que ocurra debido a dos cajeros automáticos se utilizan a la vez que por una lectura no confirmada a partir de una base de datos.
Dicho esto, SQL Server 2005 fija la mayoría de los errores que hicieron NOLOCK necesario. Así que a menos que esté utilizando SQL Server 2000 o anterior, no lo necesita.
Lecturas
nivel de fila de versiones
El ejemplo de libro de texto para el uso legítimo de la pista nolock es el muestreo informe contra una base de datos de actualización de alta OLTP.
Para tomar un ejemplo tópica. Si un gran banco de la calle de Estados Unidos quería un informe por horas en busca de los primeros signos de una carrera de nivel de la ciudad en la orilla, una consulta nolock podría escanear tablas de transacciones que resumen los depósitos en efectivo y retiros de efectivo por ciudad. Para tal informe el pequeño porcentaje de error causado por deshace las transacciones de actualización no reducirían el valor del informe.
Por desgracia, no se trata sólo de lectura de datos no confirmados. En el fondo se puede terminar la lectura de las páginas dos veces (en el caso de una división de página), o puede que se pierda las páginas en total. Por lo que sus resultados pueden ser extremadamente sesgada.
Salida artículo Itzik Ben-Gan . He aquí un extracto:
" Con la sugerencia NOLOCK (o establecer el nivel de aislamiento de la sesión para leer UNCOMMITTED) le dice que SQL Server usted no espera consistencia, por lo que hay hay garantías. Tenga en cuenta, sin embargo que "los datos inconsistentes" no sólo decir que es posible que vea comprometido cambios que fueron luego deshacen, o cambios de datos en un intermedio estado de la transacción. También significa que en una consulta simple que escanea toda la tabla / índice de SQL Server Data puede perder la posición de exploración, o si podría terminar recibiendo la misma fila dos veces . "
No está seguro de por qué no se está envolviendo las transacciones financieras en las transacciones de bases de datos (como cuando la transferencia de fondos de una cuenta a otra - no cometer un lado de la transacción en-un-tiempo - es por eso que existen transacciones explícitas) . Incluso si su código es braindead a las transacciones comerciales ya que suena como que es, todas las bases de datos transaccionales tienen el potencial de hacer una cancelación implícita en caso de errores o fallos. Creo que esta discusión está muy por encima de su cabeza.
Si usted está teniendo problemas de bloqueo, poner en práctica el control de versiones y limpiar su código.
Sin bloqueo no sólo devuelve valores incorrectos que devuelve registros fantasma y duplicados.
Es un error común que siempre hace que las consultas se ejecutan más rápido. Si no hay bloqueos de escritura sobre una mesa, que no hace ninguna diferencia. Si hay bloqueos en la tabla, se puede hacer la consulta más rápido, pero hay una razón cerraduras fueron inventados en el primer lugar.
Para ser justos, aquí hay dos escenarios especiales, donde una pista nolock puede proporcionar una utilidad
1) la base de datos del servidor SQL Pre-2005 que tiene que ejecutar consulta larga contra la base de datos OLTP vivo esto puede ser la única manera
2) aplicación mal escrita que bloquea los registros y devuelve el control a la interfaz de usuario y los lectores están bloqueadas indefinidamente. Nolock puede ser útil en este caso si la aplicación no se puede arreglar (tercero, etc.) y la base de datos están ya sea antes de 2005 o de versiones no se pueden encender.
NOLOCK es equivalente a READ UNCOMMITTED, sin embargo Microsoft dice que no se debe utilizar para los estados UPDATE o DELETE:
Para UPDATE o DELETE: Esta característica se quitará en una versión futura de Microsoft SQL Server. Evitar el uso de esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente utilizan esta función.
http://msdn.microsoft.com/en-us/library/ ms187373.aspx
Este artículo se aplica a SQL Server 2005, por lo que el apoyo a NOLOCK existe si está utilizando esa versión. Con el fin de asegurar el futuro de su código (suponiendo que haya decidido utilizar las lecturas sucias) que podría utilizar esto en sus procedimientos almacenados:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
Se puede utilizar cuando sólo se está leyendo los datos, y que realmente no se preocupan por si está o no puede estar recibiendo de vuelta los datos que no se ha comprometido todavía.
Puede ser más rápido en una operación de lectura, pero no puedo decir realmente en qué medida.
En general, recomiendo no usarla -. Lectura de datos no confirmados puede ser un poco confuso en el mejor
Otro caso en el que por lo general es bien está en una base de datos de informes, donde los datos son quizá ya envejecido y escribe simplemente no sucederá. En este caso, sin embargo, la opción debe fijarse en el nivel de base de datos o tabla por el administrador cambiando el nivel de aislamiento por omisión.
En el caso general: se puede usar cuando estás muy seguro de que está bien para leer los datos antiguos. Lo importante para recordar es que su muy fácil de conseguir que mal . Por ejemplo, incluso si está bien en el momento de escribir la consulta, ¿está seguro de que algo no va a cambiar en la base de datos en el futuro para hacer estos cambios más importantes?
También voy a segundo la noción de que es probable que sea no una buena idea en la aplicación de banca. O aplicación de inventario. O en cualquier lugar que usted está pensando acerca de las transacciones.
Respuesta Simple: cada vez que el SQL no es la alteración de los datos, y usted tiene una consulta que podría interferir con otras actividades (a través de bloqueo).
Vale la pena considerar para cualquier consulta utilizados para los informes, especialmente si la consulta tarda más de 1 segundo.
Es especialmente útil si usted tiene OLAP-tipo de informes se ejecuta en contra de una base de datos OLTP.
La primera pregunta, si, es "¿por qué estoy preocuparse acerca de esto?" ln mi experiencia, fudging el valor predeterminado de bloqueo de comportamiento a menudo se lleva a cabo cuando alguien está en "probar algo" y esto es un caso donde inesperadas consecuencias no son improbables.Con demasiada frecuencia, es un caso de la optimización y también puede llegar fácilmente a la izquierda incrustado en una aplicación "por si acaso". Es importante entender por qué lo estás haciendo, ¿qué problema resuelve, y si realmente tienen el problema.
Mis 2 centavos - que tiene sentido utilizar WITH (NOLOCK) cuando se necesita para generar informes. En este punto, los datos no cambiarían mucho y que no quieres para bloquear esos registros.
Si usted está manejando las transacciones financieras entonces nunca desee utilizar nolock. nolock es la mejor opción para seleccionar de grandes tablas que tienen actualizaciones de lotes y no le importa si el registro se obtiene podría estar fuera de fecha.
Para los registros financieros (y casi todos los demás registros en la mayoría de las aplicaciones) nolock causaría estragos como usted podría leer datos desde un registro que se está escribiendo en no obtener los datos correctos.
He usado para recuperar un "siguiente lote" cosas que hacer. No importa en este caso el elemento que exacta, y tengo una gran cantidad de usuarios que usan esta misma consulta.
Respuesta corta:
No utilice nunca WITH (NOLOCK).
Respuesta larga:
NOLOCK es utilizada en muchas ocasiones como una forma mágica para acelerar la base de datos lee, pero trato de evitar su uso siempre que sea posible.
El conjunto de resultados puede contener filas que aún no se han confirmado, que son a menudo más adelante deshace.
Un error o conjunto de resultados puede estar vacío, sean filas desaparecidos o mostrar la misma fila varias veces.
Esto se debe a otras transacciones se están moviendo datos al mismo tiempo lo estás leyendo.
LEER COMPROMETIDOS añade un problema adicional en que los datos está dañado dentro de una sola columna en la que varios usuarios cambian la misma célula simultáneamente.
Existen otros efectos secundarios también, lo que resultará en sacrificar la velocidad aumenta usted estaba esperando para ganar en el primer lugar.
Se puede argumentar que está bien para usarlo en lugares donde se puede obtener con la suya, pero ¿cuál es el punto? No puedo pensar en ninguna situación en la que los datos dañados es aceptable.
Nunca uses NOLOCK nunca.
(nunca)
Uso nolock cuando están de acuerdo con los datos "sucios". Lo que significa nolock también puede leer datos que está en el proceso de ser modificado de datos y / o no comprometidas.
Por lo general, no es una buena idea para utilizarlo en entornos de alta transacción y es por eso que no es una opción por defecto en la consulta.
utilizo con la indirecta (nolock) particularmente en SQLServer 2000 bases de datos con alta actividad. No estoy seguro de que se necesita en SQL Server 2005 sin embargo. He añadido recientemente que toque en un servidor SQL Server 2000 a petición de DBA del cliente, porque él estaba notando una gran cantidad de bloqueos de registro SPID.
Todo lo que puedo decir es que el uso de la pista no nos ha herido y parece haber logrado resolver el problema de bloqueo en sí. El DBA en ese cliente en particular, básicamente, insistió en que usamos la pista.
Por cierto, las bases de datos con la que trato son back-ends a los sistemas de reclamaciones médicas de la empresa, por lo que estamos hablando de millones de registros y más de 20 mesas en muchas combinaciones. Me suelen añadir una pizca (nolock) por cada tabla en la unión (a menos que sea una tabla derivada, en cuyo caso no se puede utilizar esa pista en particular)
La respuesta más simple es una simple pregunta - ¿Usted necesita los resultados para ser repetible? Si sí, entonces NOLOCKS no es apropiado en cualquier circunstancia
Si usted no necesita repetibilidad continuación nolocks pueden ser útiles, especialmente si usted no tiene control sobre todos los procesos de conexión a la base de datos de destino.
