Elementos de Bases de Datos

Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur

Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar]

Clase 19 1er. Cuatrimestre de 2004

Tipos de Fallos
 Fallos en la Transacción
1. Error lógico: la transacción no puede continuar su ejecución a causa de alguna condición interna.
2. Error del sistema: el sistema alcanza un estado no correcto. La transacción puede volver a ejecutarse más tarde.

Otras transacciones continúan con su ejecución.

 Caída del sistema: por ejemplo, errores del hardware o software de base de datos o software del
sistema operativo.
 Fallo de disco: daño físico en el medio de almacenamiento masivo.

Todas las transacciones deben ser recuperadas.

Acciones de recuperación
Para asegurar la consistencia en la base de datos y la atomicidad de las transacciones (a
pesar de los fallos), los algoritmos tienen dos partes:

 Acciones tomadas durante el procesamiento normal de la transacción para asegurar que

existe suficiente información para permitir la recuperación de fallos(preventivas).
 Acciones tomadas a continuación de un fallo para asegurar la consistencia de la base de
datos y la atomicidad de las transacciones (paleativas).

Recuperación mediante Bitácora

La bitácora es una estructura usada para guardar información sobre las modificaciones que se
realizaron a los datos. Existen varias implementaciones. Veremos una implementación que contiene
registros con los campos:

 Nombre de la Transacción: el nombre de la transacción que ejecutó el Write.

 Nombre del Dato: el nombre único del dato escrito.
 Valor Antiguo: el valor del dato anterior a la escritura.
 Valor Nuevo: el valor que tendrá el dato después de la escritura.

Modificación diferida
 Garantiza la atomicidad de la transacción grabando todas las modificaciones en la bitácora
pero aplazando todas las operaciones Write hasta que la transacción se comete
parcialmente.
 La información en la bitácora asociada a la transacción parcialmente cometida se usa en
la ejecución de las escrituras diferidas.
 Si el sistema se cae antes de que termine de ejecutarse una transacción, o si la
transacción aborta, se ignora la información de la bitácora.
Modificación diferida: pasos a seguir
 Información de la bitácora
1. Antes de que comience una transacción T, se escribe el registro de bitácora <T,start>.
2. Si T realiza una operación Write(X,v), se escribe el registro de bitácora <T,X,v>.
3. Cuando T está parcialmente cometida, se escribe el registro de bitácora <T,commit>.

 El esquema de recuperación usa la operación REDO(Rehacer) usando información de la

bitácora.
1. REDO (T)cuando en la bitácora existen los registros<T,start> y <T,commit>.

Modificación inmediata
 Las modificaciones en la base de datos se realizan mientras la transacción está activa,
antes de alcanzar el estado de cometida.
 Este tipo de modificaciones se denominan modificaciones no cometidas.
 En caso de que ocurra una caída o fallo de una transacción se debe recurrir a una
operación Undo que “deshace” los cambios hechos.
 La operación Undo extrae la información de la bitácora para determinar qué datos deben
restaurarse.

Modificación inmediata: pasos a seguir

 Información de la bitácora
1. Antes de que comience una transacción T, se escribe el registro de bitácora <T,start>.
2. Si T realiza una operación Write(X,v), se escribe el registro de bitácora <T,X,v1,v2>.
3. Cuando T está parcialmente cometida, se escribe el registro de bitácora <T,commit>.

 No puede permitirse la actualización efectiva de la base de datos (Output (RegDatos))

antes de que se escriba el registro de bitácora en memoria estable (Output
(RegBitácora)).

Recuperación de fallos
 El esquema de recuperación usa las operaciones y Undo (Deshacer) y Redo
(Rehacer) usando información de la bitácora.
 Cuando se produce un fallo, el esquema de recuperación consulta a la bitácora para
