Transacciones

Bases de Datos
Andrea Rodrı́guez
Transacciones
M. Andrea Rodrı́guez-Tastets
Universidad de Concepción,Chile
www.inf.udec.cl\ ∼andrea
[email protected]
II Semestre - 2014
Bases de Datos
Andrea Rodrı́guez
Objetivos de la Unidad
Entender el concepto de transacciones.
Bases de Datos
Andrea Rodrı́guez
Transacciones
I
Una transacción es una unidad lógica de procesamiento de la
base de datos que incluye una o más operaciones de acceso a
la base de datos
I
Se distinguien transacciones solo de lectura a la base de
datos o transacciones de actualización, es decir, leer, cambiar
y escribir un elementos a la base de datos.
I
Las transacciones pueden delimitarse con sentencias
explı́citas begin transaction and end transaction
Bases de Datos
Andrea Rodrı́guez
Transacciones (cont.)
I
Asumimos que una base de datos es modelada en forma
simplificada como una colección de elementos de datos con
nombre (registro, bloque en disco, páginas..)
I
Las operaciones básicas son: Leer elemento(X) y
Escribir elemento(X)
Bases de Datos
Andrea Rodrı́guez
Transacciones (cont.)
Leer elemento(X):
I
Encontrar la dirección del bloque de disco que contiene el
elemento X.
I
Copiar ese bloque de disco en un almacenamiento intermedio
(buffer) dentro de la memoria principal (si es que ese bloque
no está ya en algún buffer de la memoria principal).
I
Copiar el elemento X del almacenamiento intermedio en la
variable de programa X.
Bases de Datos
Andrea Rodrı́guez
Transacciones (cont.)
Escribir elemento(X):
I
Encontrar la dirección del bloque de disco que contiene el
elemento X.
I
Copiar ese bloque de disco en un almacenamiento intermedio
(buffer) dentro de la memoria principal (si es que ese bloque
no está ya en algún buffer de la memoria principal).
I
Copiar el elemento X desde la variable del programa X en el
lugar correcto dentro del búfer.
I
Almacenar el bloque actualizado desde el búfer al disco.
Bases de Datos
Andrea Rodrı́guez
Concurrencia
I
En sistemas multiusuario, es necesario un mecanismo para
controlar la concurrencia. Se pueden producir inconsistencias
importantes derivadas del acceso concurrente (3 problemas).
I
Las transacciones de los usuarios se podrı́an ejecutar de
manera concurrente y podrı́an acceder y actualizar los
mismos elementos de la BD.
Bases de Datos
Andrea Rodrı́guez
Control de concurrencia
I
Problemas: (i) actualización perdida, (ii) actualización
temporal (lectura sucia) and (iii) resumen incorrecto (iv)
lectura no repetible (v) fantasmas.
I
Ejemplo: Sistema de BD de reservas en una lı́nea área.
Transacción T1: transfiere N reservas de un vuelo, cuyo
número de asientos reservados está almacenado en el
elemento de la BD llamado X, a otro vuelo, cuyo número de
asientos reservados está almacenado en el elemento de la BD
llamado Y. Transacción T2: agrega un número de asientos al
vuelo con asientos reservados guardados en elemento X.
Bases de Datos
Actualización perdida
Andrea Rodrı́guez
I
Esto ocurre cuando las transacciones que tienen acceso a los
mismos elementos de la BD tienen sus operaciones
intercaladas de modo que hacen incorrecto el valor de algún
elemento.
I
T1 y T2 se introducen al mismo tiempo y sus operaciones se
intercalan.
T1
R(X)
X=X-N
T2
R(X)
X=X+N
W(X)
R(Y)
W(X)
Y=Y+N
W(Y)
Bases de Datos
Andrea Rodrı́guez
Actualización perdida (cont.)
I
El valor final del elemento X es incorrecto, porque T2 lee el
valor de X ANTES de que T1 lo modifique en la BD, con lo
que se pierde el valor actualizado que resulta de T1.
I
Si X=80 al principio, N=5 (T1 transfiere 5 reservas de
asientos del vuelo que corresponde a X al vuelo que
corresponde a Y) y M=4 (T2 reserva 4 asientos en X), el
resultado final debera ser X=79, pero es X=84, porque la
actualizacin de T1 que eliminó 5 asientos de X se ha perdido.
Bases de Datos
Andrea Rodrı́guez
Actualización temporal
I
Esto ocurre cuando una transacción actualiza un elemento de
la BD y luego la transacción falla por alguna razón. Otra
transacción tiene acceso al elemento actualizado antes de
que se restaure a su valor original.
I
T1 actualiza el elemento X y después falla antes de
completarse, ası́ que el sistema debe cambiar X otra vez a su
valor original.
I
Antes de que pueda hacerlo, la transacción T2 lee el valor
“temporal” de X, que no se grabará permanentemente en la
BD debido al fallo de T1.
I
El valor que T2 lee de X se llama dato sucio, porque fue
creado por una transacción que no se ha completado ni
confirmado todavı́ a.
Bases de Datos
Andrea Rodrı́guez
Actualización temporal (cont.)
T1
R(X)
X=X-N
W(X)
T2
R(X)
X=X+N
W(X)
R(Y)
T1 falla y debe restaurar X a su antiguo valor, mientras tanto T2
ha leı́do el valor temporal incorrecto de X.
Resumen incorrecto
Si una transacción está calculando una función agregada de
resumen sobre varios registros mientras otras transacciones están
actualizando algunos de ellos, puede ser que la función agregada
calcule algunos valores antes de que se actualicen y otros después
de actualizarse.
T1
T2
Sum = 0
R(A)
Sum = Sum+A
R(X)
X = X-N
W(X)
R(X)
Sum= Sum+X
R(Y)
Sum = Sum+Y
R(Y)
Y=Y+N
W(Y)
T2 lee X después de restarle N a X y lee Y antes de sumárle N,
ası́ que el resultado es un resumen incorrecto (discrepancia de N)
Bases de Datos
Andrea Rodrı́guez
Bases de Datos
Andrea Rodrı́guez
Lectura no repetible
T1
R(X)
T2
R(X)
W(X)
R(X)
Fantasmas: una lectura de una tupla que no existı́a antes.
Muchas más problemas...
Bases de Datos
Andrea Rodrı́guez
Manejador de Transacciones
Siempre que se introduce una transacción a un SGBD para
ejecutarla, el sistema tiene que asegurarse de que:
I
Todas las operaciones de la transacción se realicen con éxito
y su efecto quede registrado permanentemente en la BD.
I
Que la transacción no tenga efecto alguno sobre la BD ni
sobre otra transacción, si es que no se completa o falla.
Bases de Datos
Tipos de Fallas
I
Caı́da del Sistema: durante la ejecución de la transacción se
produce un error de hardware, software o red.
I
Error de transacción o del sistema: alguna operación de la
transacción puede hacer que ésta falle (overflow) o errores de
lógica.
I
Errores locales o condiciones de excepción, por ejemplo saldo
insuficiente. Esta podrı́a programarse y no ser un tipo de
fallo.
I
Imposición de control de concurrencia: puede suceder que
método de control de concurrencia aborte una transacción o
deadlock (varias transacciones pelean por el mismo recurso).
I
Fallo del disco
I
Catástrofes
Andrea Rodrı́guez
Bases de Datos
Andrea Rodrı́guez
Estado de transacciones
Una transacción es una unidad atómica de trabajo que se realiza
por completo o bien no se efectúa en absoluto
Read/Write
Begin
End
Parcialmente
confirmada
Activa
Abort
Fallida
Commit
Confirmada
Abort
Terminada
Bases de Datos
Estado de transacciones (cont.)
Andrea Rodrı́guez
I
El componente del sistema encargado de lograr la atomicidad
se conoce como administrador de transacciones y las
operaciones COMMIT (comprometer) y ROLLBACK
(retroceder) son la clave de su funcionamiento.
I
La operación COMMIT señala el término exitoso de la
transacción: le dice al administrador de transacciones que se
ha finalizado con éxito una unidad lógica de trabajo, que la
base de datos está o deberı́a estar de nuevo en un estado
consistente y que se pueden comprometer, o hacer
permanentes todas las modificaciones efectuadas por esa
unidad de trabajo.
I
La operación ROLLBACK, en cambio, señala el término no
exitoso de la transacción: le dice al administrador de
transacciones que algo salió mal, que la base de datos podrı́a
estar en un estado inconsistente y que todas las
modificaciones efectuadas hasta el momento por la unidad
lógica de trabajo deben retroceder o anularse.
Bases de Datos
Andrea Rodrı́guez
Caracterı́sticas de las transacciones
I
Atomicidad, en el sentido que hemos especificado
anteriormente: se ejecutan todas las sentencias o ninguna.
I
Preservación de la consistencia: la ejecución de una
transacción deja la BD en un estado consistente.
I
Aislamiento, ya que una transacción no muestra los cambios
que produce hasta que finaliza.
I
Persistencia, ya que una vez que finaliza la transacción con
éxito, sus efectos perduran en la BD.
I
Seriabilidad, en el sentido de que el efecto de ejecutar
transacciones concurrentemente debe ser el mismo que se
producirı́a al ejecutarlas por separado en un orden secuencial
según van entrando en el sistema.
Planes
Bases de Datos
Andrea Rodrı́guez
I
Un plan/planificación P de n transacciones Ti , es la
descripción del orden en que se ejecutan las operaciones de
dichas Ti , manteniendo, para cada Ti , el orden original de
sus operaciones.
I
Un plan secuencial (o en serie) de un conjunto de T es aquel
en el que todas las operaciones de cada Ti se ejecutan en
secuencia sin que se intercale ninguna operación de otra Tj .
I
Todos los planes secuenciales son correctos porque
garantizan las propiedades de una transacción.
I
Los planes secuenciales pueden ser ineficientes: conviene
intercalar operaciones siempre que mantengan las
propiedades de las transacciones.
I
Un plan equivalente: aquel que produce los mismos efectos
en la BD.
I
Plan secuenciable o serializable: aquel que es equivalente a
otro secuencial (también es correcto)
Bases de Datos
Andrea Rodrı́guez
Planes (cont.)
Dos operaciones de un plan están en conflicto si:
I
Pertenecen a distintas transacciones.
I
Tienen acceso al mismo elemento X.
I
Al menos una de las operaciones es W(X).
I
Para el P1 , R1 (X ) y W2 (X ) están en conflicto.
Bases de Datos
Andrea Rodrı́guez
Equivalencia por conflictos
Dos planes P1 y P2 son equivalentes por conflictos si, para todo
par de operaciones en conflicto, ambas operaciones se ejecutan en
el mismo orden en P1 y P2. Si dos operaciones (de dos Ts) no
están en conflicto dentro de un plan, se pueden cambiar de orden.
Esto permite conseguir planes equivalentes más eficientes
(intercalando todo lo posible). Un plan P es secuenciable en
cuanto a conflictos si se puede encontrar un plan secuencial P que
sea equivalente por conflictos al P.
Bases de Datos
Andrea Rodrı́guez
Equivalencia por vista
Dos planes P y P’ son equivalentes por vista si ambos tienen las
mismas Ts y en los dos se cumplen las siguientes condiciones para
los mismos valores, operaciones y transacciones:
I
Si el valor leı́do por cada Ri (X ) de Ti cumple que fue
producido por Wj (X ), o X era el valor inicial del plan P,
entones se ha de cumplir lo mismo en P’ (asegurando que
ambos leen los mismos valores).
I
La operacin Wk (Y ) es la última que escribe Y en el plan P
también lo es en P (asegura que ambos Ps dejan el mismo
estado final en la BD).
Un plan P es secuenciable en cuanto a vistas si se puede encontrar
un plan secuencial P que sea equivalente por vistas al P.
Bases de Datos
Andrea Rodrı́guez
Ejemplo Plan en Serie (Plan A)
T1
R(X)
X=X-N
W(X)
R(Y)
Y = Y+N
W(Y)
T2
R(X)
X=X+M
W(X)
Bases de Datos
Andrea Rodrı́guez
Ejemplo Plan NO en Serie (Plan B)
T1
R(X)
X=X-N
W(X)
T2
R(X)
X=X+M
W(X)
R(Y)
Y = Y+N
W(Y)
Bases de Datos
Andrea Rodrı́guez
Equivalencia de planes
I
El plan B es equivalente por conflicto al plan A. El plan B es
serializable.
I
Para probar si un plan es serializable por conflictos se usa un
grafo de precedencia o grafo de serialización, que es un grafo
dirigido G = (N, A), con N = {T1 , T2 , . . . , T : n} y
A = {a1 , a2 , . . . , an } arcos. Cada arco ai tiene la forma
(Tj → Tk ), con j, k = 1, n, donde Tj es el nodo inicial de ai
y Tk es el nodo final. El arco se crea si una de las
operaciones de Tj aparece en el plan antes que alguna
operación en conflicto de Tk .
Bases de Datos
Andrea Rodrı́guez
Equivalencia de planes (cont.)
I
Para cada transacción Ti que participa en el plan, crear un
nodo etiquetado Ti en el grafo.
I
Para cada paso en P en el que Tj ejecuta una orden R(X )
después de que Ti ejecute una orden W (X ), crear un arco
(Ti → Tj ) en el grafo.
I
Para cada paso en P en que Tj ejecuta una operació W (X )
después de que Ti ejecute R(X ), crear un arco (Ti → Tj ) en
el grafo.
I
Para cada paso en P en que Tj ejecuta W (X ) después de
que Ti ejecute W (X ), crear un arco (Ti → Tj ) en el grafo.
I
El Plan P es serializable si y solo si el grafo no tiene ciclos.
Bases de Datos
Andrea Rodrı́guez
Grafo de precedencia (ejemplo)
Asuma el siguiente plan con dos transacciones:
P : R1 (X )R2 (X )W1 (X )R1 (Y )W2 (X )W1 (Y ).
El grafo de precedencia es entonces:
T1
X
T2
X
Ya que existe un ciclo, el plan no es serializable.
Ejercicio: Considere el siguiente plan:
P = R2 (Z )R2 (Y )W2 (Y )R3 (Y )R3 (Z )R1 (X )W1 (X )
W3 (Y )W2 (Z )R2 (X )R1 (Y )W1 (Y )W2 (X )
Bases de Datos
Andrea Rodrı́guez
Archivo de log
Para conseguir anular y recuperar transacciones, el método más
usado consiste en utilizar un archivo de diario o log en el que va
guardando toda la información necesaria para deshacer (en caso de
fracasar) o rehacer ( en caso de recuperar) las transacciones. Este
archivo consta de:
I
identificador de la transacción
I
hora de modificación
I
identificador del registro afectado
I
tipo de acción
I
valor anterior del registro
I
nuevo valor del registro
I
información adicional
Bases de Datos
Andrea Rodrı́guez
Puntos de revisión (check points)
Un concepto relacionado con los archivos de log es el
CHECKPOINT, que permite manejar en forma eficiente el
contenido de los archivos log, ya que permiten no tener que
recorrer todo el archivo de log, ante fallas. El establecimiento de
puntos de revisión implica:
I
Grabar fı́sicamente el contenido de los búfers de datos a la
base de datos fı́sica.
I
Grabar fı́sicamente un registro de punto de revisión especial
dentro del archivo de log o bitácora.
Los puntos marcados como checkpoint, permiten la recuperación
de la base de datos en caliente, es decir, después de la caı́da del
sistema se obtiene la dirección del registro de recuperación más
reciente y se recorre el archivo de log desde el punto marcado
como checkpoint
Bases de Datos
Andrea Rodrı́guez
Puntos de revisión (cont)
t1
t2
t3
t4
t5
check point
caída del sistema
La transacción t1 no se ve afectada por la falla del sistema, ni por
el proceso de recuperación, por haberse completado antes del
último punto de recuperación. Las transacciones t2 y t4, a pesar
de haber terminado no han sido grabadas en la base de datos, ya
que éstas serı́an comprometidas en un checkpoint. Las
transacciones t3 y t5 deberán rehacerse ya que no han concluido.
Bases de Datos
Andrea Rodrı́guez
Transacciones en SQL
I
La definición de transacción en SQL es una unidad lógica de
trabajo que garantiza ser atómica.
I
No tiene un sentencia de iniciación explı́cita, pero si terminan
con COMMIT o ROLLBACK
I
Las caracterı́stica de las transacciones en SQL se definen con
la sentencia SET TRANSACTION, la que especifica modo de
acceso, tamaño del área de diagnóstico y nivel de aislamiento.
Bases de Datos
Andrea Rodrı́guez
Transacciones en SQL: modo de acceso
Puede especificar un READ ONLY o READ WRITE. Un modo
READ WRITE permite que se ejecuten operaciones de insertar,
modificar, crear o borrar. En cambio un modo READ ONLY solo
sirve para leer.
Bases de Datos
Andrea Rodrı́guez
Transacciones en SQL: área de diagnóstico
DIAGNOSTICS SIZE n, especifica un valor entero que indica el
número de condiciones que se pueden tomar simultáneamente en
el área de diagnóstico. Estas condiciones suministan información al
usuario de errores o excepciones de sentencias SQL ejecutadas más
recientemente.
Bases de Datos
Andrea Rodrı́guez
Transacciones en SQL: nivel de aislamiento
ISOLATION LEVEL <aislamiento>, donde aislamiento puede
tomar los sgtes valores:
I
READ UNCOMMITED (lectura no confirmada)
I
READ COMMITED (lectura confirmada)
I
REPEATABLE READ (lectura repetible)
I
SERIALIZABLE
Bases de Datos
Transacciones en SQL: nivel de aislamiento (cont.)
Si se usa algo menos restrictivo que serializable, pueden ocurrir
una de las siguientes violaciones:
I
Lectura sucia: Ocurre cuando una transacción usa los valores
actualizados por otra transacción aún no confirmada y que
aborta.
I
Lectura no repetible: Una trasacción T1 puede leer un valor
de una tabla. Si una trasacción T2 actualiza luego ese valor y
T1 vuelve a leer el valor, T1 verá un valor diferente.
I
Fantasmas: Una transacción T1 puede leer un conjunto de
tuplas, quizás dependiendo de la condición WHERE de una
consulta. Si una transacción T2 inserta una nueva tupla que
también satisface la condición del WHERE usada en T1,
entonces cuando T 1 se repita verá una tupla que no existı́a
previamente.
Andrea Rodrı́guez
Bases de Datos
Andrea Rodrı́guez
Transacciones en SQL: violaciones posibles
Nivel de aislamiento
Lectura no confirmada
Lectura confirmada
Lectura repetible
Serializable
Lectura sucia
Si
No
No
No
Lectura repetible
Si
Si
No
No
Fantasmas
Si
Si
Si
No
Bases de Datos
Andrea Rodrı́guez
Ejemplo SQL
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTICS SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC INSERT...;
EXEC UPDATE...;
EXEC COMMIT;
GOTO: THE END;
UNDO: EXEC SQL ROLLBACK;
THE END:...;