1 administración de bases de datos recuperación objetivos apreciar la necesidad de proteger la...

1

Administración de Bases de Datos

Recuperación

Objetivos

Apreciar la necesidad de proteger la información frente a fallos del sistema

Identificar los tipos de fallos que pueden ocurrir en un SGBD

Comprender el propósito de los diarios (log) y los puntos de validación del sistema

Conocer y entender diferentes técnicas del SGBD para recuperarse frente a fallos

2


Recuperación

Contenidos

Aspectos generales sobre recuperación

Tipos de fallos

El proceso de recuperación

Técnicas de recuperación

Anexo: Mecanismos de recuperación en Oracle

3



Los SGBD deben asegurar la disponibilidad de los datos

Por lo que proporcionan mecanismos que permiten recuperar la BD frente a fallos lógicos o físicos que destruyen todos o partes de los datos

Mecanismo de recuperación del SGBD:

Responsable de la restauración de la BD al estado consistente previo al fallo

También debe proporcionar alta disponibilidad, minimizando el tiempo de la incidencia

4



Transacción T: Añadir a la BDs la empleada (14, Julia, 30)

codEmp nomEmp

dept

1 German 10

12 Antonio 20

7 Cristina 30

22 Eva 20

5 Rubén 10

... ... ...

EMPLEADO

Dept nomDep Ciudad numEmp

20 Producción

Murcia 2

10 Dirección Sevilla 2

30 Sistemas Barcelona

1

... ... ...

DEPARTAMENTO

5



El código de T podría ser:

(0) EXEC SQL BEGIN TRANSACTION;...(1) EXEC SQL WHENEVER SQLERROR ROLLBACK;(2) EXEC SQL INSERT INTO empleado VALUES (14, Julia, 30);(3) EXEC SQL UPDATE departamento SET

numEmp=numEmp+1 WHERE dept=30;(4) EXEC SQL COMMIT;

Única transacción con varias operaciones/sentencias SQL ¿Cuál es el estado de la BD entre las sentencias 2 y 3?

6



Idea básica: atomicidad y durabilidad de toda transacción

Secuencia de operaciones que llevan a la BD de un estado consistente a otro estado consistente

Debe garantizarse frente a todo tipo de fallos posible

El SGBD debe asegurar que toda transacción T ... Ejecuta todas las operaciones con éxito y su efecto quede

permanentemente en la BD, o bien, No tenga ningún efecto sobre la BD ni otras transacciones

Nunca deben ejecutarse sólo algunas operaciones de T Ni tan siquiera por culpa de un “fallo” en mitad de T

7



Recuperación:

Restablecer la información a un estado consistente, tras un fallo del sistema que ha dejado la BD en un estado inconsistente o sospechoso de serlo

El principio básico de la recuperación de BD: Redundancia Física

El SGBD vela porque:

No se pierda ninguna transacción Ninguna transacción quede a medio ejecutarse (integridad) Ninguna transacción se realice más de una vez

8



Para realizar su labor, el subsistema de recuperación debe monitorizar las transacciones:

Cuando se inicia Cuando se termina Cuando se confirma Cuando aborta

El gestor de la recuperación monitoriza las siguientes transacciones:

BEGIN_TRANSACTION READ o WRITE END_TRANSACTION COMMINT_TRANSACTION ROLLBACK ABORT

9


Estados y operaciones de una transacción

activaParcialmente confirmada

confirmada

fallida terminada

abortar abortar

confirmarinicio fin

leer/escribir

rollback

commit

protocolos de

recuperación

10


Tipos de Fallos

Fallo por imposición del control de concurrencia Violación de la seriabilización, bloqueo mortal, ...

Fallo en la transacción Overflow, división por cero, violaciones de restricciones, ... Fallos locales (sólo afectan a la transacción fallida)

Fallo software SGBD, SO, comunicaciones, ... Fallos globales

Fallo hardware Fallos en discos, máquinas, redes, ... Fallos globales

Fallos catastróficos Corte de suministro eléctrico, robo, incendio, inundación,

sabotaje, borrado/sobreescritura accidental, etc.

11


Fallos

Los fallos pueden afectar a las transacciones es sus propiedades ACID:

Atomicity Consistency Isolation Durability

Solución:

Mecanismos de control de concurrencia Mecanismos de recuperación

12


Fallos

Vamos a tratar principalmente:

