Gestin de

transacciones
Marta Zorrilla
Universidad de Cantabria

Lecturas recomendadas
Bsicas
Cap. 15-17. Silberschatz, A., Korth, H.F., Sudarshan, S.,
Fundamentos de Bases de Datos, 5 edicin, Madrid,
2006.
Cap. 17-19. Elmasri, R., Navathe, S.B., Fundamentos de
Sistemas de Bases de Datos, 3; edicin, Pearson
Education, 2008.
Cap. 4. Pons, O. et al. Introduccin a las bases de datos.
Paraninfo. 2007

Tabla de contenido
Transacciones
Propiedades
Elementos del gestor
responsables del control
Estados de las transacciones
Planificador de transacciones
Grafo de precedencia
Secuencialidad en cuanto a
conflictos
Recuperabilidad

Control de concurrencia
Problemas de concurrencia
Protocolos basados en bloqueo
Protocolos basados en marcas
temporales
Protocolos basados en
validacin
Granularidad mltiples
Esquemas multiversin
Niveles de consistencia en SQL

Sistemas de recuperacin
Clasificacin de los fallos
Recuperacin y atomicidad
Acceso a los datos
Ficheros de Log
Copias de seguridad

Concepto de transaccin
Una transaccin es una unidad de ejecucin de un
programa que accede y posiblemente modifica los datos
almacenados. (begin transaction, commit, rollback)
Transferir 50 desde una cuenta A a una cuenta B

leer(A)
A := A 50
escribir(A)
leer(B)
B := B + 50
escribir(B)

Requisito
Requisito de
de aislamiento
durabilidad si
desde
entre
Requisito
si
los
quepasos
se notifica
3 y de
6 se
alatomicidad
usuario
permiteque
acceder
sela
transaccin
falla
despus
del
aha
otra
completado
transaccin
la transaccin
a la
base de
(es
paso
3 yhaantes
del
pasola6,
Requisito
de
consistencia
el
la
datos
decir,
parcialmente
que
tenido
actualizada,
lugar
sistema
debera
suma
A de
ydeB50
noasegurar
se las
alteraque
porsus
ver
transferencia
una de
base
datos
),
actualizaciones
no
sedereflejan
la
ejecucin
de
la
inconsistente
actualizaciones
( la
desuma
latransaccin.
base
A
de+ B en
lamenor
base
de
ser
datos
producidas
de datos,
lo que
porde
debera).
la lo contrario
Se
resultar
unade
inconsistencia.
puede
transaccin
asegurar
deben
forma
permanecer,
trivial a
ejecutando
pesar de los
las
fallos.
transacciones
secuencialmente, es decir, una
detrs de otra.

Propiedades de las
transacciones
Atomicidad. O todas las operaciones de la transaccin se
reflejan correctamente en la base de datos, o ninguna.
Consistencia. La ejecucin aislada de una transaccin
preserva la consistencia (coherencia) de los datos.
Aislamiento. Aunque varias transacciones se pueden
ejecutar concurrentemente, cada transaccin debe ignorar
a las otras transacciones que se ejecutan concurrentemente
con ella.
Es decir, por cada par de transacciones Ti y Tj, el sistema
garantiza que, o bien Tj ha terminado su ejecucin antes de
que comience Ti , o que Tj ha comenzado su ejecucin
despus de que Ti terminara.

Durabilidad. Tras la finalizacin con xito de una

transaccin permanecen los cambios realizados en la base
de datos, incluso si hay fallos en el sistema.

Elementos del gestor

El Gestor de Transacciones asegura la
Atomicidad de las transacciones.
El Gestor de Concurrencia controla la
interaccin entre las transacciones concurrentes
(aislamiento) para garantizar la consistencia de la
informacin.
El Gestor de Recuperacin que permite
retornar a una situacin estable (durabilidad) a
pesar de fallos en el sistema ( p. ej. Corte de luz,
cada del S.O. ) o en las transacciones
establecidas en los programas (p.e. reglas de
negocio).
La consistencia la garantiza el programador

Estados de una transaccin

