1
Recuperación de Fallos del Sistema
Competencias específicas
• Proteger la información almacenada frente a fallos del sistema mediante las técnicas disponibles en los SGBDs.
• Justificar la necesidad de disponer de un producto fiable, capaz de proteger la información frente a fallos del sistema.
• Explicar el propósito del fichero de bitácora y de los puntos de validación del• Explicar el propósito del fichero de bitácora y de los puntos de validación del sistema.
1Tema 7. Recuperación de Fallos del Sistema
Contenidos
Recuperación de Fallos del Sistema
7.1 Conceptos generales de recuperación
7.2 El proceso de recuperación del fallo de una transacción
7.3 Técnicas de recuperación de fallos del sistema
7.4 Recuperación de fallos en un SGBD particular
2Tema 7. Recuperación de Fallos del Sistema
2
Recuperación de Fallos del Sistema
Bibliografía más relevante
• [EN 2007] capítulo 19
• [CB 2005] capítulo 20
• [SKS 2002] capítulo 17
3Tema 7. Recuperación de Fallos del Sistema
Conceptos generales de recuperación
codEmp nomEmp depto1 José 10
EMPLEADO
DEPARTAMENTO12 Antonio 207 Cristina 30
22 Julia 205 Rubén 10... ... ...
codDep nomDep ciudSede numEmp20 Producción Murcia 210 Dirección Madrid 230 Sistemas Valencia 1... ... ... ...
• Transacción T: Añadir a la base de datos la empleada (14, ‘Eva’, 30)
4Tema 7. Recuperación de Fallos del Sistema
3
• 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);
Conceptos generales de recuperación
(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 SQLSQL
• ¿Cuál es el estado de la BD entre las sentencias (2) y (3)?
5Tema 7. Recuperación de Fallos del Sistema
• 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
Conceptos generales de recuperación
• 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
6Tema 7. Recuperación de Fallos del Sistema
4
• Recuperación«dejar la información de la BD en un estado correcto,
Conceptos generales de recuperación
jtras 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ónNo se pierda ninguna transacción– Ninguna transacción quede “a medio ejecutarse”– Ninguna transacción se ejecute más de una vez
7Tema 7. Recuperación de Fallos del Sistema
Fallo local:• Sólo afecta a la T
1. Locales previstos por la aplicación– «Saldo insuficiente en transacción de reintegro»
2 Locales no previstos
Conceptos generales de recuperación
Tipos de fallos
fallida• Pérdida de datos
de T en memoriaprinc. y búfer E/S
2. Locales no previstos– Error de programación (bug), interrupción
3. Por imposición del control de concurrencia– 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
8Tema 7. Recuperación de Fallos del Sistema
5
5. Fallos de disco
Conceptos generales de recuperación
Tipos de fallos (y 2)
– 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.
9Tema 7. Recuperación de Fallos del Sistema
• Hay que asegurar que una vez que T se ha confirmado, nunca será necesario anularla
Conceptos generales de recuperación
Recuperabilidad de planes de transacciones
,(cancelarla, revertirla, abortarla)
• Un plan P es recuperable si ninguna transacción Tde 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
10Tema 7. Recuperación de Fallos del Sistema
6
– Así, Tj “no lee de” Tk...Si Tk ha abortado antes de que Tj lea el elemento X
Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (2)
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 T1se confirme
Pd: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; c1 ; c2;
11Tema 7. Recuperación de Fallos del Sistema
• En un plan recuperable ninguna T confirmada tiene que anularse jamás, pero puede ocurrir el fenómeno de la reversión en cascada
Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (3)
reversión en cascadaTk 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 tiempop p
• 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 recuperable12Tema 7. Recuperación de Fallos del Sistema
7
• 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
Conceptos generales de recuperación
Recuperabilidad de planes de transacciones (y 4)
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• 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
13Tema 7. Recuperación de Fallos del Sistema
Conceptos generales de recuperación
Ejercicios de recuperabilidad
14Tema 7. Recuperación de Fallos del Sistema
8
• Cuando ocurre un fallo... ... ¿cómo restaurar la base de datos a un estado consistente?
Conceptos generales de recuperación
Bitácora
Redundancia + Técnica de Recuperación
Acciones para restablecer el contenido de la BD a un
Seguir la pista de la ejecución de cada transacción
estado que asegure:– Consistencia de la BD– Atomicidad de transacciones– Durabilidad de transacciones
cada transacción– Cuándo se inicia,
confirma o aborta– Qué operaciones
realiza sobre qué datos
FICHERODE
BITÁCORA
15Tema 7. Recuperación de Fallos del Sistema
• Fichero que almacena detalles sobre las operacionesefectuadas como parte de las transacciones
L di i j l i t hi tó i
Conceptos generales de recuperación
Bitácora (2)
– 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
16Tema 7. Recuperación de Fallos del Sistema
9
< INICIAR, T >
Conceptos generales de recuperación
Bitácora (3): tipos de entradas
– 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 l b d d t di l bi h li d den 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
17Tema 7. Recuperación de Fallos del Sistema
Suponemos que
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 deshacero rehacer algunas de sus operaciones, a partir del contenido de la bitácora (se verá)
18Tema 7. Recuperación de Fallos del Sistema
10
• 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
Conceptos generales de recuperación
Acceso a datos almacenados
– 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
BD
MEMORIA PRINCIPAL
Area de trabajo
de TBúferde BD
19Tema 7. Recuperación de Fallos del Sistema
• 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
Conceptos generales de recuperación
Punto de confirmación de una transacción
– El efecto de dichas operaciones se anotó en bitácora, incluyendo el COMMITT 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 ...
INICIAR T1
Bitácora
UPDATE... INSERT...SELECT...T1
COMMIT
<INICIAR,T1><ESCRIBIR,T1,...>
<LEER,T1,...><ESCRIBIR,T1,...>
<COMMIT,T1>...
BD okBD ok
20Tema 7. Recuperación de Fallos del Sistema
11
• Cuando T termina de ejecutar ROLLBACK significa que...– T ha resultado fallida
El ROLLBACK tó bitá
Conceptos generales de recuperación
Punto de confirmación de una transacción (y 2)
– 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...
T1ROLLBACK <INICIAR,T1>
<ESCRIBIR,T1,...><LEER,T1,...>
<ROLLBACK,T1>...
BD ok
21Tema 7. Recuperación de Fallos del Sistema
• Si el fallo ocurre cuando T está en curso de ejecución, entonces se debe deshacer T
P l ó t d fi ió ( tó <COMMIT T>)
El proceso de recuperación del fallo de unatransacción
– 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
UPDATE... SELECT...T
COMMIT
entonces se debe rehacer T– No es seguro que todo cambio haya sido llevado a la BD en disco
22Tema 7. Recuperación de Fallos del Sistema
12
• deshacer T implica deshacer cada una de sus operaciones, a partir de las anotaciones en bitácora, empezando por la última (orden inverso)
El proceso de recuperación del fallo de una transacción
ú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)el mismo orden)
< ESCRIBIR, T, X, valor_anterior, valor_nuevo >rehacer (< ESCRIBIR, T, X, 10, 5 >) X = 5 en la BD
23Tema 7. Recuperación de Fallos del Sistema
• Las entradas < LEER,... > son necesarias para detectar reversión en cascada
El proceso de recuperación del fallo de una transacción
T2 debe ser deshecha !
...< ESCRIBIR, T1, X, 10, 5 >
...< LEER, T2, X >
< ESCRIBIR, T2, X, 5, 25 >...
< ROLLBACK, T1 >
• 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
...
24Tema 7. Recuperación de Fallos del Sistema
13
• La bitácora es un fichero almacenado en disco, por lo que para insertar una nueva entrada es necesario
Escritura anticipada en bitácora
El proceso de recuperación del fallo de una transacción
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 deBúfer de bitácora, que contiene un bloque del fichero debitá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
25Tema 7. Recuperación de Fallos del Sistema
• Cuando ocurre un fallo, algunas entradas pueden no haber sido llevadas al fichero de bitácora en disco
Escritura anticipada en bitácora (2)
El proceso de recuperación del fallo de una transacción
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 p pde una transacción
• Es necesario seguir un protocolo de escritura anticipada en bitácora, o bitácora adelantada
26Tema 7. Recuperación de Fallos del Sistema
14
Bitácora adelantada• No se puede grabar en disco los cambios realizados por T
Escritura anticipada en bitácora (3)
El proceso de recuperación del fallo de una transacción
• No se puede grabar en disco los cambios realizados por Thasta que se haya escrito en disco toda entrada debitácora para T hasta el momento actual
UPDATE... DELETE...T
COMMIT
CAMBIOSa disco
BITÁCORAa disco
PUNTO DE CONFIRMACIÓN
• El COMMIT de T no se completa hasta que se haya escrito en discotoda 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
27Tema 7. Recuperación de Fallos del Sistema
• Nunca puede ocurrir...UPDATE DELETE COMMIT
ESCRITURA ENDISCO DE CAMBIOS ESCRITURA EN
DISCO DE BITÁCORA
Escritura anticipada en bitácora (y 4)
El proceso de recuperación del fallo de una transacción
UPDATE... DELETE...T
COMMIT DISCO DE BITÁCORA
UPDATE... DELETE...T
COMMIT
C OSBITÁCORA
• Pero sí puede suceder...PUNTO DE CONFIRMACIÓN
CAMBIOSa disco
BITÁCORAa disco
SELECT... INSERT...T
COMMIT
CAMBIOSa disco
BITÁCORAa disco
28
15
Puntos de validación
El proceso de recuperación del fallo de una transacción
UPDATE... SELECT...T1
INSERT...
...<INICIAR,T2><INICIAR,T3><ESCRIBIR,T2,...>
ó b l é i d b
T1DELETE... SELECT...
T2COMMIT
UPDATE... INSERT...T3
SELECT...
<INICIAR,T1><ESCRIBIR,T1,...><ESCRIBIR,T3,...><LEER,T1,...><ESCRIBIR,T3,...><LEER,T2,...><ESCRIBIR,T1,...><COMMIT T2>• ¿Cómo sabe el SGBD qué transacciones debe
deshacer?
• ¿Y cómo sabe cuáles debe rehacer?
<COMMIT,T2><LEER,T3,...>Examinar TODA la bitácora:
ausencia de entradas COMMIT
Rehacer TODAS las Ti confirmadas
mejora conpuntos devalidación
29Tema 7. Recuperación de Fallos del Sistema
• SGBD marca automáticamente un punto de validación...C d i t
Puntos de validación (2)
El proceso de recuperación del fallo de una transacció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:– 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
30Tema 7. Recuperación de Fallos del Sistema
16
• Marcar un punto de validación significa ...
Puntos de validación (3)
El proceso de recuperación del fallo de una transacción
1. Suspender la ejecución de las transacciones2. Forzar escritura en disco del búfer de bitácora3. Forzar escritura en disco de todo bloque del búfer
de BD modificado4. Escribir en búfer de bitácora el registro_de_validación y
forzar su escritura en discoforzar su escritura en disco5. Escribir en Fichero Especial de Arranque la dirección que
ocupa el registro_de_validación dentro del fichero bitácora6. Reanudar la ejecución de las transacciones
31Tema 7. Recuperación de Fallos del Sistema
Al marcar un punto de validación se transfiere al di l f t d l i ESCRIBIR
Puntos de validación (4)
El proceso de recuperación del fallo de una transacción
disco el efecto de las operaciones ESCRIBIRrealizadas 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 p p ,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)32Tema 7. Recuperación de Fallos del Sistema
17
• Describir los posibles tipos de fallos
Resumen
• Condiciones de recuperabilidad de un plan de transacciones
• Rol desempeñado por la bitácora
• Efectos del punto de validación
33Tema 7. Recuperación de Fallos del Sistema
Tras un fallo de tipo 5 o 6, que produjo daños en la BD...
Estrategia de recuperación representativa
Técnicas de recuperación de fallos
p , q p j• 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
34Tema 7. Recuperación de Fallos del Sistema
18
• Ninguna transacción T modifica la BD antes de llegar a su punto de confirmaciónS difi l lid ió d bi li d T h t
Técnica basada en la actualización diferida
Técnicas de recuperación de fallos
• Se difiere la consolidación de cambios realizados por T hasta después de confirmarse T
UPDATE... DELETE...T
COMMIT
• Si el fallo ocurre antes de alcanzar T su punto de
BITÁCORAa disco
CAMBIOSa disco
Si el fallo ocurre antes de alcanzar T su punto deconfirmación, no es necesario deshacer sus operaciones
• Si el fallo ocurre después de alcanzar T su punto deconfirmación, es necesario rehacer sus operaciones
35Tema 7. Recuperación de Fallos del Sistema
Algoritmo NO-DESHACER / REHACER1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías
Técnica basada en la actualización diferida (2)
Técnicas de recuperación de fallos
1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías2. Inicializar ACTIVAS con la lista de transacciones activas almacenada en el
último registro_de_validación en bitácora3. Examinar la bitácora a partir del último punto de validación en adelante4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a
CONFIRMADAS6 Al t i d i l bitá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)
36Tema 7. Recuperación de Fallos del Sistema
19
• En bitácora, las entradas <ESCRIBIR,...> sólo necesitanguardar el valor nuevo: pueden rehacerse pero nunca
Técnica basada en la actualización diferida (y 3)
Técnicas de recuperación de fallos
g _ p pdeshacerse
• 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 queLas 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.
37Tema 7. Recuperación de Fallos del Sistema
• Una transacción T puede modificar la BD antes de llegar a su punto de confirmaciónAl bi li d T d lid
Técnica basada en la actualización inmediata
Técnicas de recuperación de fallos
• Algunos cambios realizados por T pueden consolidarse en disco antes de confirmarse T ( modificaciones no comprometidas )
UPDATE... DELETE...T
COMMIT
BITÁCORAa disco
CAMBIOSa disco
• 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
38Tema 7. Recuperación de Fallos del Sistema
20
Algoritmo DESHACER / REHACER1. Crear dos listas ACTIVAS y CONFIRMADAS, vacías
Técnica basada en la actualización inmediata (2)
Técnicas de recuperación de fallos
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 adelante4. Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS5. Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a
CONFIRMADAS6. Al terminar de examinar la bitácora:
Deshacer las operaciones <ESCRIBIR > de las transacciones de la lista ACTIVAS en • 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
39Tema 7. Recuperación de Fallos del Sistema
• En bitácora, las entradas <ESCRIBIR,...> necesitan guardar elvalor_anterior y valor_nuevo: pueden deshacerse o rehacerse
S d b d h i h d é
Técnica basada en la actualización inmediata (3)
Técnicas de recuperación de fallos
• Se debe deshacer primero, y rehacer despuésLas operaciones se desharán en el orden inverso al de
anotación en bitácoraNo se deshace cada T activa “en aislado”, sino que se van deshaciendo todas las activas “a la vez”, operación a operaciónLas operaciones se reharán en el mismo orden en queLas operaciones se reharán en el mismo orden en que
aparecen en bitácoraNo se rehace cada T confirmada “en aislado”, sino que se van rehaciendo todas las confirmadas “a la vez”, operación a operación
40Tema 7. Recuperación de Fallos del Sistema
21
• 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
Técnica de actualización inmediata: variación
Técnicas de recuperación de fallos
• Todos los cambios hechos por T se llevan a la BD antes de llegar T a su punto de confirmación
UPDATE... DELETE...T
COMMIT
BITÁCORAa disco
CAMBIOSa disco PUNTO DE CONFIRMACIÓN
• 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 deconfirmación, no es necesario rehacer sus operaciones
41Tema 7. Recuperación de Fallos del Sistema
Técnicas de recuperación de fallos
• Aplicar los tres algoritmos al ejemplo de la diapositiva 29??
Práctica…
• Código del Algoritmo DESHACER/NO-REHACERUsado en la variación de la técnica de actualizaciones inmediatas
Lo que se deja como “ejercicio”...
• ¿Qué ocurre con transacciones que terminan con ROLLBACK?
– Usado en la variación de la técnica de actualizaciones inmediatas
• Cambios necesarios en los algoritmos si el sistema noutilizara puntos de validación/revisión
42Tema 7. Recuperación de Fallos del Sistema
22
Ejercicio
43Tema 7. Recuperación de Fallos del Sistema