6. Recuperación de fallos

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

Contenidos 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

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. Addison-Wesley. (Cap. 17)

6.1 Conceptos generales de recuperación
EMPLEADO codEmp nomEmp depto 1 José 10 12 Antonio 20 7 Cristina 30 22 Julia 5 Rubén ... DEPARTAMENTO codDep nomDep ciudSede numEmp 20 Producción Murcia 2 10 Dirección Madrid 30 Sistemas Valencia 1 ... Transacción T: Añadir a la base de datos la empleada (14, ‘Eva’, 30)

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)?

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 Siempre que se introduce una transacción T en un SGBD para ser ejecutada, el SGBD tiene que asegurarse de que... Todas las operaciones de T se realicen con éxito y su efecto quede asentado de forma permanente en la BD en disco, o bien La transacción no tiene ningún efecto sobre la BD ni sobre cualquier otra transacción. El SGBD no debe permitir que se apliquen a la BD algunas operaciones de T y otras no, cosa que podría ocurrir si T falla después de ejecutar algunas de sus operaciones pero antes de realizarlas todas. Todo esto está muy relacionado con la propiedad de atomicidad y la de durabilidad de toda transacción en un sistema de bases de datos.

«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 El gestor de recuperación garantizará que... Toda transacción se ejecute Toda transacción se ejecute por completo Toda transacción se ejecuta sólo una vez (o varias, pero su efecto es el mismo que si sólo se hubiera ejecutado una vez)

Tipos de fallos Locales previstos por la aplicación «Saldo insuficiente en transacción de reintegro» Locales no previstos Error de programación (bug), interrupción Por imposición del control de concurrencia Violación de seriabilidad; bloqueo mortal 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 Fallo local: Sólo afecta a la T fallida Pérdida de datos de T en memoria princ. y búfer E/S

Tipos de fallos (y 2) 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 Fallos físicos o catastróficos Corte de suministro eléctrico, robo del disco, incendio, sabotaje, sobreescritura por error, etc.

O se ejecutan todas las operaciones que componen la transacción,
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

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 BD COMMIT T1 SGBD Ejemplo: INTERACCIÓN PERSONA - CAJERO AUTOMÁTICO: Inicio de transacción: Cuando se introduce la tarjeta Una vez concluida la operación realizada (reintegro), cuando solicitamos realizar otra operación (consulta de saldo) Fin de transacción: COMMIT: cuando se confirma que se desea salir ROLLBACK: cuando surge un error interno o cuando se detecta una operación no realizable (reintegro de una cantidad superior al saldo) KO T2 ROLLBACK T2

6.1.2 Propiedades de una transacción
Atomicidad Todo o nada Conservación de la Consistencia T lleva la BD de un estado de consistencia a otro No necesariamente se mantiene la consistencia “a mitad de T” Aislamiento (Isolation) T no muestra los cambios que produce hasta que finaliza Puede no imponerse de forma estricta (niveles de aislamiento) Durabilidad Una vez que T finaliza con éxito y es confirmada, los cambios perduran aunque el sistema falle después Conocidas como propiedades ACID SubSistema de Recuperación SS de Integridad + Programadores SS de Control de Concurrencia