Activa, el estado inicial; la transaccin permanece en este
estado mientras se est ejecutando.
Parcialmente comprometida, despus de ejecutarse la ltima
instruccin.
Fallida, despus de descubrir que la ejecucin normal ya no
puede llevarse a cabo.
Abortada, despus del retroceso de la transaccin y haber
restaurado la base de datos su estado anterior al inicio de la
transaccin. Dos opciones despus de que haya abortado:
reiniciar la transaccin
cancelar la transaccin

Comprometida, despus de
terminar con xito.

Planificador de transacciones
Responsable de determinar el orden de ejecucin de
las transacciones sin intercalar sus acciones.
Serializacin vs concurrencia:
Ejecutar concurrentemente varias transacciones aumenta la
utilizacin del procesador y del disco y reduce el tiempo
medio de respuesta

La condicin suficiente para que un plan sea

serializable es que pueda ser transformado mediante
permutacin de sus acciones en un plan en serie.

Ejemplo de planificacin
Sea T1 la transferencia de $50 desde A a B, y T2 la
transferencia del 10% del saldo desde A a B.
tiempo

P1. secuencial

P2. secuencial

Ejemplo de planificacin

(y 2)

Sea T1 la transferencia de $50 desde A a B, y T2 la

transferencia del 10% del saldo desde A a B.

P3. planificacin concurrente, pero

presenta conflicto de secuencialidad

P4. concurrente pero NO PRESERVA la

consistencia

Secuencialidad en cuanto a
conflictos

Se tienen en cuenta dos tipos de operaciones:

lecturas y escrituras, aunque tambin se ven
implicadas las operaciones de insercin y borrado.
Entonces, se puede decir que dos acciones de
distintas transacciones:
a) sobre diferentes elementos siempre son permutables,
b) sobre el mismo elemento Q:

1. Ti:leer(Q) y Tj:leer(Q) son permutables,

2. Ti:leer(Q) y Tj:escribir(Q) son dos acciones no
permutables. Tambin la contraria, Ti:escribir(Q), Tj:leer(Q)
3. Ti:escribir(Q) y Tj:escribir(Q) son dos acciones no
permutables.
Por lo tanto, cuando Ti lea el elemento antes de que Tj lo
escriba, Ti precede a Tj, y viceversa.

Ejemplo: plan no serializable

Grafos de precedencia: permite definir una relacin de
precedencia entre transacciones.
Se dice que la transaccin Ti precede a la transaccin Tj en un plan
si existen dos acciones no permutables ai y aj tales que ai se ejecuta
en Ti antes de que aj sea ejecutada en Tj.
La condicin suficiente para que el plan sea serializable es que el
grafo de precedencia asociado no contenga ciclos.

Planificaciones recuperables
Si una transaccin Tj lee un elemento de datos previamente
escrito por una transaccin Ti, y la operacin comprometer de Tj
aparece antes que la operacin comprometer de Ti, entonces si
aborta Ti, Tj sera no recuperable.
Si T9 se compromete inmediatamente
despus de la lectura y T8 aborta, T9
habra ledo (y posiblemente mostrado al
usuario) un estado inconsistente de la
base de datos.
Por tanto, la base de datos debe
asegurar que las planificaciones son
recuperables.

Planificacin sin cascada

Incluso si una planificacin es recuperable, pudiera
darse el caso de tener que realizar un rollback en
cascada, si fallara Ti.
Sucede cuando hay transacciones posteriores que
han ledo Ti sin estar sta comprometida.
Supone un alto coste
por lo que hay que
evitarlo.

Control de concurrencia
Se requieren planificaciones secuenciales
en cuanto a conflictos y sin cascada para
garantizar el aislamiento.
Esquemas de control de concurrencia Mecanismos para conseguir aislamiento
Basados en bloqueo
Basados en marcas temporales
Basados en validacin

Ejercicio
Es secuenciable en cuanto a conflictos esta planificacin?

Ejercicio
Esta planificacin es secuenciable
frente a conflictos?

T5
T1
T3
T2
T4
Si es secuenciable

Ejercicio
T1:
leer(A)
Leer(B)
If A=0 then B=B+1
Escribir(B)
T2:
leer(A)
Leer(B)
If B=0 then A=A+1
Escribir(A)

Requisito de consistencia A o B = 0
Valores iniciales A=B=0
a) Demostrar que la ejecucin
secuencial conserva la
consistencia
b) Mustrese una ejecucin
concurrente de T1 y T2 no
secuencial
c) existe ejecucin concurrente que
produzca una planificacin
secuenciable?

Control de
concurrencia
Marta Zorrilla
Universidad de Cantabria

Problemas de concurrencia
Lectura no confirmada
Tiempo

Actualizacin perdida
Tiempo
t1
t2
t3
t4

Trans.#1

Trans.#2

Read Q

Read Q

Write Q

Write Q

t1
t2
t3

Trans.#1

Trans.#2

Write Q

Read Q

Rollback

Escritura no confirmada
Tiempo
t1
t2
t3

Trans.#1

Trans.#2

Write Q

Write Q

Rollback

Problemas de concurrencia
Inconsistencia
A=40

B=50

C=30

Tiempo

Trans.#1

Trans.#2

T1

Leer A

T2

Leer B

T3

Leer C

T4

Write C-10

T5

Leer A

T6

Write A + 10

T7

Commit

T8
T9

Leer C
Write A+B+C

Trans.#1: A +B +C
Trans. #2: C -10
A + 10

A+B+C = 110 y no 120, la escritura est confirmada

Bloqueo
Objetivo: Asegurar la secuencialidad retrasando las ejecucin de
acciones que pueden provocar conflictos.
Modos de bloqueo:
Compartido:
Para realizar lecturas del elemento Q.
bloquear_C (Q)

Exclusivo:
Para realizar lecturas y escrituras del elemento Q.
bloquear_X (Q)

Las transacciones solicitan bloqueos y es el control de la

concurrencia el que los concede. Posteriormente las
transacciones deben desbloquear el elemento (desbloquear(Q)).

Bloqueo (y 2)
Compatibilidad de modos de bloqueo
Compartido

Exclusivo

Compartido

Cierto

Falso

Exclusivo

Falso

Falso

Si hay incompatibilidad ante una peticin de bloqueo

se debe esperar a que terminen todos los bloqueos
incompatibles
La transaccin no ejecuta ninguna otra accin hasta
que no se le conceda el bloqueo
inanicin

Ejemplo bloqueos
//T1: transferir 100 de B a A
T1:

/* T2: visualizar el total A+B*/

T2:

Bloquear_X(B);
Leer(B);
B := B 100;
Escribir (B);
Desbloquear (B);
Bloquear_X(A);
Leer(A);
A:=A+100;
Escribir (A);
Desbloquear (A);

Bloquear_C(A);
Leer(A);
Desbloquear (A);
Bloquear_C(B);
Leer(B);
Desbloquear (B);
visualizar (A+B);

Si la ejecucin es secuencial (T1
T2 o T2
T1) siendo A=100 y

B=200, el resultado es 300

Ejemplo de mal uso de

bloqueos
A=100
B=200
Si T1 y T2 se ejecutaran
en serie
A+B=300
Pero con este esquema de
bloqueos al finalizar T2:
A+B= 200

Bloqueo en dos fases

Para que los algoritmos de bloqueo funcionen, todas las
transacciones se han de ejecutar siguiendo el protocolo de
bloqueo de las dos fases. Este protocolo consiste en que:
Fase de crecimiento: una transaccin puede obtener bloqueos pero
no puede liberarlos.
Fase de decrecimiento: una transaccin puede liberar bloqueos pero
no puede obtener ninguno nuevo.

Todo plan de ejecucin para un conjunto de transacciones que

cumplen el protocolo de bloqueo de las dos fases es
serializable.
Sin embargo, en algunos casos el nivel de concurrencia
disminuye
las transacciones no liberan los elementos hasta
que terminan de ejecutarse

Problema de interbloqueo
Una situacin de interbloqueo surge cuando un grupo de
transacciones satisface las siguientes propiedades:
Toda transaccin del grupo est detenida y esperando por un
elemento.
La finalizacin de una transaccin que no pertenece al grupo no
permite a ninguna transaccin del grupo conseguir el bloqueo
del elemento por el que espera.

Ni T3 ni T4 pueden progresar
rollback

Solucin al interbloqueo
Si el algoritmo de concurrencia no impide el interbloqueo,
peridicamente se ha de examinar las peticiones de reserva
para detectar interbloqueos.Se reconocen por la aparicin
de ciclos en grafos de espera.
Con qu periodicidad?
Seleccin de la transaccin a abortar

Otros algoritmos establecen un tiempo de espera mximo,

de tal forma que si una transaccin sobrepasa ese tiempo
de espera se supone que ha entrado en un interbloqueo y
es abortada.
qu tiempo? Esperas largas producen retraso y cortas,
abortos incluso cuando no se produce interbloqueo.

Otros hacen que cada transaccin pida todas sus reservas

de una vez y el gestor de concurrencia se las concede todas
o ninguna. De esta forma el nivel de concurrencia baja ms.

Otras variantes de bloqueo

en dos fases
El bloqueo estricto en dos fases, esto es, la transaccin debe
tener todos los bloqueos en modo exclusivo hasta que se
complete.
Menos concurrencia
Evita rollback en cascada

El bloqueo riguroso en dos fases con conversiones de

bloqueo. Se puede cambiar un bloqueo compartido por uno
exclusivo (subir) y viceversa, pero la subida slo se puede realizar
en la fase de crecimiento y la bajada en la de decrecimiento.
Cuando Ti realiza una operacin leer(Q), el sistema genera una
instruccin bloquear-C(Q) seguida de la operacin leer(Q)
Cuando Ti realiza una operacin escribir(Q), el sistema comprueba si
Ti posee bloqueo compartido, si es as, genera instruccin subir(Q)
seguida de escribir(Q). En otro caso, genera instruccin bloquear-X(Q)
seguida de escribir(Q)
Todos los bloqueos que obtenga una transaccin no se desbloquean
hasta que dicha transaccin se comprometa o aborte (sin cascada).

Ejemplo para mostrar

conversin de bloqueo
T1:

T2:

Bloquear_X(a1);
Leer(a1);
Bloquear_C(a2);
Leer(a2);
.
Bloquear_C (an);
Leer (an);
Escribir (a1);
Desbloquear (a1);
Desbloquear (a2);
Desbloquear (an);

Bloquear_C(a1);
Leer(a1);
Bloquear_C(a2);
Leer(a2);
visualizar (a1+b1);
Desbloquear (a1);
Desbloquear (a2);

Como a1 requiere bloqueo exclusivo, la ejecucin de T1 y T2 debe ser

secuencial utilizando bloqueo en dos fases.

Ejemplo con conversin

T1:
Bloquear_C(a1);
Leer(a1);
Bloquear_C(a2);
Leer(a2);
.

Bloquear_C (an);
Leer (an);

T2:
Bloquear_C(a1);
Leer(a1);
Bloquear_C(a2);
Leer(a2);
visualizar (a2+a1);
Desbloquear (a1);
Desbloquear (a2);

Subir (a1);
Escribir (a1);
Desbloquear (a1);
Desbloquear (a2);
Desbloquear (an);

Con conversiones de bloqueo se

consigue mayor concurrencia

Marcas temporales
Se asocia a cada Ti un valor temporal secuencial (reloj del
sistema, contador). Si Ti es anterior a Tj, entonces
MT(Ti)<MT(Tj).
Tambin se asocian marcas temporales a los datos (Q)
E-mt(Q). Marca temporal de la ltima T que escribi Q con xito
L-mt(Q). Marca temporal de la ltima T que ley Q con xito

El protocolo establece el orden de ejecucin teniendo en cuenta

en qu momento aparece una transaccin y cuando se leyeron o
escribieron por ltima vez los datos a los que accede.
Las operaciones conflictivas (lectura/escritura, ) se ordenan a
partir de las marcas temporales. Las de solo lectura se ejecutan
en cualquier orden.
Una transaccin que haya sido retrocedida, se le asigna una
nueva marca temporal y se inicia de nuevo

