PDF de programación - Mecanismos de Recuperación

Mecanismos de
Recuperación

1

Índice

Aspectos generales sobre recuperación
Tipos de fallos
Fallos con pérdida de memoria volátil

– Actualización inmediata
– Actualización diferida

Fallos con pérdida de memoria estable
Mecanismos de recuperación en

ORACLE

© O. Díaz, A. Illarramendi UPV/EHU

2

Bibliografía

Fundamentals of Database Systems (4.edición 2004)

Fundamentos de Sistemas de Bases de Datos (3. Edición
2002)
R.A. Elmasri, S. B. Navathe
Addison Wesley 2002

Fundamentos de Bases de Datos (4. edición)

A. Silberschatz, H. F. Korth, S. Sudarshan
Mc. Graw Hill 2002

Database System Implementation

H. García Molina, J.D. Ullman, J. Widom
Prentice Hall 2000

© O. Díaz, A. Illarramendi UPV/EHU

3

Propiedades de la Transacción

Principio ACID (su cumplimiento debe estar asegurado por el SGBD)

Se ejecuta como unidad (Atomicity) Gestor de
Preserva la consistencia(Consistency) Gestor de Rest.

transacciones, Gestor de recuperación

de integridad

Una transacción no muestra los cambios que
produce hasta que finaliza (Isolation) Gestor de Control
de Concurrencia

Si termina correctamente, sus cambios

permanecen (Durability) Gestor de Recuperaciones

© O. Díaz, A. Illarramendi UPV/EHU

4

Aspectos generales sobre
recuperación
Los sistemas de Bases de Datos deben

asegurar la disponibilidad de los
datos a aquellos usuarios que tienen
derecho a ello por lo que proporcionan
mecanismos que permiten recuperar la
BD contra fallos lógicos o físicos que
destruyen los datos en todo o en parte

© O. Díaz, A. Illarramendi UPV/EHU

5

Aspectos generales sobre
recuperación
Mecanismo de recuperación:

responsable de la restauración de la BD
al estado consistente previo al fallo.
También debe proporcionar alta
disponibilidad, esto es, debe minimizar
el tiempo durante el que la BD no se
puede usar después de un fallo.

© O. Díaz, A. Illarramendi UPV/EHU

6

Aspectos generales sobre
recuperación

El principio básico en el que se apoya la
recuperación de la Base de Datos es la

“Redundancia Física”

En muchos casos los procesos de recuperación y de
control de concurrencia están interrelacionados. En
general, cuanto mayor sea el grado de concurrencia
que deseemos alcanzar, mayor tiempo consumirá la
tarea de recuperación.

7

© O. Díaz, A. Illarramendi UPV/EHU

Aspectos generales sobre
recuperación
Para fines de recuperación el sistema necesita

mantenerse al tanto de cuando la transacción se
inicia, termina y se confirma o aborta.

El gestor de recuperación se mantiene al tanto de las
siguientes operaciones (esta información se almacena en
el diario):
BEGIN_TRANSACTION
READ O WRITE
END_TRANSACTION
COMMIT_TRANSACTION
ROLLBACK O ABORT

8

© O. Díaz, A. Illarramendi UPV/EHU

Aspectos generales sobre
recuperación

leer/escribir

begin_of_tra

ACTIVA

end_of_tra

PARCIALMENTE
CONFIRMADA

confirmar

CONFIRMADA

abortar

abortar

FALLIDA

TERMINADA

DTS (Diagrama de Transición de Estados) para la ejecución de

transacciones

Parcialmente Confirmada:
el SGBD verifica que no hay interferencias dañinas con otras transacciones.

© O. Díaz, A. Illarramendi UPV/EHU

9

Tipos de Fallos

Fallo del ordenador (caída del sistema)
Error de la transacción (ej. Overflow,

violación restricción)

Errores de los usuarios (ej. el usuario borra

accidentalmente una tabla)

Imposición de control de concurrencia (ej.

estado de bloqueo mortal)

Fallo disco
Catástrofes físicas (Ej. inundación)

© O. Díaz, A. Illarramendi UPV/EHU

10

Fallos

Los fallos pueden afectar a las transacciones

en sus propiedades ACID. Deben existir
algoritmos que garanticen la consistencia de
la BD y la atomicidad de las transacciones a
pesar de los fallos.

Solución:

– Mecanismos de control de concurrencia
– Mecanismos de recuperación

© O. Díaz, A. Illarramendi UPV/EHU

11

Fallos referentes al SGBD

Dos tipos importantes:

– Los que provocan la pérdida del contenido

de la memoria estable (discos)

– Los que provocan la perdida de la

memoria volátil (memoria principal),
debidos a interrupción de suministro
eléctrico o por funcionamiento anormal del
hardware

© O. Díaz, A. Illarramendi UPV/EHU

12

Estrategia de Recuperación Típica

Si hay daños en una porción de la BD (ej. debido a

un fallo del disco) el método de recuperación:
– restaurará una copia anterior de la BD (que puede estar en

cinta) y

– reconstruirá un estado más actual, volviendo a aplicar

operaciones almacenadas en el diario.

Cuando la BD no presenta daños físicos pero se ha

vuelto inconsistente, la estrategia consiste en
– invertir los cambios que provocaron la inconsistencia. Se
trabaja con el diario, no se necesita una copia archivada.

© O. Díaz, A. Illarramendi UPV/EHU

13

Operaciones básicas

memoria volátil

read/write

buffer local
buffer local
buffer local
buffer local