Fallos que provocan la pérdida de la memoria volátil (memoria principal)

Fallos que provocan la pérdida de la memoria estable (memoria secundaria)

13


Diario

Cuando ocurre un fallo, ¿cómo restaurar la base de datos a un estado consistente?

Redundancia: diario (log, journal, registro histórico,...) Monitorizar la ejecución de las transacciones: cuando se

inicia, confirma, aborta, acaba, qué operaciones realiza sobre qué datos

Se obliga a que los datos que se modifican se escriban en disco antes en el diario que en la BD (log write-ahead protocol)

Particiones de disco (o discos) distintos Copia de seguridad periódica

Técnica de recuperación Acciones que permitan restablecer el contenido de la BD a

un estado que asegure: consistency, atomicity, durability

14


Diario

Entradas del fichero:

[START_TRANSACTION, T, time]Indica que la transacción T ha comenzado la ejecución

[COMMIT, T, time]Indica que T finalizó con éxito y su efecto puede ser confirmado en la BD en disco: los cambios pueden quedar permanentes en la BD.

[ROLLBACK, T, time]Indica que la transacción ha sido anulada de forma que ninguna de sus operaciones tendrá efecto sobre la BD

[READ, T, X, VALUE, time]Indica que T leyó el valor del elemento X de la BD

[WRITE, T, X, OLDVALUE, NEWVALUE, time]Indica que T ha modificado el valor del elemento X

15


Diario

Operaciones:

REDO(T), rehacer: se escriben los NEWVALUE de T en la BD

UNDO(T), deshacer: se escriben los OLDVALUE de T en la BD

Recuperar un fallo de T consistirá en deshacer (UNDO) o rehacer (REDO) algunas de las operaciones, a partir del contenido del diario

Actualizaciones del diario

Inmediatas Diferidas

16


Pérdida de memoria

Buffer local

Buffer local

Buffer local

Buffer local

BufferGlobal BD

input/output

Bloquesread/writeDatos

Área de trabajo privada de cada transacción

17


COMMIT

Cuando T realiza un COMMIT significa que: Todas las operaciones se ejecutaron con éxito El efecto de dichas operaciones se anotó en la bitácora,

incluyendo el COMMIT! T ha llegado a un punto de confirmación

y se puede suponer que: T está confirmada Sus cambios son permanentes en la BD Bloqueos liberados, buffers liberados, etc.

BD ok BD okT

UPDATE... SELECT... INSERT... COMMIT...

...[START ...][WRITE ...][READ ...][WRITE ...][COMMIT ...]...

18


ROLLBACK

Cuando T realiza un ROLLBACK significa que: T ha resultado fallida, y sus operaciones no deben tener

efecto El efecto de dichas operaciones se anotó en la bitácora,

incluyendo el ROLLBACK! T ha llegado a un punto de confirmación

y se puede suponer que: T está cancelada Sus operaciones han sido anuladas en la BD Bloqueos liberados, buffers liberados, etc.

BD ok

T

UPDATE... SELECT... INSERT... ROLLBACK...

...[START ...][WRITE ...][READ ...][WRITE ...][ROLLBACK ...]...

19


Proceso de recuperación

Si el fallo ocurre cuando T está en ejecución, entonces se debe deshacer (UNDO), pues no alcanzó su punto de confirmación (no anotó COMMIT)

Si el fallo ocurre cuando T ha sido confirmada, entonces se debe rehacer (REDO), pues no es seguro que todos los cambios hayan sido llevados a la BD en disco

T

UPDATE... SELECT... INSERT...

T

UPDATE... SELECT... INSERT... COMMIT...

20


Proceso de recuperación

UNDO T implica deshacer cada una de las operaciones a partir de las anotaciones en bitácora, empezando por la última (orden inverso!)

UNDO [WRITE, T, X, OldValue, NewValue, time] => X=OldValue en BD

REDO T implica rehacer cada una de las operaciones, a partir de las anotaciones en el diario, empezando por la primera (mismo orden)

REDO [WRITE, T, X, OldValue, NewValue, time] => X=NewValue en BD

21


Diario adelantado (a la BD)

Escritura inmediata en el diario

El diario es un fichero almacenado en disco, por lo que para insertar una nueva entrada es necesario:

Copiar el bloque adecuado del fichero en memoria principal Actualizar el bloque en memoria, insertando la nueva entrada Copiar el bloque desde memoria al disco Una escritura de bloque en disco por cada nueva entrada!

