Administración de Bases de Datos

Administración de Bases de Datos
Recuperación Objetivos Apreciar la necesidad de proteger la información frente a fallos del sistema Identificar los tipos de fallos que pueden ocurrir en un SGBD Comprender el propósito de los diarios (log) y los puntos de validación del sistema Conocer y entender diferentes técnicas del SGBD para recuperarse frente a fallos

Recuperación Contenidos Aspectos generales sobre recuperación Tipos de fallos El proceso de recuperación Técnicas de recuperación Anexo: Mecanismos de recuperación en Oracle

Aspectos generales sobre recuperación Los SGBD deben asegurar la disponibilidad de los datos Por lo que proporcionan mecanismos que permiten recuperar la BD frente a fallos lógicos o físicos que destruyen todos o partes de los datos Mecanismo de recuperación del SGBD: Responsable de la restauración de la BD al estado consistente previo al fallo También debe proporcionar alta disponibilidad, minimizando el tiempo de la incidencia

Aspectos generales sobre recuperación Transacción T: Añadir a la BDs la empleada (14, Julia, 30) EMPLEADO DEPARTAMENTO codEmp nomEmp dept 1 German 10 12 Antonio 20 7 Cristina 30 22 Eva 5 Rubén ... Dept nomDep Ciudad numEmp 20 Producción Murcia 2 10 Dirección Sevilla 30 Sistemas Barcelona 1 ...

Aspectos generales sobre recuperación El código de T podría ser: (0) EXEC SQL BEGIN TRANSACTION; ... EXEC SQL WHENEVER SQLERROR ROLLBACK; EXEC SQL INSERT INTO empleado VALUES (14, Julia, 30); EXEC SQL UPDATE departamento SET numEmp=numEmp+1 WHERE dept=30; 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?

Aspectos generales sobre recuperación Idea básica: atomicidad y durabilidad de toda transacción Secuencia de operaciones que llevan a 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 ... Ejecuta todas las operaciones con éxito y su efecto quede permanentemente en la BD, o bien, No tenga ningún efecto sobre la BD ni otras transacciones Nunca deben ejecutarse sólo algunas operaciones de T Ni tan siquiera por culpa de un “fallo” en mitad de T

Aspectos generales sobre recuperación Recuperación: Restablecer la información a un estado consistente, tras un fallo del sistema que ha dejado la BD en un estado inconsistente o sospechoso de serlo El principio básico de la recuperación de BD: Redundancia Física El SGBD vela porque: No se pierda ninguna transacción Ninguna transacción quede a medio ejecutarse (integridad) Ninguna transacción se realice más de una vez

Aspectos generales sobre recuperación Para realizar su labor, el subsistema de recuperación debe monitorizar las transacciones: Cuando se inicia Cuando se termina Cuando se confirma Cuando aborta El gestor de la recuperación monitoriza las siguientes transacciones: BEGIN_TRANSACTION READ o WRITE END_TRANSACTION COMMINT_TRANSACTION ROLLBACK ABORT

Estados y operaciones de una transacción protocolos de recuperación commit leer/escribir inicio activa fin Parcialmente confirmada confirmar confirmada abortar abortar fallida terminada rollback

Tipos de Fallos Fallo por imposición del control de concurrencia Violación de la seriabilización, bloqueo mortal, ... Fallo en la transacción Overflow, división por cero, violaciones de restricciones, ... Fallos locales (sólo afectan a la transacción fallida) Fallo software SGBD, SO, comunicaciones, ... Fallos globales Fallo hardware Fallos en discos, máquinas, redes, ... Fallos catastróficos Corte de suministro eléctrico, robo, incendio, inundación, sabotaje, borrado/sobreescritura accidental, etc.

Fallos Los fallos pueden afectar a las transacciones es sus propiedades ACID: Atomicity Consistency Isolation Durability Solución: Mecanismos de control de concurrencia Mecanismos de recuperación

Fallos Vamos a tratar principalmente: Fallos que provocan la pérdida de la memoria volátil (memoria principal) Fallos que provocan la pérdida de la memoria estable (memoria secundaria)

