En esta segunda entrada sobre los niveles de aislamiento vamos a ver qué significa en la práctica lo que vimos en el post de ayer. Si aún no lo has leído te recomiendo que vayas primero a él para saber de lo que hablamos. Vamos a comparar el mismo caso práctico con los niveles de aislamiento READ UNCOMMITTED, READ COMMITTED y READ COMMITTED SNAPSHOT.
Para que todos podáis hacer las pruebas en vuestra instalación de SQL vamos a usar la base de datos de ejemplo AdventureWorks. AdventureWorks es una base de datos de ejemplo que proporciona Microsoft y que está disponible para descargar en su web. Tanto si estáis empezando a aprender SQL como si ya lleváis tiempo y queréis estar al día os recomiendo siempre que tengáis una instalación donde hacer pruebas con alguna base de datos de ejemplo. Otra buena base de datos que no debería faltar en vuestra instalación de pruebas es la versión SQL de los datos anonimizados de stackoverflow que proporciona Brent Ozar.
Caso Práctico
Este ejemplo es uno de los más típicos que nos vamos a encontrar en nuestro día a día como DBA. Vamos a simular 2 transacciones, la primera va a hacer una actualización de la tabla de personas y mientras la actualización esté en progreso una segunda transacción va a intentar leer los datos.
NIVEL DE AISLAMIENTO READ COMMITTED
| SESIÓN 1 | SESIÓN 2 | NOTAS |
 | La primera sesión inicia una operación de escritura sobre la tabla. Se genera un bloqueo exclusivo sobre el registro. | |
 | Cuando la segunda sesión va a leer se queda en espera, el intento de bloqueo compartido sobre el registro no es compatible con el bloqueo exclusivo de la transacción de la primera sesión. | |
| rollback | La transacción se aborta. Se genera un rollback y se libera el bloqueo exclusivo. | |
 | Con el bloqueo exclusivo liberado la segunda sesión ya es capaz de devolver los datos solicitados. |
NIVEL DE AISLAMIENTO READ COMMITTED SNAPSHOT
| SESIÓN 1 | SESIÓN 2 | NOTAS |
| La primera sesión inicia una operación de escritura sobre la tabla. Se genera un snapshot del dato anterior a la transacción en TempDB | |
| Cuando la segunda sesión solicita ese registro lo puede recuperar del snapshot en TempDB. | |
| rollback | La transacción se aborta. Se genera un rollback y se elimina el snapshot. |
NIVEL DE AISLAMIENTO READ UNCOMMITTED
| SESIÓN 1 | SESIÓN 2 | NOTAS |
| La primera sesión inicia una operación de escritura sobre la tabla. | |
 | Cuando la segunda sesión solicita ese registro lo lee directamente aunque se esté modificando. | |
| rollback | La transacción se aborta y se genera un rollback | |
| En una segunda lectura la sesión 2 recupera un dato diferente. |
Conclusión
Hemos podido ver que significa leer datos sucios y qué implicaciones tiene. Además, hace unos días vimos también el peligro de las lecturas fantasma de NOLOCK que también se producen en el nivel de aislamiento READ UNCOMMITTED. Tras esta serie de artículos estamos preparados para elegir los niveles de aislamiento correctos para nuestras bases de datos.
Ahí va mi recomendación personal: si tenemos que hacer una prueba o leer un dato puntualmente en un entorno productivo pero sin afectar a la producción podemos usar READ UNCOMMITTED. No deberíamos usar este nivel de aislamiento en ningún caso más. Usaremos un nivel de aislamiento READ COMMITTED SNAPSHOT si nuestra base de datos tiene un problema de bloqueos. Si estamos desarrollando una base de datos nueva mi recomendación también sería READ COMMITTED SNAPSHOT. Por el contrario, en la mayoría de los casos, si todo funciona con la configuración por defecto mejor dejarlo como está. Al fin y al cabo, un cambio que va a afectar a todas las transacciones requiere un esfuerzo en pruebas que rara vez nos será rentable si no es para solucionar un problema específico.
