¿Qué es "con (nolock)" en SQL Server?
¿Alguien puede explicar las implicaciones de usarlo with (nolock)en consultas, cuándo debería o no debería usarlo?
Por ejemplo, si tiene una aplicación bancaria con altas tasas de transacción y muchos datos en ciertas tablas, ¿en qué tipos de consultas estaría bien nolock? ¿Hay casos en los que siempre debes usarlo o nunca usarlo?
CON (NOLOCK) es el equivalente a utilizar READ UNCOMMITED como nivel de aislamiento de transacciones. Por lo tanto, corre el riesgo de leer una fila no confirmada que posteriormente se revierte, es decir, datos que nunca llegaron a la base de datos. Por lo tanto, si bien puede evitar que otras operaciones bloqueen las lecturas, conlleva un riesgo. En una aplicación bancaria con altas tasas de transacción, probablemente no será la solución adecuada para cualquier problema que esté intentando resolver con ella, en mi humilde opinión.
La pregunta es qué es peor:
- un punto muerto, o
- ¿un valor incorrecto?
Para las bases de datos financieras, 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 es actualizar dos filas, restarlas de una y agregarlas a la otra. Eso está mal.
En una base de datos financiera se utilizan transacciones comerciales. Eso significa agregar una fila a cada cuenta. Es de suma importancia que estas transacciones se completen y las filas se escriban correctamente.
Obtener un saldo de cuenta incorrecto temporalmente no es gran cosa, para eso está la conciliación al final del día. Y es mucho más probable que se produzca un sobregiro de una cuenta porque se utilizan dos cajeros automáticos a la vez que debido a una lectura no confirmada de una base de datos.
Dicho esto, SQL Server 2005 solucionó la mayoría de los errores que eran NOLOCKnecesarios. Entonces, a menos que esté utilizando SQL Server 2000 o una versión anterior, no debería necesitarlo.
Lectura adicional
Versiones a nivel de fila
El ejemplo de libro de texto para el uso legítimo de la sugerencia de nolock es el muestreo de informes en una base de datos OLTP de alta actualización.
Por poner un ejemplo de actualidad. Si un gran banco de EE. UU. quisiera generar un informe horario en busca de los primeros signos de una corrida bancaria a nivel de ciudad, una consulta nolock podría escanear tablas de transacciones que sumen depósitos y retiros de efectivo por ciudad. Para un informe de este tipo, el pequeño porcentaje de error causado por las transacciones de actualización revertidas no reduciría el valor del informe.
No estoy seguro de por qué no incluye transacciones financieras en transacciones de bases de datos (como cuando transfiere fondos de una cuenta a otra, no confirma un lado de la transacción a la vez, es por eso que existen transacciones explícitas). Incluso si su código tiene muerte cerebral para las transacciones comerciales como parece, todas las bases de datos transaccionales tienen el potencial de realizar reversiones implícitas en caso de errores o fallas. Creo que esta discusión está muy por encima de tu cabeza.
Si tiene problemas de bloqueo, implemente el control de versiones y limpie su código.
Ningún bloqueo no solo devuelve valores incorrectos, sino que también devuelve registros fantasmas y duplicados.
Es un error común pensar que siempre hace que las consultas se ejecuten más rápido. Si no hay bloqueos de escritura en una tabla, no hay ninguna diferencia. Si hay candados en la mesa, puede hacer que la consulta sea más rápida, pero hay una razón por la que se inventaron los candados en primer lugar.
Para ser justos, aquí hay dos escenarios especiales en los que una sugerencia de nolock puede resultar útil.
1) Base de datos del servidor SQL anterior a 2005 que necesita ejecutar consultas largas en la base de datos OLTP en vivo, esta puede ser la única forma
2) Aplicación mal escrita que bloquea registros y devuelve el control a la interfaz de usuario y los lectores quedan bloqueados indefinidamente. Nolock puede ser útil aquí si la aplicación no se puede reparar (de terceros, etc.) y la base de datos es anterior a 2005 o no se puede activar el control de versiones.
