respaldo y recuperacion
TRANSCRIPT
Administración de Bases de Datos
[email protected] [email protected]
Ing. Ronald Pérez
Respaldo y Recuperación
Administración de Bases de Datos
Definición de Recuperación de una BD: restablecimiento de un estado correcto de la BD
(consistente) después que un fallo del sistema haya ocasionado que el estado actual sea inconsistente.
Principios en los que se fundamenta: redundancia física de los datos.
(disco-memoria, incluso disco-disco y redundancia múltiple)
¿Quién se encarga de la recuperación? La recuperación la gestiona el módulo gestor de
recuperación del SGBD.
Introducción
Administración de Bases de Datos
Tipos de Almacenamiento
Almacenamiento volátil: no sobrevive a las
caídas del sistema.
Almacenamiento no volátil: disco, cinta.
Almacenamiento estable frente al no
estable: la información no se pierde “nunca”
se repite en varios medios volátiles(disco) con
modos de fallos independientes
La BD requiere de almacenamiento no volátil
Administración de Bases de Datos
Durante la ejecución de las transacciones, una BD puede
sufrir diferentes fallos:
Fallos de transacción:
Errores lógicos: una transacción no puede
completarse por algún error interno a la misma.
Errores del sistema: una transacción es abortada
por el SGBD (p.e. para asegurar la consistencia o
evitar el bloqueo mortal).
Tipos de fallos
Administración de Bases de Datos
Durante la ejecución de las transacciones, una BD puede
sufrir diferentes fallos:
Fallos catastróficos: que afectan al conjunto
Caída del sistema: la falta de alimentación u otro
problema hardware (excepto de discos) detiene el
funcionamiento normal y produce la pérdida de la
información en memoria volátil.
Fallo del disco: se produce una destrucción total o
parcial de los datos almacenados en un disco.
Tipos de fallos
Administración de Bases de Datos
Los algoritmos de recuperación son técnicas para
asegurar la consistencia de la BD y la atomicidad de
las transacciones incluso en presencia de fallos.
Para ello, los algoritmos de recuperación tienen dos
procedimientos de actuación:
1) Acciones que se realizan durante el
funcionamiento normal para disponer de la
información necesaria en caso de tener que
recuperarse de un fallo;
2) Acciones que se realizan para recuperar la base
de datos después de producirse un fallo.
Funcionamiento del módulo de
recuperación
Administración de Bases de Datos
El sistema de recuperación se ocupa de que se cumplan dos de las propiedades ACID de las transacciones:
La atomicidad implica sólo dos posibilidades para las transacciones:
abortar (ninguno de sus acciones tiene efecto, y debe reiniciarse).
confirmar (sus acciones tienen efecto permanente).
Transacción activa: si ha empezado pero no ha alcanzado un estado final (aborto o confirmación).
Atomicidad:
se ejecutan todas las
acciones o ninguna
Durabilidad:
cuando una T se completa
los cambios realizados deben
permanecer en el sistema
Almacenamiento
estable
Conceptos básicos
Administración de Bases de Datos
El sistema de recuperación se apoya en una
serie de elementos para realizar su función
Realización de copias de seguridad.
completas o incrementales
Almacenamiento de una traza
que guarda las acciones (actualizaciones)
realizadas
(también llamada diario o log )
Almacenamiento estable
Estructuras de datos para la
recuperación
Administración de Bases de Datos
Copia de seguridad:
es una copia total de la BD realizada en un
momento en que la BD está en un estado
consistente.
o es una copia de seguridad incremental,
formada sólo por las modificaciones realizadas
desde la última copia de seguridad incremental.
Se utiliza tras un fallo del medio (fallo catastrófico).
Se puede realizar con la BD detenida o en
funcionamiento.
Estructuras de datos: copia de
seguridad
Administración de Bases de Datos
Estructuras de datos: traza
La traza (o diario, o log ) guarda información sobre las
actualizaciones realizadas en la BD (información necesaria
para realizar la recuperación en caso de fallo).
Tiene 4 (o 5) tipos de entradas (registros de la traza):
Si se evita la restauración en cascada (lo habitual, ya que se
suele usar bloque en dos fases estricto), no es necesario
registrar traza de las lecturas, excepto para auditoría.
Se usa la escritura anticipada de la traza: la traza de las
acciones se guardan en el disco antes que sus efectos.
[Comenzar_Trans, T]
[Confirmar, T] [Abortar, T]
[T, g, BFIM, AFIM]
BFIM: BeFore IMage
para deshacer
AFIM: AFter IMage
para rehacer
Administración de Bases de Datos
Estructuras de datos: traza
La traza es un elemento fundamental para la
recuperación, por lo que suele duplicarse o triplicarse
en varios discos para evitar su perdida.
Ejemplo de traza para una planificación P1:
[T1 init][T1,A,2,4][T1,B,2,1][T1 commit] ([pto control])
Valores previos: A=2, B=2
P1: T1: lee A, A=A+2,esc(A),lee(B),B=B-1,esc(B),commit
Administración de Bases de Datos
Estructuras de datos: traza
Puntos de control (o de sincronismo):
periódicamente se escribe en la traza un registro especial llamado punto de sincronismo, indicando que en ese momento el sistema escribe en el disco todos los buffers del SGBD que han sido modificados en la base de datos por las transacciones en curso (y que temporalmente estaban en memoria).
El SGBD debe decidir el intervalo entre puntos de sincronismo (medido en tiempo o número de transacciones).
Realizar un punto de control implica:
Suspensión temporal de la ejecución de transacciones.
Escritura forzada de todos los buffers modificados a disco.
Escribir un registro especial en la traza [punto de control]
Reactivar las transacciones en ejecución.
Administración de Bases de Datos
Reglas básicas de gestión de buffers
En general (por velocidad) los sistemas traen los datos a
memoria principal y realizan las actualizaciones en
memoria (no en disco); para ello existe un conjunto de
buffers en la memoria principal, llamado caché del
SGBD.
La función de la gestión de los buffers es del sistema
operativo, pero dada su incidencia en el funcionamiento
de la BD los SGBD participan en la gestión de buffers
con llamadas de bajo nivel al SO.
En la caché del SGBD hay
bloques de datos,
bloques de índices,
bloques de la traza.
Administración de Bases de Datos
Reglas básicas de gestión de buffers
Cuando el SGBD necesita un determinado bloque de datos:
primero revisa la caché del SGBD para ver si está en
ella;
en caso contrario, el elemento se localiza en la BD y se
copian las paginas de disco apropiadas a la caché;
si la caché está llena se hace necesario desalojar una
página que se pueda desalojar, “evacuándola” (a disco)
si ha sido modificada (en el lugar o en la sombra).
los bits de reserva y de página sucia indican si la página
está preparada para ser llevada a disco y si ha sido
modificada.
Páginas sucias: páginas actualizadas que no han sido
todavía escritas en disco.
Administración de Bases de Datos
Reglas básicas de gestión de buffers
Para decidir cuando una página sucia puede/debe ser escrita en
disco se puede seguir:
estrategia no-robar: una página sucia no puede ser escrita ni
desalojada antes de que se confirme la transacción que la
actualizó.
estrategia robar: una página sucia puede ser escrita y
desalojada cuando sea necesario independientemente de que
la transacción haya llegado a la confirmación.
estrategia forzar: toda página sucia se escribe a disco cuando
se confirma la transacción que la actualizó (pequeño sobrecoste
de escr.).
estrategia no-forzar: no es necesario forzar la escritura cuando
se confirma, sólo cuando sea necesario por otras causas.
La mayoría de los SGBDs emplean robar/no-forzar para reducir las
necesidades de memoria y agilizar el funcionamiento sin fallos.
Administración de Bases de Datos
Reglas básicas de gestión de buffers
Para garantizar la atomicidad de las
transacciones:
Regla de traza por adelantado: la traza que
contiene información de una actualización debe
escribirse en el disco antes de escribir a disco
dicho objeto actualizado de la BD.
Se asegura la Atomicidad.
Regla de confirmación: todos los registros de la
traza correspondientes a una transacción
deben escribirse en el disco antes de que se
confirme dicha transacción.
Se asegura la Durabilidad. Evita pérdidas de
imagen posterior AFIM
Evita pérdidas de
imagen anterior BFIM
Administración de Bases de Datos
Procedimientos de recuperación
Procedimiento de recuperación: operaciones
necesarias para arrancar la BD tras finalizar de modo
normal o fallo.
Utiliza las estructuras de datos estudiadas: traza o
copia de seguridad, dependiendo del tipo de fallo.
El objetivo es alcanzar un estado consistente de la
BD minimizando el trabajo perdido.
¿Cómo?
Deshacer actualización:
escribir en BD la
imagen anterior desde
la traza
Rehacer actualización:
escribir en BD la
imagen posterior desde
la traza
Administración de Bases de Datos
Procedimientos de recuperación
Tipos de procedimientos de recuperación:
Recuperación normal: tras una parada de la BD sin fallos, si el punto de control es el último registro de la traza.
Recuperación en caliente: tras un fallo del sistema, si el último registro de la traza no es un punto de control. Busca el último punto de sincronismo en la traza.
Localiza las transacciones confirmadas y las transacciones abortadas (o interrumpidas).
Deshace o rehace transacciones según las diferentes técnicas.
Recuperación en frío: se usa tras un fallo del medio que no haya afectado a la traza. Se toma una imagen consistente a partir de una copia de seguridad y se procesa la traza desde el punto de sincronismo asociado a la copia de seguridad.
Administración de Bases de Datos
Algoritmos de recuperación
Conceptualmente, podemos distinguir dos técnicas principales para recuperarse frente a fallos no catastróficos:
Actualización diferida
Actualización inmediata
Las técnicas de actualización diferida no actualizan la BD hasta llegar al punto de confirmación.
En las técnicas de actualización inmediata las operaciones de una transacción modifican la BD antes de que la transacción confirme.
Estudiaremos cuatro algoritmos que se basan en combinar acciones de las técnicas anteriores.
Administración de Bases de Datos
Algoritmos de recuperación
Todos estos algoritmos se describen según realizan 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:
tr.activas (La), tr.abortadas (Lb), tr.confirmadas (Lc).
En todos los algoritmos la acción begin(t) es idéntica:
void begin( transac t)
{
inserta_en_lista(La,t);
}
Administración de Bases de Datos
Algoritmo no deshacer/rehacer
Con esta técnica, basada en la actualización diferida,
nunca es necesario deshacer una transacción después de
un fallo del sistema, porque no han llegado a tener efecto.
Por ello, no es necesario guardar las imágenes anteriores
en la traza.
La escritura en disco de las páginas actualizadas se
difiere hasta llegar al punto de confirmación de la
transacción.
Abortar transacciones es muy barato.
Sólo es práctico para transacciones cortas y que
actualicen pco.
Administración de Bases de Datos
Algoritmo no deshacer/rehacer
Si se produce un fallo, las transacciones deben
rehacerse.
En esta técnica no es necesario guardar el valor anterior
(BFIM), ya que nunca se deshace.
Siempre (en todas las técnicas) hay que escribir la traza
en disco antes de las propias actualizaciones.
Durante el proceso de recuperación después de una
caída una transacción debe rehacerse si y sólo si la
traza contiene ambas marcas de inicio y de confirmación
de dicha transacción.
En todas las técnicas las operaciones deben ser
idempotentes, porque puede fallar durante la
recuperación.
Administración de Bases de Datos
Algoritmo no deshacer/rehacer
Si la traza en tres instantes de tiempo al fallar es:
la recuperación en cada caso es como sigue
Caso (a): no se debe rehacer ninguna transacción
Caso (b): se debe rehacer T0 (y se ignoran los registros de T1)
Caso (c): se debe rehacer T0 y T1
Administración de Bases de Datos
Algoritmo no deshacer/rehacer
void lee( transac t, pagina p, buffer b)
{
if (esta_actualizada_por(p,t) )
lee_img_post_en_buffer(p,b);
else
lee_pagina_en_buffer(p,b);
}
void esc( transac t,pagina p, buffer b)
{
esc_img_post_buffer_traza(p);
}
Los algoritmos para las diferentes funciones
con esta técnica son:
La gestión de buffers se produce según lo indicado en el apartado correspondiente, trayendo de disco a caché cuando se necesita, sin necesidad de indicarlo explícitamente en los algoritmos.
Administración de Bases de Datos
void confirma( transac t)
{ pagina p; //recorre la traza hacia delante
for (p=pagina_actualizada(t); p!=NULL; p=pagina_sig(t,p))
escribe_post_imag_traza_en_disco(p); //rehace
inserta_en_lista(Lc,t);
elimina_de_lista(La,t);
}
void aborta( transac t)
{ pagina p;
buffer b;
inserta_en_lista(Lb,t);
elimina_de_lista(La_t);
}
void rearranque()
{
transac t;
for (t = La ; t!= NULL; t = t->sig)
if( esta_en_lista(Lc,t)
confirma(t); //donde rehace
else aborta(t); //pero no necesita deshacer
}
Algoritmo no deshacer/rehacer
Aborta y
confirma
Administración de Bases de Datos
A=2 4
B=3 6
init lee A
[T1 init][T1,A,4][T1 commit][T2 init][T2,B,6][T2 commit]!FALLO!
esc A A=A+2
init lee B
commit
esc B B=B+3
T2
T1
FALLO
Ejemplo:
commit
Guarda imagen posterior
Algoritmo no deshacer/rehacer
Administración de Bases de Datos
Algoritmo deshacer/no rehacer
Con esta técnica, basada en la actualización inmediata, nunca es necesario rehacer una transacción después de un fallo del sistema. Por ello, no es necesario guardar las imágenes posteriores en la traza.
Las páginas actualizadas se escriben en disco cada vez que se actualizan elementos, sin esperar a la confirmación de la transacción.
Abortar transacciones puede ser caro (hay que deshacer las actualizaciones ya escritas en disco).
En la práctica no resulta lo más eficiente.
Administración de Bases de Datos
void esc( transac t,pagina p, buffer b)
{
inserta_imag_ant_buffer_traza(p);
escribe_buffer_en_pagina(p,b);
}
void lee( transac t,pagina p, buffer b)
{
lee_pagina_en_buffer(p,b);
}
Algoritmo deshacer/no rehacer
Los algoritmos para las diferentes funciones
con esta técnica son:
Administración de Bases de Datos
void confirma( transac t)
{ pagina p;
for (p=pagina_actualizada(t); p!=NULL; p=pagina_sig(t,p))
escribe_en_disco(p);
inserta_en_lista(Lc,t);
elimina_de_lista(La,t);
}
void aborta( transac t)
{ pagina p;
buffer b;
inserta_en_lista(Lb,t);
for(p=pagina_actualizada(t); p!=NULL; P=pagina_sig(t,p))
escribe_en disco_imagen_ant_de_p_desde_traza(); //deshace
elimina_de_lista(La,t);
}
void rearranque()
{
transac t;
for (t = La ; t!= NULL; t = t->sig)
aborta(t); //donde deshace
}
Sólo aborta
transacciones
Algoritmo deshacer/no rehacer
Administración de Bases de Datos
A=2 4
B=3 6
init lee A
[T1 init][T1,A,2][T1 commit][T2 init][T2,B,3]!FALLO!
esc A A=A+2
init lee B
commit
esc B B=B+3
T2
T1
FALLO
Ejemplo: Guarda imagen anterior
Algoritmo deshacer/no rehacer
Administración de Bases de Datos
Algoritmo deshacer/rehacer
Esta técnica, basada en la actualización inmediata,
combina la habilidad de rehacer con la de deshacer.
Las páginas sucias se vuelcan a disco en cualquier
momento que sea necesario, aunque correspondan a
transacciones no confirmadas (se ocupa el gestor de
buffers).
Se optimiza el funcionamiento normal
(sin abortos ni fallos).
El procedimiento de abortar es más costoso.
El procedimiento de rearranque más costoso.
Es el más comúnmente empleado por los SGBDs.
Administración de Bases de Datos
Algoritmo deshacer/rehacer
Es imprescindible que los registros de la traza se escriban a disco antes que los datos actualizados.
Procedimientos de recuperación:
Con las transacciones que en la traza tengan registrado el inicio pero no la confirmación, se Deshace la transacción, yendo hacia atrás en la traza desde el último registro de la transacción, restaurando las BFIM.
Con las transacciones que tengan registrados en la traza el inicio y la confirmación, se Rehace la transacción, yendo hacia delante en la traza, desde el primer registro de la transacción, estableciendo las AFIM.
Las operaciones deben ser idempotentes.
Se realizan primero las operaciones de Deshacer y luego las de Rehacer
Administración de Bases de Datos
Algoritmo deshacer/rehacer
Si la traza en tres instantes de tiempo al fallar es:
la recuperación en cada caso es como sigue
Caso (a): se deshace T0, restaurando A=1000 y B=2000
Caso (b): se deshace T1 y se rehace T0, restaurando C=700 y estableciendo A=950 y B=2050
Caso (c): se rehace T0 y T1, poniendo A=950, B=2050, C=600
Administración de Bases de Datos
Algoritmo deshacer/rehacer
Uso de los Puntos de control (checkpoints)
Los puntos de control, tanto en deshacer/rehacer como en los demás algoritmos, evitan tener que recorrer toda la traza para la recuperación, lo que resultaría muy costoso y realizaría acciones innecesarias.
Cuando se realiza (y registra) un punto de control, se escriben toda la información a disco y se guarda la información de las transacciones activas en ese momento. <checkpoint La>
Administración de Bases de Datos
Algoritmo deshacer/rehacer
Uso de los Puntos de control (checkpoints)
Cuando el sistema se recupera de una caída
se inicializan undo-list y redo-list vacías,
se va recorriendo la traza hacia atrás hasta un punto de control,
si se encuentra <Ti commit> se incluye Ti en la redo-list,
si se encuentra <Tj start> y Tj no está en la redo-list se incluye Tj en la undo-list,
al llegar a un <checkpoint La>, si se encuentra Tk en La y Tk no está en la redo-list se incluye en la undo-list,
se sigue la traza hacia atrás hasta encontrar todos los <Tu start> de las Tu que estén la La, deshaciendo los pasos de las Tu,
se avanza en la traza hasta el punto de control más reciente,
se sigue avanzando en la traza rehaciendo todas las operaciones registradas correspondientes a las Ti en la redo-list.
Administración de Bases de Datos
Algoritmo deshacer/rehacer Uso de los Puntos de control (checkpoints)
Ejercicio: deshacer/rehacer con la siguiente traza:
<T0 start>
<T0, A, 0, 10>
<T0 commit>
<T1 start> /* Scan at step 1 comes up to here */
<T1, B, 0, 10>
<T2 start>
<T2, C, 0, 10>
<T2, C, 10, 20>
<checkpoint {T1, T2}>
<T3 start>
<T3, A, 10, 20>
<T3, D, 0, 10>
<T3 commit>
Administración de Bases de Datos
void esc( transac t,pagina p, buffer b)
{
inserta_imag_ant_buffer_traza(p);
inserta_imag_post_buffer_traza(p);
}
void lee( transac t,pagina p, buffer b)
{
if ( esta_actualizada_por(p,t) )
lee_img_post_en_buffer(p,b);
else
lee_pagina_en_buffer(p,b);
}
Algoritmo deshacer/rehacer
Los algoritmos para las diferentes funciones
con esta técnica son:
Administración de Bases de Datos
void confirma( transac t)
{ pagina p;
inserta_en_lista(Lc,t);
for (p=pagina_actualizada(t); p!=NULL; p=pagina_sig(t,p))
if (esta_sucia(p))
escribe_post_imag_traza_en_disco(p); //rehace
elimina_de_lista(La,t);
}
void aborta( transac t)
{ pagina p;
bufer b;
inserta_en_lista(Lb,t);
for (p=pagina_actualizada(t); p!=NULL; p=pagina_sig(t,p))
lee_en_buffer_img_ant_de_p_desde_traza(p,b); //deshace
elimina_de_lista(La_t);
}
void rearranque()
{
transac t;
for (t = La ; t!= NULL; t = t->sig)
if( esta_en_lista(Lc,t)
confirma(t);
else aborta(t);
}
Aborta y
confirma
Alg
ori
tmo
desh
acer-
reh
acer
Administración de Bases de Datos
A=2 4
B=3 6
init lee A
[T1 init][T1,A,2,4][T1 commit][T2 init][T2,B,3,6][T2 commit]!FALLO!
esc A A=A+2
init lee B
commit
esc B B=B+3
T2
T1
FALLO
Ejemplo:
commit
Guarda imagen posterior y anterior
Algoritmo deshacer/rehacer
Administración de Bases de Datos
Algoritmo no deshacer/no rehacer
Existen dos técnicas básicas de actualización:
actualización en el sitio, en la cual cuando es necesario escribir en disco se sobreescriben los objetos de la BD en su posición original. Se utiliza en todos los algoritmos de recuperación vistos anteriormente.
El sombreado (paginación en la sombra) escribe las páginas actualizadas en una nueva posición, y mantiene (provisionalmente) las páginas originales en su ubicación original. La nueva página sólo es visible cuando la transacción se confirma. Esta técnica permite los algoritmos no deshacer/no rehacer.
Administración de Bases de Datos
Algoritmo no deshacer/no rehacer La paginación en la sombra es una alternativa a la
recuperación basada en la traza (si no hay concurrencia de transacciones ni siquiera se necesita traza).
En ejecuciones serializadas
Se mantienen dos tablas de páginas, la tabla de páginas actual y la tabla de páginas en la sombra.
Cuando se inicia una transacción se copia la tabla de páginas actual en la tabla “sombra”.
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)
Cuando se confirma la transacción, se descarta la tabla “sombra”.
Si se produce un fallo, la tabla “sombra” se copia en la “actual”.
No es necesario ni rehacer ni deshacer
Administración de Bases de Datos
Algoritmo no deshacer/no rehacer
paginación en la sombra
Administración de Bases de Datos
Algoritmo no deshacer/no rehacer
Inconvenientes
Se debe guardar y copia la tabla de páginas entera.
En cualquier caso hay que gestionar la “recolección de basura” de páginas “obsoletas” después de la confirmación de una transacción.
Los datos de la BD quedan fragmentados.
En caso de ejecuciones concurrentes, hay que guardar y utilizar información en la traza y la recuperación se complica mucho respecto a las planificaciones serializadas.
En conjunto, la técnica supone un sobrecoste de operaciones que la hace ineficiente en la práctica.
Administración de Bases de Datos
void confirma( transac t)
{ pagina p;
for (p=pagina_actualizada(t); p!=NULL; p=pagina_sig(t,p))
if (esta_sucia(p))
escribe_post_imag_traza_en_disco(p);
elimina_de_lista(La,t);
}
void rearranque()
{
transac t;
for (t = La ; t!= NULL; t = t->sig)
aborta(t);
}
Algoritmo no deshacer/no rehacer
Los algoritmos específicos con esta técnica
son: