Conceptos de Recuperación Descripción de la Recuperación Recuperación y Clasificación de los Algoritmos Algoritmos de Recuperación Recuperarse al fallo de una transacción transacción significa que la base de datos se restaura restaura al estado coherente coherente más reciente, inmediatamente anterior al momento del fallo para esto el sistema guarda las información sobre los cambios de las transacciones esta información se guarda guarda en el registro del sistema. 1. Si hay un fallo como la caída del disco, el el sistema restaura una copia copia se seguridad del registro, hasta el momento del fallo. 2. Cuando el daño se vuelve inconsistente, se pueden rehacer algunas operaciones para restaurar a un estado consistente. En este caso no se necesita una copia archivada. Actualización Diferida Diferida No se actualiza físicamente la base de datos Hasta Hasta que no haya alcanzado su punto de confirmación. confirmación. Actualización Inmediata Inmediata La base de datos puede ser actualizada por Algunas Algunas Operaciones antes de que esta ultima ultima alcance su punto confirmación.
de
Tipos de Almacenamiento ·
Almacenamiento volátil: no sobrevive a las caídas del sistema.
·
Almacenamiento no volátil: disco, cinta...: existen accidentes.
· Almacenamiento estable frente al no estable: la información no se pierde “nunca”, se repite en varios medios no volátiles (disco) con modos de fallo independientes. Almacenamiento en en cache (búfer) de los bloques de disco disco El proceso de recuperación se entrelaza con funciones del sistema operativo en particular con el almacenamiento en cache o en búfer en la memoria principal, Normalmente se reserva una colección de búferes en memoria, denominados cache DBMS. Se utiliza un directorio para rastrear los elementos de la base de datos que se encuentra en los búferes. Bit sucio que puede incluirse en la entrada entrada del directorio, para indicar si se ha modificado modificado o no el búfer. Pin-un pin dice que una página en cache se está accediendo accediendo actualmente. actualmente. Actualización en el lugar (in place) escribe en el búfer el mismo ubicación ubicación de disco original. original. Shadowing(en la sombra) escribe escribe un búfer actualizado en una ubicación ubicación diferente. BFIM before image imagen antes de la actualización. AFIM after imagen imagen después de la actualización. Registro antes de la escritura, robar/no-robar y forzar no forzar En este caso, el mecanismo de recuperación debe garantizar la grabación de la BFIM de los datos en la entrada apropiada del registro del sistema y que esa entrada se vuelque en el disco antes que la BFIM sea sobrescrita con la AFIM de la base de datos del disco. Puntos de control en el registro del sistema y puntos de control difusos Otro tipo de entrada en el registro es el denominado punto de control [checkpoint]. En este punto el sistema escribe en la base de datos en disco todos los búferes del DBMS que se han modificado. No tienen que rehacer sus operaciones, es decir, ESCRIBIR en caso caso de una caída del sistema. El gestor de recuperaciones de un DBMS debe decidir en qué intervalos tomar un punto de control. La toma de un punto de control consiste en las siguientes acciones: 1.
Suspender temporalmente la ejecución de las las transacciones. transacciones.
2.
Forzar la escritura de disco de todos los búferes de memoria que se hayan modificado.
3.
Escribir un registro [checkpoint] en el registro del sistema y forzar la escritura del registro en el disco.
4.
Reanudar la ejecución de las transacciones.
Diarios para Recuperación ·
Se utilizan también los términos log y journal.
·
Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos.
·
Esta información permite recuperar.
·
Se almacena en disco.
·
Operaciones posibles a reflejar:
[start,T] [write,T,X, valor_viejo, valor_nuevo] (Opcional) [read,T,X] [commit,T] [abort,T] undo, redo 1 Técnicas de Recuperación Basadas en la Actualización Diferida · Graba todas las actualizaciones de la BD en el diario, pero aplaza la ejecución de todas las operaciones de escritura (write) de una transacción hasta que ésta se encuentre parcialmente cometida. ·
Solamente requiere el nuevo valor del dato.
·
Si la transacción aborta (no llega a committed), simplemente hay que ignorar las anotaciones en el diario.
·
Para recuperaciones usa el procedimiento:
redo (Ti), que asigna los nuevos valores a todos los datos que actualiza Ti. · Después de ocurrir un fallo, se consulta el diario para determinar que transacciones deben repetirse y cuales anularse. Ti debe anularse si el diario contiene el registro start pero no el commit. Ti debe repetirse si el diario contiene el registro start y el commit. · La operación redo debe ser idempotencia, es decir, ejecutarla varias veces debe producir el mismo resultado que ejecutarla una sola vez. Los Redo comienzan a hacerse en el último checkpoint! Interrogación 10000?: no sabemos si la información está en disco o en memoria Recuperación Mediante la Actualización Diferida en un Entorno monousuario El algoritmo RDU se utiliza un procedimiento rehacer, proporcionado con posterioridad, Para rehacer operaciones escribir_elemento. Actualización Diferida con ejecución concurrente en un entorno multiusuario Planificación de la ejecución de las transacciones Cuando se tomo el punto de control en el momento t1 l a transacción T1 se habría confirmado.
determinadas
Recuperaciones Basadas en Actualizaciones Inmediatas · Permite que las actualizaciones se graben en la BD mientras la transacción está todavía en estado activo (actualizaciones no cometidas). ·
Antes de ejecutar un output (X), deben grabarse en memoria estable los registros del diario correspondientes a X.
·
Los registros del diario deben contener tanto el valor antiguo como el nuevo.
·
El esquema de recuperación utiliza dos procedimientos de recuperación:
undo (Ti): restaura los datos que Ti actualiza a los valores que tenían antes. redo (Ti): asigna los nuevos valores a todos los datos que actualiza Ti. · Después de ocurrir un fallo, el procedimiento de recuperación consulta el diario para determinar qué transacciones deben repetirse y cuáles deshacerse: Ti debe deshacerse si el diario contiene el registro starts pero no el commit. Ti debe repetirse si el diario contiene el registro starts y el commit. · Las operaciones undo y redo deben ser idempotencias para garantizar la consistencia de la BD aun cuando se produzcan fallos durante el proceso de recuperación. Recuperación hasta un punto de validación 1. Examina el diario hacia atrás hasta localizar un registro . 2. Considera sólo los registros existentes entre este punto y el final del diario. 3. Ejecuta undo(Tj) para las transacciones que no tengan registro , partiendo del final del fichero. 4. Ejecuta redo (Ti) para las transacciones que tengan su registro , partiendo desde el punto de verificación hasta el final del diario. Procedimientos de Recuperación 1.
Recuperación Normal
· Tiene lugar después de una parada normal de la máquina, en la que se escribe un punto de verificación como último registro del diario. · Este procedimiento se ejecuta cuando el último registro del diario es un punto de verificación o recuperación del sistema. ·
Este tipo de recuperación también tiene lugar cuando aborta una transacción, debido a la razón que sea.
2.
Recuperación en Caliente
·
Después de un error del sistema.
· Se ejecuta cuando el último registro del diario no es un punto de verificación y el operador no indica pérdida de memoria secundaria. ·
El procedimiento de recuperación es el indicado en el apartado referente a los puntos de verificación en el diario.
3.
Recuperación en Frío
·
Después de un incidente con la memoria masiva dañada.
·
Se ejecuta si se pierden datos o la BD ya no es coherente.
·
Se utiliza:
Copia de seguridad (backup) más reciente de la BD (Debe existeir). Diario de las actividades posteriores.
Se aplican las imágenes posteriores al respaldo. ·
Puede encadenar una recuperación en caliente.
·
Se deben realizar copias de seguridad de la BD periódicamente:
Toda la BD debe copiarse en memoria secundaria. El proceso de transacciones debe pararse durante el procedimiento de copia (Costoso). Algoritmo de Recuperación ARIES a)
El registro del sistema en el momento de la caída.
b)
Las tablas de transacciones y de páginas sucias en el momento de punto de control.
c)
Las tablas de transacciones y de páginas sucias después de la fase de análisis.
Respaldos de Bases de Datos Siempre es necesario tener un respaldo de nuestras bases de datos, pero que pasa cuando nuestras bases de datos están tan pesadas que el phpMyAdmin se queda colgado. Para eso nos sirve mysqldump un comando que nos trae MySQL para hacer respaldos de nuestras bases de datos su sintaxis es la siguiente: Ejemplos
mysqldump [OPTIONS] database [tables]
O mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...] O mysqldump [OPTIONS] –all-databases [OPTIONS] Algunos de sus parámetros mas utilizados son los siguientes: -A, –all-databases Dump all the databases. This will be same as –databaseswith all databases selected. add-drop-database Add a ‘ DROP DATABASE’ before each create. add-drop-table Add a ‘drop table’ before each create. add-locks Add locks around insert statements. allow-keywords Allow creation of column names that are keywords. create-options Include all MySQL specific create options. e, –extended-insert Allows utilization of the new, much faster INSERT syntax. p, –password[=name] Password to use when connecting to server. If password is not given it’s solicited on the tty. u, –user=name User for login if not current user. Bien, ahora colocamos un ejemplo de su uso: #Respaldando una única base de datos mysqldump -uroot -p –all –add-locks -e mibase > bkmibase.sql; #Respaldar todas mis bases de datos mysqldump -uroot -p –all –all-databases –add-locks -e > bkmisbases.sql; Ok, ya tenemos nuestro respaldo ahora: ¿como la importamos? pues bien para cargarlo existen varias formas aquí les presento una que nos sirve bastante: #Nos conectamos a mysql mysql -uroot -p
USE mibase; source /path/TO/mibase.sql; Como comentario para importar tablas tipo innodb se recomienda agregar: SET FOREIGN_KEY_CHECKS=0; Al inicio del archivo y al final con el fin de no obtener errores. SET FOREIGN_KEY_CHECKS=1; Soporte para control de Transacciones y Recuperación de Fallas Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardware.
Ejemplos Diarios para Recuperación
Se utilizan también los términos log y journal. Mantiene un registro de todas las operaciones que afectan a ítems de la base de datos. Esta información permite recuperar. Se almacena en disco. Operaciones posibles a reflejar:
Recuperación Mediante la Actualización Diferida en un Entorno monousuario El algoritmo RDU se utiliza un procedimiento rehacer, proporcionado con posterioridad, Para rehacer operaciones escribir_elemento.
determinadas
Actualización Diferida con ejecución concurrente en un entorno multiusuario Planificación de la ejecución de las transacciones Cuando se tomo el punto de control en el momento t1 l a transacción T1 se habría confirmado. Procedimientos de Recuperación 1.
Recuperación Normal
· Tiene lugar después de una parada normal de la máquina, en la que se escribe un punto de verificación como último registro del diario.
· Este procedimiento se ejecuta cuando el último registro del diario es un punto de verificación o recuperación del sistema. ·
Este tipo de recuperación también tiene lugar cuando aborta una transacción, debido a la razón que sea.
2.
Recuperación en Caliente
·
Después de un error del sistema.
· Se ejecuta cuando el último registro del diario no es un punto de verificación y el operador no indica pérdida de memoria secundaria. ·
El procedimiento de recuperación es el indicado en el apartado referente a los puntos de verificación en el diario.
3.
Recuperación en Frío
·
Después de un incidente con la memoria masiva dañada.
·
Se ejecuta si se pierden datos o la BD ya no es coherente.
·
Se utiliza:
Copia de seguridad (backup) más reciente de la BD (Debe existeir). Diario de las actividades posteriores. Se aplican las imágenes posteriores al respaldo. ·
Puede encadenar una recuperación en caliente.
·
Se deben realizar copias de seguridad de la BD periódicamente:
Toda la BD debe copiarse en memoria secundaria. El proceso de transacciones debe pararse durante el procedimiento de copia (Costoso). Algoritmo de Recuperación ARIES a)
El registro del sistema en el momento de la caída.
b)
Las tablas de transacciones y de páginas sucias en el momento de punto de control.
c)
Las tablas de transacciones y de páginas sucias después de la fase de análisis.
Soporte para control de Transacciones y Recuperación de Fallas Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardwar Otros Ejemplos Tecnicas de recuperacion de Base de datos Actualización diferida con ejecución concurrente en un entorno multiusuario
Planificacuot;Arial", "sans-serif"; mso-ansi-language: ES; mso-bidi-font-weight: bold;"> En general, una transacción incluirá acciones que no afectan a la base de datos, como por ejemplo, generar o imprimir un mensaje o un informe a partir de la información obtenida en la base de datos.
Técnica de recuperación basada en actualización inmediata La base de datos puede ser actualizada sin tener que esperar que la transacción llegue a su confirmación. Se pueden distinguir dos categorías principales de algoritmos de actualización inmediata: Algoritmo de recuperación DESHACER/NO-REHACER Algoritmo de recuperación DESHACER/REHACER. Procedimiento RAI: Usar dos listas de transacciones mantenidas por el sistema, las transacciones confirmadas y las activas. Deshacer todas las operaciones de la transacción activa Rehacer todas las operaciones de las transacciones confirmadas a partir del diario, en el orden que se escribieron en el mismo. Paginación en la sombra o pagina espejo: Procedimiento de Escritura: 1. Cuando se inicia una transacción ambas tablas son iguales. 2. Cuando se actualiza una página, se escribe la página actualizada en una página no usada, y se actualiza la tabla actual para apuntar a ésta (dejando la “sombra” sin modificar). 3. Cuando se confirma la transacción, la tabla de páginas actual pasa a almacenamiento no volátil (se cambian las direcciones de las tablas). 4. Si se produce un fallo, la tabla “sombra” se copia en la “actual”. 5. No es necesario ni rehacer ni deshacer.
Recuperación en sistemas de multibase de datos: en la siguiente imagen se muestra la secuencia para la recuperación de datos.
Respaldo de base de datos y recuperación de fallos catastróficos: Hasta aquí todas las tecnicas que se han estudiado se aplican a fallos no catastróficos. Una suposición clave ha sido que diario del sistema se mantiene en disco y no se pierde como consecuencia del fallo. De manera similar, el directorio sombra se debe almacenar en disco para hacer posible la recuperación cuando se use la paginación en la sombra. Las tecnicas de recuperación que se han visto usa las entradas del diario de sistema o el directorio sombra para recuperarse de un fallo llevando de nuevo la base de datos aun estado consistente. El gestor de recuperación de un SGBD debe estar equipado también para manejar fallos mas catastróficos, como son fallos de disco. La técnica principal para manejar tales fallos es la de realizar copias de seguridad de la base de datos. La base de datos completa y el diario se copian periódicamente en medios de almacenamiento alternos. En caso de un fallo catastrófico del sistema,se puede cargar la copia de seguridad mas reciente y el sistema podrá reinicia rse. Para evitar la perdida e todos los efectos de las transacciones que se han ejecutado desde el ultimo respaldo, se acostumbra hacer copas de seguridad del diario del sistema en intervalos de tiempo mas frecuentes que la copia de seguridad de toda la base de datos. El diario del sistema suele ser bastante mas pequeño que la base de datos misma y por lo tanto se puede respaldar con mayor frecuencia.
