de Transacciones Administracion

Base de Datos II

Monica Caniupan
mcaniupa@ubiobio.cl
Universidad del B o-B o

Octubre 2013

Transacciones

concurrente y la Las transacciones son el fundamento de la ejecucion de un fallo del sistema en un SGBD recuperacion se dene como cualquier Una transaccion Un SGBD tiene entrelaza las acciones de varias transacciones concurrente de El SGBD debe garantizar que el resultado de una ejecucion transacciones sea equivalente (en su efecto sobre la BD) a alguna ejecucion secuencial

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

2 / 42

Propiedades de las Transacciones

es una serie de Desde el punto de vista de un SGBD, una transaccion operaciones de escritura y lectura a la BD Un SGBD debe garantizar cuatro propiedades:
1

2 3

de cada transaccion es atomica: La ejecucion o se realizan todas las acciones o no se realiza ninguna Consistencia: las transacciones deben preservar la consistencia de la BD aisladas, o protegidas, de los efectos de otras Aislamiento: las transacciones estan transacciones naliza exitosamente, sus efectos deben persistir Durabilidad: si la transaccion incluso si se produce una ca da del sistema

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

3 / 42

 Acciones de una Transaccion

son: lectura y escritura de Las acciones que puede ejecutar una transaccion objetos de la BD
t Rt (O ) denota lectura del objeto O por la transaccion Wt (O ) denota escritura de O por t debe indicar como ultima Cada transaccion accion:
termina satisfactoriamente, o commit (comprometer): indica que la transaccion termina pero se deshacen los cambios abort (abortar): indica que la transaccion realizados a la BD

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

4 / 42

Planes

(planicacion) es una lista de acciones (lectura, escritura, Un plan de ejecucion comprometer o abortar) de un conjunto de transacciones T aparecen en un plan debe El orden en el cual dos acciones de una transaccion ser el mismo orden en el que aparecen en T

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

5 / 42

Ejemplo: Plan
Consideremos los siguientes planes:
Plan no serial T1 T2 R (A ) W (A) R (B ) W (B ) R (C ) W (C ) commit T1 commit T2 Serial: T1 T2 T1 T2 R (A) W (A) R (C ) W (C ) commit T1 R (B ) W (B ) commit T2

Si las acciones de diferentes transacciones no son intercaladas, i.e. las transacciones son ejecutadas de inicio a n, una por una, el plan se denomina plan serial Para el ejemplo existen dos posibles planes seriales: T1 T2 y T2 T1

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

6 / 42

 Concurrente de Transacciones Ejecucion

Los SGBD entrelazan las acciones de distintas transacciones para mejorar el rendimiento
necesita leer desde disco, el SGBD podr Si una transaccion a empezar a procesar otra transaccion

Surge entonces el concepto de planes serializables Un plan serializable sobre un conjunto S de transacciones que comprometen los cambios, es un plan cuyo efecto sobre cualquier instancia consistente de la BD se secuencial sobre S garantiza identico al de alguna planicacion

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

7 / 42

Ejemplo: Planes Serializables

Los siguientes planes son serializables, el primero produce el mismo efecto que ejecutar T1 T2 , el segundo es equivalente a T2 T1
T1 R (A ) W (A) T2 T1 T2 R (A) W (A) R (B ) W (B ) W (A) R (B ) W (B ) commit T2 commit T1

R (A) W (A) R (B ) W (B ) R (B ) W (B ) commit T2 commit T1

R (A)

Las ejecuciones secuenciales pueden producir distintos resultados, pero todos se de ellos sera el resultado de una suponen aceptables; el SGBD no garantiza cual entrelazada ejecucion

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

8 / 42

Problemas al Intercalar Transacciones

Dos acciones sobre el mismo objeto de la BD presentan conicto si por lo menos una de las acciones es una escritura Existen tres tipos de conictos entre dos transacciones T1 y T2 :
1 2 3

Conicto de escritura-lectura (WR) o lectura de datos no comprometidos Conicto de lectura-escritura (RW) o lecturas no repetidas Conicto de escritura-escritura (WW) o sobre-escritura de datos no comprometidos

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

9 / 42

(1) Conicto de escritura-lectura (WR)

El principal problema de WR es la lectura de datos no comprometidos, i.e. T2 lee un objeto que fue modicado por T1 , pero que aun no ha sido comprometido En tal caso, la lectura es conocida como lectura sucia

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

10 / 42

Ejemplo: Lectura Sucia

Consideremos las transacciones T1 y T2 :
T1 transere 100 desde la cuenta A a la B T2 incrementa A y B por el 10 %

Supongamos los valores iniciales A = 1000 y B = 500

T1 R (A), A=1000 W (A), A=900 T2 Este plan produce los valores A = 990 y B = 650 T1 T2 produce los valores A = 990 y B = 660 T2 T1 produce A = 1000 y B = 650 El problema es que T2 lee el valor de A modicado por T1 pero que no ha sido comprometido

R (A), A=900 W (A), A=990 R (B ), B=500 W (B ), B=550 commit T2 R (B )= 550 W (B )= 650 commit T1

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

11 / 42

Conicto de escritura-lectura (WR)

aun, Mas a escribir algun T1 podr valor para A que hace la BD inconsistente Es importante que T1 vuelva a escribir un valor correcto para A antes que T2 lea A se produce si las transacciones son ejecutadas de manera serial, ya Ningun dano tal inconsistencia que T2 no vera puede dejar la base de datos inconsistente por un per Una transaccion odo de la BD debe quedar en un tiempo, pero una vez comprometida la transaccion, estado consistente

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

12 / 42

(2) Conicto de lectura-escritura (RW)

El principal problema de lectura-escritura es la lectura no repetida de datos, i.e. T1 , mientras T2 modica el valor de un objeto A que es le do por una transaccion aun T1 esta en progreso diferente Si T1 vuelve a leer A, el valor sera Consideremos las transacciones T1 y T2 , y sea A el numero de copias disponibles de un libro
T1 lee A = 1 T2 lee A = 1, resta 1 y compromete (A=0) T1 trata de restar 1 a A y recibe un error, A ya no tiene el valor 1!

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

13 / 42

(3) Conicto de escritura-escritura (WW)

T2 sobre-escribe el valor de un objeto A que ya ha sido modicado por una T1 , mientras T1 todav en progreso transaccion a esta Este problema se conoce como sobre-escritura de datos no comprometidos Supongamos que los salario de Pedro y Juan deben ser iguales
T1 asigna salarios iguales a 2000 T2 asigna salarios iguales a 1000

El plan T1 T2 asigna salarios iguales a 1000, T2 T1 asigna salarios iguales a 2000

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

14 / 42

Conicto de escritura-escritura (WW)

intercalada: Supongamos la siguiente ejecucion T1 W (Juan), Salario=2000 W (Juan), Salario=1000 commit T2 W (Pedro), Salario=2000 commit T1 El plan no produce salarios iguales para Juan y Pedro Por lo tanto este plan no es serializable T2 W (Pedro), Salario=1000

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

15 / 42

Planes con Abort

aborta, todas las acciones son deshechas y la BD Cuando una transaccion vuelve al estado inicial Un plan serializable sobre un conjunto de transacciones S es un plan cuyo efecto serial sobre el sobre cualquier BD consistente es identico a alguna ejecucion conjunto de transacciones comprometidas en S de plan serializable asume que las transacciones que abortan Esta denicion deben ser completamente deshechas, lo cual puede ser imposible en algunas situaciones

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

16 / 42

Ejemplo: Planes con Abort

Consideremos las transacciones T1 y T2 :
T1 transere 100 desde la cuenta A a la B T2 incrementa A y B por el 10 %

Supongamos los valores iniciales A = 1000 y B = 500

T1 R (A), A=1000 W (A), A=900 T2

R (A), A=900 W (A), A=990 R (B ), B=500 W (B ), B=550 commit T2 abort T1

T2 ha le do un valor de A que no deber a haber estado nunca ah Si T2 no comprometiera antes que T1 aborta, podr amos tratar la situacion propagando el aborto de T1 en cascada y abortar T2 y sus acciones no pueden ser deshechas! Este plan no Pero T2 ya comprometio es recuperable
Base de Datos II (Universidad del B o-B o) Transacciones Octubre 2013 17 / 42

Planes Recuperables

despues de que En un plan recuperable las transacciones se comprometen solo se comprometen todas las transacciones de las cuales se han le do cambios Si las transacciones leen solamente los cambios de transacciones es recuperable, sino que puede abortar una comprometidas, el plan no solo sin abortar otras transacciones en cascada (planes que evitan transaccion abortos en cascada)

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

18 / 42

Planes Conicto Equivalentes

Dos planes son conicto equivalentes si:

Involucran el mismo conjunto de acciones de las mismas transacciones, y Ordenan cada par de acciones conictivas de dos transacciones que comprometen de la misma manera

en conicto si operan sobre el mismo objeto y al menos una Dos acciones estan de ellas es escritura Podemos cambiar el orden de acciones que no son conictivas sin alterar el efecto del plan sobre la BD Si dos planes son conicto equivalentes, tienen el mismo efecto sobre la BD Un plan es conicto serializable si es conicto equivalente con algun plan serial Todo plan conicto equivalente es serializable

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

19 / 42

Ejemplo: Planes Conicto Equivalentes

Consideremos el siguiente plan: R1 (x ), R2 (y ), W3 (x ), R2 (x ), R1 (y ) Las operaciones pueden ser re-ordenadas de la siguiente manera:
Las lecturas de T1 pueden ser ejecutadas en el siguiente orden: R1 (x ), R1 (y ), R2 (y ), W3 (x ), R2 (x ) La lectura de T2 se puede reordenar de la siguiente forma: R1 (x ), R1 (y ), W3 (x ), R2 (y ), R2 (x ) serial T1 -T3 -T2 , y como consecuencia El plan es conicto equivalente a la ejecucion el plan es serializable

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

20 / 42

Ejemplo: Planes Conicto Equivalentes

Consideremos el siguiente plan: R2 (y ), R1 (x ), R3 (y ), R2 (x ), W2 (y ), W1 (x ), R3 (x ) Podemos reordenar las operaciones de la siguiente manera:

La lectura de T1 puede ser localizada junto con la escritura de T1 R2 (y ), R3 (y ), R2 (x ), W2 (y ), R1 (x ), W1 (x ),R3 (x ) Luego, las operaciones de T2 se reordenan de la siguiente forma: R3 (y ), R2 (y ), R2 (x ), W2 (y ), R1 (x ), W1 (x ), R3 (x ) Sin embargo, no podemos mover R3 (y ) ni R3 (x ) sin causar conictos, por lo tanto serial de las transacciones este plan no es conicto equivalente a ninguna ejecucion

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

21 / 42

Grafos de Precedencia

Es posible capturar los potenciales conictos entre transacciones de un plan en un grafo de precedencia El grafo de precedencia G (S ) para un plan S se construye de la siguiente manera:
que compromete en S es un nodo en G (S ) Cada transaccion de Ti precede y es conictiva con alguna Existe un arco desde Ti a Tj si una accion de Tj accion

Un plan S es conicto serializable s y solo s su grafo de precedencia es ac clico (no contiene ciclos)

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

22 / 42

Ejemplo: Grafo de Precedencia

El siguiente plan no es conicto equivalente. Su grafo de precedencia G (S ) contiene ciclos:
T1 R (A) T2 W (A) commit T2 W (A) commit T1 W (A) commit T3 T3

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

23 / 42

Control de Concurrencia Basado en Bloqueos

de planes que son serializables y Un SGBD solo debe permitir la ejecucion recuperables Para ello, el SGBD utiliza un protocolo de bloqueos Tenemos dos tipos de bloqueos (candados):
Exclusivos X Compartidos S (shared)