PARCIALMENTE CONFIRMADA
6.1.3 y Operaciones y Estados de una transacción Diagrama de Transición de Estados de la ejecución de una transacción Verificaciones para control de concurrencia y recuperación LEER / ESCRIBIR INICIO DE TRANSACCIÓN FIN DE TRANSACCION PARCIALMENTE CONFIRMADA CONFIRMAR ACTIVA CONFIRMADA ABORTAR ABORTAR Para posibilitar el control de la concurrencia y la recuperación del sistema tras fallos o caídas del mismo, es necesario almacenar cuándo la transacción se inicia, termina, se confirma o se aborta. Así, el sistema se mantiene al tanto de las OPERACIONES: * INICIO_DE_TRANSACCIÓN * LEER o ESCRIBIR Operaciones de lectura/escritura de elementos de la base de datos, dentro de una transacción * FIN_DE_TRANSACCIÓN Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si los cambios realizados por la transacción (hasta ahora en buffers de memoria volátil) pueden aplicarse permanentemente a la base de datos en disco (CONFIRMAR) o si la transacción debe abortarse por alguna razón (viola el control de concurrencia, por ejemplo) * CONFIRMAR La transacción terminó con éxito, todos los cambios que ha realizado se pueden confirmar sin peligro en la BD y ya no serán cancelados. * ABORTAR La transacción terminó sin éxito y toda actualización que ha realizado se debe cancelar OPERACIONES ADICIONALES (para recuperación del sistema) ** DESHACER Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción completa ** REHACER Ciertas operaciones realizadas por una transacción deben repetirse, para asegurar que todas las operaciones de una transacción CONFIRMADA se hayan aplicado con éxito a la BD Otras: * DESHACER una operación * REHACER (algunas operaciones de) una transacción FALLIDA TERMINADA

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 Veamos cómo caracterizar los planes de transacciones según su recuperabilidad, es decir aquellos que facilitan la recuperación tras un fallo. Cuando se ejecutan varias transacciones siguiendo determinado plan y ocurre un fallo, es necesario asegurar que ninguna transacción confirmada ha de deshacerse jamás, para todas las transacciones que participan en el plan. Si eso está asegurado, entonces dicho plan es recuperable, puesto que se puede recuperar la BD a un estado correcto si ocurre un fallo a mitad de la ejecución de dicho plan. T1 lee de T2 si, a pesar de que otra T3 escribe X entre que T2 lo escribe y T1 lo lee, T3 aborta antes de que T1 lo lea. Es decir, si ocurre esto: e2(X) ; ... ; e3(X) ; ... ; r3 ; ... ; l1(X) P es recuperable si se cumple que si T1 lee de T2, entonces T2 debe confirmarse antes que T1 (o lo que es lo mismo, T1 debe confirmarse después de T2)

Pc: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; c2 ; r1 ;
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; El plan C es un plan no recuperable, y puede demostrarse suponiendo que puede darse el caso de que T1 abortara después de confirmarse T2, como se muestra a continuación: Pc: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; c2 ; r1 ; Si esto ocurre, sucede que... - T2 ha utilizado un elemento X modificado por una transacción T1 sin estar completada (confirmada/abortada), - Dicha T1 ha fallado y su efecto en la base de datos se descarta como si T1 nunca se hubiera ejecutado - T2 ha usado un elemento “sucio”, en cierto modo “inexistente”, así que debería ser anulada también. Pero T2 ya se ha confirmado (ha ejecutado un commit). Así, este plan C es NO recuperable.

Pe: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; r1 ;
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 La cancelación en cascada puede consumir mucho tiempo, porque además de que hay que comprobar y detectar qué transacciones deben revertirse en cascada, si son muchas las transacciones que hay que anular, serán muchas operaciones que deshacer para luego volver a reiniciar las transacciones después... Así que nos interesa poder saber qué planes nunca tendrán ese problema. En un plan sin reversión en cascada, toda T está al nivel de aislamiento READ COMMITED, puesto que T sólo lee datos escritos por otras T confirmadas.

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 Los planes estrictos están garantizados si se utiliza el protocolo de bloqueo en dos fases (B2F) estricto (estudiado en el tema anterior Control de la Concurrencia)

Redundancia + Técnica de Recuperación
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 Acciones para restablecer el contenido de la BD a un estado que asegure: Consistencia de la BD Atomicidad de transacciones Durabilidad de transacciones FICHERO DE BITÁCORA

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

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

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á)

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 BD Las operaciones de lectura y escritura pueden transferir bloques desde disco al búfer de BD, pero NO requieren específicamente la transferencia desde el búfer al disco. Ello lo realizará el propio SGBD cuando sea necesario: El gestor del búfer necesita espacio para otros bloques requeridos por las T’s El SGBD quiere reflejar en la BD los cambios sufridos por el bloque (o bloques) contenido en el búfer de BD Una operación ESCRIBIR(X) no tiene por qué provocar la escritura inmediata del búfer de BD en el disco, pues ese bloque puede contener otros datos que estén siendo accedidos por las transacciones, por ejemplo. Sin embargo, una vez que cierto elemento X modificado por T es almacenado en el búfer de BD (el bloque que lo contiene), X (modificado) queda accesible al resto de transacciones (de manera análoga a si ya estuviera almacenado en la base de datos), puesto que el búfer es común a todas las transacciones y cualquier operación LEER(X) de cualquier otra T busca el elemento X en el búfer de BD primero y, si no lo encuentra, en la BD. Búfer de BD Area de trabajo de T

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 Bitácora ... <INICIAR,T1> <ESCRIBIR,T1,...> <LEER,T1,...> <COMMIT,T1> Toda transacción T finaliza con COMMIT o ROLLBACK COMMIT y ROLLBACK finalizan una transacción, no un programa (que puede consistir de varias transacciones) Es importante observar que se dice “cuando TERMINA de ejecutar un COMMIT”: una cosa es que la transacción emita la operación COMMIT y otra cosa es que dicha operación se ejecute y lo haga con éxito. Desde que T emite COMMIT, hasta que dicha operación acaba de ejecutarse (y T llega, por tanto, a su punto de confirmación), la transacción T está en el estado PARCIALMENTE CONFIRMADA BD ok BD ok UPDATE... SELECT... INSERT... COMMIT T1

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 ... <INICIAR,T1> <ESCRIBIR,T1,...> <LEER,T1,...> <ROLLBACK,T1> BD ok UPDATE... SELECT... ROLLBACK Es importante observar que si T falla (ejecuta un ROLLBACK), NO SE BORRAN las entradas en bitácora de las operaciones que realizó T, sino que se anota la entrada ROLLBACK y se emplean las entradas correspondientes a T para realizar las acciones de recuperación necesarias para dejar el sistema consistente, como si T nunca se hubiera iniciado. T1

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 UPDATE... SELECT... T COMMIT 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

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) rehacer (< ESCRIBIR, T, X, 10, 5 >)  X = 5 en la BD Un ejemplo de por qué REHACER una transacción (confirmada antes de un fallo) no consiste en volver a ejecutarla, sino copiar los cambios realizados desde Bitácora a la BD. El ejemplo de la llamada telefónica: Dos personas hablan por teléfono móvil. La persona A está calculando una multiplicación compleja, cuyo resultado ha de comunicar a la persona B. Una vez que A ha terminado de calcular, le dice a la B: - Ya la he calculado y verificado, y el resultado es... Y justo en ese instante se corta la comunicación (fallo en la línea). Cuando, tras un rato se restablece la comunicación, la persona B que sabe que A ya calculó correctamente la multiplicación, así que sólo necesita que A le comunique el resultado, y no que A vuelva a calcular la multiplicación. A sería una transacción. B sería el SGBD. El corte de la comunicación sería un fallo (posterior a la finalización correcta de la transacción A).

Las entradas < LEER,... > son necesarias para detectar reversión en cascada 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 ... < ESCRIBIR, T1, X, 10, 5 > < LEER, T2, X > < ESCRIBIR, T2, X, 5, 25 > < ROLLBACK, T1 >

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

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 Seguir paso a paso, con el apoyo de la pizarra, el ejemplo de la página 7 y siguientes del tema escrito.

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 PUNTO DE CONFIRMACIÓN UPDATE... DELETE... COMMIT 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 El segundo punto significa que T sólo alcanza su PUNTO DE CONFIRMACIÓN cuando se ha terminado de escribir en disco el búfer de bitácora (las entradas correspondientes a T). Se fuerza la escritura en disco de las entradas de búfer de bitácora para T, antes de consolidar cambios hechos por T

Escritura anticipada en bitácora (y 4) Nunca puede ocurrir... ESCRITURA EN DISCO DE CAMBIOS ESCRITURA EN DISCO DE BITÁCORA UPDATE... DELETE... COMMIT T UPDATE... DELETE... T COMMIT CAMBIOS a disco BITÁCORA a disco Pero sí puede suceder... PUNTO DE CONFIRMACIÓN Lo que sí puede suceder: Si el fallo sucede una vez grabada la bitácora en disco, cuando se están llevando los cambios a la BD, puede ocurrir que se rehagan/deshagan operaciones que nunca se llevaron a la BD (las anotadas en el búfer de bitácora que sí dio tiempo a grabar en disco). T alcanza su PUNTO DE CONFIRMACIÓN cuando ha terminado de escribir en disco las entradas correspondientes a T incluidas en el búfer de bitácora. Si el fallo ocurre cuando se está escribiendo el búfer de bitácora en el disco (en el fichero de bitácora), no pasa nada, porque seguro que los cambios correspondientes (a las entradas en el búfer) no han sido llevados a la BD; si entre las entradas que no ha dado tiempo a almacenar está la entrada COMMIT, el SGBD entenderá que T no terminó (a pesar de que T sí ejecutara COMMIT) y deshará T empleando las entradas de bitácora en disco. SELECT... INSERT... T COMMIT CAMBIOS a disco BITÁCORA a disco

Puntos de validación ... <INICIAR,T2> <INICIAR,T3> <ESCRIBIR,T2,...> <INICIAR,T1> <ESCRIBIR,T1,...> <ESCRIBIR,T3,...> <LEER,T1,...> <LEER,T2,...> <COMMIT,T2> <LEER,T3,...> UPDATE... SELECT... T1 INSERT... DELETE... T2 COMMIT T3 ¿Cómo sabe el SGBD qué transacciones debe deshacer? ¿Y cómo sabe cuáles debe rehacer? Es posible evitar examinar TODA la bitácora y rehacer TODAS las transacciones confirmadas, haciendo uso de los PUNTOS DE VALIDACIÓN del sistema. Examinar TODA la bitácora: ausencia de entradas COMMIT mejora con puntos de validación Rehacer TODAS las Ti confirmadas

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 Punto de validación=Punto de control=Punto de revisión

Puntos de validación (3) Marcar un punto de validación significa ... Suspender la ejecución de las transacciones Forzar escritura en disco del búfer de bitácora Forzar escritura en disco de todo bloque del búfer de BD modificado Escribir en búfer de bitácora el registro_de_validación y forzar su escritura en disco Escribir en Fichero Especial de Arranque la dirección que ocupa el registro_de_validación dentro del fichero bitácora Reanudar la ejecución de las transacciones [*** El Por Qué del color AZUL en el paso 3 : Más adelante veremos que, dependiendo de la técnica de recuperación empleada por el SGBD, las modificaciones llevadas a la BD desde el búfer de BD en un punto de validación serán: Sólo las realizadas por las T’s confirmadas (actualizaciones diferidas), o bien Las realizadas por todas las T’s, confirmadas o no (actualizaciones inmediatas) ***]

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) [*** El Por Qué del color AZUL en parte del primer párrafo de esta diapositiva: En teoría en un punto de validación se llevan a disco los cambios hechos por las transacciones ya confirmadas, pero podrían llevarse también los realizados por no confirmadas, si se utiliza el protocolo de actualizaciones inmediatas, que permite que T modifique la base de datos antes de confirmarse. ***] Momentos en los que el SGBD realiza una consolidación de cambios en la BD en disco: Marcación de un Punto de validación, por parte del SGBD Se ha llenado el búfer de bitácora: se escribe dicho bloque en disco (en el fichero bitácora) Se ha llenado el búfer de BD y el SGBD necesita dicho espacio para traer otros bloques desde la BD: se escribe primero la bitácora y después el bloque de datos

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 Se considera que la bitácora no sufre ningún fallo.

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 BITÁCORA a disco CAMBIOS a disco UPDATE... DELETE... COMMIT Si el fallo ocurre después de alcanzar T su punto de confirmación, es necesario rehacer sus operaciones Si el fallo ocurre antes de alcanzar T su punto de confirmación, no es necesario deshacer sus operaciones T Durante la ejecución de T, todas sus actualizaciones se realizan en su área de trabajo privada y en el búfer de BD, y son anotadas en el búfer de bitácora (todo ello en memoria). [Por supuesto que, si se llena de entradas el búfer de bitácora, el sistema escribirá el bloque en el fichero de bitácora en disco y comenzará a llenar un nuevo bloque en el búfer de bitácora (memoria)] Una vez que T finaliza con éxito, se fuerza la escritura en disco del búfer de bitácora, momento en el que T alcanza su punto de confirmación. Después se consolidan los cambios en la BD en disco.

