Realizar consultas SQL sin bloqueos en SQL Server

Uno de los desafíos más comunes al trabajar con bases de datos es manejar correctamente los bloqueos y las concurrencias. En SQL Server, los bloqueos son necesarios para mantener la integridad de los datos mientras se realizan transacciones. Sin embargo, en algunas situaciones, estos bloqueos pueden causar problemas de rendimiento o incluso bloqueos de recursos. ¿Cómo podemos realizar consultas sin bloqueos, también conocidas como lecturas "sucias" o no bloqueantes? Vamos a descubrirlo.

READ UNCOMMITTED

La forma más fácil de realizar una consulta sin bloqueos en SQL Server es utilizando el nivel de aislamiento de transacción READ UNCOMMITTED o la sugerencia de tabla NOLOCK. Cuando usamos este nivel de aislamiento o sugerencia, SQL Server no emite bloqueos compartidos al leer los datos y no respeta los bloqueos exclusivos de otras transacciones. Aquí hay un ejemplo:

SELECT * FROM miTabla WITH (NOLOCK)

O usando SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM miTabla;

READ COMMITTED SNAPSHOT

Otra forma de realizar consultas sin bloqueos es habilitar READ COMMITTED SNAPSHOT en el nivel de base de datos. Esto cambia el comportamiento predeterminado de READ COMMITTED para usar versiones de fila en lugar de bloqueos. Cuando se habilita esta opción, SQL Server mantiene versiones de las filas modificadas, lo que permite a las transacciones leer estas versiones "snapshot" sin bloquear. Aquí es cómo habilitarlo:

ALTER DATABASE miBaseDeDatos
SET READ_COMMITTED_SNAPSHOT ON

Es importante mencionar que estas técnicas pueden permitir leer datos no confirmados, lo que puede resultar en la lectura de datos inconsistentes o incorrectos (fenómenos conocidos como lecturas "sucias", lecturas "fantasmas" y lecturas "no repetibles"). Por lo tanto, deben usarse con precaución y en situaciones en las que estos fenómenos sean aceptables.

Recuerda siempre evaluar cuidadosamente las implicaciones en términos de consistencia de datos y rendimiento antes de decidir utilizar cualquier estrategia de manejo de bloqueos. Y como siempre, es esencial probar estas estrategias en un entorno de prueba antes de implementarlas en un entorno de producción.