REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACION UNIVERSITARIA

UNIVERSIDAD POLITECNICA TERRITORIAL DEL ESTADO BOLIVAR

TRAYECTO4 SECCION N2

TÉCNICAS DE RECUPERACIÓN DE BASE DE DATOS

PROFESOR: INTEGRANTES:

HERMES MARCANOS 28504585 JOHARLIN SANTAELLA

26374054 LILIANA BRAVO

22580182 JOSE MORENO

CIUDAD BOLIVAR, 04.2019

Técnicas de recuperación de base de datos
En cada uno de estos casos puede perderse información. Por tanto, el
sistema de bases de datos debe realizar con anticipación acciones que
garanticen que las propiedades de atomicidad y durabilidad de las
transacciones, se preservan a pesar de tales fallos. Una parte integral de un
sistema de bases de datos es un esquema de recuperación, el cual es
responsable de la restauración de la base de datos al estado consistente previo
al fallo. El esquema de recuperación también debe proporcionar alta
disponibilidad; esto es, debe minimizar el tiempo durante el que la base de
datos no se puede usar después de un fallo.

Una recuperación de bases de datos consisten en devolver a la base de

datos a un estado consistente y con la menor pérdida de información y tiempo
posible, en la cual se incluyen acciones durante el proceso normal de
transacciones, y acciones después de un fallo.

Concepto de recuperación

Es la acción y resultado de recuperar algo o recuperarse alguien, por

ejemplo, un objeto extraviado, o bien de recuperarse de alguna afección física,
como ser la quebradura de un brazo tras un accidente, respectivamente.

Cuando se trata de la recuperación de algo material se pretenderá volver

a tener aquello que se perdió o se dañó. Si se perdió algo, las maneras más
comunes de recuperarlo es volver al lugar donde se cree haberlo perdido,
preguntarle a la gente si lo vio y también inspeccionar el lugar para encontrarlo.
Mientras tanto, si se trata de un artefacto o máquina que se rompió, para lograr
su recuperación, se deberá enviar al mismo a un servicio técnico especializado
que lo revise y lo repare para que vuelva a funcionar. Normalmente en estos
lugares identifican el daño y proponen el arreglo más conveniente.
Introducción a la Recuperación

La recuperación en un sistema de base de datos significa principalmente

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

Clasificación de algoritmos:
Conceptualmente, podemos distinguir dos técnicas principales para
recuperarse frente a fallos no catastróficos:

Las técnicas de actualización diferida no actualizan la BD hasta llegar al

punto de confirmación.

- Algoritmo no deshacer/rehacer
En las técnicas de actualización inmediata las operaciones de una
transacción modifican la BD antes de que la transacción confirme.
- Algoritmo deshacer/no rehacer
- Algoritmo deshacer/rehace.

Algoritmos de Recuperación

En Todos estos algoritmos se describen según realiza las siguientes

acciones:
Begin (t): introduce la transacción t en el gestor de transacciones.
Leer (t, p, b): la transacción t lee la página p en el búfer b.
Esc (t, b, p): la transacción t escribe el búfer b en la página p.
Confirma (t): se confirma la transacción t.
Aborta (t): se aborta la transacción t.
Rearranca (): realiza la recuperación tras un fallo del sistema.
Estos algoritmos mantienen tres listas de transacciones:
ntr.activas (La), tr.abortadas (Lb), tr.confirmadas (Lc).

Algoritmos de Recuperación ARIES

Se trata de un método de recuperación “real” empleado (con diversas

optimizaciones) en la mayoría de los SGBD actuales. N ARIES utiliza una
estrategia robar/no forzar para las escrituras en disco. El algoritmo se basa en
tres conceptos:

- Escritura anticipada en la traza.

- Repetición de la historia (para reconstruir el estado de la BD en el momento
de la caída, con rehacer y deshacer).
- Anotación en el diario de las modificaciones durante el deshacer (para evitar
repeticiones de deshacer si se produce un fallo durante la recuperación).

El procedimiento de recuperación consiste en tres pasos principales:

Análisis
Rehacer
Deshacer
Diarios para Recuperación