Marcas temporales (y 2)
Ti ejecuta leer(Q)
a. Si MT(Ti) < E-mt(Q)
ERROR.
Una Tj posterior a Ti escribi Q antes de que fuera ledo por Ti.
Hay que retroceder Ti.

b. Si MT(Ti) > E-mt(Q)
CORRECTO

leer (Q)
actualizar L-mt(Q) con el mximo de ( L-mt(Q) , MT(Ti) )

Ti ejecuta escribir(Q)
a. Si MT(Ti) < L-mt(Q)
ERROR:
Una Tj posterior a Ti ley Q antes de que fuera escrito por Ti.
Hay que retroceder Ti.

b. Si MT(Ti) < E-mt(Q)
ERROR

Ti intenta escribir un valor obsoleto de Q
Hay que retroceder Ti.

c. En otro caso
CORRECTO

escribir (Q)
actualizar E-mt(Q) con MT(Ti)

Ejemplo
Si MT(T14) < MT(T15)
La planificacin que se
presenta s es correcta

Protocolo basado en marcas temporales:

Se asegura la secuencialidad en cuanto a conflictos
Se asegura la ausencia de interbloqueos
Puede generar planificaciones no recuperables aunque se
pueden evitar con una extensin del mtodo.

Algoritmos optimistas o
basados en validacin
Se basan en la idea de que los problemas de concurrencia
van a aparecer en muy pocas ocasiones.
Es cierto en bases de datos en las que se realizan solamente
operaciones de consulta, siendo las operaciones de escritura
muy escasas.
Consiste en hacer que las transacciones preparen todas sus
modificaciones en un buffer con anterioridad a modificar la
base de datos. Una vez las transacciones han terminado y
antes de modificar la base de datos, se ejecuta una validacin
que comprueba la secuencialidad de las operaciones
realizadas en el buffer (p. ej. con marcas temporales). En
caso de que la validacin falle, las transacciones sern
abortadas y ejecutadas de nuevo con otro plan.
Posibilidad de inanicin de transacciones largas, pero no se
producen rollback en cascada ya que se escribe despus de
validar.

Protocolo basado en
validacin
Cada transaccin Ti tiene 3 marcas temporales
Inicio(Ti) : el tiempo Ti en el cual comienza la
transaccin
Validacin(Ti): el tiempo Ti en el cual comienza
la fase de validacin
Fin (Ti) : el tiempo Ti en el cual termina la fase
de escritura
El orden de secuencialidad de las transacciones se
determina por la marca temporal de validacin

Comprobacin
de

de validacin
Tj

Para toda Ti con MT (Ti) < MT (Tj) se debe

cumplir una de las dos condiciones siguientes:
fin (Ti) < inicio(Tj)
inicio(Tj) < fin (Ti) < validacin(Tj) y el conjunto de
datos escritos por Ti no tiene interseccin por los ledos
por Tj.

entonces Tj puede ser confirmada. En otro caso,

la validacin falla y Tj es abortada.

Planificacin por validacin

T14
leer(B)

leer(A)
(validar)
mostrar (A+B)

T15
leer(B)
B:- B-50
leer(A)
A:- A+50

(validar)
escribir (B)
escribir (A)

fin (T14) < inicio(T15)

inicio(T15) < fin (T14) < validacin(T15)

GRANURALIDAD MLTIPLE
La idea es manejar elementos de informacin de distinto
tamao, no nicamente datos individuales (la base de datos,
unas tablas, una nica tabla, registros, etc.)
Se necesita definir mltiples niveles de granuralidad (se puede
representar como un rbol).
Los bloqueos se realizan sobre nodos del rbol.
Se agiliza el mecanismo de peticin de bloqueos. No es
necesario bloquear explcitamente cada nodo descendiente del
elemento al que se quiere acceder (ya sea en modo C o X).
Permite concurrencia y reduce sobrecarga de bloqueos. til en
aplicaciones en las que se mezclan transacciones cortas que
acceden a algunos datos con otras largas que producen
informes a partir de un archivo completo

Jerarqua de granularidad