determinar que transacciones deben deshacerse o rehacerse.
1. UNDO (T): cuando la bitácora contiene el registro<T,start> pero no contiene el registro
<T,commit>.
2. REDO (T): cuando la bitácora contiene tanto el registro<T,start> como el registro <T,commit>
Puntos de Verificación (Checkpoints)
 Cuando ocurre un fallo del sistema es necesario consultar la bitácora para ver cuáles
transacciones deben rehacerse y cuáles deshacerse.
 Esto implica revisar TODA la bitácora.
1. El proceso de búsqueda consume tiempo.
2. La mayor parte de las transacciones que, según el algoritmo, deben volver a hacerse, ya
escribieron sus actualizaciones en la base de datos en memoria estable.
3. Volver a hacerlas no causa daño (redo es idempotente) pero consume tiempo.

Checkpoints: pasos a seguir

 Los checkpoints buscan reducir los tiempos extra en los procesos de búsqueda en la
bitácora.
 Al disparar un checkpoint el sistema realiza la siguiente secuencia de acciones:
1. Grabar en memoria estable todos los registros de bitácora que están en memoria principal.
2. Grabar en disco los bloques modificados de los registros intermedios (buffer).
3. Grabar un registro de bitácora <checkpoint> en memoria estable.

 El checkpoint es una actividad del sistema de base de datos periódica y programada.

Checkpoints: pasos a seguir ante fallos

 Para cada transacción Ti tal que aparece en la bitácora el registro <Ti,commit> antes
del registro<checkpoint>, no es necesario ejecutar un REDO.
 Después de un fallo, se examina la bitácora para determinar cuál fue la última
transacción Ti que comenzó a ejecutarse antes del último checkpoint.
1. Esto se hace examinando la bitácora hacia atrás buscando el primer registro <checkpoint> y
cuál es el registro <Ti,start> más cercano.
2. Luego, se aplica Redo o Undo sobre Ti y todas las transacciones Tk que le suceden.

Pasos a seguir con el resto de las transacciones:

 Ejecutar Redo(Tk) para todas las transacciones cuyo registro <Tk,commit> aparece en la
bitácora.
 Ejecutar Undo(Tk) de la transacción cuyo registro<Tk,commit> no aparece en la bitácora
(sólo si se usa modificación inmediata).
Hasta ahora el algoritmo de recuperación sólo considera un ambiente de trabajo centralizado y no
concurrente. Al momento de un fallo de sistema, a lo sumo existe una única transacción activa

Checkpoints con transacciones concurrentes

 En un esquema sin concurrencia, en el proceso de recuperación solamente se
consideraban:
1. Aquellas transacciones que comenzaron después del checkpoint más reciente.
2. La única transacción (si existía) que estaba activa al momento del más reciente checkpoint.
 En un esquema concurrente puede haber más de una transacción activa al momento del
checkpoint.
 Por lo tanto, el esquema de checkpoints debe ser levemente modificado cuando se utilizan
transacciones concurrentes.
 En lugar de agregar un registro <checkpoint>solamente, se agrega un registro de la forma:
<checkpoint L>

 Donde L denota a la lista de transacciones activas al momento del checkpoint.

 La lista L limita la búsqueda hacia atrás del checkpoint en la bitácora.
 Como en el caso anterior, no existen actualizaciones a los bloques de buffer ni a la
bitácora durante el proceso de checkpointing.

Recuperación y Concurrencia
 Hasta ahora, consideramos recuperaciones en entornos donde solamente se ejecuta
una transacción por vez.
 Un sistema centralizado, aun cuando incorpora facilidades de concurrencia, cuenta
con un único buffer de disco y un único registro de bitácora.
 Los bloques de buffering son compartidos por todas las transacciones.

Tipos de Fallos y Concurrencia

 Fallo de una transacción
1. Cualquiera sea el motivo por el que falle una transacción T (lógico o del sistema) el rollback
puede involucrar a otras transacciones además de la transacción T abortada (retrocesos en
cascada).
2. Las transacciones no involucradas continúan su ejecución.

 Caída del Sistema