Mantiene un registro de todas las operaciones que afectan a ítems de la

base de datos. Esta información permite recuperar y Se almacena en disco.

•Las Operaciones posibles a reflejar:

• [Start, T]
[Write, T, X, valor viejo, valor nuevo] (Opcional)
• [Read, T, X] leer
• [Commit, T] commit (acción de comprometer) se refiere a la idea de consignar
un conjunto de cambios "tentativos, o no permanentes"
• [Abort,T]
Undo, redo.

La entrada de un diario debe establecer las diferencias entre los dos tipos de
información que puede tener una entrada del diario para una operación de
escritura.

1. La información necesaria para DESHACER.

2. La información necesaria para REHACER.
• La terminología de recuperación estándar del SABD incluye los términos
• Especifican cuando una página de la base de datos puede escribirse a disco
desde la cache:

La Estrategia no-robar
La Estrategia robar
Estrategia forzar
Estrategia no-forzar.
Los SABD típicos emplean una estrategia robar/no-forzar.

*Restauración de transacciones
 Es cuando una base de datos se encuentra en estado de restauración,
puede usar el cuadro de diálogo Restaurar registro de transacciones para
restaurar la base de datos a una transacción marcada en las copias de
seguridad de registros disponibles.

Para restaurar una transacción marcada

Tras conectarse a la instancia apropiada de Microsoft Motor de base de datos

de SQL Server, en el Explorador de objetos, haga clic en el nombre del servidor
para expandir el árbol correspondiente.

Expanda Bases de datos y, en función de la base de datos, seleccione la base

de datos de un usuario o expanda Bases de datos del sistema y seleccione una
base de datos del sistema.

Haga clic con el botón derecho en la base de datos, seleccione Tareas y,

después, haga clic en Restaurar.

Haga clic en Registro de transacciones para abrir el cuadro de diálogo

Restaurar registro de transacciones.

En la página General, en la sección Restaurar en, seleccione Transacción

marcada para abrir el cuadro de diálogo Seleccionar transacción marcada. Este
cuadro de diálogo muestra una cuadrícula en la que aparecen las
transacciones marcadas disponibles en las copias de seguridad de los registros
de transacciones seleccionados.

De forma predeterminada, la restauración se realiza hasta la transacción

marcada, sin incluirla. Para restaurar también la transacción marcada,
seleccione Incluir transacción marcada.
Robar/forzar

La estrategia no-robar establece que una página de la caché

actualizada por una transacción no puede escribirse a disco antes de la
confirmación de dicha transacción.

́ gina puede o no escribirse a discó.

El bit de reserva indica si la p a

Si el protocolo permite escribir antes de confirmar, se le llama

estrategia robar. El robar se usa cuando el gestor de la caché necesita un
búfer vacío.

Si todas las p á ginas actualizadas por una transacción son escritas

inmediatamente a disco cuando se confirma la transacción, se llama
estrategia forzar. De lo contrario se llama no-forzar.

Un esquema recuperación de actualización diferida sigue un

estrategia de no robar.

Los sistemas tradicionales usan una estrategia robar/no forzar ya que

esto permite el manejo de búfer más pequeños que no contengan toda una
transacción.

La idea de no forzar es útil para que una página actualizada de una

transacción ya confirmada pueda estar en el búfer y ser usada por otra
transacción

Para facilitar el trabajo del SGBD, se usan listas de transacciones

activas, listas de transacciones confirmadas y listas de transacciones
abortadas.

* Técnicas de recuperación basadas en la actualización

Técnica de Recuperación: actualización diferida

Una transacción no puede modificar la base de datos en disco antes

de llegar a su punto de confirmación.

Una transacción no llega a su punto de confirmación antes de grabar

todas sus operaciones de actualización en el diario y forzar la escritura del
diario en disco.

Usar dos listas de transacciones: confirmadas desde el último punto

de control activas (solo una en este tipo de sistemas).

Aplicar la operación REHACER de todas las operaciones de

escritura de las transacciones confirmadas a partir del log.

Reiniciar operaciones activas.

Rehacer una operación de escritura OP-ESCRITURA consiste en

examinar su entrada de diario y asignar el nuevo valor 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 página 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.

Programación en la sombra

En este esquema solo requiere un diario en un ambiente útil usuario.

Se mantiene un directorio actual que apunta a las páginas delas bases de

datos. Al comenzar una transacción se hace la copia del directorio actual
en disco a un directorio sombra.

El directorio sombrase guarda mientras la transacción usa el directorio

actual las modificaciones se hacen sobre una copia de la BD y se manejan
versiones, siendo el directorio actual el que es modificado.

Para recuperar, basta con liberar las páginas modificadas y desechar el

directorio actual.

Recuperación en sistemas de multibase de datos

Interacción con el control de concurrencia

El esquema recuperación depende en gran medida del esquema de

control de concurrencia que se use. Para retroceder los efectos de una
transacción fallida deben deshacerse las modificaciones realizadas por esa
transacción.

Supóngase que se debe retroceder una transacción T0 y que un dato Q,

que fue modificado por T0, tiene que recuperar su antiguo valor. Si se está
usando un esquema basado en registro histórico para la recuperación, es
posible restablecer el valor de Q utilizando la información contenida en el
registro histórico.

Supóngase ahora que una segunda transacción T1 realiza una nueva

modificación sobre Q antes de retroceder T0. En este caso, al retroceder T0, se
perdería la modificación realizada por T1.

Es necesario, por tanto, que si una transacción T modifica el valor de un

elemento de datos Q, ninguna otra transacción pueda modificar el mismo
elemento de datos hasta que T se haya comprometido o se haya retrocedido.
Este requisito puede satisfacerse fácilmente utilizando bloqueo estricto de dos
fases, esto es, bloqueo de dos fases manteniendo bloqueos exclusivos hasta el
final de la transacción.

Retroceso de transacciones

Se utiliza el registro histórico para retroceder una transacción Ti fallida.

El registro histórico se explora hacia atrás; para cada registro del registro
histórico de la forma <Ti, Xj, V1, V2>, se restablece el valor del elemento de
datos Xj con su valor anterior: V1. La exploración del registro histórico termina
cuando se encuentra el registro <Ti iniciada>.

Es importante el hecho de recorrer el registro histórico empezando por el

final, ya que una transacción puede haber actualizado más de una vez el valor
de un elemento de datos. Como ejemplo, considérese este par de registros:
<Ti, A, 10, 20>
<Ti, A, 20, 30>
 Estos registros del registro histórico representan una modificación del
elemento de datos A por parte de la transacción Ti, seguida de otra
modificación de A hecha también por Ti. Al recorrer el registro histórico al revés
se establece correctamente el valor de A como 10. Si el registro histórico se
recorriera hacia delante, A tomaría como valor 20, lo cual es incorrecto. Si para
el control de concurrencia se utiliza el bloqueo estricto de dos fases, los
bloqueos llevados a cabo por una transacción T sólo pueden ser
desbloqueados después de que la transacción se haya retrocedido según se
acaba de describir. Una vez que T (que se está retrocediendo) haya
actualizado un elemento de datos, ninguna otra transacción podría haber
actualizado el mismo elemento de datos debido a los requisitos del control de.
Así pues, la restitución del valor anterior de un elemento de datos no borrará
los efectos de otra transacción.

Puntos de revisión

Cuando las transacciones pueden ejecutarse concurrentemente, la

situación se torna más complicada ya que varias transacciones pueden estar
activas en el momento en que se produce el último punto de revisión.

En un sistema de procesamiento de transacciones concurrente es

necesario que el registro del registro histórico correspondiente a un punto de
revisión sea de la forma <revisión L>, donde L es una lista con las
transacciones activas en el momento del punto de revisión. De nuevo se
supone que, mientras que se realiza el punto de revisión, las transacciones no
efectúan modificaciones ni sobre los bloques de la memoria intermedia ni sobre
el registro histórico.

El requisito de que las transacciones no puedan realizar modificaciones

sobre los bloques de la memoria intermedia ni sobre el registro histórico
durante un punto de revisión puede resultar molesto, ya que el procesamiento
de transacciones tendrá que parar durante la ejecución de un punto de revisión.
 Un punto de revisión durante el cual se permite que las transacciones
realicen modificaciones incluso mientras los bloques de memoria intermedia se
están guardando en disco, se denomina punto de revisión difuso.

Recuperación al reiniciar

El sistema construye dos listas cuando se recupera de una caída: la

lista-deshacer, que consta de las transacciones que han de deshacerse, y la
lista-rehacer, que está formada por las transacciones que deben rehacerse.

Estas dos listas se construyen durante la recuperación de la siguiente

manera. Al principio ambas están vacías. Luego se recorre el registro histórico
hacia atrás examinando cada registró hasta que se encuentra el primer registro
<revisión>:

• Para cada registro encontrado de la forma <Ti comprometida>, se añade Ti a

la lista-rehacer.
• Para cada registro encontrado de la forma <Ti iniciada>, si Ti no está en la
lista-rehacer, entonces se añade Ti a la lista-deshacer.
Una vez que se han examinado los registros apropiados del registro histórico,
se atiende al contenido de la lista L en el registro punto de revisión. Para cada
transacción Ti en L, si Ti no está en la lista-rehacer, entonces se añade Ti a la
lista-deshacer.

Cuando se terminan la lista-rehacer y la lista-deshacer, el proceso de

recuperación procede de la siguiente manera:

1. Se recorre de nuevo el registro histórico hacia atrás comenzando en el

último registro y se realiza una operación deshacer por cada registro del
registro histórico que pertenezca a una transacción Ti de la lista-
 deshacer. En esta fase se ignoran los registros del registro histórico
concernientes a transacciones de la lista-rehacer. El recorrido del
registro histórico termina cuando se encuentran registros <Ti iniciada>
para cada transacción Ti de la lista-deshacer.
2. Se localiza el último registro <revisión L> del registro histórico. Nótese
que este paso puede necesitar de un recorrido del registro histórico
hacia delante si el registro punto de revisión quedó atrás en el paso 1.
3. Se recorre el registro histórico hacia delante desde el último registro
<revisión L> y se realiza una operación rehacer por cada registro del
registro histórico que pertenezca a una transacción Ti de la lista-rehacer.
En esta fase se ignoran los registros del registro histórico concernientes
a transacciones de la lista-deshacer.

Es importante procesar el registro histórico hacia atrás en el paso 1 para

garantizar que el estado resultante de la base de datos sea correcto. Después
de haber deshecho todas las transacciones de la lista-deshacer se rehacen
aquellas transacciones que pertenezcan a la lista-rehacer. En este caso es
importante procesar el registro histórico hacia delante.

Cuando se ha completado el proceso de recuperación, se continúa con

el procesamiento normal de las transacciones. Es importante el hecho de
deshacer las transacciones de la lista-deshacer antes de rehacer las
transacciones de la lista-rehacer al utilizar los pasos 1 a 3 del algoritmo
anterior. El siguiente problema podría ocurrir de no hacerse así. Supóngase
que el elemento de datos A vale inicialmente 10. Supóngase también que una
transacción Ti modifica el valor de A situándolo en 20 y aborta a continuación;
el retroceso de la transacción devolvería a A el valor 10. Supóngase que otra
transacción Tj cambia entonces a 30 el valor de A, se compromete y,
seguidamente, el sistema cae.

Si se rehace primero, A tomará el valor 30; y luego, al deshacer, A

acabará valiendo 10, lo cual es incorrecto. El valor final de A debe ser 30, lo
que puede garantizarse si se deshace antes de rehacer.
Respaldo de base de datos y recuperación de fallos catastróficos

Las técnicas 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 más 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 más reciente y
el sistema podrá reiniciarse.

Para evitar la pérdida de todos los efectos de las transacciones que se

han ejecutado desde el último respaldo, se acostumbra hacer copas de
seguridad del diario del sistema en intervalos de tiempo más frecuentes que la
copia de seguridad de toda la base de datos. El diario del sistema suele ser
bastante más pequeño que la base de datos misma y por lo tanto se puede
respaldar con mayor frecuencia.