INGENIERÍA EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN

...

SET TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATEABLE READ | SERIALIZABLE}.

A partir del SQL server 2005 se implementan 2 nuevas propiedades de bases de datos que son configurables atreves del comando ALETER DATA BASE. Estas son READ_CPMMITED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLUTION las 2 sesta desactivadas por defecto.

- Para activar READ_COMMITED_SNAPSHOT y utilizar aislamiento READ CMMITED. Con esto estaremos aprovechando las ventajas del versionado de filas (row versioning). Por ellos, en muchos casis simplemente será necesario activar la opción de base de datos READ_COMMITED_SNAPCHOT y disfrutar del versionado de filas sin necesidad de tocar el código de las transacciones.

- Para activar ALLOW_SNAPSHOT_ISOLATION y utilizar el aislamiento SNAPSHOT. Es decir ejecutar SET TRANSACTION ISOLATION LEVEL SNAPCHOT. En caso del desarrollo de una aplicación nueva, es suficiente con tenerlo en cuenta. Pero en caso de una aplicación existente, pude aplicar tener ue modificar el código fuente.

Del mismo modo, también nos resultara 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 están activas en una u otra base de datos.

En la mayoría de los casos, será preferible utilizar el modo de aislamiento de lecturas confirmadas (READ COMMITED) junto con la opción de base de datos READ_COMMITTED_SNAPSHOT, debido a que:

Utiliza menos espacio en TEMPDB, que la utilización explícita del nivel de aislamiento SNAPSHOT (SET TRANSACTION ISOLATION LEVEL SNAPSHOT).

Soporta el funcionamiento de transacciones distribuidas, que no es soportado con la utilización explícita del nivel de aislamiento SNAPSHOT.

Es fácil de implantar, ya que al activar la opción 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 beneficiarán del aislamiento por versionado de filas.

No es vulnerable ante conflictos de actualizaciones, mientras que por el contrario, con la utilización explícita del nivel de aislamiento si es posible que ocurran conflictos de actualizaciones. Es decir, si una transacción A lee una fila, seguidamente una transacción B actualiza dicha fila, y a continuación la transacción A actualiza la misma fila, la diferencia entre el aislamiento READ_COMMITTED_SNAPSHOT y el SNAPSHOT, está en si se produce un conflicto de actualización en la transacción A (finalizándose la transacción y realizándose ROLLBACK) o si ambas actualizaciones (de la transacción A y de la transacción B) se completan y confirman correctamente.

Como resolver los problemas de transacción de los niveles de aislamiento

El nivel de aislamiento de una transacción define el grado en que esta transacción debe ser aislada de las modificaciones de datos realizadas por otras transacciones.

Escoger un nivel de aislamiento adecuado nos asegura la protección e integridad de todos los datos.

Niveles de aislamiento de transacción en bases de datos

En SQL Server se categoriza los niveles de aislamiento de la siguiente manera:

- READ UNCOMMITTED

- READ COMMITTED

- REAPEATABLE READ

- SERIALIZABLE

- SNAPSHOT

Es importante conocer que solo se puede asignar un nivel de aislamiento a la vez, y que permanece así durante toda la conexión a la base de datos a menos de que sea cambiado explícitamente.

Las principales diferencias de cada nivel tienen que ver con su grado de aislamiento y la cantidad de problemas de concurrencia.

[pic 2]

Podemos ver que el nivel SERIALIZABE es el de mayor grado de aislamiento y el que no presenta problemas de concurrencia. READ UNCOMMITTED es el de menor grado de aislamiento y por lo tanto con mayor cantidad de problemas de concurrencia.

Esta grafica es muy útil a la hora de escoger el nivel adecuado para nuestra base de datos.

Efectos Secundarios de la Concurrencia

Actualización Perdida: Esto ocurre cuando más de una transacción intenta actualizar un record en específico al mismo tiempo.

Lectura no repetible: Supongamos que leemos un valor de una tabla y empezamos a trabajar en ella pero al mismo tiempo otro proceso modifica el valor en el origen, resultando en una salida falsa de nuestra transacción. Esto es lo que se conoce como lectura no repetible. Trabaja con datos inconsistentes.

Lectura Sucia: en un tipo de lectura no repetible, que ocurre cuando un proceso intenta leer un dato mientras otro proceso está lo está actualizando y aún no ha acabado,

Lectura Fantasma: Ocurre cuando 2 queries idénticas son ejecutadas y el conjunto de filas que retorna la primera son distintas a las que retorna la segunda.

READ UNCOMMITTED

En este nivel se pueden leer datos que han sido modificados por una transacción en progreso, pero que aún no han sido confirmados (committed). Es decir que en este nivel se permiten las lecturas sucias. Puede ser útil en caso de que se necesite un alto nivel de concurrencia.

Ejemplo

Usuario 1

[pic 3]

Usuario 2

[pic 4]

Resultado:

[pic 5]

READ COMMITTED

Es el nivel por defecto asignado en SQL Server y especifica que las declaraciones no pueden leer datos que han sido modificados pero no confirmados (committed). Evita las lecturas sucias, pero puede suceder que se den perdidas de actualización, lecturas fantasmas o lecturas no repetibles.

Ejemplo

Usuario 1

[pic 6]

Usuario