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

15

Granularidad

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

42

Niveles de aislamiento

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.

54

BASES DE DATOS I

Bibliografía

Date, C.: “An Introduction to Database Systems”. 7º edición. AddisonWesley. 2000.

Elmasri, R., Navathe, S.: “Fundamentals of Database Systems”. Addison Wesley. 2004.

Silberschatz, A., Korth, H, Sudarshan, S.: “Database SystemConcepts”. McGraw Hill. 2001.