UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE CIENCIAS DE LA COMPUTACION

Carrera de Ingeniería Informática

TEMA 4

“CONTROL DE CONCURRENCIA DE
TRANSACCIONES “

Elaborado por:
ING. Ubaldo Pérez Ferreira.

Santa Cruz de la Sierra – Bolivia

 Acceso concurrente
• Los SGBD según el número de usuarios que
pueden utilizarlos de forma concurrente, se
clasifican en sistemas:

monousuario multiusuario
 Multiprogramación
Varios usuarios pueden usar un mismo equipo a la
vez gracias a la multiprogramación: el
computador puede procesar al mismo tiempo
varias transacciones.

Dos transacciones T1 y T2 son concurrentes

cuando se ejecutan simultaneamente en una
sola CPU, que solo puede ejecutar una por una.
 Concurrencia Intercalada Vs. Simultanea

T1 T1 T1 CPU 1
CPU 1 T2 T2 T2 CPU 2

t1 t2 t3 t4

Intercalado
Si sólo hay una CPU, el Sistema
Operativo de multiprogramación
reparte el tiempo de CPU entre las
transacciones:
ejecución concurrente intercalada
modelo que supondremos
Simultaneo
Si el equipo tiene varias CPU,
es posible el procesamiento
simultáneo (paralelo) de
transacciones

PROCESADORES
RISC vs x86
 Transacciones Concurrentes

Varias transacciones introducidas por usuarios, que se ejecutan de

manera concurrente, pueden leer/modificar el mismo elemento de
datos X almacenados en la Base de Datos
 Transacciones Concurrentes

Dada dos transacciones

T1 y T2
T1 T2

¿Cómo ejecutan las dos transacciones T1 y

T2?
Ejecución Secuencial Ejecución intercalada

T1 T1 T1
T2 T2 T2

Tiempo Tiempo
 Transacciones Concurrentes

• Razones para permitir la concurrencia:

– Aumentar la productividad: número de transacciones
ejecutadas por minuto.
– Aumentar la utilización de la CPU (menos tiempo ociosa)
y Control del disco.
– Reducir el tiempo medio de respuesta de transacciones
(las ‘pequeñas’ no esperan a las ‘grandes’).

El aprovechamiento de los recursos computacionales y la

reducción de los tiempos de respuesta exige la
concurrencia de transacciones en BD multiusuario
 Transacciones Concurrentes

Las operaciones que utilizan las transacciones para el acceso a la Base

de Datos son:
1. Leer(X): Transfiere el dato X de la base de datos a una memoria
intermedia local perteneciente a la transacción que ejecuta la
operación leer.
2. Escribir(X): Transfiere el dato X de la memoria intermedia local
a la base de la transacción que ejecuta la operación Escribir.
Ejemplo: Sea Ti una transacción para transferir 10.000 Bs. de la cuenta ‘A’ a
la Cuenta ‘B’. Se puede definir dicha transacción como:

Ti: 1 . leer(A);
2. A= A – 10.000;
3. Escribir(A);
4. leer(B);
5. B= B + 10.000;
6. Escribir(B);
 Problemas de la concurrencia
i) Problemas de Actualización Perdida
¿Por qué es necesario el control de la concurrencia?
• ... porque pueden surgir problemas si las transacciones
concurrentes se ejecutan de manera no controlada
X= 80, N=5, M=4, Y=70
T1 T2
Ejemplo: sistema de bases de datos que
permite hacer y anular reservas de asientos X=80 leer(X);
en vuelos de diferentes compañías aéreas. X=80-5 X= X-N; (x=75)
X=80+4 X=80 leer(X);
– Se almacena un registro por cada vuelo, que
incluye, entre otras cosas, el número de
X=75 X= X+M; (X=84)
asientos reservados en el vuelo escribir(X);
– Sean dos transacciones T1 y T2 Y=70 leer(Y);
concurrentes: X=84 escribir(X);
• T1 transfiere N reservas realizadas en
Y=70 + 5
un vuelo X a otro vuelo Y Y=Y+N; (Y=75)
Y=75 escribir(Y); El elemento X =84 tiene un valor
• T2 reserva M plazas en el vuelo X
incorrecto debe ser X=79 porque s
actualización por T1 se ‘perdió’ (se
sobrescribió)