Escritura diferida en el diario

El buffer del diario contiene un bloque del diario hasta que se llena de entradas, momento en el que se escribe en el disco

Copiar el bloque desde memoria a disco Una única escritura por bloque!

22



Cuando ocurre un fallo. Algunas entradas pueden no haber sido llevadas al diario en disco

Con el fallo, se pierde el contenido de la memoria principal Entradas del diario en el buffer (bloque incompleto)

Dichas entradas no serán consideradas en el proceso de recuperación!

El subsistema de recuperación del SGBD sólo consulta el diario!

Es necesario segur un protocolo de escritura anticipada del diario: diario adelantado

23



No se pueden grabar en la BD los cambios realizados por T hasta que se haya escrito en disco toda entrada del diario para T (primero diario, luego BD)

El COMMIT de T no se puede completar hasta que se haya escrito en disco cualquier entrada de diario para T pendiente de escribir (localizada en el buffer)

Se fuerza la escritura en disco de las entradas del buffer de diario para T, antes de consolidar los cambios hechos por T

Escrituras de bloque por transacción!

24



Nunca puede ocurrir ...

Pero sí puede suceder ...

TUPDATE... SELECT... INSERT... COMMIT...

ESCRITURA BD ESCRITURA DIARIO


ESCRITURA DIARIO

ESCRITURA BD


ESCRITURA DIARIO

ESCRITURA BD

25


Puntos de validación (checkpoint)

Dado un fallo ...

¿Cómo sabe el SGBD qué transacciones deben deshacerse?

Examinar TODO el diario buscando aquellas Ti sin COMMIT? ¿y cuáles debe rehacer?

Examinar TODO el diario buscando las Ti con COMMIT?

T1UPDATE... SELECT... INSERT... SELECT...

T2SELECT... INSERT... INSERT... COMMIT...

T3UPDATE... SELECT... INSERT...

26



El SGBD marca automáticamente un punto de validación:

Cada cierto tiempo Tras escribir N entradas en el diario Cada vez que se graba un bloque de buffer a disco

Es otro tipo de entrada del diario

[CHECKPOINT ...] Contiene la lista de identificadores de transacciones

activas Dirección en el diario de la primera y última entradas

de cada transacción activa

27



Marcar un punto de validación significa ...

Suspender la ejecución de todas las transacciones Forzar la escritura en disco del buffer del diario Forzar la escritura en disco de todo bloque del buffer

global Escribir en el buffer del diario el registro de validación

y forzar su escritura en disco Escribir en otro diario, la dirección de la entrada de

validación en el diario Reanudar la ejecución de las transacciones

28



Los puntos de validación permiten: Recorrer el diario a partir del último punto de

validación ... Y no desde el principio

Ignorar las transacciones confirmadas antes del último punto de validación

... No es necesario rehacer TODAS las confirmadas

activaParcialmenteConfirmada

confirmadaconfirmarinicio fin

leer/escribir

terminada

Commit buffer[COMMIT]

Commit diario

[CHECKPOINT]

29


Tipos de Fallos

(1) Fallo por imposición del control de concurrencia Violación de la seriabilización, bloqueo mortal, ...

(2) Fallo en la transacción Overflow, división por cero, violaciones de restricciones, ... Fallos locales (sólo afectan a la transacción fallida)

(3) Fallo software SGBD, SO, comunicaciones, ... Fallos globales

(4) Fallo hardware Fallos en discos, máquinas, redes, ... Fallos globales

(5) Fallos catastróficos Corte de suministro eléctrico, robo, incendio, inundación,

sabotaje, borrado/sobreescritura accidental, etc.

30


Técnicas de recuperación de fallos

Ante fallos de tipo 1 o 2:

Invertir las modificaciones que provocaron la inconsistencia: deshacer algunas operaciones <= diario

Si es necesario, asegurar cambios correctos: rehacer algunas operaciones <= diario

Ante fallos de tipo 3, 4 o 5:

Restaurar copia de seguridad de la BD Reconstruir el estado consistente más reciente:

rehacer algunas operaciones <= diario

31



Actualización diferida

No se modifica la BD hasta después de realizar un COMMIT

Se difiere la consolidación de los cambios realizados por la transacción hasta después de confirmarse

