Jos Rodrguez 2005-0444 Darwin Ruiz 2004-1102 Base de Datos Prof.

Patricia Rodrguez

Transacciones Las transacciones son el fundamento de la ejecucin concurrente y la recuperacin de un fallo del sistema en un SGBD Una transaccin se dene como cualquier ejecucin de un programa de usuario en un SGBD Una transaccin diere de una ejecucin de un programa fuera del SGBD (por ejemplo, de un programa en C ejecutndose sobre UNIX) Por motivos de rendimiento, un SGBD tiene que entrelazar las acciones de varias transacciones El SGBD debe garantizar que el resultado de una ejecucin concurrente de transacciones sea equivalente (en su efecto sobre la BD) a alguna ejecucin secuencial

Propiedades de las Transacciones Desde el punto de vista de un SGBD, una transaccin es una serie de operaciones de escritura y lectura a la BD Un SGBD debe garantizar cuatro propiedades: 1. La ejecucin de cada transaccin es atmica: o se realizan todas las acciones o no se realiza ninguna 2. Consistencia: las transacciones deben preservar la consistencia de la BD 3. Aislamiento: las transacciones estn aisladas, o protegidas, de los efectos de otras transacciones 4. Durabilidad: si la transaccin naliza exitosamente, sus efectos deben persistir incluso si se produce una cada del sistema

Acciones de una Transaccin Las acciones que puede ejecutar una transaccin son: lectura y escritura de objetos de la BD Rt (O) denota lectura del objeto O por transaccin t Wt (O) denota escritura de O por t Cada transaccin debe indicar como ltima accin commit (comprometer), que indica que la transaccin est terminada satisfactoriamente Abort (abortar), que indica que la transaccin est terminada y deshechos los cambios realizados en la BD

Plane s Un plan de ejecucin (planicacin) es una lista de acciones (lectura, escritura, comprometer o abortar) de un conjunto de transacciones El orden en el cual dos acciones de una transaccin T aparecen en un plan debe ser el mismo orden que el orden en el que aparecen en T

Ejemplo:

Plan no serial T T 1 2 R(A) W (A) R(B) W (B) R(C) W (C) commit T1

Serial: T1 T2 T T 1 2 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, commit T2 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 o T2 T 1

Ejecucin Concurrente de Transacciones Los SGBD entrelazan las acciones de distintas transacciones para mejorar el rendimiento Si una transaccin necesita leer desde disco, el SGBD podra empezar a procesar otra transaccin Surge entonces el concepto de planes serializables (planicacin secuenciable) 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 es idntico al de alguna planicacin secuencial sobre S

Ejemplo: Los siguientes planes son serializables, el primero produce el mismo efecto que ejecutar T1 T2 , el segundo es equivalente a T2 T1

T 1 R(A) W (A)

T
2

T
1

T 2 R(A) W (A)

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

R(A) R(B) W (B) W (A) R(B) W (B)

commit T1 Las ejecuciones secuenciales pueden producir distintos commit T2 resultados, pero todos se suponen aceptables; el SGBD no garantiza1 cul de ellos ser el resultado de una commit T ejecucin entrelazada

Problemas al Intercalar Transacciones Dos acciones sobre el mismo objeto de la BD entrn en conicto si por lo menos una de las acciones es una escritura Existen tres tipos de conictos entre dos transacciones T1 y T2 : 1. Conicto de escritura-lectura (WR), o lectura de datos no comprometidos 2. Conicto de lectura-escritura (RW), o lecturas no repetidas 3. Conicto de escritura-escritura (WW), o sobreescritura de datos no comprometidos

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 an no ha sido comprometido Tal lectura es conocida como lectura sucia

Ejemplo: Considere 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 T
2

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 no 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

Ms an, T1 podra escribir algn 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 Ningn dao se produce si las transacciones son ejecutadas de manera serial, ya que T2 no va a ver tal inconsistencia Una transaccin puede dejar la base de datos inconsistente por un perodo de tiempo, pero una vez comprometida la transaccin, la BD debe quedar en un estado consistente

Conicto de lectura-escritura (RW) El principal problema de RW es la lectura no repetida de datos, i.e. T2 modica el valor de un objeto A que es ledo por una T1 , mientras T1 est an en progreso Si T1 vuelve a leer A, el valor ser diferente Ejemplo: Considere las transacciones T1 y T2 , y sea A el nmero 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!

Conicto de escritura-escritura (WW) T2 sobreescribe el valor de un objeto A que ya ha sido modicado por una transaccin T1 , mientras T1 todava est en progreso Este problema se conoce como sobreescritura de datos no comprometidos Ejemplo: Suponga 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

Supongamos la siguiente ejecucin intercalada:

T 1 W (P edro), Salario=1000 W (Juan), Salario=2000 W (Juan), Salario=1000 W (P edro), Salario=2000 commit T1

T
2

commit T2

El plan no produce salarios iguales para Juan y Pedro

Por lo tanto este plan no es serializable

Planes con Abort Cuando una transaccin aborta, todas las acciones son deshechas, y la BD vuelve al estado inicial Un plan serializable sobre un conjunto de transacciones S es un plan cuyo efecto sobre cualquier BD consistente es idntico a alguna ejecucin serial sobre el conjunto de transacciones comprometidas en S. Es decir si para toda transaccin que participan en l, sus operaciones se ejecutan de forma consecutiva. Esta denicin de plan serializable asume que las transacciones que abortan deben ser completamente deshechas, lo cual puede ser imposible en algunas situaciones

Ejemplo: Considere 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
T R(A), A=1000 W (A), A=900 R(A), A=900 W (A), A=990 R(B), B=500 W (B), B=550 commit T2 abort T1
1

T
2

T2 ha ledo un valor de A que no debera haber estado nunca ah

Si T2 no comprometiera antes que T1 abortara, podramos tratar la situacin propagando el aborto de T1 en cascada y abortar tambin T2 Pero T2 ya comprometi y sus acciones no pueden ser deshechas! Este plan no es recuperable En un plan recuperable las transacciones se comprometen slo despus de que se comprometan a su vez todas las transacciones que hayan ledo sus cambios. Es decir, si existe al menos una transaccin T en P que lee de una transaccin T` y que se compromete antes de haberse comprometido la transaccin T` . Si las transacciones leen solamente los cambios de transacciones comprometidas, el plan no slo es recuperable, sino que puede abortar una transaccin sin abortar otras transacciones en cascada (planes que evitan abortos en cascada)

Planes Conicto Equivalentes Dos planes son conicto equivalentes si el orden de todas las operaciones en conicto es el mismo en ambos planes. Dos acciones estn en conicto si operan sobre el mismo objeto y al menos una 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 algn plan serial

Todo plan conicto equivalente es serializable

Ejemplo: El siguiente plan produce el mismo efecto que ejecutar T T T T1 T2 T3 pero no1 es conicto equivalente a T1 T2 T3 2 3 R(A)
W (A) commit T2 W (A) commit T1 W (A) commit T3

Las operaciones de escritura de T1 y T2 aparecen en diferente orden y no pueden ser reordenadas

Considere 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: 1. 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) 2. Luego, las operaciones de T2 se reordenan de la siguiente forma: R3 (y), R2 (x), R2 (y), W2 (y), R1 (x), W1 (x), R3 (x) 3. Sin embargo, no podemos mover R3 (y) ni R3 (x), por lo tanto este plan no es conicto equivalente a ninguna ejecucin serial de las transacciones

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

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: Cada transaccin que compromete en S es un nodo en G(S) Existe un arco desde Ti a Tj si una accin de Ti precede y es conictiva con alguna accin de Tj Un plan S es conicto serializable s y solo s su grafo de precedencia es acclico (no contiene ciclos)

Ejemplo: El siguiente plan no es conicto equivalente porque existe un ciclo en G(S)

T 1 R(A) W (A) commit T2 W (A) commit T1 W (A) commit T3

T
2

T
3

Control de Concurrencia Basado en Bloqueos Un SGBD solo debe permitir la ejecucin de planes que son serializables y recuperables Para ello, el SGBD utiliza un protocolo de bloqueos Tenemos dos tipos de bloqueos (candados): 1. Exclusivos X 2. Compartidos S (shared) El protocolo de bloqueo ms usado se denomina bloqueo exclusivo de dos fases (2PL estricto)

Bloqueo Exclusivo de Dos Fases El protocolo 2PL exclusivo (estricto) tiene dos reglas: 1. Si una transaccin T quiere leer (respectivamente, modicar) un objeto, primero solicita un bloqueo compartido (respectivamente, exclusivo) sobre el objeto 2. Todos los bloqueos concedidos a una transaccin se liberan cuando la transaccin se completa Obviamente, si una transaccin tiene un bloqueo exclusivo sobre un objeto, tambin puede leer el objeto Una transaccin que requiere un bloqueo es suspendida hasta que el SGBD pueda otorgar el candado

Si una transaccin tiene un candado exclusivo sobre un objeto, no puede haber otra transaccin con un candado exclusivo o compartido sobre el objeto

La siguiente tabla resume la entrega de candados: X S X NO NO S NO SI

El protocolo 2PL estricto permite que solo planes seguros sean ejecutados

ST (O) denota la solicitud de un candado compartido por la transaccin T sobre el objeto O (XT (O), respectivamente para candado exclusivo)

Ejemplo: Considere 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, el siguiente plan no est permitido por el protocolo 2PL estricto:
T 1 R(A), A=1000 W (A), A=900 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 T
2

Con el protocolo 2PL estricto el plan se ejecuta de la siguiente manera:

T X(A) 1 R(A), A=1000 W (A), A=900 X(B) R(B)= 500 W (B)= 600 commit T1 X(A) R(A), A=900 W (A), A=990 X(B) R(B), B=600 W (B), B=660 commit T2

T
2

El protocolo 2PL estricto asegura que el grafo de precedencia de cualquier plan permitido sea acclico Existe una variante al 2PL estricto llamado 2PL que relaja la segunda regla del 2PL estricto

Protocolo 2PL En 2PL una transaccin puede entregar sus candados antes del nal de la transaccin (antes de commit o abort) En 2PL la segunda regla es: Una transaccin no puede pedir candados adicionales una vez que empieza a devolver sus candados El protocolo 2PL asegura que los grafos de dependencias de los planes son acclicos y por lo tanto solo permite planes conicto serializables

Ejemplo: Un plan aceptado por 2PL pero no por 2PL estricto:

T X(A) 1 R(A) W (A) X(B) libera X(A) 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

T
2

Soporte de Transacciones en SQL En SQL una transaccin es inicializada cada vez que un usuario ejecuta un SELECT, UPDATE, o CREATE TABLE SQL tambin permite bloquear objetos con diferentes niveles de granularidad, e.g. tuplas en vez de tablas Ejemplo: Supongamos la siguiente transaccin T1 (en SQL): SELECT N.nivel, MIN(N.edad) FROM Navegantes N WHERE N.nivel = 8 Qu objetos deberan ser bloqueados?

Supongamos que SQL permite bloquear todas las tuplas que satisfacen la condicin N.nivel = 8. Esto no previene que otra transaccin T2 inserte una nueva tupla que satisfaga la condicin Entonces, si T1 selecciona nuevamente las tuplas con N.nivel = 8 el resultado ser diferente Tal problema se denomina problema fantasma, en donde una transaccin ejecuta 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 que podran estar involucradas en la transaccin T1 , entonces, la solucin en este caso es bloquear toda la tabla, pagando el costo de concurrencia

SQL permite elegir algunos niveles de aislamiento:

1. READ UNCOMMITTED 2. READ COMMITTED 3. REPEATABLE READ 4. 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 repetible es posible es posible NO NO Fantasma es posible es posible es posible NO

Interbloqueos

Ejemplo: Supongamos la siguiente situacin:

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

T
2

Este tipo de ciclos de transacciones se denomina interbloqueos

El SGBD debe prevenir o detectar (y resolver) estas situaciones

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

El problema se resuelve abortando una de las transacciones involucradas en el ciclo y liberando todos sus candados La eleccin de la transaccin a abortar puede realizarse en base a varios criterios: 1. La transaccin que posee menos candados 2. La transaccin que ha avanzado menos en su ejecucin 3. La transaccin que dista mucho de su nalizacin

Mecanismos de Recuperacin

Protocolo de bitcora adelantada Recuperacin a fallas en el sistema Recuperacin a fallas en los medios de almacenamiento

Base de Datos Prof. Patricia Rodrguez