b
u
f
f
e
r

g
l
o
b
a
l


memoria estable

BD

input/output

bloque

Área de trabajo privada para cada transacción

Las operaciones básicas de acceso a una BD que una

transacción puede incluir son:
– leer-elemento (READ)
– escribir-elemento (WRITE)
–
– OUTPUT

INPUT

© O. Díaz, A. Illarramendi UPV/EHU

14

Operaciones básicas
Nivel Transacciones
READ(x) -- SELECT
•
•
•

buscar si X está en el buffer global
si no, ocasionar un input para traer el bloque que contiene a X
copiar X del buffer global al buffer local

WRITE(x) -- INSERT, UPDATE, DELETE
•
•

copiar X del buffer local al buffer global
SGBD transfiere el bloque actualizado desde el buffer al disco (en
algún momento)

Nivel Gestor de Buffer
INPUT
• Copia el bloque que contiene el elemento X en el buffer global
OUTPUT
• Copia el bloque que contiene a X al disco

© O. Díaz, A. Illarramendi UPV/EHU

15

El Diario o Bitácora

Objetivo: recuperar fallos con pérdida
Fichero gestionado por el SGBD
Entradas:

– [start_transaction, T ] identificador de la transacción
– [commit, T]
– [abort, T]
– [read_item, T, dato, <valorLeido>]
– [write_item, T, dato, <valorAntigüo>, <valorNuevo>]

Operaciones:

– REDO: se escriben los <valorNuevo> en la BD
– UNDO: se repone los <valorAntigüo> en la BD

© O. Díaz, A. Illarramendi UPV/EHU

16

Fichero Diario

Puede surgir un problema en caso de que se
realice un cambio en la BD y no en el fichero
diario; por ello normalmente se obliga a que
los registros que se modifican se escriban
antes en el fichero diario que en la BD, para
poder anular así, en caso de necesidad, las
transacciones (log write-ahead protocol)

© O. Díaz, A. Illarramendi UPV/EHU

17

Fallos con pérdida de memoria
volátil

Actualización inmediata

• escribir (X) se hace directamente en el Buffer Global.

Actualización diferida

• escribir (X) se hace sobre el buffer local. Sólo al terminar la

transacción se vuelca sobre el buffer global.

© O. Díaz, A. Illarramendi UPV/EHU

18

Actualización inmediata

BUFFER GLOBAL
X:_________Y:__________

BUFFER LOCAL
X:_________Y:__________
begin_of_transaction
escribir(X,10)
leer(Y)
end_of_transaction

DIARIO

[start_transaction, T]
[write_transaction,T,x, 2,10]
[read_item,T,y]
[commit,T]

BD

•Actualizaciones inmediatas: escribir (X) se hace directamente en el Buffer
Global.
•Al hacer el output de los registros del diario, T pasa a parcialmente confirmada
•Ante un fallo con pérdida, si la entrada [commit,T]

• (caso A). aparece en el diario, entonces REDO(T)
• (caso B). no aparece en el diario, entonces UNDO(T)

© O. Díaz, A. Illarramendi UPV/EHU

19

Error con actualizaciones inmediatas

A)

BOT escribir(x) EOT output

tiempo

[start_transaction,T]

[commit,T]

[write_item,T,x,2,10]

se pierde escribir(x): REDO

B)

BOT escribir(x) OUTPUT escribir(y) EOT

[start_transaction,T]

© O. Díaz, A. Illarramendi UPV/EHU

[write_item,T,x,2,10]]

no se garantiza atomicidad: UNDO

20

Error con actualizaciones inmediatas

Se pueden producir “rollbacks” en
cascada lo que implica un costo en
proceso y en tiempo

© O. Díaz, A. Illarramendi UPV/EHU

21

Actualización Diferida

BUFFER GLOBAL
X:_________Y:__________

BUFFER LOCAL
X:_________Y:__________
begin_of_transaction
escribir(X,10)
leer(Y)
end_of_transaction

DIARIO

[start_transaction, T]
[write_transaction,T,x, 2,10]
[read_item,T,y]
[commit,T]

BD

•Actualizaciones diferidas: escribir (X) se hace sobre el buffer local. Sólo al terminar
la transacción se vuelca sobre el buffer global.
•Al hacer el output de los registros del diario, T pasa a parcialmente confirmada.
•Ante un fallo con pérdida, si la entrada [commit,T]:

© O. Díaz, A. Illarramendi UPV/EHU

• (caso A). aparece en el diario, entonces REDO(T)
• (caso B). no aparece en el diario, entonces “ignorar y volver a lanzar T”

22

Actualización Diferida

No puede usarse en la práctica a menos que

las transacciones sean cortas y cada
transacción cambie pocos elementos.

Para otro tipo de transacciones existe el
potencial de agotamiento del espacio del
buffer.

No se realiza la operación UNDO

© O. Díaz, A. Illarramendi UPV/EHU

23

Error con actualizaciones diferidas

A)

BOT escribir(x) EOT output

tiempo

[start_transaction,T]

[commit,T]

[write_item,x,2,10]]

se pierde escribir(x): REDO

B)

BOT escribir(x) EOT

output

tiempo

[start_transaction,T]

© O. Díaz, A. Illarramendi UPV/EHU

[write_item,x,2,10]]

escribir(x) no ha modificado la BD
Sólo hay que volver a lanzar T

24

Proceso de recuperación

(1º)

(2º)

UNDO

REDO

[start_transaction,T1]
.............
[commit,T1]
[start_transac