Si el fallo ocurre antes de alcanzarse su punto de confirmación, no es necesario deshacer sus operaciones

Si el fallo ocurre después de su punto de confirmación, es necesario rehacer sus operaciones


ESCRITURA DIARIO

ESCRITURA BD

32



Algoritmo no-deshacer / rehacer

1. Crear dos listas vacías: ACTIVAS y CONFIRMADAS2. Inicializar ACTIVAS con la lista de transacciones activas

almacenada en el último registro de validación del diario3. Examinar el diario a partir del último punto de validación4. Si se encuentra [START T], añadir T a la lista ACTIVAS5. Si se encuentra [COMMIT T], mover R de ACTIVAS a

CONFIRMADAS6. Al terminar de examinar el diario:

1. Rehacer las operaciones <WRITE > de las transacciones en el mismo orden en que aparecen en el diario

2. Reiniciar las transacciones de la lista ACTIVAS

33



En el diario, las entradas <WRITE > sólo necesitan guardar el valor nuevo (pueden rehacerse, pero nunca deshacerse)

Reiniciar una transacción es reintroducirla en el sistema como si fuera nueva

Las operaciones de rehacen en el orden en que aparecen anotadas en el diario

No se rehace cada transacción “aisladamente”, si no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una.

34



Actualización inmediata

La BD puede modificarse antes de realizar un COMMIT Se actualizan inmediatamente los cambios realizados

por la transacción antes de confirmarlos

Si el fallo ocurre antes de alcanzarse su punto de confirmación, es necesario deshacer sus operaciones

Si el fallo ocurre después de su punto de confirmación, es necesario rehacer sus operaciones


ESCRITURA DIARIO

ESCRITURA BD

35



Algoritmo deshacer / rehacer

1. Crear dos listas vacías: ACTIVAS y CONFIRMADAS2. Inicializar ACTIVAS con la lista de transacciones activas

almacenada en el último registro de validación del diario3. Examinar el diario a partir del último punto de validación4. Si se encuentra [START T], añadir T a la lista ACTIVAS5. Si se encuentra [COMMIT T], mover R de ACTIVAS a

CONFIRMADAS6. Al terminar de examinar el diario:

1. Deshacer las operaciones <WRITE > de las transacciones de la lista ACTIVAS, en orden inverso al del diario

2. Rehacer las operaciones <WRITE > de las transacciones de CONFIRMADAS, en el mismo orden al del diario

36



En el diario, las entradas <WRITE > necesitan guardar el valor anterior y nuevo: pueden rehacerse o deshacerse

Se debe deshacer primero y rehacer después Las operaciones de deshacen en el orden inverso en que

aparecen anotadas en el diario No se deshace cada transacción activa “aisladamente”, si

no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una.

Las operaciones de rehacen en el mismo orden en que aparecen anotadas en el diario

No se rehacen cada transacción confirmada “aisladamente”, si no que se van rehaciendo todas las operaciones de las transacciones involucradas una a una.

37



La Base de Datos entre otros contiene: Ficheros de datos (data files) Ficheros de recuperación (redo log files) Ficheros de control sobre la estructura física de la BDs

(control file) Ficheros de parémetros (parameter file)

Instancia de Oracle Conjunto de procesos que se ejecutan en background Zona de memoria global (System Global Area, SGA)

Buffer de datos Buffer del diario Buffer de planes de ejecución de sentencias SQL

Zona de memoria de proceso (Program Global Area, PGA)

38



Procesos de una instancia ORACLE DBWR (Database writer) CKPT (Checkpoint) LOGWR (Log Writer) ARCH (Archive)

Si se produce un fallo, el sistema recurre a los ficheros de log para recuperar un estado consistente

Tamaño del fichero de log: escritura circular. El sistema va alternando entre dos o más ficheros. Cuando termina con el último, empieza con el primero

Fallo en los ficheros de log: escritura doble (multiplexada) Archivo histórico de logs Volcado periódico total del contenido completo de la BD (full

dump)

39



Dump

Volcar periódicamente el contenido entero de la BD: archivar De todos los datos (full dump) Sólo los datos modificados desde el último proceso de

volcado (incremental dump) Volcado “en frío”: el SGBD está parado Volcado “en caliente”: el SGBD está funcionando Recuperación “en caliente”!

1 administración de bases de datos recuperación objetivos apreciar la necesidad de proteger la...

Documents