5.4 MÉTODOS DE RECUPERACIÓN DE UN SGBD.
La recuperación consiste en tres pasos principales: Análisis: Identifica las páginas sucias y el conjunto de transacciones activas en el momento de la caída y el punto del log apropiado para empezar la operación REHACER Rehacer: se replican las operaciones del log. Deshacer: Se recorre el log hacia atrás y se deshacen las transacciones activas en el momento de la caída, o iniciadas después, de las que no se ha encontrado confirmación. Recuperación en Oracle Red Log Files: dos o más archivos donde se registra cualquier modificación transaccional de una memoria intermedia de la BD. Archivos de control: metadatos necesarios para operar en la base de datos, incluyendo información sobre copias de seguridad. Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción. En la Recuperación de un fallo: Recupera los datos con REHACER (Desde Redo Log File). Deshace las transacciones no comprometidas con Deshacer (Desde el segmento de rollback).
Recuperarse al fallo de una transacción significa que la base de datos se restaura al estado 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 en el registro del sistema.
1. Si hay un fallo como la caída del disco, el sistema restaura una 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: No se actualiza físicamente la base de datos Hasta que no haya alcanzado su punto de confirmación.
Actualización Inmediata: La base de datos puede ser actualizada por Algunas Operaciones antes de que esta última alcance su punto de confirmación.
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 Caché (Búfer) de los Bloques de Disco
El proceso de recuperación se entrelaza con funciones del sistema operativo en particular con el almacenamiento en caché o en búfer en la memoria principal, Normalmente se reserva una colección de búferes en memoria, denominados caché DBMS. Se utiliza un directorio para rastrear los elementos de la base de datos que se encuentra en los búferes.
Bit Sucio:
Puede incluirse en la entrada del directorio, para indicar si se ha modificado o no el búfer.
Pin:
Un pin dice que una página en caché se está accediendo actualmente.
Actualización en el Lugar (In Place):
Escribe en el búfer la misma ubicación de disco original.
Shadowing (en la Sombra):
Escribe un búfer actualizado en una ubicación diferente.
BFIM (Before Image): Imagen antes de la actualización.
AFIM (After Image): 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 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 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:
1. [start, T]
2. [write, T, X, valor_viejo, valor_nuevo] (Opcional)
3. [read, T, X]
4. [commit, T]
5. [abort, T]
6. undo, redo
* 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 no sabemos si la información está en disco o en memoria.
* 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:1. Ti debe deshacerse si el diario contiene el registro starts pero no el commit.2. 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 <checkpoint>.
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 <Tj commits>, partiendo del final del fichero.
4. Ejecuta redo (Ti) para las transacciones que tengan su registro <Ti commits>, partiendo desde el punto de verificación hasta el final del diario.
Procedimientos de Recuperación
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.
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.
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 existir). 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:
mysqldump [OPTIONS] database [tables]
O mysqldump [OPTIONS] –databases [OPTIONS] DB1 [DB2 DB3...]
O mysqldump [OPTIONS] –all-databases [OPTIONS]
Comentarios
Publicar un comentario