1. La recuperación involucra a todas las transacciones ejecutadas o en ejecución a partir del
último punto de verificación.

 En ambos casos se usa la información de bitácora para proceder a la recuperación.

Retroceso de Transacciones
 Una transacción puede ser retrocedida (rolled back) no solamente cuando se produce
una falla en el sistema sino cuando es abortada.
 Una transacción puede ser abortada por diferentes razones:
1. Por un usuario, por ejemplo, cuando decide abortar.
2. Por si misma, por ejemplo, por algún error inesperado.
3. Por el sistema, por ejemplo, cuando una transacción está en deadlock con otras transacciones.
Recuperación y Concurrencia
 El esquema de recuperación depende fuertemente del esquema de control de concurrencia
utilizado.
 El retroceso de una transacción fallada debe deshacerlos cambios hechos por la misma.
1. Ejemplo: Si una transacción T0modificó el dato Q y tiene que ser retrocedida, entonces debe restaurarse el
valor anterior de Q.
2. Pero si una transacción T1 realizó otro cambio sobre Q después del cambio de T0pero antes de que T0sea
retrocedida, el cambio realizado por T1se perderá.

 Por lo tanto, si una transacción T actualiza un item Q, es deseable que cualquier otra
transacción que desee modificar Q espere que T esté cometida.

Retroceso de Transacciones
 El retroceso de una transacción T fallada implica recorrer la bitácora hacia atrás, ya que
una transacción puede realizar más de un cambio sobre el mismo dato.
...,<T,A,10,20>, ...,<T,A,20,30>, ...

 Esto es, T primero modifica A de 10 a 20 y luego de 20 a 30.

 El orden en que se recorre la bitácora es importante ya que, si no la recorremos hacia
atrás, se restauraría el valor 20 a A (cuando debe ser 10).

Crash o Caídas de Sistemas

 La recuperación involucra a todas las transacciones ejecutadas o en ejecución
(posiblemente más de una) a partir del último punto de verificación.
 El sistema de recuperación recorre la bitácora para construir dos listas:
1. undo-list
2. redo-list

 Estas listas contienen a las transacciones que deben deshacerse y rehacerse

respectivamente.
1. Inicialmente estas listas están vacías.

Undo-List y Redo-List
 Se realiza un recorrido hacia atrás de los registros almacenados en la bitácora hasta
el primer <checkpoint, L>:
1. Por cada item <Ti,commit>, se agrega Ti a redo-list.
2. Por cada item <Ti,start>, si Tino está enredo-list entonces se agrega a la lista undo-list

 Luego se examina la lista L de transacciones activas al momento del <checkpoint, L>

1. Por cada transacción Ti de L si Tino esta incluida en redo-list se agrega a undo-list.
Recuperación ante Fallos
 Se vuelve a recorrer la bitácora hacia atrás, realizando un undo por cada transacción en la
lista undo-list. El proceso se detiene cuando se encuentra en la bitácora el item <Ti,start>
de cada transacción Ti en la lista undo-list.
 Se ubica el más reciente <checkpoint> en la bitácora. Este paso puede involucrar un
recorrido hacia adelante si el checkpoint fue pasado en el paso 1.
 Se recorre hacia adelante desde el más reciente<checkpoint> y se realiza un redo de cada
transacción Ti en la lista redo-list.
 Es importante respetar el orden de ejecución de las operaciones para la recuperación.
 Las operaciones undo deben realizarse antes que las operaciones redo.
 Las operaciones de undo se realizan recorriendo la bitácora desde abajo hacia arriba, esto
es, en orden inverso al que se ejecutaron.
 Las operaciones de redo se realizan recorriendo la bitácora desde arriba hacia abajo, esto
es, en el mismo orden en que se actualizó.

Ejemplo:
<Ti,A,10,20>
<Tj,A,20,30>

<Tj,commit> Ti aborta pero Tj comete

 Si se realiza un redo primero, A quedará en 30 y el posterior undo dejará a A con 10.

 El valor final de A debería ser 30, y eso es posible de alcanzar si se realiza primero el
