Niveles de Aislamiento en SQL

NIVELES DE AISLAMIENTO EN SQL

El nivel de aislamiento de una transaccin (transaction isolation level) define el grado en que se asla una transaccin de las modificaciones de recursos o datos realizadas por otras transacciones. Esto dicho as, quizs no permita entender fcilmente su significado (excepto para DBAs o programadores muy avanzados). El nivel de aislamiento de una transaccin es una caracterstica de vital importancia en el desarrollo de aplicaciones de base de datos, ya que afecta a los tipos y duracin de bloqueos que se producen en nuestra infraestructura de base de datos, lo cual, tiene efectos directos en el rendimiento y tiempo de respuesta de nuestras consultas y transacciones. Adems, el nivel de aislamiento nos permite indicar cmo deseamos que se comporte nuestro motor de base de datos frente a situaciones como las lecturas sucias (dirty reads), las lecturas no repetibles o las lecturas fantasma, comportamientos que pueden impactar consistentemente en la eficacia de nuestros desarrollos en entornos de base de datos con concurrencia. Evidentemente, la eleccin del modo de aislamiento es ms importante cuanto mayor es la concurrencia de la base de datos (sin concurrencia, a quin le interesan los modos de aislamiento?). Para empezar es importante entender perfectamente el comportamiento por defecto de SQL Server en las operaciones de lectura y de escritura:

En operaciones de escritura. Siempre se obtiene un bloqueo exclusivo que se mantiene hasta que se completa la transaccin. En operaciones de lectura. El comportamiento depender del nivel de aislamiento de la transaccin. Por defecto, SQL Server utiliza el modo de aislamiento basado en bloqueos READ COMMITTED, que se explica un poco ms adelante.

SQL Server ofrece seis niveles de aislamiento diferentes, que podemos agrupar en:

Niveles de Aislamiento basados en bloqueos. Se trata del comportamiento tradicional de SQL Server (existente desde versiones anteriores de SQL Server), como se ha descrito en el prrafo anterior. El funcionamiento de SQL Server se basa en el establecimiento y gestin de los bloqueos. Existen cuatro modos de aislamiento diferentes basados en bloqueos cubiertos en la norma SQL-99 : READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ y SERIALIZABLE. Niveles de Aislamiento basados en versionado de filas (row versioning - similar a ORACLE). Desde SQL Server 2005 estn disponibles dos nuevos niveles de aislamiento: READ COMMITTED SNAPSHOT y SNAPSHOT. Estos dos nuevos niveles de aislamiento se basan en el versionado de filas (row versioning). Una de las principales razones de utilizar el versionado de filas (row versioning) es minimizar los bloqueos ocurridos en la base de datos, con el fin de obtener un mejor rendimiento (las operaciones de lecturas, slo establecern bloqueos compartidos de esquema a nivel de tabla, y NO bloquearn filas ni pginas de datos). Siempre que una transaccin modifica un fila en uno de los modos de aislamiento de versionado de filas, SQL Server utiliza TEMPDB para almacenar una copia de la fila con el valor original y el nmero de secuencia de la transaccin. En caso de que mltiples transacciones modifiquen la misma fila, se almacena en TEMPDB una cadena de valores de la fila. Las operaciones de lectura podrn acceder a la versin apropiada de cada fila (accediendo a TEMPDB si es necesario) para as obtener datos congruentes sin necesidad de generar bloqueos. Para que encontremos ms familiar el uso del versionado filas (row versioning), resulta de inters saber que SQL Server saca provecho del versionado de filas (row versioning) en el funcionamiento de las tablas virtuales inserted y deleted de los triggers, en las operaciones de ndice con la clusula ONLINE, etc.

Tanto para comprender bien los modos de aislamiento basados en bloqueos, como para comprender los modos de aislamiento basados en versionado de filas, es muy importante tambin comprender bien los conceptos de lecturas sucias (dirty reads), lecturas no repetibles (non repeatable reads) y lecturas fantasma (phantom reads). Estos conceptos se explican un poco ms adelante. A continuacin se describen los cuatro posibles niveles de aislamiento basados en bloqueos.

READ UNCOMMITTED puede recuperar datos modificados pero no confirmados por otras transacciones (lecturas sucias - dirty reads). En este nivel se pueden producir todos los efectos secundarios de simultaneidad (lecturas sucias, lecturas no repetibles y lecturas fantasma - ej: entre dos lecturas de un mismo registro en una transaccin A, otra transaccin B puede modificar dicho registro), pero no hay bloqueos ni versiones de lectura, por lo que se minimiza la sobrecarga. Una operacin de lectura (SELECT) no establecer bloqueos compartidos (shared locks) sobre los datos que est leyendo, por lo que no ser bloqueada por otra transaccin que tenga establecido un bloqueo exclusivo por motivo

