Tcnicas de recuperacin a la base de datos.

Concepto de recuperacin, introduccin a la recuperacin y clasificacin de

los algoritmos de recuperacin.

La recuperacin en un sistema de base de datos significa principalmente la

recuperacin de la propia base de datos; es decir, el restablecimiento de la misma
a un estado correcto o mejor dicho consistente, despus de que alguna falla haya
ocasionado que el estado actual sea inconsistente, o al menos eso parezca.

1. Si hay un fallo como la cada del disco, el sistema restaura una copia se
seguridad del registro, hasta el momento del fallo.

2. Cuando el dao se vuelve inconsistente, se pueden rehacer algunas

operaciones para restaurar a un estado consistente. En este caso no se necesita
una copia archivada.

Actualizacin Diferida Actualizacin Inmediata

No se actualiza La base de datos puede

fsicamente la base de ser actualizada por
datos Hasta que no Algunas Operaciones
haya alcanzado su antes de que esta
punto de confirmacin. ultima alcance su punto
de confirmacin.

NO-DESHACER/REHACER DESHACER/REHACER
 Escritura anticipada en el diario robar/no-robar y forzar no forzar

En este caso, el mecanismo de recuperacin debe garantizar la grabacin 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.

Restauracin de transacciones.

La restauracin de las transacciones anotadas en el diario las realiza una utilidad

del SGBD, que devuelve la base de datos al estado inmediatamente anterior al
momento del fallo. Este proceso se conoce habitualmente como
restauracin/reejecucin.

La clave para el uso con xito de un diario de transacciones radica en la

capacidad del SGBD para reconocer el comienzo y el final de cada transaccin.
Para cada transaccin de la base de datos, el diario contiene marcas de
comienzo de transaccin y final de transaccin, adems de una grabacin de
los cambios individuales realizados en la base de datos para dicha transaccin. La
marca de final de transaccin se graba en el diario slo despus de la
conclusin con xito de la transaccin. As, si una cada del sistema interrumpe el
procesamiento de una transaccin, no aparecer ninguna marca de final de
transaccin en el diario.

Cuando se realice un proceso de restauracin/reejecucin, slo se restaurarn a

partir del diario las transacciones completadas, y se generar un informe impreso,
que indicar qu transacciones no se han completado y, por tanto, no han sido
introducidas en la base de datos.

Para bases de datos extremadamente activas, la tcnica de

restauracin/reejecucin puede resultar inadecuada, ya que el reprocesamiento
del diario puede llevar varias horas, durante las cuales la base de datos no puede
ser usada con normalidad. Si una base de datos es muy activa, esta no
disponibilidad puede revelarse intolerable, y ser preciso emplear otras tcnicas
de restauracin.
 Tcnicas de recuperacin.

Tcnicas de recuperacin basadas en la actualizacin diferida.

Deferir o posponer las actualizaciones de la base de datos hasta que la

transaccin complete su ejecucin satisfactoriamente y alcance su punto de
confirmacin.

Recuperacin mediante la actualizacin diferida en un entorno monousuario.

El algoritmo RDU se utiliza

un procedimiento rehacer,
Proporcionado con
posterioridad,
Para rehacer determinadas
operaciones
escribrir_elemento.

Actualizacin diferida con ejecucin concurrente en un entorno

multiusuario.

Planificacin de la ejecucin de las transacciones.

Cuando se tomo el punto de control en el momento t1 la transaccin T1

Se habra confirmado.
Tcnicas de recuperacin basadas en la actualizacin inmediata.
Permite que las actualizaciones se graben en la Base de Datos mientras la
transaccin est todava 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 recuperacin utiliza dos procedimientos de recuperacin:
o undo (Ti): restaura los datos que Ti actualiza a los valores que tenan
antes.
o redo (Ti): asigna los nuevos valores a todos los datos que actualiza
Ti.
Despus de ocurrir un fallo, el procedimiento de recuperacin consulta el
diario para determinar qu transacciones deben repetirse y cules
deshacerse:
o Ti debe deshacerse si el diario contiene el registro starts pero no el
commit.
o 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 recuperacin.
 Paginacin de la sombra.

La base de datos se divide en un nmero determinado de bloques de

tamao fijo (pginas).
En memoria voltil se mantiene la tabla actual y en memoria estable una
tabla doble (sombra).
La idea principal es mantener dos tablas de pginas durante la vida de una
transaccin.

Procedimiento de Escritura:
1. Cuando se inicia una transaccin ambas tablas son iguales.
2. Cuando se actualiza una pgina, se escribe la pgina actualizada en una pgina
no usada, y se actualiza la tabla actual para apuntar a sta (dejando la sombra
sin modificar).
3. Cuando se confirma la transaccin, la tabla de pginas actual pasa a
almacenamiento no voltil (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.
 Recuperacin en sistemas de multibase de datos.

En la siguiente imagen se muestra la secuencia para la recuperacin de datos.

 Respaldo de base de datos y recuperacin de fallos catastrficos

Hasta aqu todas las tcnicas que se han estudiado se aplican a fallos no
catastrficos. Una suposicin 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 recuperacin cuando se
use la paginacin en la sombra. Las tcnicas de recuperacin 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 recuperacin de un SGBD debe estar equipado tambin para manejar

fallos mas catastrficos, como son fallos de disco. La tcnica 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 peridicamente en medios de
almacenamiento alternos. En caso de un fallo catastrfico del sistema, se puede
cargar la copia de seguridad mas reciente y el sistema podr reiniciarse.
Para evitar la prdida 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 ms frecuentes que la copia de
seguridad de toda la base de datos. El diario del sistema suele ser bastante ms
pequeo que la base de datos misma y por lo tanto se puede respaldar con mayor
frecuencia.