Control de Concurrencia Control de Concurrencia Operaciones

BASES DE DATOS I
Control de Concurrencia
Objetivo
•Forzar
el aislamiento de transacciones
conflictivas mediante la exclusión mutua.
•Preservar
la consistencia de la BD mediante
la ejecución adecuada de las transacciones.
•Resolver
los conflictos de escritura simultánea
y de lecto-escritura simultáneas.
BASES DE DATOS I
Control de Concurrencia
AIslamiento (+ Consistencia) Control de
Concurrencia
Base de Datos compuesta por ítems de
datos
Transacción read/write de ítems de
datos de la BD
BASES DE DATOS I
Operaciones Conflictivas
Plan de ejecución (schedule): desarrollo en el
tiempo de la ejecución de transacciones
concurrentes ejecución intercalada de
sentencias de las transacciones.
Un schedule mantiene el orden de las
operaciones dentro de cada transacción.
Dos operaciones de un plan de ejecución son
conflictivas si satisfacen las siguientes
condiciones:
(1)
(2)
(3)
Pertenecen a diferentes transacciones
Intentan acceder al mismo ítem
Una o las dos operaciones intentan escribir sobre
el ítem
1
BASES DE DATOS I
Operaciones Conflictivas
Dos transacciones que acceden al mismo ítem
intercaladas de manera que producen un resultado
incorrecto.
T1
read_item(X);
X  X - N;
write_item(X);
read_item(Y);
T2
X
Y
read_item(X);
X  X + M;
40
43
38
85
write_item(X);
43
Y  Y + N;
write_item(Y);
X=40
Y=85
N=2
M=3
40
38
87
87
X fue sobreescrito !! Los valores correctos debieron
ser:T1, T2 X=41, Y=87 o bien T2, T1 X=41 , Y=87
BASES DE DATOS I
Problemas típicos de la concurrencia
Actualización perdida (Lost Update
Problem)
Análisis (sumario) Inconsistente o Lectura
no Repetible (Unrepeatable Read
Problem)
Lectura Sucia o Fantasma (Dirty Read
Problem)
BASES DE DATOS I
Actualización Perdida
T1
T2
read_item(X);
read_item(Y);
read_item(X);
read_item(Y);
X  X – 2*Y
X  Y;
write_item(X);
commit
write_item(X);
commit
X = 40
40
Y=5
5
40
5
30
5
30
5
Trans-1, Trans-2 X=5
Trans-2, Trans-1 X= -5
No necesariamente las diferentes ejecuciones seriales arrojan el mismo
resultado !!
2
BASES DE DATOS I
Análisis Inconsistente
T1:
T2:
T1
T2
Suma  0;
0
read_item(A);
4
Suma  suma + A;
A=4
X=4
Y=8
N=2
suma
4
read_item(X);
4
X  X - N;
2
write_item(X);
2
read_item(X);
2
suma  sum + X;
6
read_item(Y);
8
suma  suma + Y;
14
read_item(Y);
8
Y  Y + N;
10
write_item(Y);
10
El análisis inconsistente ocurre por utilizar registros en distinto estado de
actualización!!T2 utiliza X actualizado e Y sin actualizar
BASES DE DATOS I
Lectura Sucia o Fantasma
T1:
T2:
T1
read_item(X);
4
X  X - N;
2
write_item(X);
T2
2
read_item(X);
2
X  X- N;
0
write_item(X);
0
N=2
Falla!!
Al fallar T1, el valor X=2 virtualmente nunca existió !! T2 leyó un
valor “fantasma”
BASES DE DATOS I
Plan de Ejecución de Transacciones
Serializabilidad de Transacciones el
resultado de la ejecución concurrente de dos
o más transacciones debe ser igual al que se
hubiese obtenido de una ejecución serial (no
concurrente)
Si hay N transacciones ejecutándose
concurrentemente N! ejecuciones seriales
posibles
3
BASES DE DATOS I
Serializabilidad
Idea: cuáles operaciones pueden intercambiarse
en un plan de ejecución?
Las siguientes NO, pues el resultado cambia !!:
Acciones de la misma transacción
Acciones en diferentes transacciones sobre
el mismo ítem, cuando al menos una de las
acciones es write
BASES DE DATOS I
Serializabilidad de los Planes de Ejecución
Serial
Un plan es serial si para cada transacción
participante, todas las operaciones se
realizan consecutivamente en el plan (no
hay intercalado de sentencias).
Serializable
Un plan es serializable si es equivalente
a cualquier plan serial de las mismas
transacciones.
BASES DE DATOS I
Conflictos
Planes conflicto-equivalentes:
Tienen el mismo conjunto de
acciones, y
Cada par de acciones conflictivas
están ordenadas de la misma forma
Un plan es conflicto-serializable si es
conflicto-equivalente a un plan serial
4
BASES DE DATOS I
Bloqueos (locks)
Cerrojo que crea una zona de exclusión en determinados ítems de
datos.
El tamaño del bloqueo define la granularidad: fina (nivel de datos)
gruesa (BD)
Cerrojo: variable asociada a cada ítem de dato
Describe el estado de un ítem con respecto a las operaciones
que pueden realizarse sobre él
Cerrojo binario: Locked/Unlocked
Cerrojo multimodo: ReadLock / WriteLock / Unlocked
Tres operaciones
read_lock(X)
write_lock(X)
unlock(X)
Cada ítem de dato puede estar en cualquiera de los tres estados.
BASES DE DATOS I
Bloqueos (locks)
Granularidad
Afecta significativamente el nivel de concurrencia
Afecta significativamente el desempeño del control de
concurrencia
Ejemplos de granularidad de ítems:
Un campo de un registro de una BD.
Un registro de la BD.
Un bloque de disco.
Un archivo completo.
Toda la BD.
Los locks se almacenan en una tabla del sistema.
Pueden ‘promover’ (upgrade lock): ReadLock WriteLock
Pueden ser ‘degradados’ (downgrade lock): WriteLock ReadLock
BASES DE DATOS I
Granularidad
5
BASES DE DATOS I
Bloqueos (locks)
Los bloqueos sobre ítems de datos pueden
combinarse limitadamente
S-locks (compartidos/shared) para lecturas:
slock(x) (≡ReadLock(x))
bloqueo solicitado
Bloqueo en el ítem
-
S
X
-
Ok
Ok
Ok
S
Ok
Ok
---
X
Ok
---
---
Compatibilidad de bloqueos
X-locks (exclusivos) para escrituras: xlock(x)
(≡WriteLock(x))
BASES DE DATOS I
Control de Concurrencia: Estrategias
Los DBMSs no verifican la serializabilidad
Muy ineficiente o impracticable !! (estrategia
reparadora)
Las transacciones arriban continuamente
Se requieren innumerables ‘undo’
Debería ‘ir probando’ todas las combinaciones
Solución: protocolos (estrategia preventiva)
Se puede garantizar la serializabilidad de los planes
de ejecución si cada transacción sigue el protocolo y
éste es forzado por el procesador de transacciones.
BASES DE DATOS I
Grafos de Precedencia
T1:
read_item(X);
X:= X - N;
write_item(X);
read_item(Y);
Y:=Y + N;
write_item(Y);
T2:
read_item(X);
X:= X + M;
write_item(X);
T1:
read_item(X);
X:= X - N;
write_item(X);
read_item(Y);
Y:=Y + N;
write_item(Y);
T2:
T1:
T2:
read_item(X);
X:= X + M;
write_item(X);
read_item(X);
X:= X - N;
write_item(X);
read_item(Y);
Y:=Y + N;
write_item(Y);
T1:
read_item(X);
X
 X - N;
write_item(X);
read_item(Y);
Y  Y- P
read_item(X);
X  X + M;
write_item(X);
write_item(Y);
read_item(X);
X:= X + M;
write_item(X);
T2:
read_item(Y);
Y  Y + N;
write_item(Y);
6
BASES DE DATOS I
Grafo de Serializabilidad
Un nodo para cada transacción Ti
Un arco de Ti a Tj si hay una operación de Ti
que precede y entra en conflicto con una de Tj
Teorema: Un plan de ejecución es serializable
por conflictos si y sólo si su grafo de
serializabilidad es acíclico.
BASES DE DATOS I
Locks no evitan todos los problemas …
Ejecutadas según un plan concurrente, con cerrojos
T1
T2
read_lock(Y);
read_item(Y);
unlock(Y);
Desbloquea demasiado pronto !!
write_lock(X);
read_item(X);
X X+Y;
write_item(X);
unlock(X);
read_lock(X);
read_item(X);
unlock(X);
write_lock(Y);
read_item(Y);
Y X+Y;
write_item(Y);
unlock(Y);
T1
X
Y
T2
Resultado: X=50, Y=50
No-serializable!
ciclo en el grafo
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
Se dice que una transacción sigue el
protocolo de dos fases si TODOS los
bloqueos (fase de crecimiento) preceden al
primer desbloqueo (fase de decrecimiento)
7
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
Básico: cuando una transacción devuelve un
ítem, ya no puede bloquear ningún otro
Punto de bloqueo
Cantidad
de
bloqueos
BEGIN
bloquea
desbloquea
Fase 1
crecimiento
Fase 2
decrecimiento
END
duración de la
transacción
BASES DE DATOS I
Ejemplo: Dos transacciones
T1
read_lock(Y);
read_item(Y);
unlock(Y);
write_lock(X);
read_item(X);
X  X+Y;
write_item(X);
unlock(X);
T2
read_lock(X);
read_item(X);
unlock(X);
write_lock(Y);
read_item(Y);
Y X+Y;
write_item(Y);
unlock(Y);
Ejecutadas según un plan serial S1: T1, T2
Valores iniciales X=20, Y=30 → Resultado: X=50, Y=80
BASES DE DATOS I
Ejemplo: Dos transacciones según el P2F
T1’
T2’
read_lock(Y);
read_item(Y);
write_lock(X);
unlock(Y);
read_item(X);
X  X+Y;
write_item(X);
unlock(X);
read_lock(X);
read_item(X);
write_lock(Y);
unlock(X);
read_item(Y);
Y  X+Y;
write_item(Y);
unlock(Y);
T1’ y T2’ siguen el P2F
Cualquier plan de ejecución de T1’ y T2’ será serializable
La concurrencia es limitada por la necesidad de arbitrar
requerimientos de ambas transacciones
8
BASES DE DATOS I
Variaciones del P2F
P2F Conservativo : Bloquea TODOS los ítems que necesita
ANTES de comenzar la ejecución, predeclarando su conjunto de
ítems de lectura y escritura
Si uno o más ítems están siendo bloqueados por otra
transacción, la transacción que lo requiere ESPERA
No se produce Deadlock, pero es muy restrictivo
P2F Estricto: Una transacción no desbloquea sus ítems de
escritura (WriteLocks) hasta que alcanza el commit o bien aborta
No está libre de deadlocks pero garantiza la recuperabilidad del
plan (Plan estricto: una transacción no puede leer/escribir X
hasta que la última transacción que haya usado X haya llegado
al commit o abortado)
Es la versión más popular
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
Estricto
bloquea
desbloqueo
Cantidad
de
bloqueos
BEGIN
Período de uso
del ítem
duración de la
END transacción
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
Componentes Esenciales
Lock Manager: Administra los bloqueos sobre los
ítems de datos.
Lock table: La utiliza el Lock Manager para
almacenar los siguientes datos:
o
La Base de Datos requiere que todas las
transacciones estén bien formadas • Debe bloquear los ítems de datos, antes de leerlos o
escribirlos.
• No bloquea un ítem sobre el que ya tiene un bloqueo ni
intenta desbloquear un ítem libre.
9
BASES DE DATOS I
Operaciones de Bloqueo
Componentes básicos del bloqueo binario: LOCK obtenido ← no
Repetir
If LOCK (X) = 0 (*el ítem está desbloqueado*)
Then LOCK (X) ← 1 (*bloquearlo*)
obtenido ← si
Else Begin
esperar … (hasta que LOCK (X) = 0
y el Lock Manager active la transacción)
Hasta obtenido = si
End;
BASES DE DATOS I
Operaciones de Bloqueo
Componentes básicos del bloqueo binario: UNLOCK LOCK (X) ← 0 (*desbloquea el ítem*)
If existe alguna transacción esperando por X
Then activar una y adjudicarle el ítem;
BASES DE DATOS I
Operaciones de Bloqueo
Componentes básicos del bloqueo multimodo: READLOCK
obtenido ← no
Repetir
If LOCK (X) = “unlocked”
Then Begin LOCK (X) ← “read-locked”
#reads (X) ← 1
obtenido ← si;
End
Else If LOCK (X) ← “read-locked”
Then #reads (X) ← #reads (X) +1
obtenido ← si
Else Begin esperar… (hasta que LOCK
“unlocked” y el Lock Manager active la transacción)
End
Hasta obtenido = si
End;
(X)
=
10
BASES DE DATOS I
Operaciones de Bloqueo
Componentes básicos del bloqueo multimodo: WRITELOCK obtenido ← no
Repetir
If LOCK (X) = “unlocked”
Then Begin LOCK (X) ← “Write-locked”;
#writes (X) ← 1;
obtenido ← si;
End
Else Begin esperar (hasta que LOCK (X) = “unlocked
y el Lock Manager active la transacción)
Hasta obtenido = si
End;
BASES DE DATOS I
Operaciones de Bloqueo
Componentes básicos del bloqueo multimodo: UNLOCK If LOCK (X) = “write-locked”
Then Begin LOCK (X) ← “unlocked”;
activar una de las transacciones que esperan si hay alguna
End
Else If LOCK (X) ← “read-locked”
Then Begin #reads (X) ← #reads (X) -1
If #reads (X) = 0
Then Begin LOCK (X) = “unlocked”;
Activar alguna transacción en espera si la hay
End
End;
BASES DE DATOS I
Abrazo Mortal (deadlock)
Dos o más transacciones esperan
indefinidamente que otra devuelva un
ítem de dato.
T1
read_lock(Y);
read_item(Y);
write_lock(X);
no puede espera !!
T2
read_lock(X);
read_item(X);
write_lock(Y);
no puede espera !!
11
BASES DE DATOS I
Abrazo Mortal (deadlock) e Inanición (livelock)
Para prevenir deadlocks P2F conservativo
Timestamping las transacciones más
jóvenes son abortadas
Detección de deadlocks T1
T2
Grafo espera-por
Selección de una ‘víctima’
Recomienzo cíclico
Livelock: una transacción no puede obtener los
recursos que necesita por un período de tiempo
indefinido, mientras las otras avanzan
normalmente Estrategia first-come-first-served
BASES DE DATOS I
Equivalencia y Serializabilidad por Vistas
Equivalencia:
Para cada ítem X, si Ti lee el valor inicial de X en
P1, Ti debe leer también el valor inicial de X en
P2.
Para cada lectura de X por Ti en P1, si el valor
leído por Ti es escrito por Tj, Ti debe también
leer el valor de X producido por Tj en P2.
Para cada ítem X, si la última escritura de X fue
ejecutada por Ti en P1, la misma transacción
debe escribir el valor final de X en P2.
BASES DE DATOS I
Equivalencia y Serializabilidad por Vistas
Un plan S es serializable por vistas (view
serializable) si es equivalente por vistas a un
esquema serial.
Ofrece una definición menos restrictiva de plan de
ejecución que la serializabilidad por conficto: Cada
plan conflicto-serializable es serializable por vistas.
12
BASES DE DATOS I
Serializabilidad Semántica
Algunas aplicaciones pueden producir planes
correctos aunque no sean serializables ni por
conflicto ni por vistas.
Ejemplo: Débito/Crédito (Suma y resta se vuelven
conmutativas)
T1
T2
T1
read_item(X);
X:=X-10;
write_item(X);
read_item(Y);
Y:=Y+10;
write_item(Y);
T2
read_item(Y);
Y:=Y-20;
write_item(Y);
read_item(Z);
Z:+Z+20;
write_item(Z);
read_item(X);
X:=X-10;
write_item(X);
read_item(Y);
Y:=Y+10;
write_item(Y);
read_item(Y);
Y:=Y-20;
write_item(Y);
read_item(Z);
Z:+Z+20;
write_item(Z);
BASES DE DATOS I
Métodos para Serializabilidad
Multi-version: se aguardan los valores viejos de los
ítems de datos cuando estos son actualizados.
Timestamps: son identificadores únicos de las
transacciones, generados por el sistema. Las
transacciones se ordenan por este identificador para
lograr la serializabilidad.
Protocolos: cuando cada transacción adhiere a un
protocolo, se garantiza la serializabilidad de todos
los planes en los cuales participen esas
transacciones bloqueos.
Control de Concurrencia Pesimista
Verifica antes de modificar la BD, bloqueando
datos antes de leerlos o escribirlos, o chequeando
timestamps.
BASES DE DATOS I
Transacciones en SQL 92
Start Transaction
No hay una sentencia explícita
Implícitamente comienza por una sentencia
SQL
End Transaction
Si ocurre COMMIT o ROLLBACK
Automáticamente con AUTOCOMMIT cuando
se completa la sentencia SQL
13
BASES DE DATOS I
Estableciendo Propiedades
SET TRANSACTION
[READ ONLY | READ WRITE]
ISOLATION LEVEL
[READ UNCOMMITTED | SERIALIZABLE |
REPEATABLE READ | READ COMMITTED]
BASES DE DATOS I
Niveles de Aislamiento
Read Uncommitted
Read Committed
Puede ver cambios comprometidos de otras
transacciones
No hay lectura sucia, pero es posible la lectura norepetible
Aceptable para consultas o soporte a las decisiones
Repeatable Read
Puede ver cambios no comprometidos de otras
transacciones
Lectura sucia, Lectura no-repetible
Recomendada solamente para funciones estadísticas
No hay lectura sucia ni no-repetible
Puede exhibir el fenómeno ‘fantasma’
Serializable
BASES DE DATOS I
Niveles de aislamiento
14
BASES DE DATOS I
Implementación de Niveles de Aislamiento
Read Uncommitted
Read Committed
sin S-locks
S-locks pueden ser levantados en cualquier
momento
X-locks con el P2F estricto
Repeatable Read
Serializable
P2F estricto sobre todos los datos
P2F estricto sobre todos los datos e índices
BASES DE DATOS I
Tuplas Fantasma
Si una transacción bloquea tuplas de una relacion, por
ej. Con el atributo X=25, y luego se insertan nuevas
tuplas en la relación con X=25 para algunas
transacciones este puede ser un comportamiento no
serializable.
o
o Estas tuplas se llaman fantasmas
o Los fantasmas pueden ser evitados estableciendo un
lock exclusivo en TODA la relación, antes de insertar
tuplas limita el grado de concurrencia.
o El programador puede elegir el nivel de aislamiento en
SQL, para permitir o evitar este fenómeno.
BASES DE DATOS I
Locks en Índices
Cuando se actualiza una relación (archivo) actualización de los índices asociados
o
o Nuevamente locks para asegurar
serializabilidad.
o Árboles-B la raíz puede ser alterada por
cualquier actualización actualizaciones
concurrentes no pueden ser manejadas con locks!!
15
BASES DE DATOS I
Locks en Árboles-B
Idea Establecer un bloqueo exclusivo en un
nodo si existe la posibilidad de que sea
actualizado.
Bloquear todo el camino hacia la base.
Desbloquear el camino desde la base al
nodo, tan pronto como se haya
actualizado.
Protocolo de árbol
BASES DE DATOS I
Problemas con los Bloqueos
Los bloqueos evitan la no-serializabilidad.
Resultan demasiado estrictos en algunos casos,
limitando innecesariamente el grado de
concurrencia enfoque pesimista.
Otras estategias se desempeñan mejor si las
transacciones no entran en conflicto con
frecuencia enfoque optimista.
BASES DE DATOS I
Optimismo vs pesimismo
Enfoque Pesimista mejor en situaciones de alto
conflicto:
Menor cantidad de abortos.
Menor tiempo de procesamiento.
Enfoque Optimista mejor en situaciones de
bajo conflicto (por ej. muchas transacciones de
solo lectura).
Mayor grado de concurrencia.
En la práctica soluciones híbridas.
16
BASES DE DATOS I
Timestamps (Marcas de Tiempo)
Asocia un número único a cada transacción timestamp (marca o estampado de tiempo ≡
’fecha de nacimiento’ de la transacción).
Las transacciones son ejecutadas en forma
intercalada pero simulando su ejecución según su
’fecha de nacimiento’ (las mas jóvenes primero).
No hay bloqueos no puede producirse deadlock.
Cada dato que es accedido adquiere una marca, si
la operación es posible.
BASES DE DATOS I
Plan de Ejecución basado en Marcas de
Tiempo
Si una transacción T:
Intenta leer un ítem de la BD escrito por una
transacción no comprometida esperar hasta que
alcance el commit o aborte.
Intenta leer un ítem que ha sido actualizado por una
transacción más joven (> timestamp!!) rollback.
Intenta actualizar un ítem que ha sido actualizado o
leído por una transacción más joven rollback.
Rollback recomienzo de T con un nuevo timestamp
Actualización física no puede ejecutarse (por conflicto)
no se ejecuta ninguna de las operaciones de la
transacción (atomicidad) reinicio no requiere
rollback pues no hay datos físicamente actualizados.
BASES DE DATOS I
Plan de Ejecución basado en Marcas de
Tiempo
El sistema debe conocer, para cada ítem de
dato, la marca de tiempo de la transacción más
joven que leyó o actualizó el ítem valores de
sincronización.
r(X) - timestamp de la transacción más joven
que ejecutó read(X)
w(X) - timestamp de la transacción más joven
que ejecutó write(X)
17
BASES DE DATOS I
Marcas de Tiempo: Mecanismo
Para cada transacción T, con timestamp t(T):
T intenta ejecutar READ(Xi) if t(T) >= w(Xi)
then r(Xi)  max(t(T), r(Xi))
else reiniciar T
T intenta ejecutar WRITE(Xj) if t(T) >= r(Xj) & t(T) >= w(Xj)
then w(Xj)  t(T)
else reiniciar T
BASES DE DATOS I
Marcas de Tiempo: Act. Perdida Revisitado
Transacción A
Leer X
Actualizar X
tiempo
Transacción B
t1
t2
Leer X
t3
t4
Actualizar X
Si A es más joven que B, t(A) > t(B) La actualización de B en t4 fallará porque en t3 w(X)  t(A) y
t(A) > t(B) B se reinicia.
Si A es más antigua que B t(A) < t(B)
A debería reiniciarse en t3 porque en t2 r(X)  t(B) y t(B) > t(A)
Livelock
y deadlock no ocurren con marcas de tiempo pero el
reinicio reiterado es un problema.
BASES DE DATOS I
Bibliografía
Date, C.: “An Introduction to Database Systems”. 7º edición. Addison
Wesley. 2000.
Elmasri, R., Navathe, S.: “Fundamentals of Database Systems”.
Addison Wesley. 2004.
Silberschatz, A., Korth, H, Sudarshan, S.: “Database System
Concepts”. McGraw Hill. 2001.
18