ESQUEMAS MULTIVERSIN
La idea es que cada operacin de escribir(Q) crea una
versin (Qi) y cuando se realiza una operacin leer(Q), el
gestor elige una versin de Q que garantice la
secuencialidad.
Una alternativa es utilizar marcas temporales con
estructuras del tipo:
Qi= (Contenido del elemento Q, E-mt(Q), L-mt(Q))
Se borran las versiones cuando su marca temporal es anterior
a cualquiera de las marcas temporales de las transacciones
activas

Problemas:
la lectura requiere actualizar L-mt(Q)
ms accesos a disco
Los conflictos entre transacciones se resuelven con retrocesos
y no con esperas. Ms costoso.

Operaciones de insertar y
borrar
Sean las transacciones Ti y Tj y Ti incluye una operacin
borrari(Q). Sea opj(Q) una operacin realizada por Tj en Q,
donde op = lectura, escritura, borrado o insercin. (<
significa antes):
si borrari(Q) < leerj(Q): error lgico para Tj, sino OK
si borrari(Q) < escribirj(Q): error lgico para Tj, sino OK
Si borrari(Q) < borrarj(Q): error lgico para Tj, sino error lgico
para Ti,
si borrari(Q) < insertarj(Q): si Q existe < borrari(Q), OK
sino error lgico Ti
si Q existe y no se ha borrado antes de insertarj(Q) error lgico Tj

Anlogo para insertari(Q).

Conclusin: causan conflicto necesitan bloqueos o marcas
temporales

Operaciones de insertar y
borrar(cont.)
Si se utiliza bloqueo en dos fases:
Una operacin de borrar requiere bloqueo exclusivo
Una operacin de insertar, requiere bloqueo exclusivo para la
tupla que inserta

Si se utiliza marcas temporales:

MT(ti) debe ser posterior a E(Q) y L(Q) para borrar
Y al insertar, se actualizar E(Q) y L(Q) a MT(ti)

Se puede producir el fenmeno fantasma.

Una transaccin (e.j., sumar los saldos de las cuentas de las
sucursales de Santander) y una transaccin que inserta una
tupla en la relacin (e.j., insertar una nueva cuenta en
sucursal de Santander) puede ocurrir conflicto a pesar de no
tener tuplas en comn
Si slo se bloquean las tuplas que se ven afectadas por la
transaccin, se pueden producir planificaciones no
serializables; por eso hay que evitar que se puedan realizar
acciones sobre la relacin afectada
bloqueo de elemento de
datos o bloqueo de ndice.

Transacciones en SQL
El lenguaje de manipulacin de datos incluye una construccin
para especificar el conjunto de acciones que comprometen una
transaccin.
En SQL, una transaccin empieza implcitamente.
Una transaccin en SQL termina por:
Commit work compromete la transaccin actual y empieza una nueva.
Rollback work origina el aborto de la transaccin actual.

Niveles de consistencia especificados por SQL-92:

Secuenciable por defecto (serializable)

Lectura repetible (repeatable read)
Con compromiso de lectura (read commited)
Sin compromiso de lectura (read uncommited)

Niveles de aislamiento SQL-92

Secuenciable no se permiten lecturas sucias, ni lecturas
no repetibles, ni fantasmas.
Lectura repetible slo se pueden leer los registros
comprometidos, repetidas lecturas del mismo registro en
una transaccin deben devolver el mismo valor. No permite
que otra transaccin actualice el registro.
Con compromiso de lectura slo se pueden leer los
registros comprometidos, pero lecturas sucesivas del
registro pueden devolver valores diferentes.
Sin compromiso de lectura se pueden leer incluso
registros no comprometidos.

Problemas de concurrencia
Lectura sucia (dirty read): T1 puede leer una actualizacin de
T2 an no confirmada y si T2 falla y se aborta, T1 ley un
valor que no existe.
Lectura no repetible (nonrepeatable read): T1 puede leer un
valor D que posteriormente actualiza T2. Si T1 vuelve a leer
el valor de D lo encuentra cambiado.
Fantasmas (phantoms) - T1 puede leer una tabla en la que
posteriormente T2 inserta una fila. Si T1 vuelve a leer la tabla
aparece una fila nueva: un fantasma.

