Solución:
WITH (NOLOCK) es el equivalente a usar READ UNCOMMITED como nivel de aislamiento de transacciones. Por lo tanto, corre el riesgo de leer una fila no confirmada que posteriormente se deshace, es decir, datos que nunca llegaron a la base de datos. Por lo tanto, si bien puede evitar que las lecturas se bloqueen con otras operaciones, 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é tratando de 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 que actualiza dos filas, restando de una y agregando a otra. Eso está mal.
En una base de datos financiera, utiliza 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.
Conseguir que el saldo de la cuenta sea temporalmente incorrecto no es gran cosa, para eso es la reconciliación al final del día. Y es mucho más probable que se produzca un sobregiro de una cuenta porque se están utilizando dos cajeros automáticos a la vez que por una lectura no confirmada de una base de datos.
Dicho esto, SQL Server 2005 solucionó la mayoría de los errores que provocaban NOLOCK necesario. Por lo tanto, a menos que esté utilizando SQL Server 2000 o una versión anterior, no debería necesitarlo.
Otras lecturas
Control de versiones a nivel de fila
Desafortunadamente, no se trata solo de leer datos no comprometidos. En segundo plano, puede terminar leyendo páginas dos veces (en el caso de una división de página), o puede perder las páginas por completo. Por lo tanto, sus resultados pueden estar muy sesgados.
Consulte el artículo de Itzik Ben-Gan. He aquí un extracto:
“Con la sugerencia NOLOCK (o estableciendo el nivel de aislamiento de la sesión en READ UNCOMMITTED) le dice a SQL Server que no espera consistencia, por lo que no hay garantías. Sin embargo, tenga en cuenta que” datos inconsistentes “no solo significa que es posible que vea cambios no confirmados que luego se revirtieron o cambios de datos en un estado intermedio de la transacción. También significa que en una consulta simple que escanea todos los datos de la tabla / índice, SQL Server puede perder la posición de escaneo, o puede terminar obteniendo la misma fila dos veces.. “