marp | 08TE0264

Pgina 1

Niveles de Aislamiento en SQL

de una operacin de escritura. Este nivel de aislamiento ofrece grandes beneficios de rendimiento, pero slo deberemos utilizarlo en aquellos casos en que la ocurrencia de lecturas sucias (dirty reads) no sea un problema. READ COMMITTED permite que entre dos lecturas de un mismo registro en una transaccin A, otra transaccin B pueda modificar dicho registro, obteniendose diferentes resultados de la misma lectura. Evita las lecturas sucias (dirty reads), pero por el contrario, permite lecturas no repetibles. Es la opcin por defecto en SQL Server 2000 y SQL Server 2005. Con este nivel de aislamiento, una operacin de lectura (SELECT) establecer bloqueos compartidos (shared locks) sobre los datos que est leyendo. Sin embargo, dichos bloqueos compartidos finalizarn junto con la propia operacin de lectura, de tal modo que entre dos lecturas cabe la posibilidad de que otra transaccin realice una operacin de escritura (ej: UPDATE), en cuyo caso, la segunda lectura obtendr datos distintos a la primera lectura (lecturas no repetibles). REPEATABLE READ evita que entre dos lecturas de un mismo registro en una transaccin A, otra transaccin B pueda modificar dicho registro, con el efecto de que en la segunda lectura de la transaccin A se obtuviera un dato diferente. De este modo, ambas lecturas seran iguales (lecturas repetidas). Para ello, una operacin de lectura (SELECT) establecer bloqueos compartidos (shared locks) sobre los datos que est leyendo, y los mantendr hasta el final de la transaccin, garantizando as que no se produce lecturas no repetibles (non repeatable reads). Mayor consistencia en la transaccin, mediante mayores recursos y bloqueos (se evitan los problemas de las lecturas sucias y de las lecturas no repetibles, pagando el precio de necesidad de mayores recursos). Sin embargo, este modo de aislamiento no evita las lecturas fantasma, es decir, una transaccin podra ejecutar una consulta sobre un rango de filas (ej: 100 filas) y de forma simultnea otra transaccin podra realizar un insercin de una o varias filas sobre el mismo rango. SERIALIZABLE garantiza que una transaccin recuperar exactamente los mismos datos cada vez que repita una operacin de lectura (es decir, la misma sentencia SELECT con la misma clusula WHERE devolver el mismo nmero de filas, luego no se podrn insertar filas nuevas en el rango cubierto por la WHERE, etc. - se evitarn las lecturas fantasma), aunque para ello aplicar un nivel de bloqueo que puede afectar a los dems usuarios en los sistemas multiusuario (realizar un bloqueo de un rango de ndice - conforme a la clusula WHERE - y si no es posible bloquear toda la tabla). Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatable reads), y de las lecturas fantasma (phantom reads).

En caso de trabajar con modos de aislamiento basados en bloqueo, es muy importante recordar que el tiempo de espera por un bloqueo por defecto en SQL Server es infinito. Es decir, si tenemos una transaccin que est manteniendo un bloqueo sobre un recurso (ej: una fila particular de una tabla), y mientras una transaccin B intenta acceder a dicho recurso (ej: a la misma fila), la transaccin B se quedar en espera por un tiempo indefinido (o hasta que la transaccin A libere dicho recurso). A que ahora entendemos mejor porqu es modo de aislamiento READ UNCOMMITTED resulta tan atractivo, eh? Es posible establecer un tiempo de espera de bloqueo mximo, con el fin de evitar esperas largas en las transacciones. Para ello, es posible utilizar la sentencia SET LOCK_TIMEOUT para especificar el tiempo mximo de espera por bloqueo (en milisegundos). En caso se que una transaccin alcance el tiempo mximo de espera por bloqueo, se producir un mensaje de error 1222 (Msg 1222, Level 16, State 51, Line 1. Lock request time out period exceeded.). Tambin es posible conocer el actual tiempo de espera por bloqueo, consultando el valor de la funcin del sistema @@LOCK_TIMEOUT. A continuacin se describen los dos posibles niveles de aislamiento basados en versionado de filas (row versioning).

SNAPSHOT. Evita los problemas de las lecturas sucias (dirty reads), de las lecturas no repetibles (non repeatable reads), y de las lecturas fantasma (phantom reads). Sin embargo, en vez de realizar un uso intensivo de bloqueos, su funcionamiento se basa en el almacenamiento de versiones de filas en TEMPDB. Si una transaccin empieza en un momento del tiempo determinado, slo ser capaz de acceder a la informacin de la base de datos que era real en aquel momento del tiempo. Por ello, es posible que existan mltiples versiones de la misma fila en TEMPDB, con el fin de servir a mltiples transacciones. Debido al impacto que tiene este modo de aislamiento sobre la base de datos del sistema TEMPDB, slo es recomendable en bases de datos intensivas en lecturas o en bases de datos con grandes problemas de bloqueos. Una situacin de concurrencia particular de ste modo de aislamiento es el caso de los conflictos de actualizacin (update conflicts): Si una fila es leda en una transaccin, y posteriormente como parte de la misma transaccin es modificada, PERO entre la lectura inicial y la posterior modificacin ha sido alterada por otra transaccin, se produce un conflicto de actualizacin (update conflict), que implica un mensaje de error 3960 (Msg 3960, Level 16, State 4 Line 1. Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table 'myTable' directly or indirectly in database 'myDB' to update, delete or insert the row that has been modified or deleted by another transaction. Retry the transaction or change de isolation level for the update/delete statement), y adems tambin implica que la transaccin se dehace (Rollback). READ COMMITTED SNAPSHOT. Se trata de una mezcla entre los modos de aislamiento READ COMMITTED y SNAPSHOT. Tiene la ventaja de utilizar el versionado de filas (row versioning), de tal modo, que las lecturas no son bloqueadas por las escrituras (y viceversa). Sin embargo, pueden producirse lecturas no repetibles (non repeatable

marp | 08TE0264

Pgina 2

Niveles de Aislamiento en SQL

reads) y lecturas fantasma (phantom reads). Es tambin importante tener en cuenta que en este modo de aislamiento, no se produce error en caso de conflictos de actualizacin (update conflicts). En SQL Server, y para los cuatro modos de aislamiento basados en bloqueo (Read Uncommitted, Read Committed, Repeateable Read, Serializable), es suficiente con utilizar la sentencia SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATEABLE READ | SERIALIZABLE}. En SQL Server se incluyen dos nuevas propiedades de base de datos (configurables a travs del comando ALTER DATABASE). Se trata de las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION (ambas desactivadas por defecto - revisar el comando ALTER DATABASE de SQL Server), de tal modo, que tenemos las siguientes opciones:

Activar READ_COMMITTED_SNAPSHOT (poner ON) y utilizar aislamiento READ COMMITED. La principal ventaja de ste mtodo, es que al utilizar el nivel de aislamiento READ COMMITED (que es justo el modo de aislamiento por defecto en SQL Server), estaremos aprovechando las ventajas del versionado de filas (row versioning). Por ello, en muchos casos, simplemente ser necesario activar la opcin de base de datos READ_COMMITTED_SNAPSHOT (poner a ON) y disfrutar del versionado de filas (row versioning), sin necesidad de tocar el cdigo de las transacciones. Activar ALLOW_SNAPSHOT_ISOLATION (poner ON) y utilizar aislamiento SNAPSHOT. Requiere establecer de forma explcita el nivel de aislamiento SNAPSHOT, es decir, ejecutar SET TRANSACTION ISOLATION LEVEL SNAPSHOT. En caso del desarrollo de una aplicacin nueva, es suficiente con tenerlo en cuenta, pero en caso de una aplicacin existente, puede implicar tener que modificar el cdigo fuente (algo que podra llegar a ser poco viable, segn el caso).

Del mismo modo, tambin nos resultar muy til ejecutar el comando DBCC USEROPTIONS y consultar sys.databases para poder conocer en qu modo de aislamiento estamos funcionando, y si las opciones de versionado estn activadas en una u otra base de datos. En la mayora de los casos, ser preferible utilizar el modo de aislamiento de lecturas confirmadas (READ COMMITED) junto con la opcin de base de datos READ_COMMITTED_SNAPSHOT, debido a que:

Utiliza menos espacio en TEMPDB, que la utilizacin explcita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT). Soporta el funcionamiento de transacciones distribuidas, que no es soportado con la utilizacin explcita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT). Es fcil de implantar, ya que al activar la opcin de base de datos READ_COMMITTED_SNAPSHOT, todas las transacciones que utilicen el nivel de aislamiento de lecturas confirmadas (READ COMMITTED - el nivel de aislamiento por defecto en SQL Server) se beneficiarn del aislamiento por versionado de filas (row versioning). No es vulnerable ante conflictos de actualizaciones, mientras que por el contrario, con la utilizacin explcita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT) si es posible que ocurran conflictos de actualizaciones. Es decir, si una transaccin A lee una fila, seguidamente una transaccin B actualiza dicha fila, y a continuacin la transaccin A actualiza la misma fila, la diferencia entre el aislamiento READ_COMMITTED_SNAPSHOT y el SNAPSHOT, est en si se produce un conflicto de actualizacin en la transaccin A (finalizndose la transaccin y realizndose ROLLBACK) o si ambas actualizaciones (de la transaccin A y de la transaccin B) se completan y confirman correctamente.

marp | 08TE0264

Pgina 3