Ejercicio
Determinar si el algoritmo de ordenacin
por marca de tiempo permite su ejecucin

Recuperacin
Marta Zorrilla
Universidad de Cantabria

CLASIFICACIN DE FALLOS
Fallo en la transaccin:
Error lgico (del programa): la transaccin no puede
continuar por alguna condicin interna como acceso a
informacin que no existe, entradas errneas, overflow,
etc.
Error del sistema: la transaccin no puede continuar,
p. ej. interbloqueos, aunque entrar a ejecutarse ms
tarde.

Cada del sistema:

Fallo hardware (alimentacin), o software (del SGDB,
del SO). Se pierde informacin voltil.

Fallo de disco:
Por ejemplo, un bloque que no se puede leer o
transferir. Se pierde informacin no voltil.

Recuperacin
Los algoritmos de recuperacin aseguran la
consistencia y atomicidad de las transacciones
aunque se produzcan fallos. Es necesario:
Guardar informacin durante el proceso normal para
poder realizar una recuperacin
Realizar la recuperacin en caso de fallo

Medios
Copias de seguridad (back-up).
Peridicamente se deben hacer copias y guardarlas en lugar
seguro. Generalmente en cinta y almacn ignfugo

Registro histrico (log).

Para restaurar la base de datos desde su ltimo backup
hasta ltima situacin estable antes del fallo.
El log se almacena en un disco externo y, por lo tanto, no
se pierde a no ser que el fallo sea catastrfico.

Acceso a los datos

Las transacciones llevan informacin del disco a la memoria
principal y de ah al disco.
Cada Ti, crea un rea de trabajo privada en la cual guarda copia
de todos los elementos que ha accedido y actualizado. Usa las
operaciones:
read(X) asigna el valor del elemento de datos X a la variable local xi.
write(X) asigna el valor de la variable local xi al elemento de datos X
en el buffer.
Ambas operaciones pueden requerir la lectura de disco a memoria
(input(BX).

Transacciones

Ejecutan read(X), acceden a X por primera vez

Los accesos siguiente se hacen en memoria.
Despus del ltimo acceso, write(X).
output(BX) no va necesariamente despus de write(X). Puede que
an haya datos sobre los que se est accediendo.
si se produce un
fallo entre ambas operaciones, se pierden los datos.

Ejemplo de acceso a datos

buffer
input(A)

Buffer Block A

Buffer Block B

A
output(B)

read(X)

write(Y)
x2

x1

y1
work area
of T1
memory

work area
of T2

disk

Fichero de log
Modificacin diferida:
Una transaccin no escribe nada en la base de datos hasta que
se ha confirmado.
Una transaccin no se ha confirmado hasta que no haya
registrado todos sus cambios en el LOG

Modificacin inmediata
Se escribe en la base de datos y en log al tiempo

Informacin que anota

<Ti iniciada>: Indica que la transaccin Ti ha comenzado a
ejecutarse.
<Ti, Xj, V1, V2>: Indica que la transaccin Ti ha actualizado el
valor del elemento Xj con valor V2 y anteriormente tena V1.
<Ti, X, V>: Indica que la transaccin Ti ha ledo el valor V del
elemento X.
<Ti confirmada>: Indica que la transaccin T ha terminado con
xito y ha anotado todos sus cambios en el log.
<Ti abortada>: Indica que la ejecucin de la transaccin Ti ha
fallado y ha sido abortada.

Ejemplo diferida
T0: read (A)
A: A - 50
write (A)
read (B)
B: B + 50
write (B)

T1 : read (C)
C:C- 100
write (C)

<T0 redo>

A=1000,
B=2000 y
C=700

<T0 redo>
<T1 redo>

Fichero de LOG en tres instantes de tiempo

Ejemplo inmediata
T0: read (A)
A: A - 50
write (A)
read (B)
B: B + 50
write (B)
<T0 undo>

T1 : read (C)
C: C- 100
write (C)
<T0 redo>
<T1 undo>

Fichero de LOG en tres instantes de tiempo

<T0 redo>
<T1 redo>

Checkpoint

Problemas en el procedimiento de recuperacin:

1. Bsqueda en el fichero log consume mucho tiempo
2. La mayora de las transacciones que deben rehacerse de
acuerdo con el algoritmo ya tienen escritas sus
actualizaciones en la base de datos.

Puntos de revisin (checkpoints)

1. Salida a disco de todos los registros en memoria
2. Salida a disco de todos los bloques de memoria
modificados.
3. Escribir en LOG <checkpoint> y forzar su grabacin a
disco
Mientras se produce checkpoint no se permiten
transacciones de actualizacin (escribir en bloque de
memoria intermedia o escribir en fichero de log)

Checkpoints (Cont.)
Durante la recuperacin slo se tienen en cuenta las Ti
que empezaron antes del checkpoint y las Ti que
comenzaron despus.
1. Se recorre el log hacia atrs hasta encontrar el
<checkpoint> ms reciente
2. Se continua hacia atrs hasta encontrar <Ti start>.
3. Lo anotado en el log anteriormente se ignora y puede
eliminarse cuando se desee.
4. Para todas las transacciones (empezando en Ti o posteriores)
con no <Ti commit>, se ejecuta undo(Ti). (para log
inmediato)
5. Se recorre hacia adelante el log, para todas las Ti con un
<Ti commit>, se ejecuta redo(Ti).

Ejemplo de Checkpoints
Tiempof

Tiempoc
T1
T2
T3
T4

checkpoint
T1 puede ignorarse
T2 y T3 rehacer.
T4 deshacer

Fallo del sistema

Recuperacin de una BD
El proceso de recuperacin consiste en deshacer todos los
cambios realizados por transacciones abortadas y rehacer
todas las comprometidas.
Dos propiedades deseables en todo planificador que van a
ayudar a garantizar la integridad de los datos:
Planes de ejecucin recuperables. Despus de un aborto
siempre se debe recuperar un estado consistente de la base de
datos. Se dice que un plan es recuperable cuando para todo
par de transacciones Ti y Tj tales que Tj lee los previamente
escritos por Ti, la transaccin Ti siempre termina antes que Tj.
Planes de ejecucin sin cascadas. Para evitar la necesidad
de abortar una cascada de transacciones, los planes tienen
que cumplir la siguiente condicin. Para todo par de
transacciones Ti y Tj tales que Tj lee los datos previamente
escritos por Ti, la transaccin Ti siempre termina antes que Tj
lea los datos.

El proceso de recuperacin
Si hay daos extensos en una porcin considerable de la
base de datos
back-up y aplicar las acciones de las
transacciones confirmadas anotadas en el fichero de log
hasta el momento del fallo. En este caso siempre se
necesita la supervisin del administrador de la base de
datos.
Cuando la base de datos no presenta daos fsicos pero se
ha vuelto inconsistente
deshacer los cambios que
provocaron la inconsistencia consultando las entradas del
fichero de log. Puede ser que la recuperacin se pueda
hacer automticamente, sin intervencin del administrador.

Ejercicio
A=2, B=16, W=5, X=10, Y=20
T2

T3

Anotaciones
log inmediato

T1

Leer A

A: A*2

Leer W

T2 start

Escribir A

Leer X

T1, A, 2 ,4

T1 start

T1 commit

X: X+W

Escribir X

Leer Y

A: A*5

T2, X, 10, 15

Y: Y-W

Escribe A

T3, A, 4, 20

Escribir Y

Lee B

T2, Y, 20, 15

B: B*5

T2 commit

1
0

Escribe B

T3, B, 16, 90

Leer A

T3 start

T3 commit

en

Optimizando el cdigo
transaccional
Ejecutar transacciones lo ms cortas
posibles
Limitar transacciones a operaciones de
modificacin siempre que no se re-lean
datos en la misma transaccin
Usar niveles de aislamiento bajos siempre
que sea posible
Reducir al mnimo imprescindible los datos
a modificar en una transaccin

Ejercicio de Checkpoints
Tiempof

Tiempoc
T1
T2
T3
T4
T5
checkpoint
T1 y T2 puede ignorarse
T3,T4 y T5 rehacer.
T5 deshacer

T6
Fallo del sistema