Cómo funciona READ COMMITED en SQL Server

Son varios los llamados Isolation Levels que podemos utilizar en nuestros servidores. Básicamente son los que definen el grado en el que una transacción será aislada de una modificación de objeto o información realizada por otra transacción. En esta oportunidad vamos a ver cómo funciona READ COMMITED en SQL Server.

ISOLATION LEVEL

Si bien en el primer párrafo está descrito lo que es un Isolation Level (nivel de aislamiento), puedes resumirlo en un simple hecho. Concurrencia.

Lo que verás al configurar un Isolation Level es justamente el comportamiento ante operaciones concurrentes.

Diferentes motores tienen diferentes niveles de aislamiento en su instalación.

READ COMMITED en SQL Server

Este es el modo de aislamiento por defecto en el motor. Si instalamos SQL Server sin ninguna configuración fuera de lo estándar, trabajarás con Read Commited.

Personalmente creo que este nivel de aislamiento es el adecuado conceptualmente cuando hablamos de modelos de datos. Lo ideal es proteger los datos lo más posible.

¿Qué dice el concepto de READ COMMITED?

Las instrucciones no pueden leer datos que hayan sido modificados, pero no confirmados, por otras transacciones.

SET TRANSACTION ISOLATION LEVEL

Veámoslo en acción

Vamos a consultar una tabla de 1 millón de filas buscando una en particular. (Si buscas datos de pruebas, puedes Generar Millones de datos aleatorios en SQL Server con este enlace)

Voy a consultar un registro particular solo para ver que sí se retorna correctamente los datos.

Simulemos ahora la concurrencia

Verás dos imágenes. A la izquierda una ejecución que pretende hacer una actualización (update) de la tabla mientras se hace una consulta en el lado derecho. Dos sesiones diferentes para simular el concepto de la concurrencia.

Vamos por pasos:

1. Ejecuta solo el BEGIN

En la sesión del lado izquiero ejecuto primero solo el BEGIN TRAN, esto para dejar activa (abierta) una transacción.

2. Ahora vamos por el update

Selecciona solo el update en la sesión de la izquierda. Verás que no se toma ni siquiera 1 segundo en ejecutarse. Lo interesante aquí es que, ya que ejecutamos la transacción explícita (iniciar con el BEGIN TRAN), no se ha confirmado aún la finalización de la transacción; esto hasta explícitamente confirmar (COMMIT) o descartar (ROLLBACK).

3. Ahora vamos a la sesión de la derecha a ejecutar la consulta

No te olvides que hasta ahora tienes una transacción abierta (sin confirmar). Ejecuta todo el SELECT correspondiente a la ventana y mira lo que sucede.

Esta segunda transacción, que al principio en una ejecución individual no necesitaba ni un segundo en concluir ahora no se terminará hasta que la primera sesión se confirme. Puedes ver en la imagen anterior que la segunda sesión continúa ejecutándose y en un tiempo que se ve mucho más superior a lo que se esperaría.

Este consulta (SELECT) puede esperar para siempre…hasta que se confirme la primera (UPDATE).

Fíjate cómo luego de ejecutar el ROLLBACK en la primera sesión, inmediatamente finaliza la segunda sesión.

Pasa exactamente lo contrario si hacemos COMMIT en la primera sesión. Cuando se confirme la primera transacción, la segunda ya muestra el valor actualizado y confirmado.

¿Entonces cómo funciona el READ COMMITED en SQL Server?

Como acabas de verlo. La principal característica del Isolation Level READ COMMITED es el de mostrarte los datos siempre cuando ya están confirmados y escritos en disco.

El utilizar las transaccioines explícitas en este ejemplo solamente es para que veas lo que sucede en el medio durante la concurrencia de consultas. Imagínate si tienes un UPDATE que se tome mucho tiempo en ejecutarse, el SELECT que quiera ejecutarse en el mismo instante, tendrá que esperar a que el primero finalice.

Este es el comportamiento por defecto y el que garantiza confiabilidad en mantener la integridad de los datos. Está dentro de un grupo llamado Concurrencia Pesimista (pesimistic concurrency) pero con mayor protección en la integridad.

Puedes ver a continuación Qué significa NOLOCK en SQL Server.