Técnica basada en la actualización diferida (2) Algoritmo NO-DESHACER / REHACER Crear dos listas ACTIVAS y CONFIRMADAS, vacías Inicializar ACTIVAS con la lista de transacciones activas almacenada en el último registro_de_validación en bitácora Examinar la bitácora a partir del último punto de validación en adelante Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a CONFIRMADAS 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)

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. Rehacer una operación ESCRIBIR realizada por T consiste en examinar su correspondiente entrada en bitácora <ESCRIBIR,T,X,valor_nuevo> y asignar valor_nuevo al elemento X de la BD. Esta operación rehacer debe ser idempotente (es decir, ejecutarla varias veces debe equivaler a ejecutarla una sola vez). En realidad todo el proceso de recuperación ha de ser idempotente, puesto que si el sistema falla durante el proceso de recuperación, el segundo intento de recuperación podría rehacer operaciones ESCRIBIR que ya hubieran sido restauradas durante el primer intento.

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 CAMBIOS a 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 T UPDATE... DELETE... COMMIT Se considera que la bitácora no sufre ningún fallo.

Técnica basada en la actualización inmediata (2) Algoritmo DESHACER / REHACER Crear dos listas ACTIVAS y CONFIRMADAS, vacías Inicializar ACTIVAS con la lista de transacciones activas almacenada en el último registro_de_validación en bitácora Examinar la bitácora a partir del último punto de validación en adelante Si se encuentra una entrada <INICIAR,T>, añadir T a la lista ACTIVAS Si se encuentra una entrada <COMMIT,T>, mover T de ACTIVAS a CONFIRMADAS 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 Deshacer una operación ESCRIBIR realizada por T consiste en examinar su correspondiente entrada en el fichero de bitácora <ESCRIBIR,T,X,valor_anterior,valor_nuevo> y asignar valor_anterior al elemento X de la BD. Rehacer una operación ESCRIBIR realizada por T consiste en examinar su correspondiente entrada en el fichero de bitácora <ESCRIBIR,T,X ,valor_anterior,valor_nuevo> y asignar valor_nuevo al elemento X de la BD. Estas operaciones deben ser idempotentes (es decir, ejecutarlas varias veces debe equivaler a ejecutarlas una sola vez).

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

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 CAMBIOS a disco PUNTO DE CONFIRMACIÓN Si el fallo ocurre después de alcanzar T su punto de confirmación, no es necesario rehacer sus operaciones 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 T UPDATE... DELETE... COMMIT Se modifica el concepto de PUNTO DE CONFIRMACIÓN: se retrasa hasta la grabación con éxito de los bloques del búfer de BD en disco. El SGBD seguirá el algoritmo DESHACER / NO-REHACER. Su definición se deja como ejercicio.

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

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] ;

 Anexo. Control de transacciones en Oracle (2)
Fin de transacción (cont.) ROLLBACK  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]; 

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  € ROLLBACK TO SAVEPOINT julia_salario ; UPDATE Empleado SET salario = 1300 WHERE nombre= 'Cristina Ortín' ; COMMIT ;

6. Recuperación de fallos

Presentaciones similares

Presentación del tema: "6. Recuperación de fallos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

6. Recuperación de fallos

Presentaciones similares

Presentación del tema: "6. Recuperación de fallos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback