TÉCNICAS DE RECUPERACIÓN DE BASES DE DATOS

Trabajo de investigación: Administración de base de datos

DOCENTE: INTEGRANTES:
ING. CAMPOS MARILEN
TSU. GÁMEZ JOSELVIS
C.I.: V-26.984.065
TSU. HERNANDEZ DANIEL
C.I.: V-26.384.551
TSU. JARAMILLO JESÚS
C.I.: V-25.568.229

Ingeniería en Informática
Sección 01 – Trayecto IV, Semestre I

El Tigre, octubre de 2018.

 INDICE
INTRODUCCIÓN ……………………………………………………........................ 3
CONCEPTO DE RECUPERACIÓN
4
…………………………………………………
Introducción a la recuperación y clasificación de algoritmos de
4
recuperación .
Escritura anticipada en el diario, robar/no robar y forzar/no forzar
5
…………..
Restauración de transacciones
6
………………………………………………...
TÉCNICAS DE RECUPERACIÓN …………………………………………………. 8
Basadas en actualización referida ……………………………………………. 8
Basadas en actualización inmediata
10
…………………………………………..
Paginación en la sombra
11
………………………………………………………
Recuperación en sistemas multibases de datos ………………………………. 11
Respaldo de bases de datos y recuperación de fallos catastróficos
13
……………
CONCLUSIÓN
15
……………………………………………………………………….
REFERENCIAS BIBLIOGRÁFICAS ……………………………………………… 17
 INTRODUCCIÓN
En el siguiente trabajo de investigación se describen los conceptos principales de las
técnicas de recuperación de base de datos, comenzando por los conceptos de recuperación y
finalizando con las técnicas de recuperación.

Dichos puntos a su vez estarán conformados por:

a) Introducción a la recuperación y clasificación de algoritmos de recuperación
b) Escritura anticipada en el diario, robar/no robar y forzar/no forzar
c) Restauración de transacciones
d) Basadas en actualización referida
e) Basadas en actualización inmediata
f) Paginación en la sombra
g) Recuperación en sistemas multibases de datos
h) Respaldo de bases de datos y recuperación de fallos catastróficos

Con el objetivo de recopilar y analizar en un documento la información antes

mencionada para su comprensión y entendimiento se consultaron en su mayoría
documentos alojados en los sitios webs, blogs, etc.
 1. CONCEPTO DE RECUPERACIÓN

Introducción a la recuperación y clasificación de algoritmos de recuperación

La recuperación de información (IR, Information Retrieval) es el área de la ciencia y la

tecnología que trata de la adquisición, representación, almacenamiento, organización y
acceso a elementos de información. Desde un punto de vista práctico, dada una necesidad
de información del usuario, un proceso de IR produce como salida un conjunto de
documentos cuyo contenido satisface potencialmente dicha necesidad. 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.

Existen dos grandes tipos de sistemas para el procesamiento de elementos de

información: los sistemas de recuperación de información y los sistemas de Bases de Datos.
Mientras los sistemas de Bases de Datos están optimizados para el manejo de datos
estructurados con una semántica bien definida, los sistemas de recuperación de
información, por el contrario, están diseñados para el procesamiento de texto en lenguaje
natural, raramente estructurado y, por lo general, de semántica ambigua.

En un sistema de Bases de Datos el usuario introduce una consulta específica expresada

en algebra relacional, obteniendo como salida, en forma tabular, todos los resultados que
satisfacen dicho requerimiento sin posibilidad alguna de error ya que invalidaría por
completo el resultado. Sin embargo, en el caso de los sistemas de recuperación de
información los resultados frecuentemente contienen errores, y no tienen por qué ser
completos. De hecho, el objetivo de un sistema de recuperación de información es
maximizar el número de documentos relevantes devueltos a la vez que se minimiza el
número de documentos no relevantes devueltos.

Clasificación de algoritmos de recuperación

Conceptualmente, podemos distinguir dos técnicas principales para recuperarse frente a

fallos no catastróficos:

a) Técnicas de actualización diferida: no actualizan físicamente la base de datos hasta llegar

al punto de confirmación.

Algoritmo no deshacer/rehacer

b) Técnicas de actualización inmediata: las operaciones de una transacción modifican la

base de datos antes de que la transacción alcance su punto de confirmación.

- Algoritmo deshacer/no rehacer

- Algoritmo deshacer/rehace

Escritura anticipada en el diario, robar/no robar y forzar/no forzar

a) Diarios de recuperación

Se utilizan también los términos log y journal. Estos mantienen un registro de todas las
operaciones que afectan a ítems de la base de datos, esta información permite recuperar
datos y se almacena en disco.

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. Las entradas de diario del tipo Deshacer
incluyen el valor antiguo (BFIM) del elemento ya que son necesarias para deshacer el
efecto de la operación a partir del diario (asignando el valor del elemento en la base de
datos otra vez a su BFIM).
 2. La información necesaria para REHACER. Una entrada de diario del tipo Rehacer
incluye el nuevo valor (AFIM) del elemento escrito por la operación ya que se requiere
rehacer el efecto de la operación a partir del diario (asignado el valor del elemento en la
base de datos a su AFIM).

Cuando se utiliza la actualización en el lugar, es necesario utilizar un diario para la

recuperación. En este caso, el mecanismo de recuperación debe asegurarse que la BFIM del
elemento de datos se grabe en la entrada del diario apropiada y que dicha entrada se evacue
a disco antes de que la BFIM se sobrescriba con la AFIM en la base de datos del disco. En
general, a este proceso se le conoce como escritura anticipada en el diario.

La terminología de recuperación estándar del SGBD incluye los términos robar/no-robar

y forzar/no-forzar, que especifican cuando una página de la base de datos puede escribirse a
disco desde la caché:

1. 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. El bit
de reserva indica si la página puede escribirse en disco ya o no. Por el contrario, si el
protocolo permite escribir un búfer actualizado antes de la confirmación de la transacción,
se le llama estrategia robar. Robar se usa cuando el gestor del búfer reemplaza una página
existente que ha sido actualizada pero cuya transacción no se ha confirmado.

2. Si todas las páginas actualizadas por una transacción son escritas inmediatamente a disco
cuando se confirma la transacción, se le llama estrategia forzar. A lo contrario se le llama
estrategia no-forzar.

Restauración de transacciones

Si por cualquier razón una transacción falla después de actualizar la base de datos, puede
ser necesario revertir la transacción. Cualquier valor de elementos de información que la
transacción haya alterado y se haya escrito en la base de datos, deberá restablecerse a sus
valores anteriores (BFIM). Las entradas del diario del tipo deshacer sirven para recuperar
los valores antiguos de los elementos de información que deben revertirse.

Si una transacción T se revierte, cualquier transacción S que haya leída mientras tanto el
valor de algún elemento de datos X escrito por T también deberá revertirse. De manera
similar, una vez que S se revierta, cualquier transacción R que haya leído el valor de algún
elemento de datos Y escrito por S deberá revertirse también, y así sucesivamente. Este
fenómeno se denomina restauración (rollback) en cascada, y puede ocurrir cuando el
protocolo de recuperación garantiza que los planes sean recuperables pero no que sean
estrictos o sin cascada. Obviamente, la restauración en cascada puede ser bastante compleja
y costosa en tiempo. Es por ello que casi todos los mecanismos de recuperación se diseñan
de modo que la restauración en cascada nunca sea necesaria.
 II. TÉCNICAS DE RECUPERACIÓN

Basadas en la actualización diferida

Es postergar o diferir cualquier actualización a la DB hasta que la transacción complete

su ejecución exitosamente y llegue a su COMMIT. Durante la ejecución de la transacción
las actualizaciones son grabadas en el log y en el área de trabajo de la transacción. Cuando
la transacción llega a su COMMIT, el log es forzado a escribirse en disco y luego las
actualizaciones se reflejan en la DB. Si la transacción falla antes de llegar a su COMMIT
no es necesario aplicar el UNDO a ninguna operación pues la transacción no ha afectado a
la base de datos de ninguna manera. El protocolo típico de la actualización diferida se
define como sigue:

1. Una transacción no puede hacer cambios a la base de datos hasta que llegue a su
COMMIT.

2. Una transacción no llega a su COMMIT hasta que todas las operaciones de actualización
hayan sido registradas en el log y el log haya sido forzado a escribirse en disco.

Si la transacción falla después de llegar a su COMMIT pero antes de que los cambios
sean reflejados en la base de datos, basta con aplicar el algoritmo REDO según las
operaciones y los valores de los data ítems que aparecen en el log.

a) Recovery utilizando actualización diferida en ambientes monousuarios

El algoritmo de recovery es relativamente sencillo. El algoritmo conocido como RDU_S

(recovery using referred update in a single-user environment) usa un procedimiento REDO
para rehacer ciertas operaciones de escritura (write-ítem) sobre data ítems de la DB.

PROCEDURE RDU_S usa dos listas de transacciones: las transacciones que han llegado
a su COMMIT desde el último checkpoint y las transacciones activas. Aplica el algoritmo
REDO a todas las operaciones que han escrito (write- ítem) sobre los ítems, de las
transacciones que han llegado a su COMMIT según el orden en el que ellas aparecen en el
log. Luego reinicia todas las transacciones activas. El REDO es definido de la siguiente
manera: REDO (WRITE_OP) rehacer una operación de escritura sobre un data ítem
WRITE_OP consiste en examinar sus entradas al log y colocar como valor del data ítem X
el valor que aparece en new_value, considerado el valor del data ítem después de la
actualización. La operación REDO se aplica para buscar lo idéntico. Esto es que, si ella se
ejecuta una y otra vez, el resultado debe ser equivalente a que si se ejecutara una sola vez.

b) Recovery utilizando actualización diferida en ambientes multiusuarios

Para ambientes multiusuarios con control de concurrencia, el recovery puede hacerse

más complejo dependiendo del protocolo de control de concurrencia usado. En general, a
mayor grado de concurrencia que se desea llegar más difícil se vuelve el proceso de
recovery. Para combinar el método de actualización diferida para recovery con la técnica
para el control de la concurrencia, es necesario mantener todos los cerrojos sobre los ítems
activos hasta que la transacción llegue a su COMMIT. Después de ello, los cerrojos se
remueven.

PROCEDURE RDU_M: Usa dos listas de transacciones mantenidas por el sistema: las
transacciones que llegaron a su COMMIT (T) desde el último checkpoint y las
transacciones activas (T´). Aplica el algoritmo REDO a todas las operaciones que han
escrito (write-ítem) sobre los ítems, de las transacciones que han llegado a su COMMIT
según el orden en el que ellas aparecen en el log. Las transacciones que están activas y que
no han llegado a su COMMIT deben ser canceladas y sometidas nuevamente a ejecución.

c) Operaciones que no afectan a la base de datos

En general, no todas las operaciones de las transacciones afectan a la base de datos:

generación e impresión de mensajes o reportes son ejemplos de ello. Si una transacción
falla antes de completarse, el reporte no debe ser tomado en cuenta, esto debe ocurrir sólo
después de que la transacción haya llegado a su COMMIT. Esto suele controlarse dejando
este tipo de acciones en una cola de batch Jobs que son ejecutados sólo si la transacción es
exitosa si no lo es se cancelan.

Basadas en la actualización inmediata

Esta técnica de recuperación usa los procedimiento UNDO/REDO Recovery, y se

pueden aplicar tanto en ambientes monousuario como en ambientes multiusuarios.

En ambientes monousuarios:

PROCEDURE RIU_S usa dos listas de transacciones: las transacciones que han llegado
a su COMMIT desde el último checkpoint y las transacciones activas (por lo menos, una
transacción cae en esta categoría ges el ambiente es monousuario).

Aplica el algoritmo UNDO a Todas las operaciones que han escrito (write-ítem) sobre
los ítems, de las transacciones activas que aparecen en el log.

Aplica el algoritmo REDO a todas las transacciones que han llegado a su COMMIT
según el orden en el que ellas aparecen en el log.

UNDO (WRITE_OP) deshacer una operación de escritura sobre un data ítem

WRITE_OP consiste en examinar sus entradas al log
[write_ítem,T,X,old_value,new_value] y colocar como valor del data ítem X el valor que
aparece en old_value, considerado el BFIM (valor del data ítem antes de la actualización,
Before Image).

Deshacer un número de operaciones de escritura de una o más transacciones desde el

logimplica proceder en orden inverso a como estas operaciones fueron grabadas en el log.

En ambientes multiusuarios:

PROCEDURE RIU_M usa dos listas de transacciones: las transacciones que han llegado
a su COMMIT desde el último checkpoint y las transacciones.
 Activa el algoritmo UNDO a todas las operaciones que han escrito (write-ítem) sobre los
ítems, de las transacciones activas que aparecen en el log. Las operaciones deben ser
deshechas en orden inverso a como aparecen en el log.

Aplica el algoritmo REDO a todas las transacciones que han llegado a su COMMIT
según el orden en el que ellas aparecen en el log.

Paginación en la sombra

La paginación en la sombra es una técnica de recuperación alternativa a las basadas en

registro histórico. Bajo ciertas circunstancias la paginación en la sombra puede requerir
menos accesos al disco que los métodos basados en registro histórico que se presentaron
anteriormente. No obstante, como se verá, existen algunos inconvenientes en el enfoque de
la paginación en la sombra. Por ejemplo, es difícil extender la paginación en la sombra para
permitir que varias transacciones puedan ejecutarse concurrentemente.

Igual que antes, la base de datos se divide en un número determinado de bloques de

longitud fija a los que se denominará páginas. Debido a que se va a utilizar un esquema de
paginación para la gestión de la memoria, se ha tomado prestado de los sistemas operativos
el término página. No es necesario almacenar en disco estas páginas en un orden
determinado, hay muchas razones por las que esto es así. Sin embargo, debe existir una
manera de localizar la página de la base de datos.

Recuperación en sistemas de multibases de datos

A continuación se mostraran algunas técnicas para la recuperación de multibases 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 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.

Respaldo de base de datos y recuperación de fallos catastróficos

 Existen diferentes métodos para hacer respaldos de información. Una posibilidad es
copiar los datos digitales a diferentes formatos físicos. Un DVD, un CD un pendrive
también conocido como (Memoria USB), una tarjeta de memoria etc. El resguardo también
puede desarrollarse subiendo la información a un servicio online; en este caso lo que se
haría es copiar los documentos a un servidor y proteger el acceso a los documentos a través
de una clave.

1. Como se restaura un respaldo y como se restaura

Para hacer una copia de respaldo de una base de datos se recomienda crear un dump.

a) Para hacer un dump de todas las bases de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** -A > /Ruta/Hacia/archivo_dump.SQL

b) Para hacer un dump de sólo algunas bases de datos es necesario ejecutar el comando:

mysqldump --user=****** --password=****** db_1 db_2 db_n>

/Ruta/Hacia/archivo_dump.SQL

c) Para hacer un dump de todas las tablas de una base de datos es necesario ejecutar el
comando:

mysqldump --user=****** --password=****** db > /Ruta/Hacia/archivo_dump.SQL

d) Para hacer un dump de sólo ciertas tablas de una base de datos es necesario ejecutar
el comando:

mysqldump --user=****** --password=****** db --tablas tab1 tab2 >

/Ruta/Hacia/archivo_dump.SQL

Para cada uno de estos comandos es necesario indicar un usuario (user) y la contraseña
(password) con derechos de administrador en la base de datos.

2. Como restaurar
Para restaurar un dump tan sólo hay que ejecutar el comando:

mysql --user=****** --password=****** db_nom < /Ruta/Hacia/archivo_dump.SQL

 CONCLUSIÓN

De acuerdo al análisis realizado del trabajo de investigación se pudo determinar en qué

consiste la recuperación de información en una base de datos, tanto sus conceptos como sus
técnicas.

Según lo investigado se define a la recuperación de la información es el área de la ciencia

y la tecnología que trata de la adquisición, representación, almacenamiento, organización y
acceso a elementos de información. Dicha ciencia hace uso de los sistemas de recuperación
de información, estos suelen ser confundidos con los sistemas de base de datos, pero son
dos términos totalmente diferentes:

1. Los Sistemas de Bases de Datos están optimizados para el manejo de datos

estructurados con una semántica bien definida.
2. Los sistemas de recuperación de información, por el contrario, están diseñados para
el procesamiento de texto en lenguaje natural, raramente estructurado y, por lo
general, de semántica ambigua.

En cuanto a las técnicas de recuperación de información, destacan las basadas en la

actualización diferida y en la actualización inmediata.

En la diferida se establece qué:

1. Una transacción no puede hacer cambios a la base de datos hasta que llegue a su
COMMIT.

2. Una transacción no llega a su COMMIT hasta que todas las operaciones de actualización
hayan sido registradas en el log y el log haya sido forzado a escribirse en disco.

Mientras que en la inmediata establece qué todas las operaciones que han escrito (write-
ítem) sobre los ítems, de las transacciones activas que aparecen en el log. Es decir, trabaja
de manera directa con las transacciones que están activas.

En cuando al respaldo y recuperación de una base de datos se recomienda el uso de los

Dumps. Estos pueden ser utilizado para generar respaldos de bases de datos y ser usados o
incluso para ser transferidos a otro servidor de base datos SQL (No estrictamente tiene que
ser un servidor MySQL).
 REFERENCIAS BIBLIOGRÁFICAS

Elmasri, R. y Navathe S. (2000) Fundamentos de Sistemas de Bases de Datos. Quinta

Edición. Editorial Addison Wesley. Estados Unidos – Massachusetts.

Palmeriños L. (2011). Técnicas de Recuperación de Bases de Datos. [Página web en línea].

Disponible en: http://tecnicasrecuperacionbd.blogspot.com/2011/06/conceptos-de-
recuperacion.html [Consulta: 2018, octubre 23]

Celis, B. Cabeza N. y otros. (2012). Técnicas de Recuperación de Base de Datos. [Página

web en línea]. Disponible en:
http://administracionbasedatosiutllano.blogspot.com/2012/06/grupo-6-seccion-01.html
[Consulta: 2018, octubre 23]

Cuervo A. (2010). Recuperación de fallas. [Documento en línea]. Disponible en:

http://cursos.aiu.edu/base%20de%20datos%20SOG/Sesi%C3%B3n%209.pdf. [Consulta:
2018, octubre 23]

Vivanco, M. (2012). Recuperación de la base de datos [Pagina web en línea]. Disponible

en: http://basededatossw41.blogspot.com/2012/11/recuperacion-de-la-bd.html. [Consulta:
2018, Octubre 22]

Padilla G., García M. y otros (2011). Técnicas de recuperación de bases de datos

[Documento en línea]. Disponible en:
https://basesdedatosuv.files.wordpress.com/2011/05/recuperacion-eq3.docx [Consulta:
2018, octubre 23]

Porto J. y Gardey Ana. (2014). Respaldo de información [Documento en línea]. Disponible

en: https://definicion.de/respaldo-de-informacion/ [Consulta: 2018; octubre 23]

Daniel santana (2013). Administración de base de datos [Pagina web en línea]. Disponible
en: http://dan1456bd.blogspot.com/p/respaldos.html. [Consulta: 2018, octubre 22]