Aunque las transacciones pueden ser perfectamente correctas en sí mismas,

la ejecución concurrente de T1 y T2 puede producir un resultado
incorrecto, debido a la intercalación de sus operaciones, poniendo en
cuestión la integridad y la coherencia de la base de datos
 Problemas de la Concurrencia
ii) Problemas de la Actualización Temporal
• La actualización temporal (o lectura sucia)
– T1 actualiza un elemento X de la BD y luego falla, pero
antes de que se restaure el valor original de X, T2 tiene
acceso al «valor temporal» de X
T1 T2
leer_elemento(X);
X:= X-N;
escribir_elemento(X);
leer_elemento(X);
X:= X+M;
escribir_elemento(X);
leer_elemento(Y);
T1 falla y debe devolver a X su antiguo
… valor; pero mientras, T2 ha leído el valor
‘temporal’ incorrecto de X (dato sucio)
 Problemas de la Concurrencia
iii) Problemas del Resumen Incorrecto
• El resumen incorrecto
– Otra transacción T3 calcula una función agregada de resumen sobre varios registros
(suma las plazas reservadas para todos los vuelos), mientras otras transacciones, como T1,
actualizan dichos registros: puede que T3 considere unos registros antes de ser
actualizados y otros después
T1 T3
suma:=0;
leer_elemento(A);
suma:= suma+A;
leer_elemento(X); …
X:= X-N; …
escribir_elemento(X); …
leer_elemento(X);
suma:= suma+X; T3 lee X después de
leer_elemento(Y); restar N, pero lee Y
antes de sumar N, así
suma:= suma+Y;
que el resultado es un
leer_elemento(Y); … resumen incorrecto
Y:=Y+N;
… (discrepancia de N)
escribir_elemento(Y);
…
 Problemas de la Concurrencia
iv) Problemas de la Lectura NO Repetible
• La lectura no repetible
– T4 lee un elemento X dos veces y otra transacción,
como T1, modifica dicho X entre las dos lecturas: T4
recibe diferentes valores para el mismo elemento
T1 T4
leer_elemento(X);
X:= X-N;
leer_elemento(X); T4 lee X antes de
escribir_elemento(X); restar N
leer_elemento(Y);

…
leer_elemento(X); T4 lee X después
… de restar N
Y:=Y+N;
escribir_elemento(Y);
 Planificador de Transacciones

Para controlar el accesos concurrentes y específicamente de

transacciones concurrentes los SGBD utilizan un modulo
llamado “Planificador".

Administrador de
Las transacciones solicitan operaciones de
Transacciones Lectura/Escritura
T1, T2, …, Tn

Requerimientos de
Lectura/Escritura
El planificador crea agendas, secuencias ordenadas de
PLANIFICADOR las operaciones de Lectura/Escritura tomadas por una o
más transacciones
Lectura/Escritura

Si el datos esta en el Buffer el

Planificador interactúa con ellos o en
BUFFER su defecto solicita la lectura de los
datos del disco.

Disco
 Protocolo de Control de Concurrencias
Para evitar que se destruya la consistencia de la base de datos los
SGBD utilizan mecanismo denominados Protocolo de Control de
Concurrencia.
• El objetivo de un Protocolo de Control de Concurrencia:
– Planificar las transacciones de forma que no ocurran interferencias entre
ellas, y así evitar la aparición de los problemas mencionados anteriormente.
– Solución obvia: no permitir intercalación de operaciones de varias
transacciones

T1 T2 T1 T2
leer(X); leer(X);
X:= X-N; X:= X+M;
escribir(X); escribir(X);
leer(Y); leer(X);
Y:=Y+N; X:= X-N;
escribir(Y); escribir(X);
leer(X); leer(Y);
X:= X+M; Y:=Y+N;
escribir(X); escribir(Y);

Planificación A Planificación B
 Protocolo del Control de Concurrencias
• Pero el objetivo de un SGBD multiusuario también es maximizar el
grado de concurrencia del sistema
• Si se permite la intercalación de operaciones, existen muchos
órdenes posibles de ejecución de las transacciones
T1 T2 T1 T2
leer_elemento(X); leer_elemento(X);
X:= X-N; X:= X-N;
leer_elemento(X); escribir_elemento(X);
X:= X+M;
leer_elemento(X);
escribir_elemento(X); X:= X+M;
leer_elemento(Y); escribir_elemento(X);
escribir_elemento(X); leer_elemento(Y);
Y:=Y+N; Y:=Y+N;
escribir_elemento(Y); escribir_elemento(Y);

Planificación C: actualización perdida! Planificación D: correcta!

¿Existe algún modo de identificar las ejecuciones que está

garantizado que protegen la consistencia de la base de
datos? Teoría de la Serializabilidad
 Planificación de Transacciones Concurrentes

Cada transacción comprende una secuencia de

operaciones que incluyen acciones de lectura y
escritura en la BD, que finaliza con una confirmación
(commit) o anulación (rollback)

Ti: 1 . leer(A);
2. A= A – 10.000;
3. Escribir(A);
4. leer(B);
5. B= B + 10.000;
6. Escribir(B);
 Planificación de Transacciones Concurrentes

Una planificación P de n transacciones concurrentes T1,

T2 ... Tn es una secuencia de las operaciones realizadas por
dichas transacciones, sujeta a la restricción de que:
i. para cada transacción T i que participa en P,
ii. sus operaciones aparecen en P
iii. en el mismo orden en el que ocurren en T i
Denotamos como l, e, c, y r a las operaciones leer, escribir, commit y
rollback, respectivamente, tal como se muestra en la siguiente tabla.
operación abreviatura

leer l

escribir e

commit c

rollback r
 Planificación de Transacciones Concurrentes
T1 T2
leer(X) leer(X)
X=X-N X=X+M
escribir(X) escribir(X)
Dadas las
transacciones T1 y T2 leer(Y)
Y=Y+N
escribir(Y)

Ejemplos de planificaciones de transacciones serian:

El subíndice de cada operación indica la transacción que la realiza
PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ;
PB: l2(X) ; e2(X) ; c2 ; l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;
PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ;
PD: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;

No son planificaciones de transacciones las siguientes:

PF: e1(Y); l1(X) ; l1(Y); e1(X) ; c1 ; e2(X) ; l2(X) ; c2 ; Las operaciones T1 y T2 no
se ejecutan en el mismo
PG: l2(X) ; c2 ; l1(X) ; e1(X) ; e1(Y) ; c1 ; orden que la transacción
original
Faltan operaciones de T1 y T2
 Planificación Serie

Una planificación serie P es aquella en la que las

operaciones de cada transacción se ejecutan
consecutivamente sin que se intercalen operaciones de otras
transacciones, ejemplo:
Operaciones de la
T1 l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; Transacción T2

PA: T2
Operaciones de la
Transacción T1
l2(X) ; e2(X) ; c2 ;

Operaciones de la
T2 l2(X) ; e2(X) ; c2 ; Transacción T1

PB: T1 Operaciones de la
Transacción T2
l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;

Toda planificación serie es correcta BD consistente

Pero no se garantiza que los resultados de todas las ejecuciones
en serie de las mismas transacciones sean idénticos
en general, son inaceptables en la práctica (ineficiencia)
 Planificación No Serie
Una Planificación No Serie P es aquella en la que las
operaciones de un conjunto de transacciones concurrentes se
ejecutan intercaladas, ejemplo:

l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;

Pc: l2(X); e2(X) ; c2 ; KO

l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ;

l2(X); e2(X) ; c2 ;
Pd:

La Planificaciones No Serie permiten llevar la BD a un estado al que

pueda llegarse mediante una ejecución en Serie

Este es el objetivo de la
Serializabilidad
 Planificación Serializable
Un plan equivalente: es aquel que produce los mismos
efectos en la BD.
Una planificación P (no serie) es serializable si es
equivalente a alguna planificación serie de las mismas
n transacciones
– Una planificación que no es equivalente a ninguna ejecución
en serie, es una planificación no serializable
• Toda planificación serializable es correcta
– Produce los mismos resultados que alguna ejecución
en serie
• Dos maneras de definir la equivalencia entre
planificaciones:
– Equivalencia por conflictos
– Equivalencia de vistas
 Planes Equivalentes por Conflictos
¿Cuándo dos operaciones de un plan están en
conflicto?
En una planificación, dos operaciones están en conflicto si
– pertenecen a diferentes transacciones,
– tienen acceso al mismo elemento leer(X),
– y al menos una de ellas es escribir(X)
P: l1(X) ; e2(X) ; Operaciones en Conflictos
P: w1(X) ; e2(X) ;
P: w1(X) ; l2(X) ;

Operaciones en conflicto en las planificaciones PC y PD:

P C: l 1(X) ; l 2(X) ; e 1(X) ; l 1(Y) ; e 2(X) ; c 2 ; e 1(Y) ; c 1;

P D: l 1(X) ; e 1(X) ; l 2(X) ; e 2(X) ; c 2 ; l 1(Y) ; e 1(Y) ; c 1 ;

 Planes Equivalentes por Conflictos

En una planificación, dos operaciones están en conflicto si

– pertenecen a diferentes transacciones,
– tienen acceso al mismo elemento leer(X),
– y al menos una de ellas es escribir(X)

Operaciones en conflicto en las planificaciones PC y PD:

P C: l 1(X) ; l 2(X) ; e 1(X) ; l 1(Y) ; e 2(X) ; c 2 ; e 1(Y) ; c 1;

P D: l 1(X) ; e 1(X) ; l 2(X) ; e 2(X) ; c 2 ; l 1(Y) ; e 1(Y) ; c 1 ;

Dos planes son equivalentes por conflictos si el orden

de cualesquiera dos operaciones en conflicto es el
mismo en ambos planes.
 Planes Equivalentes por Conflictos

Operaciones que no están en conflicto

a. Si dos transacciones únicamente leen un determinado

elemento de datos, no entran en conflicto entre sí y el
orden de las operaciones no es importante
P: l1(X) ; l2(X) ;

b. Si hay dos transacciones que leen o escriben elementos

de datos independientes, no entran en conflicto entre sí
y el orden de las operaciones no es importante
P: e1(Y) ; e2(X) ;
P: l1(Y) ; e2(X) ; ;
 Planificación Serializable por Conflicto
Una planificación P es serializable por conflictos si equivale
por conflictos a alguna planificación serie S. Es decir, si se
puede transformar en una planificación en serie mediante la
permutación de operaciones no conflictivas (permutables) entre sí.
En este caso se intercambian cada dos operaciones de P consecutivas de transacciones
PD es un Planificación distintas y sin conflicto, hasta obtener la planificación serie equivalente.
NO SERIE (operaciones
intercaladas de T1 y T2) PD : l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;
PD1: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; c 2 ; e1(Y) ; c1 ;
PD2: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c 2 ; c1 ;
PD3: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c1 ; c2 ;
PD4: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e 2(X) ; e1(Y) ; c1 ; c2 ;
PD5: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; e 2(X) ; c1 ; c2 ;
¡Es una Planificación PD6: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; c1 ; e2(X) ; c2 ;
SERIE!
PD es serializable
PD7: l1(X) ; e1(X) ; l1(Y) ; l 2(X) ; e1(Y) ; c1; e2(X) ; c2 ;
PD8: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; l 2(X) ; c1 ; e2(X) ; c2 ;
PD9: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2Operaciones
(X) ; c2 ; de T2
Operaciones de T1
 Prueba de serializabilidad por conflictos de un Plan

Algoritmo que permite determinar si un plan es serializable

por conflictos
1. Para cada transacción Ti que participa en el plan P
El algoritmo sólo
examina las operaciones
crear un nodo etiquetado Ti en el grafo de
leer y escribir del plan serialización
para construir un grafo 2. Para cada caso en P en el que T ejecuta una orden
j
de precedencias o grafo
de serialización, donde leer(X) después de que Ti ejecute una orden
los nodos representan escribir(X) crear un arco Ti -->Tj en el grafo.
transacciones del plan y
un arco desde Ti hasta Tj 3. Para cada caso en P en el que Tj ejecuta una orden
expresa que una de las escribir(X) después de que Ti ejecute una orden
operaciones de Ti leer(X) crear un arco Ti --> Tj en el grafo.
aparecen en el plan antes
4. Para cada caso en P en el que Tj ejecuta una orden
que alguna operación en
conflicto de Tj escribir(X) después de que Ti ejecute una orden
escribir(X) crear un arco Ti --> Tj en el grafo.
5. El plan es serializable si, y sólo si, el grafo de
 Prueba de serializabilidad por conflictos de un Plan

Dados los Planes PA y PB: Paso 3 del Algoritmo

Paso 4 del Algoritmo

PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ; Paso2del Algoritmo

T1 T2

Paso 2 del Algoritmo

Paso 4 del Algoritmo

Paso 2 del Algoritmo
PB: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;
T1 T2

Como se puede observar, en ninguno de los dos grafos

hay ciclos por lo que los planes son serializables
 Prueba de serializabilidad por conflictos de un Plan

Paso 3 del Algoritmo

Dado el Plan PC: Paso 4 del Algoritmo

Paso 3 del Algoritmo

PC: l1(X) ; l2(X) ; e1(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ;

T1 T2

Se puede comprobar que el Plan no es serializable porque

su grafo de serializabilidad contiene ciclos.
 Tabla de Bloqueo (Lock Table)

Un Bloqueo (lock) es una estructura que solo puede ser adquirida

por una hebra de ejecucion (thread) a la vez. Si dos ejecuciones
tratan de obtener un lock para actualizar una tabla, la primera que
trate de obtenerlo tendrá acceso exclusivo a la tabla, la segunda
debe esperar a que la primera lo desbloquee (unlock) para obtener
el acceso.
Los locks pueden tener distintas granularidades:

Base de
Datos

Tablas

Filas BASE DE DATOS

Atributo
 Uso de la Tabla Lock

Para garantizar que no haya problemas entre transacciones el

Planificador de Transacciones del SGBD utiliza la tabla de
lock para bloquear ciertas operaciones de manera que sea
seguro ejecutar toda transacción.

El Planificador Bloquea el
dato X al que tiene acceso las
operaciones lectura/escritura
de las transacciones.
LOCK TABLE
Las transacciones
Administrador de
Transacciones
solicitan operaciones
T1, T2, …, Tn de Lectura/Escritura
Requerimientos de
Lectura/Escritura

l1(x); PLANIFICADOR
e1(x);
Ejecuta las operaciones de
Lectura/Escritura de manera segura
La operación COMMINT y
ROLLBACK libera el dato BUFFER
bloqueado por la
transacción. l1(x);
e1(x);
 Procurando la Serializabilidad usando Bloqueo (Lock)

La consistencia de transacciones se basa en que:

• Una transacción solo puede leer y escribir un elemento si se
solicitó un bloqueo y éste no se ha liberado.
• Si una transacción bloquea un elemento, debe liberarlo
posteriormente
Si una Plan con las condiciones anteriores se dice que el Plan es "legal"
T1 ejecuta Look(A) lo que implica que T1 T2 A B
el dato A solo puede modificarlo T1.
25 25
Look(A);
T1 ejecutar UnLook(A), lo que implica Leer(A); A=A+100;Escribir(A);
que el dato A queda libreado Unlock(A) 125
Look(A);
T2 ejecuta Look(A) lo que implica que Leer(A);A=A*2;Escribir(A);
el dato A solo lo puede modificar T2. Unlok(A); 250
Look(B);
T2 ejecutar UnLook(A), lo que implica
que el dato A queda libreado. Leer(B);B=B*2;Escribir(B);
Unlock(B); 50

Look(B);
Leer(B);B=B+100;Escribir(B); 150
Unlock(B);

Plan Legal, pero desafortunadamente no Serializable

(El resultado es diferente al ejecutarse en Serie T1 y T2)
 Procurando la Serializabilidad usando Bloqueo (Lock)

Locking retrasando una petición para evitar un Plan

Ilegal
T1 T2 A B
25 25
Look(A);
Leer(A);A=A+100;Escribir(A); 125
Look(B);Unlok(A)
Look(A);
Leer(A);A=A*2;Escribir(A); 250
Unlock(A);
Look(B); …
Leer(B);B=B+100;Escribir(B); 125
Unlok(B);
…Look(B);
Leer(B);B=B*2;Escribir(B); 250
Unlock(B);
T2 no puede ejecutar Look(B) porque T1 ya
lo ejecuto, entonces T2 debe esperar hasta
que T1 ejecute Unlook(B), …por lo tanto
T1 debe continuar
 Procurando la Serializabilidad usando
Two-phase locking (2PL)
En toda transacción, todos los locks preceden a todos los
unlocks. El problema de 2PL, caer en un abrazo mortal
(deadlock).

T1 T2 A B
25 25
Look(A);
Leer(A); Look(B);
Leer(B);
A=A+100;Escribir(A); 125
B=B*2;Escribir(B); 50

Look(B);
Look(A);

T1 no puede ejecutar Look(B) porque T2 ya T2 no puede ejecutar Look(A) porque T1

lo ejecuto, entonces T1 debe esperar hasta ya lo ejecuto, entonces T2 debe esperar
que T2 ejecute Unlook(B), …por lo tanto hasta que T1 ejecute Unlook(A), …por lo
T1 debe continuar tanto T2 debe continuar

Deadlock
 Procurando la Serializabilidad usando
Shared y Exclusive Locks

Cuando un transacción Ti bloquea en modo Share Lock (Ls) el

dato X, permiten que otra transacción Tj pueda solamente leer el
Share
Share Lock
Lock dato X, por lo tanto Tj debe esperar hasta que Ti lo libere
(Unlock) para poder escribir X

X
Share Lock (Ls)

Cuando un transacción Ti bloquea en modo Exclusive Lock (Lx)

Exclusive
Exclusive el dato X, no permiten que otra transacción Tj pueda leer/escribir
Lock el dato X, por lo tanto Tj debe esperar hasta que Ti lo libere
Lock
(Unlock).

X
Exclusive Lock (Ls)
 Procurando la Serializabilidad usando
Shared y Exclusive Locks

T1 coloca en modo T1 T2 T2 coloca en modo

Share Look(A) y puede Share Look(A) y puede
leer y escribir A. leer A.
Ls(A);
Leer(A); Ls(A);
T2 coloca en modo
Leer(A);
T1 no puede ejecutar Exclusive Share Look(B) y puede
Ls(B); leer y escribir B.
Look(B) porque T2 ya ejecuto
Share Lock (B) … por lo tanto
Leer(B);
debe esperar a que T2 ejecute Lx(B); T2 ejecuta Unclok(A) y
Unclok(B)… U(A);U(B); Unclok(A), libera A y B.
Lx(B);
…T1 ahora puede ejecutar Leer(B); Escribir(B);
Exclusive Look(B) porque T2 U(A);U(B); T1 ejecuta Unclok(A) y
ya ejecuto Unlock (B) Unclok(A), libera A y B.
 Nivel de Aislamiento en SQL Server

En SQL Server las transacciones especifican un nivel de aislamiento

que define el grado en que se debe aislar una transacción de las
modificaciones de recursos o datos realizadas por otras transacciones.

Los niveles de aislamiento de transacciones controlan si una

operación de lectura que hace referencia a filas modificadas por otra
transacción:
• Se bloquea hasta que se libera el bloqueo exclusivo de la fila.
• Recupera la versión confirmada de la fila que existía en el momento
en el que se inició la instrucción o la transacción.
• Lee la modificación de los datos no confirmada.
 Nivel de Aislamiento en SQL Server

SQL Server dispone de los siguientes niveles de aislamiento de transacciones:

NIVEL DESCRIPCION EFECTO
READ Especifica que las instrucciones pueden leer filas que han sido Lectura Sucia
modificadas por otras transacciones pero todavía no se han Lectura no repetible
UNCOMMITTED confirmado. Datos Fantasma
(Lectura no confirmada)
READ COMMITTED Especifica que las instrucciones no pueden leer datos que Lectura no repetible
hayan sido modificados, pero no confirmados, por otras Datos Fantasma
(Lectura confirmada) transacciones

REPEATABLE READ Especifica que las instrucciones no pueden leer datos que han Datos Fantasma
sido modificados pero aún no confirmados por otras
(Lectura repetible) transacciones y que ninguna otra transacción puede modificar
los datos leídos por la transacción actual hasta que ésta finalice

SNAPSHOT Especifica que los datos leídos por cualquier instrucción de una
transacción sean la versión coherente, desde el punto de vista
(instantánea) transaccional, de los datos existentes al comienzo de la
transacción

SERIALIZABLE Especifica lo siguiente:

Las instrucciones no pueden leer datos que hayan sido
(Serializable) modificados, pero aún no confirmados, por otras transacciones.
Ninguna otra transacción puede modificar los datos leídos por
la transacción actual hasta que la transacción actual finalice.
Otras transacciones no pueden insertar filas nuevas con valores
de clave que pudieran estar incluidos en el intervalo de claves
leído por las instrucciones de la transacción actual hasta que
ésta finalice.
Se utiliza la siguiente clausula para seleccionar el nivel de aislamiento
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }
 Bloqueo explicito en SQL Server

SQL Server controla de manera automática el control de concurrencia, sin

embargo, para algunas transacciones es necesario que el programador de
transacciones bloquee y/o libere datos específicos. La clausula WITH permite
bloquear datos y se usa con la clausula FROM.

SELECT * FROM table_name WITH ( …, )

WHERE condicion_busquedas

ROWLOCK,
PAGLOCK ,
TABLOCK,
TABLOCKX ,
XLOCK,
NOLOCK,
NOWAIT,
READCOMMITTED,
READCOMMITTEDLOCK,
READUNCOMMITTED,
SERIALIZABLE,
 Bloqueo Compartido por tabla en SQL Server

WITH (TabLock) , con esta instrucción se obtienen bloqueos compartido

(Shared Lock) para una tabla, es decir puedo bloquear todas las filas de una
tabla, mientras mi transacción este activa, sin embargo, otras transacciones
solamente pueden leer los datos de la tabla, podraan escribir cuando se se
libere el datos (COMMIT/ROLLBACK)
T1
BEGIN TRAN
… T2
SELECT * ….
FROM persona WITH (TabLock )
SELECT * FROM persona WHERE Codigo=1
…
… …
…
COMMIT/ROLLBACK
 Bloqueo Exclusivo por tabla en SQL Server

WITH (TabLockX) , con esta instrucción se obtienen bloqueos exclusivo para

una tabla, es decir puedo bloquear todas las filas de una tabla, mientras mi
transacción este activa, sin embargo otras transacciones no pueden
leer/escribir los datos de la tabla hasta que se liberen
(COMMIT/ROLLBACK)
T1
BEGIN TRAN
….
SELECT * T2
FROM persona WITH (TabLockX ) ….
…
… SELECT * FROM persona WHERE Codigo=1
… …
COMMIT/ROLLBACK
 Bloqueo Compartido por filas en SQL Server

WITH (RowLock, Xlock) , con esta instrucción se obtienen bloqueos

compartidos por fila, es decir puedo bloquear la fila de una tabla, mientras mi
transacción este activa

T1
BEGIN TRAN
….
SELECT * T2
FROM persona WITH ( RowLock ) ….
WHERE Ciudad = (´SC´)
… SELECT * FROM persona WHERE Codigo=1
…. …
COMMIT/ROLLBACK
 Bloqueo Exclusivo por filas en SQL Server

WITH (RowLock, Xlock) , con esta instrucción se obtienen bloqueos

exclusivos por fila, es decir puedo bloquear la fila de una tabla, mientras mi
transacción este activa

T1
BEGIN TRAN
….
SELECT * T2
FROM persona WITH ( RowLock ,xLock) ….
WHERE Ciudad = (´SC´)
… SELECT * FROM persona WHERE Codigo=1
…. …
COMMIT/ROLLBACK
 Bloqueo Exclusivo por filas en SQL Server

T1 RowLock = Bloquea la fila indicada en el Select.

BEGIN TRAN Xlock = Hace que el bloque sea exclusivo
….
SELECT * T2
FROM persona WITH ( RowLock, Xlock )
….
WHERE Ciudad = (´SC´)
SELECT * FROM persona WHERE Codigo=4
…