6. Recuperación de fallos
Objetivos
• Apreciar la necesidad de establecer un producto fiable,
capaz de proteger la información frente a fallos del sistema
• Identificar los tipos de fallos que pueden ocurrir en un
sistema de bases de datos
• Comprender el propósito del fichero de bitácora y los
puntos de validación del sistema
• Conocer y entender diferentes técnicas del sistema gestor
de bases de datos para la recuperación de fallos
Tema 6. Recuperación de fallos
1
6. Recuperación de fallos
Contenidos
1.Conceptos generales de recuperación
2. Concepto de transacción
1. Propiedades deseables de una transacción
2. Operaciones de una transacción
3. Estados de una transacción
2. El proceso de recuperación del fallo de una
transacción
3. Técnicas de recuperación de fallos del sistema
Tema 6. Recuperación de fallos
2
6. Recuperación de fallos
Bibliografía
[EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos de Sistemas de Bases de
Datos. 3ª Edición. Addison-Wesley. (Cap. 19 y 21)
[EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos
fundamentales. 2ª Edición. Addison-Wesley Iberoamericana. (Cap. 17, 18
y 20)
[CBS 1998] Connolly, T.; Begg C.; Strachan, A.: Database Systems: A Practical
Approach to Design, Implementation and Management. 2nd Edition. AddisonWesley. (Cap. 17)
Tema 6. Recuperación de fallos
3
6.1 Conceptos generales de recuperación
EMPLEADO
codEmp nomEmp
1
12
7
22
5
...
José
Antonio
Cristina
Julia
Rubén
...
depto
10
20
30
20
10
...
DEPARTAMENTO
codDep nomDep
ciudSede numEmp
20
10
Producción Murcia
Dirección
Madrid
2
2
30
...
Sistemas
...
1
...
Valencia
...
• Transacción T: Añadir a la base de datos la empleada (14, ‘Eva’, 30)
Tema 6. Recuperación de fallos
4
6.1 Conceptos generales de recuperación
• El código de T podría ser el siguiente: (SQL embebido)
...
(1) EXEC SQL WHENEVER SQLERROR ROLLBACK;
(2) EXEC SQL INSERT INTO Empleado VALUES (14, ‘Eva’, 30);
(3) EXEC SQL UPDATE Departamento SET numEmp=numEmp+1
WHERE codDep = 30;
(4) EXEC SQL COMMIT;
...
• Única transacción con varias operaciones/sentencias SQL
• ¿Cuál es el estado de la BD entre las sentencias (2) y (3)?
Tema 6. Recuperación de fallos
5
6.1 Conceptos generales de recuperación
• Idea básica: atomicidad y durabilidad de toda transacción
– Secuencia de operaciones que llevan la BD de un estado
consistente a otro estado consistente
– Debe garantizarse frente a todo tipo de fallos posible
• El SGBD debe asegurar que toda transacción T ...
– ejecute todas sus operaciones con éxito y su efecto
quede permanente en la BD,
o bien que ...
– no tenga ningún efecto sobre la BD ni otras transacciones
 Nunca deben ejecutarse sólo algunas operaciones de T
– Ni siquiera por culpa de un fallo “a mitad” de T
Tema 6. Recuperación de fallos
6
6.1 Conceptos generales de recuperación
• Recuperación
«dejar la información de la BD en un estado correcto,
tras un fallo del sistema que ha dejado la BD
en un estado inconsistente o sospechoso de serlo»
• El Subsistema Gestor de Recuperación del SGBD vela por
que...
– No “se pierda” ninguna transacción
– Ninguna transacción quede “a medio ejecutarse”
– Ninguna transacción se ejecute más de una vez
Tema 6. Recuperación de fallos
7
6.1 Conceptos generales de recuperación
Tipos de fallos
1. Locales previstos por la aplicación
– «Saldo insuficiente en transacción de reintegro» Fallo local:
2. Locales no previstos
– Error de programación (bug), interrupción
3. Por imposición del control de
concurrencia
• Sólo afecta a la T
fallida
• Pérdida de datos
de T en memoria
princ. y búfer E/S
– Violación de seriabilidad; bloqueo mortal
4. Fallos del sistema
– Mal funcionamiento hardware o error software (SGBD, SO)
• Afectan a todas las transacciones
• Pérdida de la memoria principal y búfer E/S
• No dañan el disco
Tema 6. Recuperación de fallos
8
6.1 Conceptos generales de recuperación
Tipos de fallos
(y 2)
5. Fallos de disco
– Fallos en dispositivos de almacenamiento
• Afectan a todas las transacciones
• Pérdida de la memoria principal y búfer E/S
• Algunos bloques del disco pueden perder sus datos
6. Fallos físicos o catastróficos
– Corte de suministro eléctrico, robo del disco, incendio, sabotaje,
sobreescritura por error, etc.
Tema 6. Recuperación de fallos
9
6.1.1 Concepto de transacción
• Unidad lógica de procesamiento
– Secuencia de operaciones que implican accesos a la base de datos
– ejemplo: transferencia de dinero entre dos cuentas bancarias
• Pero también se considera...
– Unidad lógica de integridad
– Unidad lógica de concurrencia
– Unidad lógica de recuperación
Una transacción es atómica
O se ejecutan todas las operaciones
que componen la transacción,
o no se realiza ninguna
Tema 6. Recuperación de fallos
10
6.1.1 Concepto de transacción
• Inicio de una transacción
– Sentencia SQL (LDD o LMD) interactiva
– Sentencia SQL incluida en un programa (si no tiene ya transacción en
progreso)
• Fin de una transacción
– Confirmar (COMMIT) xor Anular (ROLLBACK)
– Ambas operaciones pueden ser de tipo explícito o implícito
Fin
OK
T1
COMMIT T1
SGBD
T2
Tema 6. Recuperación de fallos
K
O
BD
ROLLBACK T2
11
6.1.2 Propiedades de una transacción
• Atomicidad
SubSistema de
Recuperación
– Todo o nada
• Conservación de la Consistencia
SS de Integridad
+ Programadores
– T lleva la BD de un estado de consistencia a otro
– No necesariamente se mantiene la consistencia “a mitad de T”
• Aislamiento (Isolation)
SS de Control de
– T no muestra los cambios que produce hasta que finaliza
– Puede no imponerse de forma estricta (niveles de aislamiento) Concurrencia
• Durabilidad
– Una vez que T finaliza con éxito y es confirmada,
los cambios perduran aunque el sistema falle después
 Conocidas como propiedades ACID
Tema 6. Recuperación de fallos
SubSistema de
Recuperación
12
6.1.3 y 6.1.4 Operaciones y Estados de
una transacción
Diagrama de Transición de Estados
de la ejecución de una transacción
INICIO DE
TRANSACCIÓN
LEER /
ESCRIBIR
FIN DE
TRANSACCION
ACTIVA
Verificaciones para
control de concurrencia
y recuperación
PARCIALMENTE
CONFIRMADA
CONFIRMAR
CONFIRMADA
ABORTAR
ABORTAR
Otras:
* DESHACER una operación
* REHACER (algunas operaciones de)
una transacción
Tema 6. Recuperación de fallos
FALLIDA
TERMINADA
13
6.1 Conceptos generales de recuperación
Recuperabilidad de planes de transacciones
• Hay que asegurar que una vez que T se ha confirmado,
nunca será necesario anularla (cancelarla, revertirla, abortarla)
• Un plan P es recuperable si ninguna transacción T
de P se confirma antes de haberse confirmado toda
transacción T’ que ha escrito un dato que T lee
– Una transacción Tj “lee de” la transacción Tk ,
si Tk escribe un elemento X y luego Tj lo lee
Tema 6. Recuperación de fallos
14
6.1 Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (2)
– Así, Tj “no lee de” Tk...
 Si Tk ha abortado antes de que Tj lea el elemento X
 Si otras transacciones escriben X después de que Tk lo haya
escrito y antes de que Tj lo lea
– Ejemplo de plan no recuperable
Pc: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; c2 ; ...
– Solución: postergar la confirmación de T2 hasta que T1 se confirme
Pd: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; c1 ; c2;
Tema 6. Recuperación de fallos
15
6.1 Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (3)
• En un plan recuperable ninguna T confirmada tiene que
anularse jamás, pero puede ocurrir el fenómeno de la
reversión en cascada
Tk no confirmada debe anularse porque
ha leído X de Tj , y Tj ha sido abortada
– Ejemplo de plan con reversión en cascada
Pe: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; r1 ;
– La cancelación en cascada puede consumir mucho tiempo
• Un plan P es sin cascada si toda T en el plan sólo lee
datos escritos por transacciones confirmadas
– ¿Cómo transformamos Pe para que evite la cancelación en cascada?
 Un plan sin cancelación en cascada, es recuperable
Tema 6. Recuperación de fallos
16
6.1 Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (y 4)
• Un plan P es estricto si las transacciones no pueden
leer ni escribir un elemento X hasta que sea
confirmada o abortada toda T que haya escrito X
• Si T1 es abortada, es necesario deshacer todas sus
operaciones de escritura
• Deshacer una operación de escritura e1(X,5) consiste en
restaurar el valor anterior del elemento X
• Pero esto puede no funcionar correctamente si el plan
no es estricto:
Pf: e1(X,5) ; e2(X,8) ; r1 ;
 Un plan estricto es recuperable y sin cancelación en cascada
Tema 6. Recuperación de fallos
17
6.1 Conceptos generales de recuperación
Bitácora
• Cuando ocurre un fallo...
... ¿cómo restaurar la base de datos a un estado consistente?
 Redundancia + Técnica de Recuperación
Seguir la pista de
la ejecución de
cada transacción
– Cuándo se inicia,
confirma o aborta
– Qué operaciones
realiza sobre qué
datos
Tema 6. Recuperación de fallos
FICHERO
DE
BITÁCORA
Acciones para restablecer
el contenido de la BD a un
estado que asegure:
– Consistencia de la BD
– Atomicidad de transacciones
– Durabilidad de transacciones
18
6.1 Conceptos generales de recuperación
Bitácora
(2)
• Fichero que almacena detalles sobre las operaciones
efectuadas como parte de las transacciones
– Log, diario, journal, registro histórico...
• Se mantiene en el disco
– En un área distinta a donde se almacenan los datos de la BD
– No le afecta ningún tipo de fallo, salvo los de tipo 5 y 6
– Se suele realizar periódicamente una copia de seguridad (en cinta)
• Cada registro del fichero se denomina entrada, que puede
ser de diversos tipos
Tema 6. Recuperación de fallos
19
6.1 Conceptos generales de recuperación
Bitácora
(3):
tipos de entradas
< INICIAR, T >
– Indica que la transacción T ha comenzado su ejecución
< ESCRIBIR, T, X, valor_anterior, valor_nuevo >
– Indica que T ha modificado el valor del elemento X
< LEER, T, X >
– Indica que T leyó el valor del elemento X de la base de datos
< COMMIT, T >
– Indica que T finalizó con éxito y su efecto puede ser confirmado en la
base de datos en disco: los cambios que ha realizado pueden quedar
permanentes en la BD
< ROLLBACK, T >
– Indica que la transacción T ha sido anulada de forma que ninguna de
sus operaciones tendrá efecto sobre la BD: la transacción será
revertida, todas sus operaciones serán deshechas
Tema 6. Recuperación de fallos
20
6.1 Conceptos generales de recuperación
Bitácora
(y 4)
Suponemos que...
• Las transacciones no se pueden anidar
• Toda modificación «permanente» de la BD «ocurre»
dentro de una transacción
 Recuperar un fallo de T consistirá en deshacer o rehacer
algunas de sus operaciones, a partir del contenido de la
bitácora (se verá)
Tema 6. Recuperación de fallos
21
6.1 Conceptos generales de recuperación
Acceso a datos almacenados
• Cada T posee un área de trabajo privada donde guarda
todo elemento que lee/escribe
– Espacio en memoria principal y local a la transacción
– Se crea al iniciarse T y se elimina cuando T finaliza
• Búfer de base de datos que contiene temporalmente los
bloques de BD que las transacciones requieren
– Uno o más bloques en memoria principal (en la caché del SGBD)
– Común a todas las transacciones
MEMORIA PRINCIPAL
Area de
trabajo
de T
Tema 6. Recuperación de fallos
Búfer
de BD
BD
22
6.1 Conceptos generales de recuperación
Punto de confirmación de una transacción
• Cuando T termina de ejecutar COMMIT significa que...
– Todas sus operaciones se ejecutaron con éxito
– El efecto de dichas operaciones se anotó en bitácora,
incluyendo el COMMIT
T ha llegado a su punto de confirmación
... y se puede suponer que...
– T está confirmada
– Sus cambios son permanentes en la BD
– Bloqueos liberados y cursores cerrados
BD ok
T1
Bitácora
UPDATE... SELECT... INSERT... COMMIT
Tema 6. Recuperación de fallos
BD ok
...
<INICIAR,T1>
<ESCRIBIR,T1,...>
<LEER,T1,...>
<ESCRIBIR,T1,...>
<COMMIT,T1>
...
23
6.1 Conceptos generales de recuperación
Punto de confirmación de una transacción
(y 2)
• Cuando T termina de ejecutar ROLLBACK significa que...
– T ha resultado fallida
– El ROLLBACK se anotó en bitácora
... y se puede suponer que...
– T ha sido cancelada (deshecha)
– Sus operaciones han sido anuladas: ningún efecto en la BD
– Bloqueos liberados y cursores cerrados
UPDATE... SELECT... ROLLBACK
BD ok
T1
Tema 6. Recuperación de fallos
...
<INICIAR,T1>
<ESCRIBIR,T1,...>
<LEER,T1,...>
<ROLLBACK,T1>
...
24
6.2 El proceso de recuperación del fallo de una
transacción
• Si el fallo ocurre cuando T está en curso de ejecución,
entonces se debe deshacer T
– Pues no alcanzó su punto de confirmación (no anotó <COMMIT,T>)
T
• Si el fallo ocurre cuando T ya ha sido confirmada,
entonces se debe rehacer T
– No es seguro que todo cambio haya sido llevado a la BD en disco
T
UPDATE... SELECT...
Tema 6. Recuperación de fallos
COMMIT
25
6.2 El proceso de recuperación del fallo de una
transacción
• deshacer T implica deshacer cada una de sus operaciones,
a partir de las anotaciones en bitácora, empezando por la
última (orden inverso)
< ESCRIBIR, T, X, valor_anterior, valor_nuevo >
deshacer (< ESCRIBIR, T, X, 10, 5 >)  X = 10 en la BD
• rehacer T implica rehacer cada una de sus operaciones, a
partir de las anotaciones en bitácora, empezando por la
primera (en el mismo orden)
< ESCRIBIR, T, X, valor_anterior, valor_nuevo >
rehacer (< ESCRIBIR, T, X, 10, 5 >)  X = 5 en la BD
Tema 6. Recuperación de fallos
26
6.2 El proceso de recuperación del fallo de una
transacción
• Las entradas < LEER,... > son necesarias para detectar
reversión en cascada
...
< ESCRIBIR, T1, X, 10, 5 >
...
< LEER, T2, X >
< ESCRIBIR, T2, X, 5, 25 >
...
< ROLLBACK, T1 >
...
 T2 debe ser deshecha !
• Si el método de concurrencia / recuperación garantizara
planes sin cascada o planes estrictos, no sería necesario
anotar entradas LEER en bitácora
Tema 6. Recuperación de fallos
27
6.2 El proceso de recuperación del fallo de una
transacción
Escritura anticipada en bitácora
• La bitácora es un fichero almacenado en disco, por lo que
para insertar una nueva entrada es necesario...
– Copiar el bloque adecuado del fichero a memoria principal
– Actualizar el bloque en memoria, insertando la nueva entrada
– Copiar el bloque desde memoria al disco
 Una escritura de bloque en disco por cada nueva entrada!!
• Búfer de bitácora, que contiene un bloque del fichero de
bitácora hasta que se llena de entradas, momento en el
que se escribe en el disco
– Espacio en memoria principal (en la caché del SGBD)
 Una única escritura por bloque
Tema 6. Recuperación de fallos
28
6.2 El proceso de recuperación del fallo de una
transacción
Escritura anticipada en bitácora (2)
• Cuando ocurre un fallo, algunas entradas pueden no haber
sido llevadas al fichero de bitácora en disco
– Entradas del bloque incompleto, en el búfer de bitácora
– Con el fallo se pierde el contenido de la memoria principal
• Dichas entradas no serán consideradas en el proceso de
recuperación, pues el SGBD acude al fichero bitácora
• Esto puede impedir la restauración correcta tras el fallo
de una transacción
• Es necesario seguir un protocolo de escritura anticipada en
bitácora, o bitácora adelantada
Tema 6. Recuperación de fallos
29
6.2 El proceso de recuperación del fallo de una
transacción
Escritura anticipada en bitácora (3)
Bitácora adelantada
• No se puede grabar en disco los cambios realizados por T
hasta que se haya escrito en disco toda entrada de
bitácora para T hasta el momento actual
UPDATE... DELETE...
COMMIT
PUNTO DE CONFIRMACIÓN
T
BITÁCORA
a disco
CAMBIOS
a disco
• El COMMIT de T no se completa hasta que se haya escrito
en disco toda entrada de bitácora para T pendiente
»Se fuerza la escritura en disco de las entradas de búfer de bitácora
para T, antes de consolidar cambios hechos por T
Tema 6. Recuperación de fallos
30
6.2 El proceso de recuperación del fallo de una
transacción
Escritura anticipada en bitácora (y 4)
• Nunca puede ocurrir...
UPDATE... DELETE...
ESCRITURA EN
DISCO DE CAMBIOS
COMMIT
ESCRITURA EN
DISCO DE BITÁCORA
T
• Pero sí puede suceder...
UPDATE... DELETE...
PUNTO DE CONFIRMACIÓN
COMMIT
T
BITÁCORA
a disco
SELECT... INSERT...
CAMBIOS
a disco
COMMIT
T
BITÁCORA
a disco
Tema 6. Recuperación de fallos
CAMBIOS
a disco
31
6.2 El proceso de recuperación del fallo de una
transacción
Puntos de validación
T1
UPDATE... SELECT...
DELETE...
INSERT...
SELECT... COMMIT
T2
T3
UPDATE...
INSERT...
SELECT...
• ¿Cómo sabe el SGBD qué transacciones
Examinar TODA la bitácora:
debe deshacer?
ausencia de entradas COMMIT
• ¿Y cómo sabe cuáles debe rehacer?
Rehacer TODAS las Ti confirmadas
Tema 6. Recuperación de fallos
...
<INICIAR,T2>
<INICIAR,T3>
<ESCRIBIR,T2,...>
<INICIAR,T1>
<ESCRIBIR,T1,...>
<ESCRIBIR,T3,...>
<LEER,T1,...>
<ESCRIBIR,T3,...>
<LEER,T2,...>
<ESCRIBIR,T1,...>
<COMMIT,T2>
<LEER,T3,...>
mejora con
puntos de
validación
32
6.2 El proceso de recuperación del fallo de una
transacción
Puntos de validación
(2)
• SGBD marca automáticamente un punto de validación...
– Cada m minutos, o
– Tras escribir t entradas <COMMIT,Ti> en bitácora desde
el último punto de validación
• Es otro tipo de entrada en el fichero de bitácora
< registro_de_validación >
– Este registro contiene:
• Lista de identificadores de transacciones activas en ese instante
• Dirección en el fichero bitácora de 1ª y ultª entradas para cada Ti
activa
Tema 6. Recuperación de fallos
33
6.2 El proceso de recuperación del fallo de una
transacción
Puntos de validación
(3)
• Marcar un punto de validación significa ...
1. Suspender la ejecución de las transacciones
2. Forzar escritura en disco del búfer de bitácora
3. Forzar escritura en disco de todo bloque del búfer
de BD modificado
4. Escribir en búfer de bitácora el registro_de_validación y
forzar su escritura en disco
5. Escribir en Fichero Especial de Arranque la dirección que
ocupa el registro_de_validación dentro del fichero bitácora
6. Reanudar la ejecución de las transacciones
Tema 6. Recuperación de fallos
34
6.2 El proceso de recuperación del fallo de una
transacción
Puntos de validación
(4)
 Al marcar un punto de validación se transfiere al disco el
efecto de las operaciones ESCRIBIR realizadas hasta ese
instante por las transacciones
– Pero no son los únicos momentos en los que se consolidan cambios
en disco... ¿en qué otros se realiza?
• El uso de puntos de validación permite, en el proceso de
recuperación...
– Recorrer la bitácora a partir del último punto de
validación (y no desde el principio)
– Ignorar Ti confirmadas antes del último punto de
validación (no es necesario rehacer todas las confirmadas)
Tema 6. Recuperación de fallos
35
6.3 Técnicas de recuperación de fallos
Estrategia de recuperación representativa
 Tras un fallo de tipo 5 o 6, que produjo daños en la BD...
• Restaurar copia de seguridad de la BD
• Reconstruir un estado más actual: rehacer operaciones de T
confirmadas hasta el momento de la caída  bitácora
 Tras un fallo de tipos 1 a 4...
• Invertir modificaciones que provocaron la inconsistencia:
deshacer algunas operaciones  bitácora
• Si es necesario, asegurar cambios correctos: rehacer algunas
otras operaciones  bitácora
 Es necesario seguir una técnica de recuperación
Tema 6. Recuperación de fallos
36
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización diferida
• Ninguna transacción T modifica la BD antes de llegar a
su punto de confirmación
• Se difiere la consolidación de cambios realizados por T hasta
después de confirmarse T
UPDATE... DELETE...
COMMIT
BITÁCORA
a disco
CAMBIOS
a disco
T
• Si el fallo ocurre antes de alcanzar T su punto de
confirmación, no es necesario deshacer sus operaciones
• Si el fallo ocurre después de alcanzar T su punto de
confirmación, es necesario rehacer sus operaciones
Tema 6. Recuperación de fallos
37
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización diferida
(2)
 Algoritmo NO-DESHACER / REHACER
1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías
2. Inicializar ACTIVAS con la lista de transacciones activas almacenada en
el último registro_de_validación en bitácora
3. Examinar la bitácora a partir del último punto de validación en adelante
4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS
5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a
CONFIRMADAS
6. Al terminar de examinar la bitácora:
• Rehacer las operaciones <ESCRIBIR,...> de las transacciones en
CONFIRMADAS, en el mismo orden en que aparecen en bitácora
• Ignorar transacciones de la lista ACTIVAS (más adelante Reiniciar)
Tema 6. Recuperación de fallos
38
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización diferida
(y 3)
• En bitácora, las entradas <ESCRIBIR,...> sólo necesitan guardar
el valor_nuevo: pueden rehacerse pero nunca deshacerse
• La operación reiniciar T es reintroducir T en el sistema, como si
fuera nueva
– Puede hacerlo el SGBD de forma automática
– o el usuario manualmente
 Las operaciones se reharán en el orden en que aparecen
anotadas en bitácora.
No se rehace cada T confirmada “en aislado”, sino que
se van rehaciendo todas las confirmadas “a la vez”,
operación a operación.
Tema 6. Recuperación de fallos
39
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización inmediata
• Una transacción T puede modificar la BD antes de
llegar a su punto de confirmación
• Algunos cambios realizados por T pueden consolidarse en
disco antes de confirmarse T ( modificaciones no comprometidas )
BITÁCORA
a disco
T
UPDATE... DELETE...
CAMBIOS
a disco
COMMIT
• Si el fallo ocurre antes de alcanzar T su punto de
confirmación (quizá después de grabar cambios en BD),
es necesario deshacer sus operaciones
• Si el fallo ocurre después de alcanzar T su punto de
confirmación, es necesario rehacer sus operaciones
Tema 6. Recuperación de fallos
40
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización inmediata
(2)
 Algoritmo DESHACER / REHACER
1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías
2. Inicializar ACTIVAS con la lista de transacciones activas almacenada en
el último registro_de_validación en bitácora
3. Examinar la bitácora a partir del último punto de validación en adelante
4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS
5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a
CONFIRMADAS
6. Al terminar de examinar la bitácora:
• Deshacer las operaciones <ESCRIBIR,...> de las transacciones de la
lista ACTIVAS, en orden inverso al que se anotaron en bitácora
• Rehacer las operaciones <ESCRIBIR,...> de las transacciones en
CONFIRMADAS, en el mismo orden en que aparecen en bitácora
Tema 6. Recuperación de fallos
41
6.3 Técnicas de recuperación de fallos
Técnica basada en la actualización inmediata
(3)
• En bitácora, las entradas <ESCRIBIR,...> necesitan guardar el
valor_anterior y valor_nuevo: pueden deshacerse o rehacerse
• Se debe deshacer primero, y rehacer después
 Las operaciones se desharán en el orden inverso al de
anotación en bitácora
No se deshace cada T activa “en aislado”, sino que se
van deshaciendo todas las activas “a la vez”, operación a
operación
 Las operaciones se reharán en el mismo orden en que
aparecen en bitácora
No se rehace cada T confirmada “en aislado”, sino que
se van rehaciendo todas las confirmadas “a la vez”,
operación a operación
Tema 6. Recuperación de fallos
42
6.3 Técnicas de recuperación de fallos
Técnica de actualización inmediata: variación
• Una transacción T puede modificar la BD antes de
alcanzar su punto de confirmación
• Todos los cambios hechos por T se llevan a la BD
antes de llegar T a su punto de confirmación
BITÁCORA
a disco
T
UPDATE... DELETE...
CAMBIOS
a disco
PUNTO DE CONFIRMACIÓN
COMMIT
• Si el fallo ocurre antes de alcanzar T su punto de
confirmación (quizá después de grabar cambios en BD),
es necesario deshacer sus operaciones
• Si el fallo ocurre después de alcanzar T su punto de
confirmación, no es necesario rehacer sus operaciones
Tema 6. Recuperación de fallos
43
6.3 Técnicas de recuperación de fallos
Práctica…
• Aplicar los tres algoritmos al ejemplo de la diapositiva 27
• ¿Qué ocurre con transacciones que terminan con
ROLLBACK?
Lo que se deja como “ejercicio”...
• Código del Algoritmo DESHACER/NO-REHACER
– Usado en la variación de la técnica de actualizaciones inmediatas
• Cambios necesarios en los algoritmos si el sistema no
utilizara puntos de validación/revisión
Tema 6. Recuperación de fallos
44
Anexo. Control de transacciones en Oracle
Inicio de transacción
– Cuando no hay ya una transacción en progreso, y se ejecuta una sentencia
LDD o LMD (interactivamente o dentro de una aplicación)
– Cada sentencia LDD es tratada como una transacción 
– No existe sentencia de tipo BEGIN TRANSACTION
Fin de transacción
• COMMIT 
– Finaliza la transacción actual y hace permanentes (confirma) los cambios
realizados
– COMMIT implícito (por parte del SGBD)
• El programa finaliza de forma normal
• Se sale de la herramienta (SQL*Plus, ...) correctamente
• Se ejecuta una sentencia LDD
– Oracle realiza COMMIT antes y después (si tiene éxito) de ejecutarla
– COMMIT explícito (por parte del programador/usuario)
COMMIT [WORK] ;
Tema 6. Recuperación de fallos
45
Anexo. Control de transacciones en Oracle
Fin de transacción
• ROLLBACK 
(2)
(cont.)
– Finaliza la transacción actual y deshace los cambios realizados
– ROLLBACK implícito (por parte del SGBD)
• La aplicación finaliza de forma anormal
• Se sale de la herramienta (SQL*Plus, ...) cerrando la ventana
– ROLLBACK explícito (por parte del programador/usuario)

ROLLBACK [WORK] [TO SAVEPOINT savepoint];
Tema 6. Recuperación de fallos
46
Anexo. Control de transacciones en Oracle
(y 3)
Reversión parcial de una transacción
• SAVEPOINT savepoint ;
– Establece un punto hasta el que se podrá hacer ROLLBACK después
UPDATE Empleado SET salario = 2000 WHERE nombre = 'Julia Ibáñez' ;
SAVEPOINT julia_salario ;
UPDATE Empleado SET salario = 1500 WHERE nombre = 'Cristina Ortín' ;
SAVEPOINT cristina_salario ;
SELECT SUM(salario) FROM Empleado ;  no se cumple que sea  315.000€
ROLLBACK TO SAVEPOINT julia_salario ;
UPDATE Empleado SET salario = 1300 WHERE nombre= 'Cristina Ortín' ;
COMMIT ;
Tema 6. Recuperación de fallos
47
Descargar

Recuperación de fallos del sistema - Departamento de Informática y