usado se denomina bloqueo exclusivo de dos fases El protocolo de bloqueo mas (2PL exclusivo)

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

24 / 42

Bloqueo Exclusivo de Dos Fases

El protocolo 2PL exclusivo (estricto) tiene dos reglas:

1

T quiere leer (respectivamente, modicar) un objeto, primero Si una transaccion solicita un candado (bloqueo) compartido (respectivamente, exclusivo) sobre el objeto se liberan cuando la Todos los candados (bloqueos) concedidos a una transaccion se completa transaccion

tiene un candado exclusivo sobre un objeto, Obviamente, si una transaccion puede leer el objeto tambien que requiere un candado es suspendida hasta que el SGBD Una transaccion pueda otorgar el candado

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

25 / 42

Bloqueo Exclusivo de Dos Fases

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

26 / 42

Bloqueo Exclusivo de Dos Fases

tiene un candado exclusivo sobre un objeto, no puede haber Si una transaccion con un candado exclusivo o compartido sobre el objeto otra transaccion La siguiente tabla resume la entrega de candados: X S X NO NO S NO SI

El protocolo 2PL estricto permite que solo los planes seguros sean ejecutados y asegura que el grafo de precedencia de cualquier plan permitido sea ac clico T sobre ST (O ) denota la solicitud de un candado compartido por la transaccion el objeto O (XT (O ), respectivamente para candado exclusivo)

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

27 / 42

Ejemplo: Protocolo 2PL Estricto

Consideremos las transacciones T1 y T2 :
T1 transere 100 desde la cuenta A a la B T2 incrementa A y B por el 10 %

Con valores iniciales de A = 1000 y B = 500 permitido por el protocolo 2PL estricto: El siguiente plan no esta
T1 R (A), A=1000 W (A), A=900 T2

R (A), A=900 W (A), A=990 R (B ), B=500 W (B ), B=550 commit T2 R (B )= 550 W (B )= 650 commit T1

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

28 / 42

Ejemplo: Protocolo 2PL Estricto

Con el protocolo 2PL estricto el plan se ejecuta de la siguiente manera:
T1 X (A) R (A), A=1000 W (A), A=900 X (B ) R (B )= 500 W (B )= 600 commit T1 T2

X (A) R (A), A=900 W (A), A=990 X (B ) R (B ), B=600 W (B ), B=660 commit T2

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

29 / 42

Ejemplo: Protocolo 2PL Estricto

permite la ejecucion de transacciones El protocolo 2PL estricto tambien intercaladas:

T1 S (A) R (A) T2

S (A) R (A) X (B ) R (B ) W (B ) commit T2 X (C ) R (C ) W (C ) commit T1

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

30 / 42

Protocolo 2PL

Existe una variante del protocolo 2PL estricto llamado 2PL que relaja la segunda regla del protocolo 2PL estricto puede entregar sus candados antes del nal de la En 2PL una transaccion (antes de commit o abort) transaccion no puede pedir candados En 2PL la segunda regla es: Una transaccion adicionales una vez que empieza a devolver sus candados El protocolo 2PL asegura que los grafos de dependencias de los planes sean ac clicos y por lo tanto solo permite planes conicto serializables

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

31 / 42

Protocolo 2PL

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

32 / 42

Ejemplo: Protocolo 2PL

Un plan aceptado por 2PL pero no por 2PL estricto:
T1 X (A) R (A) W (A) X (B ) libera X (A) T2

X (A ) R (A) W (A) X (C ) W (C ) libera X (A) libera X (C ) commit T2 W (B ) libera X (B ) commit T1

Base de Datos II (Universidad del B o-B o) Transacciones Octubre 2013 33 / 42

Soporte de Transacciones en SQL

es inicializada cada vez que un usuario ejecuta una En SQL una transaccion sentencia SELECT, UPDATE, o CREATE TABLE permite bloquear objetos con diferentes niveles de granularidad, SQL tambien e.g. tuplas en vez de tablas T1 (en SQL): Supongamos la siguiente transaccion

SELECT MIN(edad) FROM Navegantes WHERE categoria = 8

objetos deber Que an ser bloqueados?

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

34 / 42

Soporte de Transacciones en SQL

Supongamos que SQL permite bloquear todas las tuplas que satisfacen la categoria= 8. Esto no previene que otra transaccion T2 inserte una condicion nueva tupla que satisfaga la condicion Entonces, si T1 selecciona nuevamente las tuplas con categor a igual a 8 el diferente resultado sera ejecuta Tal problema se denomina problema fantasma, en donde una transaccion una consulta dos veces y obtiene diferentes conjuntos de tuplas, a pesar de no haber modicado las tuplas Para prevenir este problema el SGBD debe bloquear todas las posibles tuplas T1 , entonces, la solucion en este que podr an estar involucradas en la transaccion caso es bloquear toda la tabla, pagando el costo de concurrencia

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

35 / 42

Soporte de Transacciones en SQL

SQL permite elegir algunos niveles de aislamiento:

READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE

Con los siguientes efectos sobre las transacciones:

Nivel READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE Lectura sucia es posible NO NO NO Lectura no repetida es posible es posible NO NO P. Fantasma es posible es posible es posible NO

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

36 / 42

Interbloqueos

Supongamos la siguiente situacion:

T1 X (A) R (A) W (A) T2

X (B ) R (B ) W (B ) Solicita X (B ) Solicita X (A)

Estos ciclos entre transacciones se denominan interbloqueos El SGBD debe prevenir o detectar (y resolver) estas situaciones

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

37 / 42

Interbloqueos

Una forma usual de resolver los interbloqueos es usando un mecanismo de ha esperado un candado por mucho tiempo, se tiempos, i.e., si una transaccion se aborta asume que ha ocurrido un interbloqueo y la transaccion En la practica menos del 1 % de las transacciones se ve involucrada en un interbloqueo Los interbloqueos pueden prevenirse:
Bloqueando partes de los objetos, e.g. tuplas en vez de tablas completas puede mantener un candado Reduciendo el tiempo en que una transaccion Reduciendo la cantidad de objetos que son le dos y modicados

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

38 / 42

 de Interbloqueos Deteccion

El administrador de candados en un SGBD es el encargado de administrar los permisos sobre objetos de la BD El administrador mantiene un grafo de esperas G (T ) para detectar interbloqueos que se construye de la siguiente manera:
activa es un nodo en G (T ) Cada transaccion esperando que Tj libere un candado Existe un arco desde Ti a Tj s y solo s Ti esta

pide un El administrador agrega arcos al grafo cada vez que una transaccion candado y elimina los arcos cuando las transacciones obtienen los candados

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

39 / 42

 de Interbloqueos Ejemplo: Deteccion

Supongamos la siguiente situacion:
T1 S (A) R (A) T2 T3 T4

X (B ) W (B ) S (B ) S (C ) R (C ) X (C ) X (B ) X (A)

del interbloqueo: El Grafo G (T ) antes y despues

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

40 / 42

 de Interbloqueos Solucion

El problema se resuelve abortando una de las transacciones involucradas en el ciclo y liberando todos sus candados de la transaccion a abortar puede realizarse en base a varios La eleccion criterios:
1 2 3 4

que posee menos candados La transaccion que ha avanzado menos en su ejecucion La transaccion que dista mucho de su nalizacion La transaccion etc.

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

41 / 42

 de Interbloqueos Prevencion

un nivel de prioridad Se le otorga a cada transaccion Ti requiere un candado para el objeto A y una transaccion Tj Si una transaccion mantiene un candado conictivo para A el administrador de candados puede seguir cualquiera de las siguientes pol ticas:
1

Si Ti tiene mayor prioridad que Tj , entonces Ti espera a que Tj libere el candado. En caso contrario, Ti aborta Si Ti tiene mayor prioridad que Tj , entonces Tj se aborta. En caso contrario, Ti espera

Base de Datos II (Universidad del B o-B o)

Transacciones

Octubre 2013

42 / 42