15. Recuperación de fallos del sistema

Transcripción

1 15. Recuperación de fallos del sistema 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 15. Recuperación de fallos del sistema Recuperación de fallos del sistema Contenidos 1. Conceptos generales de recuperación 2. El proceso de recuperación del fallo de una 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. 18 y 20) [CBS 1998] Connolly, T.; Begg C.; Strachan, A.: Database Systems: A Practical Approach to Design, Implementation and Management. 2 nd Edition. Addison-Wesley. (Cap. 17) Tema 15. Recuperación de fallos del sistema 2

2 15.1 Conceptos generales de recuperación EMPLEADO codemp nomemp depto 1 José 10 DEPARTAMENTO 12 Antonio 20 coddep nomdep ciudsede numemp 7 Cristina Producción Murcia 2 22 Julia Dirección Madrid 2 5 Rubén Sistemas Valencia 1 Transacción T: Añadir a la base de datos la empleada (14, Eva, 30) Tema 15. Recuperación de fallos del sistema Conceptos generales de recuperación El código de T podría ser el siguiente: (SQL embebido) (0) EXEC SQL BEGIN TRANSACTION; (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 con varias operaciones/sentencias SQL Cuál es el estado de la BD entre las sentencias (2) y (3)? Tema 15. Recuperación de fallos del sistema 4

3 15.1 Conceptos generales de recuperación Idea básica: atomicidad y durabilidad de toda 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 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 15. Recuperación de fallos del sistema 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 Ninguna quede a medio ejecutarse Ninguna se ejecute más de una vez Tema 15. Recuperación de fallos del sistema 6

4 15.1 Conceptos generales de recuperación Tipos de fallos 1. Locales previstos por la aplicación «Saldo insuficiente en de reintegro» 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 Fallo local: Sólo afecta a la fallida Pérdida de memoria princ. y búfer E/S 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 15. Recuperación de fallos del sistema 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 15. Recuperación de fallos del sistema 8

5 15.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 T de P se confirma antes de haberse confirmado toda T que ha escrito un dato que T lee Una T j lee de la T k, si T k escribe un elemento X y luego T j lo lee Tema 15. Recuperación de fallos del sistema Conceptos generales de recuperación Recuperabilidad de planes de transacciones (2) Así, T j no lee de T k Si T k ha abortado antes de que T j lea el elemento X Si otras transacciones escriben X después de que T k lo haya escrito y antes de que T j lo lea Ejemplo de plan no recuperable P c : l 1 (X) ; e 1 (X) ; l 2 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; Solución: postergar la confirmación de T 2 hasta que T 1 se confirme P d : l 1 (X) ; e 1( X) ; l 2 (X) ; l 1 (Y) ; e 2 (X) ; e 1 (Y) ; c 1 ; c 2 ; Tema 15. Recuperación de fallos del sistema 10

6 15.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 T k no confirmada debe anularse porque ha leído X de T j, y T j ha sido abortada Ejemplo de plan con reversión en cascada P e : l 1 (X) ; e 1 (X) ; l 2 (X) ; l 1 (Y) ; e 2 (X) ; e 1 (Y) ; r 1 ; 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 P e para que evite la cancelación en cascada? iun plan sin cancelación en cascada, es recuperable Tema 15. Recuperación de fallos del sistema 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 T 1 es abortada, es necesario deshacer todas sus operaciones de escritura Deshacer una operación de escritura e 1 (X,5) consiste en restaurar el valor anterior del elemento X Pero esto puede no funcionar correctamente si el plan no es estricto: P f : e 1 (X,5) ; e 2 (X,8) ; r 1 ; iun plan estricto es recuperable y sin cancelación en cascada Tema 15. Recuperación de fallos del sistema 12

7 15.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 las transacciones Cuándo se inicia, confirma o aborta Qué operaciones realiza sobre qué datos 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 Tema 15. Recuperación de fallos del sistema 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 15. Recuperación de fallos del sistema 14

8 15.1 Conceptos generales de recuperación Bitácora (3): tipos de entradas < INICIAR, T > Indica que la 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 T ha sido anulada de forma que ninguna de sus operaciones tendrá efecto sobre la BD: la será revertida, todas sus operaciones serán deshechas Tema 15. Recuperación de fallos del sistema 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 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 15. Recuperación de fallos del sistema 16

9 15.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 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 Búfer de BD BD Tema 15. Recuperación de fallos del sistema Conceptos generales de recuperación Punto de confirmación de una 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 UPDATE SELECT INSERT T1 BD ok COMMIT BD ok <INICIAR,T1> <ESCRIBIR,T1,> <LEER,T1,> <ESCRIBIR,T1,> <COMMIT,T1> Tema 15. Recuperación de fallos del sistema 18

10 15.1 Conceptos generales de recuperación Punto de confirmación de una (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 BD ok UPDATE SELECT T1 ROLLBACK <INICIAR,T1> <ESCRIBIR,T1,> <LEER,T1,> <ROLLBACK,T1> Tema 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una 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 UPDATE SELECT T COMMIT Tema 15. Recuperación de fallos del sistema 20

11 15.2 El proceso de recuperación del fallo de una 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 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una 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 15. Recuperación de fallos del sistema 22

12 15.2 El proceso de recuperación del fallo de una 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 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una 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 Es necesario seguir un protocolo de escritura anticipada en bitácora, o bitácora adelantada Tema 15. Recuperación de fallos del sistema 24

13 15.2 El proceso de recuperación del fallo de una Escritura anticipada en bitácora (3) Bitácora adelantada No se pueden 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 El COMMIT de T no se puede completar hasta que se haya escrito en disco cualquier entrada de bitácora para T pendiente de escribir» 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 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una Escritura anticipada en bitácora (y 4) Nunca puede ocurrir UPDATE DELETE T Pero sí puede suceder UPDATE SELECT T SELECT INSERT T BITÁCORA ESCRITURA EN DISCO DE CAMBIOS COMMIT COMMIT BITÁCORA CAMBIOS CAMBIOS ESCRITURA EN DISCO DE BITÁCORA PUNTO DE CONFIRMACIÓN COMMIT Tema 15. Recuperación de fallos del sistema 26

14 15.2 El proceso de recuperación del fallo de una Puntos de validación T2 UPDATE SELECT T1 DELETE T3 UPDATE SELECT INSERT INSERT COMMIT SELECT Cómo sabe el SGBD qué transacciones debe deshacer? Examinar TODA la bitácora: ausencia de entradas COMMIT Y cómo sabe cuáles debe rehacer? Rehacer TODAS las Ti confirmadas <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 Tema 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una 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 15. Recuperación de fallos del sistema 28

15 15.2 El proceso de recuperación del fallo de una Puntos de validación (3) Marcar un punto de validación significa 1. Suspender la ejecución de las transacciones 2. Forzar escritura del búfer de bitácora en disco 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 del registro_de_validación en fichero bitácora 6. Reanudar la ejecución de las transacciones Tema 15. Recuperación de fallos del sistema El proceso de recuperación del fallo de una 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 15. Recuperación de fallos del sistema 30

16 15.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 15. Recuperación de fallos del sistema Técnicas de recuperación de fallos Técnica basada en la actualización diferida Ninguna 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 T COMMIT BITÁCORA CAMBIOS 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 15. Recuperación de fallos del sistema 32

17 15.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 (más adelante) Reiniciar las transacciones de la lista ACTIVAS Tema 15. Recuperación de fallos del sistema 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 i 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 a la vez, operación a operación Tema 15. Recuperación de fallos del sistema 34

18 15.3 Técnicas de recuperación de fallos Técnica basada en la actualización inmediata Una 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 CAMBIOS T UPDATE DELETE 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 15. Recuperación de fallos del sistema 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 15. Recuperación de fallos del sistema 36

19 15.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 i 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 a la vez, operación a operación i 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 a la vez, operación a operación Tema 15. Recuperación de fallos del sistema Técnicas de recuperación de fallos Técnica de actualización inmediata: variación Una 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 CAMBIOS PUNTO DE CONFIRMACIÓN T UPDATE DELETE 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 15. Recuperación de fallos del sistema 38