Diario Cuando ocurre un fallo, ¿cómo restaurar la base de datos a un estado consistente? Redundancia: diario (log, journal, registro histórico,...) Monitorizar la ejecución de las transacciones: cuando se inicia, confirma, aborta, acaba, qué operaciones realiza sobre qué datos Se obliga a que los datos que se modifican se escriban en disco antes en el diario que en la BD (log write-ahead protocol) Particiones de disco (o discos) distintos Copia de seguridad periódica Técnica de recuperación Acciones que permitan restablecer el contenido de la BD a un estado que asegure: consistency, atomicity, durability

Diario Entradas del fichero: [START_TRANSACTION, T, time] Indica que la transacción T ha comenzado la ejecución [COMMIT, T, time] Indica que T finalizó con éxito y su efecto puede ser confirmado en la BD en disco: los cambios pueden quedar permanentes en la BD. [ROLLBACK, T, time] Indica que la transacción ha sido anulada de forma que ninguna de sus operaciones tendrá efecto sobre la BD [READ, T, X, VALUE, time] Indica que T leyó el valor del elemento X de la BD [WRITE, T, X, OLDVALUE, NEWVALUE, time] Indica que T ha modificado el valor del elemento X

Diario Operaciones: REDO(T), rehacer: se escriben los NEWVALUE de T en la BD UNDO(T), deshacer: se escriben los OLDVALUE de T en la BD Recuperar un fallo de T consistirá en deshacer (UNDO) o rehacer (REDO) algunas de las operaciones, a partir del contenido del diario Actualizaciones del diario Inmediatas Diferidas

Pérdida de memoria Área de trabajo privada de cada transacción Buffer local Buffer Global BD input/output Bloques read/write Datos

COMMIT Cuando T realiza un COMMIT significa que: Todas las operaciones se ejecutaron con éxito El efecto de dichas operaciones se anotó en la bitácora, incluyendo el COMMIT! T ha llegado a un punto de confirmación y se puede suponer que: T está confirmada Sus cambios son permanentes en la BD Bloqueos liberados, buffers liberados, etc. ... [START ...] [WRITE ...] [READ ...] [COMMIT ...] BD ok BD ok T UPDATE... SELECT... INSERT... COMMIT...

ROLLBACK Cuando T realiza un ROLLBACK significa que: T ha resultado fallida, y sus operaciones no deben tener efecto El efecto de dichas operaciones se anotó en la bitácora, incluyendo el ROLLBACK! T ha llegado a un punto de confirmación y se puede suponer que: T está cancelada Sus operaciones han sido anuladas en la BD Bloqueos liberados, buffers liberados, etc. ... [START ...] [WRITE ...] [READ ...] [ROLLBACK ...] BD ok T UPDATE... SELECT... INSERT... ROLLBACK...

Proceso de recuperación Si el fallo ocurre cuando T está en ejecución, entonces se debe deshacer (UNDO), pues no alcanzó su punto de confirmación (no anotó COMMIT) Si el fallo ocurre cuando T ha sido confirmada, entonces se debe rehacer (REDO), pues no es seguro que todos los cambios hayan sido llevados a la BD en disco T UPDATE... SELECT... INSERT... T UPDATE... SELECT... INSERT... COMMIT...

Proceso de recuperación UNDO T implica deshacer cada una de las operaciones a partir de las anotaciones en bitácora, empezando por la última (orden inverso!) UNDO [WRITE, T, X, OldValue, NewValue, time] => X=OldValue en BD REDO T implica rehacer cada una de las operaciones, a partir de las anotaciones en el diario, empezando por la primera (mismo orden) REDO [WRITE, T, X, OldValue, NewValue, time] => X=NewValue en BD

Diario adelantado (a la BD) Escritura inmediata en el diario El diario es un fichero almacenado en disco, por lo que para insertar una nueva entrada es necesario: Copiar el bloque adecuado del fichero en 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! Escritura diferida en el diario El buffer del diario contiene un bloque del diario hasta que se llena de entradas, momento en el que se escribe en el disco Copiar el bloque desde memoria a disco Una única escritura por bloque!

Diario adelantado (a la BD) Cuando ocurre un fallo. Algunas entradas pueden no haber sido llevadas al diario en disco Con el fallo, se pierde el contenido de la memoria principal Entradas del diario en el buffer (bloque incompleto) Dichas entradas no serán consideradas en el proceso de recuperación! El subsistema de recuperación del SGBD sólo consulta el diario! Es necesario segur un protocolo de escritura anticipada del diario: diario adelantado

Diario adelantado (a la BD) No se pueden grabar en la BD los cambios realizados por T hasta que se haya escrito en disco toda entrada del diario para T (primero diario, luego BD) El COMMIT de T no se puede completar hasta que se haya escrito en disco cualquier entrada de diario para T pendiente de escribir (localizada en el buffer) Se fuerza la escritura en disco de las entradas del buffer de diario para T, antes de consolidar los cambios hechos por T Escrituras de bloque por transacción!

Diario adelantado (a la BD) Nunca puede ocurrir ... Pero sí puede suceder ... ESCRITURA BD ESCRITURA DIARIO T UPDATE... SELECT... INSERT... COMMIT... T UPDATE... SELECT... INSERT... COMMIT... ESCRITURA DIARIO ESCRITURA BD T UPDATE... SELECT... INSERT... COMMIT... ESCRITURA DIARIO ESCRITURA BD

Puntos de validación (checkpoint) Dado un fallo ... ¿Cómo sabe el SGBD qué transacciones deben deshacerse? Examinar TODO el diario buscando aquellas Ti sin COMMIT? ¿y cuáles debe rehacer? Examinar TODO el diario buscando las Ti con COMMIT? T1 UPDATE... SELECT... INSERT... T2 COMMIT... T3

Puntos de validación (checkpoint) El SGBD marca automáticamente un punto de validación: Cada cierto tiempo Tras escribir N entradas en el diario Cada vez que se graba un bloque de buffer a disco Es otro tipo de entrada del diario [CHECKPOINT ...] Contiene la lista de identificadores de transacciones activas Dirección en el diario de la primera y última entradas de cada transacción activa

Puntos de validación (checkpoint) Marcar un punto de validación significa ... Suspender la ejecución de todas las transacciones Forzar la escritura en disco del buffer del diario Forzar la escritura en disco de todo bloque del buffer global Escribir en el buffer del diario el registro de validación y forzar su escritura en disco Escribir en otro diario, la dirección de la entrada de validación en el diario Reanudar la ejecución de las transacciones

Puntos de validación (checkpoint) Los puntos de validación permiten: Recorrer el diario a partir del último punto de validación ... Y no desde el principio Ignorar las transacciones confirmadas antes del último punto de validación ... No es necesario rehacer TODAS las confirmadas leer/escribir inicio activa fin Parcialmente Confirmada confirmar confirmada Commit buffer [COMMIT] Commit diario [CHECKPOINT] terminada

Tipos de Fallos (1) Fallo por imposición del control de concurrencia Violación de la seriabilización, bloqueo mortal, ... (2) Fallo en la transacción Overflow, división por cero, violaciones de restricciones, ... Fallos locales (sólo afectan a la transacción fallida) (3) Fallo software SGBD, SO, comunicaciones, ... Fallos globales (4) Fallo hardware Fallos en discos, máquinas, redes, ... (5) Fallos catastróficos Corte de suministro eléctrico, robo, incendio, inundación, sabotaje, borrado/sobreescritura accidental, etc.

Técnicas de recuperación de fallos Ante fallos de tipo 1 o 2: Invertir las modificaciones que provocaron la inconsistencia: deshacer algunas operaciones <= diario Si es necesario, asegurar cambios correctos: rehacer algunas operaciones <= diario Ante fallos de tipo 3, 4 o 5: Restaurar copia de seguridad de la BD Reconstruir el estado consistente más reciente: rehacer algunas operaciones <= diario

Técnicas de recuperación de fallos Actualización diferida No se modifica la BD hasta después de realizar un COMMIT Se difiere la consolidación de los cambios realizados por la transacción hasta después de confirmarse Si el fallo ocurre antes de alcanzarse su punto de confirmación, no es necesario deshacer sus operaciones Si el fallo ocurre después de su punto de confirmación, es necesario rehacer sus operaciones ESCRITURA DIARIO ESCRITURA BD T UPDATE... SELECT... INSERT... COMMIT...

Técnicas de recuperación de fallos Algoritmo no-deshacer / rehacer Crear dos listas vacías: ACTIVAS y CONFIRMADAS Inicializar ACTIVAS con la lista de transacciones activas almacenada en el último registro de validación del diario Examinar el diario a partir del último punto de validación Si se encuentra [START T], añadir T a la lista ACTIVAS Si se encuentra [COMMIT T], mover R de ACTIVAS a CONFIRMADAS Al terminar de examinar el diario: Rehacer las operaciones <WRITE > de las transacciones en el mismo orden en que aparecen en el diario Reiniciar las transacciones de la lista ACTIVAS

Técnicas de recuperación de fallos En el diario, las entradas <WRITE > sólo necesitan guardar el valor nuevo (pueden rehacerse, pero nunca deshacerse) Reiniciar una transacción es reintroducirla en el sistema como si fuera nueva Las operaciones de rehacen en el orden en que aparecen anotadas en el diario No se rehace cada transacción “aisladamente”, si no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una.

Técnicas de recuperación de fallos Actualización inmediata La BD puede modificarse antes de realizar un COMMIT Se actualizan inmediatamente los cambios realizados por la transacción antes de confirmarlos Si el fallo ocurre antes de alcanzarse su punto de confirmación, es necesario deshacer sus operaciones Si el fallo ocurre después de su punto de confirmación, es necesario rehacer sus operaciones ESCRITURA DIARIO ESCRITURA BD T UPDATE... SELECT... INSERT... COMMIT...

Técnicas de recuperación de fallos Algoritmo deshacer / rehacer Crear dos listas vacías: ACTIVAS y CONFIRMADAS Inicializar ACTIVAS con la lista de transacciones activas almacenada en el último registro de validación del diario Examinar el diario a partir del último punto de validación Si se encuentra [START T], añadir T a la lista ACTIVAS Si se encuentra [COMMIT T], mover R de ACTIVAS a CONFIRMADAS Al terminar de examinar el diario: Deshacer las operaciones <WRITE > de las transacciones de la lista ACTIVAS, en orden inverso al del diario Rehacer las operaciones <WRITE > de las transacciones de CONFIRMADAS, en el mismo orden al del diario

Técnicas de recuperación de fallos En el diario, las entradas <WRITE > necesitan guardar el valor anterior y nuevo: pueden rehacerse o deshacerse Se debe deshacer primero y rehacer después Las operaciones de deshacen en el orden inverso en que aparecen anotadas en el diario No se deshace cada transacción activa “aisladamente”, si no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una. Las operaciones de rehacen en el mismo orden en que aparecen anotadas en el diario No se rehacen cada transacción confirmada “aisladamente”, si no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una.

Anexo: Mecanismos de recuperación en Oracle La Base de Datos entre otros contiene: Ficheros de datos (data files) Ficheros de recuperación (redo log files) Ficheros de control sobre la estructura física de la BDs (control file) Ficheros de parémetros (parameter file) Instancia de Oracle Conjunto de procesos que se ejecutan en background Zona de memoria global (System Global Area, SGA) Buffer de datos Buffer del diario Buffer de planes de ejecución de sentencias SQL Zona de memoria de proceso (Program Global Area, PGA)

Anexo: Mecanismos de recuperación en Oracle Procesos de una instancia ORACLE DBWR (Database writer) CKPT (Checkpoint) LOGWR (Log Writer) ARCH (Archive) Si se produce un fallo, el sistema recurre a los ficheros de log para recuperar un estado consistente Tamaño del fichero de log: escritura circular. El sistema va alternando entre dos o más ficheros. Cuando termina con el último, empieza con el primero Fallo en los ficheros de log: escritura doble (multiplexada) Archivo histórico de logs Volcado periódico total del contenido completo de la BD (full dump)

Anexo: Mecanismos de recuperación en Oracle Dump Volcar periódicamente el contenido entero de la BD: archivar De todos los datos (full dump) Sólo los datos modificados desde el último proceso de volcado (incremental dump) Volcado “en frío”: el SGBD está parado Volcado “en caliente”: el SGBD está funcionando Recuperación “en caliente”!

Administración de Bases de Datos

Presentaciones similares

Presentación del tema: "Administración de Bases de Datos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Administración de Bases de Datos

Presentaciones similares

Presentación del tema: "Administración de Bases de Datos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback