1
Objetivo
•Forzar el aislamiento de transaccionesconflictivas mediante la exclusión mutua.
•Preservar la consistencia de la BD mediantela ejecución adecuada de las transacciones.
•Resolver los conflictos de escritura simultáneay de lecto-escritura simultáneas.
BASES DE DATOS I
Control de Concurrencia
2
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
3
Operaciones Conflictivas
� Plan de ejecución (schedule): desarrollo en el tiempo de la ejecución de transaccionesconcurrentes � ejecución intercalada de sentencias de las transacciones.
� Un schedule mantiene el orden de lasoperaciones dentro de cada transacción.
� Dos operaciones de un plan de ejecución son conflictivas si satisfacen las siguientescondiciones:
(1) Pertenecen a diferentes transacciones(2) Intentan acceder al mismo ítem(3) Una o las dos operaciones intentan escribir sobre
el ítem
BASES DE DATOS I
4
� Dos transacciones que acceden al mismo ítemintercaladas de manera que producen un resultadoincorrecto.
� X fue sobreescrito !! Los valores correctos debieronser:T1, T2 � X=41, Y=87 o bien T2, T1 � X=41 , Y=87
X=40Y=85N=2M=3
BASES DE DATOS I
T1 T2
X Y
read_item(X); 40 X X - N; 38 read_item(X); 40 X X + M; 43 write_item(X); 38 read_item(Y); 85 write_item(X); 43 Y Y + N; 87 write_item(Y); 87
Operaciones Conflictivas
5
BASES DE DATOS I
Problemas típicos de la concurrencia
Actualización perdida (Lost Update Problem)
Análisis (sumario) Inconsistente o Lecturano Repetible (Unrepeatable Read Problem)
Lectura Sucia o Fantasma (Dirty Read Problem)
6
Actualización Perdida
Trans-1, Trans-2 � X=5 Trans-2, Trans-1 � X= -5No necesariamente las diferentes ejecuciones seriales arrojan el mismo
resultado !!
BASES DE DATOS I
commit5write_item(X);
commit30write_item(X);
5X Y;30X X – 2*Y
5read_item(Y);40read_item(X);
5read_item(Y); 40read_item(X);
Y = 5X = 40T2T1
7
Análisis Inconsistente
A=4 X=4 Y=8 N=2
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
10write_item(Y);
10Y Y + N;
8read_item(Y);
14suma suma + Y;
8read_item(Y);
6suma sum + X;
2read_item(X);
2write_item(X);
2X X - N;
4read_item(X);
4Suma suma + A;
4read_item(A);
0Suma 0;
sumaT2T1T2:T1:
8
Lectura Sucia o Fantasma
BASES DE DATOS I
0
0
2
T2
Falla!!
write_item(X);
X X- N;
read_item(X);
2write_item(X);
2X X - N;
4read_item(X);
T1T2: T1:
Al fallar T1, el valor X=2 virtualmente nunca existió !! � T2 leyó un valor “fantasma”
N=2
9
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ándoseconcurrentemente � N! ejecuciones serialesposibles
BASES DE DATOS I
10
Serializabilidad
� Idea: cuáles operaciones pueden intercambiarseen un plan de ejecución?
� Las siguientes NO, pues el resultado cambia !!:� Acciones de la misma transacción� Acciones en diferentes transacciones sobreel mismo ítem, cuando al menos una de lasacciones es write
BASES DE DATOS I
11
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 mismastransacciones.
BASES DE DATOS I
12
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 esconflicto-equivalente a un plan serial
BASES DE DATOS I
13
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 operacionesque 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
14
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
16
� Los bloqueos sobre ítems de datos puedencombinarse limitadamente� S-locks (compartidos/shared) para lecturas: slock(x) (≡ReadLock(x))
� X-locks (exclusivos) para escrituras: xlock(x)(≡WriteLock(x))
------OkX
---OkOkS
OkOkOk-
XS-
bloqueo solicitado
Bloqueo en el ítem
BASES DE DATOS I
Bloqueos (locks)
Compatib
ilidad de b
loqueos
17
Control de Concurrencia: Estrategias� Los DBMSs no verifican la serializabilidad
� Muy ineficiente o impracticable !! (estrategiareparadora)��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
18
Grafos de PrecedenciaT1: T2: read_item(X); X:= X - N; write_item(X); read_item(Y); Y:=Y + N; write_item(Y); read_item(X); X:= X + M; write_item(X);
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: T2:read_item(X);X:= X - N;
read_item(X);X:= X + M;
write_item(X);read_item(Y);
write_item(X);Y:=Y + N;write_item(Y);
T1: T2: 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(Y); Y Y + N; write_item(Y);
BASES DE DATOS I
19
Grafo de Serializabilidad
� Un nodo para cada transacción Ti
� Un arco de Ti a Tj si hay una operación de Tique precede y entra en conflicto con una de Tj
� Teorema: Un plan de ejecución es serializablepor conflictos si y sólo si su grafo de serializabilidad es acíclico.
BASES DE DATOS I
20
Locks no evitan todos los problemas …
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);
Resultado: X=50, Y=50ciclo en el grafo ���� No-serializable!
Desbloquea demasiado pronto !!
Ejecutadas según un plan concurrente, con cerrojos
BASES DE DATOS I
T1
T2
Y
X
21
Protocolo de Bloqueo en 2 Fases (P2F)
� Se dice que una transacción sigue el protocolo de dos fases si TODOS losbloqueos (fase de crecimiento) preceden al primer desbloqueo (fase de decrecimiento)
BASES DE DATOS I
22
� Básico: cuando una transacción devuelve un ítem, ya no puede bloquear ningún otro
bloquea
desbloquea
Punto de bloqueo
Fase 1crecimiento
Fase 2decrecimiento
BEGIN END
Cantidadde bloqueos
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
duración de la transacción
23
Ejemplo: Dos transacciones
T1read_lock(Y);read_item(Y);unlock(Y);write_lock(X);read_item(X);X X+Y;write_item(X);unlock(X);
T2read_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, T2Valores iniciales X=20, Y=30 → Resultado: X=50, Y=80
BASES DE DATOS I
24
Ejemplo: Dos transacciones según el P2F
T1’read_lock(Y);read_item(Y);write_lock(X);unlock(Y);read_item(X);X X+Y;write_item(X);unlock(X);
T2’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
BASES DE DATOS I
25
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 llegadoal commit o abortado)
� Es la versión más popular
BASES DE DATOS I
26
� Estricto
bloquea
desbloqueo
BEGIN END
Cantidadde bloqueos
duración de la transacciónPeríodo de uso
del ítem
BASES DE DATOS I
Protocolo de Bloqueo en 2 Fases (P2F)
27
BASES DE DATOS I
� Componentes Esenciales� Lock Manager: Administra los bloqueos sobre losítems de datos.� Lock table: La utiliza el Lock Manager paraalmacenar los siguientes datos:
o La Base de Datos requiere que todas lastransacciones 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 niintenta desbloquear un ítem libre.
Protocolo de Bloqueo en 2 Fases (P2F)
28
Operaciones de Bloqueo
Componentes básicos del bloqueo binario: LOCK �
obtenido ← noRepetir
If LOCK (X) = 0 (*el ítem está desbloqueado*)Then LOCK (X) ← 1 (*bloquearlo*)
obtenido ← siElse Begin
esperar … (hasta que LOCK (X) = 0 y el Lock Manager active la transacción)
Hasta obtenido = siEnd;
BASES DE DATOS I
29
Operaciones de Bloqueo
Componentes básicos del bloqueo binario: UNLOCK �
LOCK (X) ← 0 (*desbloquea el ítem*)If existe alguna transacción esperando por XThen activar una y adjudicarle el ítem;
BASES DE DATOS I
30
Operaciones de BloqueoComponentes básicos del bloqueo multimodo: READLOCK�
obtenido ← noRepetirIf LOCK (X) = “unlocked”Then Begin LOCK (X) ← “read-locked”
#reads (X) ← 1obtenido ← si;
EndElse If LOCK (X) ← “read-locked”
Then #reads (X) ← #reads (X) +1obtenido ← si
Else Begin esperar… (hasta que LOCK (X) = “unlocked” y el Lock Manager active la transacción)
EndHasta obtenido = siEnd;
BASES DE DATOS I
31
Componentes básicos del bloqueo multimodo: WRITELOCK �
obtenido ← noRepetirIf LOCK (X) = “unlocked”Then Begin LOCK (X) ← “Write-locked”;
#writes (X) ← 1;obtenido ← si;
EndElse Begin esperar (hasta que LOCK (X) = “unlocked
y el Lock Manager active la transacción)Hasta obtenido = siEnd;
BASES DE DATOS I
Operaciones de Bloqueo
32
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 algunaEnd
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
Operaciones de Bloqueo
33
T1 T2 read_lock(Y); read_item(Y); read_lock(X); read_item(X); write_lock(X); no puede � espera !!
write_lock(Y); no puede � espera !!
� Dos o más transacciones esperanindefinidamente que otra devuelva un ítem de dato.
BASES DE DATOS I
Abrazo Mortal (deadlock)
34
� Para prevenir deadlocks �
�P2F conservativo�Timestamping � las transacciones másjóvenes son abortadas
� Detección de deadlocks ��Grafo espera-por�Selección de una ‘víctima’�Recomienzo cíclico
� Livelock: una transacción no puede obtener losrecursos que necesita por un período de tiempoindefinido, mientras las otras avanzannormalmente �
� Estrategia � first-come-first-served
T1 T2
BASES DE DATOS I
Abrazo Mortal (deadlock) e Inanición (livelock)
35
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 enP2.
� Para cada lectura de X por Ti en P1, si el valor leído por Ti es escrito por Tj, Ti debe tambiénleer el valor de X producido por Tj en P2.
� Para cada ítem X, si la última escritura de X fueejecutada por Ti en P1, la misma transaccióndebe escribir el valor final de X en P2.
BASES DE DATOS I
36
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: Cadaplan conflicto-serializable es serializable por vistas.
BASES DE DATOS I
37
Serializabilidad Semántica� Algunas aplicaciones pueden producir planes correctos aunque no sean serializables ni porconflicto ni por vistas.
� Ejemplo: Débito/Crédito (Suma y resta se vuelvenconmutativas)
T1 T2 read_item(X); read_item(Y); X:=X-10; Y:=Y-20; write_item(X); write_item(Y); read_item(Y); read_item(Z); Y:=Y+10; Z:+Z+20; write_item(Y); write_item(Z);
T1 T2 read_item(X); X:=X-10; write_item(X); read_item(Y); Y:=Y-20; write_item(Y); read_item(Y); Y:=Y+10; write_item(Y);
read_item(Z); Z:+Z+20; write_item(Z);
BASES DE DATOS I
38
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 lastransacciones, generados por el sistema. Las transacciones se ordenan por este identificador paralograr la serializabilidad.
� Protocolos: cuando cada transacción adhiere a un protocolo, se garantiza la serializabilidad de todoslos planes en los cuales participen esastransacciones � bloqueos.
� Control de Concurrencia Pesimista
� Verifica antes de modificar la BD, bloqueandodatos antes de leerlos o escribirlos, o chequeandotimestamps.
BASES DE DATOS I
39
Transacciones en SQL 92
� Start Transaction � No hay una sentencia explícita� Implícitamente comienza por una sentenciaSQL
� End Transaction� Si ocurre COMMIT o ROLLBACK� Automáticamente con AUTOCOMMIT cuandose completa la sentencia SQL
BASES DE DATOS I
40
Estableciendo Propiedades
SET TRANSACTION[READ ONLY | READ WRITE]
ISOLATION LEVEL[READ UNCOMMITTED | SERIALIZABLE |REPEATABLE READ | READ COMMITTED]
BASES DE DATOS I
41
Niveles de Aislamiento
� Read Uncommitted� Puede ver cambios no comprometidos de otrastransacciones
� Lectura sucia, Lectura no-repetible� Recomendada solamente para funciones estadísticas
� Read Committed� Puede ver cambios comprometidos de otrastransacciones
� No hay lectura sucia, pero es posible la lectura no-repetible
� Aceptable para consultas o soporte a las decisiones� Repeatable Read
� No hay lectura sucia ni no-repetible� Puede exhibir el fenómeno ‘fantasma’
� Serializable
BASES DE DATOS I
43
Implementación de Niveles de Aislamiento
� Read Uncommitted� sin S-locks
� Read Committed� S-locks pueden ser levantados en cualquiermomento
� X-locks con el P2F estricto� Repeatable Read
� P2F estricto sobre todos los datos� Serializable
� P2F estricto sobre todos los datos e índices
BASES DE DATOS I
44
BASES DE DATOS I
o 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 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.
Tuplas Fantasma
45
BASES DE DATOS I
o Cuando se actualiza una relación (archivo) �actualización de los índices asociados
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!!
Locks en Índices
46
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
47
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
48
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.
BASES DE DATOS I
49
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, sila operación es posible.
BASES DE DATOS I
50
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 unatransacció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 timestampActualización física no puede ejecutarse (por conflicto)
� no se ejecuta ninguna de las operaciones de la transacción (atomicidad)� reinicio � no requiererollback pues no hay datos físicamente actualizados.
BASES DE DATOS I
51
� El sistema debe conocer, para cada ítem de dato, la marca de tiempo de la transacción másjoven que leyó o actualizó el ítem � valores de sincronización.
� r(X) - timestamp de la transacción más jovenque ejecutó read(X)
� w(X) - timestamp de la transacción más jovenque ejecutó write(X)
BASES DE DATOS I
Plan de Ejecución basado en Marcas de Tiempo
52
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: Mecanismo
53
BASES DE DATOS I
Marcas de Tiempo: Act. Perdida RevisitadotiempoTransacción A Transacción B
t1
t2
t3
t4
Leer X
Actualizar X
Leer X
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.