undo y luego el redo

Ejemplo de fallo de sistema de una transacción:

T1 T2 Estampillas BItácora
read (A)
write (A) R-ts(A)= ts(T1) <T1start>
read (A)
read (B) W-ts(A)=ts(T1) <T1, A, 100, 200>
write (B)
read (B) R-ts(A)=ts(T2) <T2start>

R-ts(B)=ts(T2) <T2, B, 400, 200>

W-ts(B)=ts(T2)

•Protocolo: Estampilla de tiempo con ts(T1) < ts(T2)

•T1 debe retroceder por no cumplir las condiciones del protocolo

•T2 debe retroceder en cascada.

Ejemplo de fallo de sistema de una transacción:

 Acciones llevadas a cabo durante la recuperación:

1. Undo (T2)
 2. Undo (T1)
 Cuando una transacción retrocede deben deshacerse TODAS sus modificaciones, en
el ejemplo que se está siguiendo, esto incluye deshacer las modificaciones de
estampillas de tiempo realizadas por T1 y T2
R-ts(A) = W-ts(A) = R-ts(B)= W-ts(B)= 0

Crash de Sistema
<T1,start> Dada la siguiente foto de la Bitácora antes de un

<T1,B,50,20> crash de sistema.

<T2,start>

<T2,A,20,30> Undo-List: T3, T2

<checkpoint, <T1, T2>>

<T1,commit> Redo-List:T1, T4
<T3,start>

<T3,B,20,40>

<T4,start> B: 20, 80

<T4,B,40,80> A:20,

<T4,C,100,50> C:50,
<T4,commit>

Garantizar la atomicidad
 La transacción T entra en el estado cometido después de haberse grabado en memoria
estable el registro de bitácora <T,commit>.
 Antes de que el registro de bitácora <T,commit>pueda grabarse en memoria estable,
deben haberse grabado en memoria estable todos los registros de bitácora que
pertenecen a T.
 Antes de grabar en la base de datos un bloque que está en memoria principal (volátil)
deben haberse grabado en memoria estable todos los registros de bitácora que
pertenecen a los datos de ese bloque.

Organización de la Memoria
Memoria Volátil Base de Datos Bitácora

Memoria No Volátil Buffer de la Base de Datos Buffer de Bitácora

Checkpoints: pasos a seguir
Bitácora Base de Datos

M volátil M no volátil M volátil M no volátil

Registros Escrituras
sobre datos sobre datos
A1...An A1...An
(*) Inicio de
checkpoint

Registros
sobre datos
A1...An
Escrituras
sobre datos
<Checkpoint> A1...An
Tiempo

Buffering de registros de bitácora

 Anteriormente supusimos que cada registro de bitácora se graba en memoria estable en el
momento en que se crea.
 Esto genera un gasto extra (overhead) pues la información normalmente se graba en
bloques.
 Como cada registro de bitácora es mucho más pequeño que un bloque, la grabación de
cada registro de bitácora se traduce en una grabación mucho mayor en el nivel físico.
 Grabar un bloque en memoria estable puede requerir varias operaciones de grabación en
el nivel físico.

Buffering de la base de datos

 La base de datos se almacena en memoria no volátil(disco) y se van trayendo a memoria
principal según se requiera. Esto se hace mediante un esquema de bloques.
 Si un bloque B1 en memoria principal fue modificado pero debe ser reemplazado por otro
bloque B2, entonces debe hacerse lo siguiente:
1. Grabar B1 (Output(B1)).
2. Luego cargar B2 (Input(B2)).

 Este es el concepto estándar de memoria virtual de los sistemas operativos.

Supongamos que la entrada del bloque B2 hace que el bloque B1 deba salir de memoria
principal:

 Deben grabarse en memoria estable todos los registros de bitácora pertenecientes al

bloqueB1.
 Debe grabarse el bloque B1 en el disco.
 Recién después puede cargarse el bloque B2 desde el disco a memoria principal.