3 PDF

Universidad Nacional del Sur Departamento de Ciencias e Ingeniera de la Computacin
Elementos de Bases de Datos 2do. Cuatrimestre de 2004
Tipos de Fallos
Elementos de Fallos en la Transaccin
Error lgico: la transaccin no puede continuar su
Otras
transa-
Bases de Datos
ejecucin a causa de alguna condicin interna.
Error del sistema: el sistema alcanza un estado no
cciones
continuan
correcto. La transaccin puede volver a ejecutarse
ms tarde. con su
Dpto.Ciencias e Ingeniera de la Computacin
ejecucin
Universidad Nacional del Sur
Caida del sistema: por ejemplo errores del Todas las
hardware o software de base de datos o transaccio
Lic. Mara Mercedes Vitturini nes deben
software del sistema operativo.
[mvitturi@cs.uns.edu.ar] ser
Fallo de disco: dao fsico en el medio de
recupera-
almacenamiento masivo.
das
Clase 19 1er. Cuatrimestre de 2004
Elementos de Bases de Datos
Clase 19 2
Recuperacin mediante
Acciones de recuperacin Bitcora
Para asegurar la consistencia en la base de datos y la La bitcora es una estructura usada para guardar
informacin sobre las modificaciones que se realizaron a
atomicidad de las transacciones (a pesar de los fallos),
los datos.
los algoritmos tienen dos partes: Existen varias implementaciones. Veremos una
Acciones tomadas durante el procesamiento normal implementacin que contiene registros con los campos:
de la transaccin para asegurar que existe suficiente Nombre de la Transaccin: el nombre de la transaccin
informacin para permitir la recuperacin de fallos que ejecut el Write.
(preventivas). Nombre del Dato: el nombre nico del dato escrito.
Acciones tomadas a continuacin de un fallo para Valor Antiguo: el valor del dato anterior a la escritura.
asegurar la consistencia de la base de datos y la Valor Nuevo: el valor que tendr el dato despus de la
atomicidad de las transacciones (paleativas). escritura.
Elementos de Bases de Datos Elementos de Bases de Datos
Clase 19 3 Clase 19 4
Modificacin diferida: pasos a

Modificacin diferida seguir
Garantiza la atomicidad de la transaccin grabando Informacin de la bitcora
todas las modificaciones en la bitcora pero Antes de que comience una transaccin T, se escribe
aplazando todas las operaciones Write hasta que la el registro de bitcora <T,start>.
transaccin se comete parcialmente. Si T realiza una operacin Write(X,v), se escribe el
registro de bitcora <T,X,v>.
La informacin en la bitcora asociada a la
transaccin parcialmente cometida se usa en la Cuando T est parcialmente cometida, se escribe el
registro de bitcora <T,commit>.
ejecucin de las escrituras diferidas.
Si el sistema se cae antes de que termine de El esquema de recuperacin usa la operacin REDO
ejecutarse una transaccin, o si la transaccin (Rehacer) usando informacin de la bitcora.
aborta, se ignora la informacin de la bitcora. REDO (T) cuando en la bitcora existen los registros
<T,start> y <T,commit>.
1
Modificacin inmediata: pasos a

Modificacin inmediata seguir
Las modificaciones en la base de datos se realizan Informacin de la bitcora
mientras la transaccin est activa, antes de
Antes de que comience una transaccin T, se escribe
alcanzar el estado de cometida. el registro de bitcora <T,start>.
Este tipo de modificaciones se denominan Si T realiza una operacin Write(X,v), se escribe el
modificaciones no cometidas. registro de bitcora <T,X,v1,v2>.
En caso de que ocurra una cada o fallo de una Cuando T est parcialmente cometida, se escribe el
registro de bitcora <T,commit>.
transaccin se debe recurrir a una operacin Undo
No puede permitirse la actualizacin efectiva de la
que deshace los cambios hechos. base de datos (Output (RegDatos)) antes de que se
La operacin Undo extrae la informacin de la bit- escriba el registro de bitcora en memoria estable
(Output(RegBitcora)).
cora para determinar que datos deben restaurarse.
Puntos de Verificacin
Recuperacin de fallos (Checkpoints)
El esquema de recuperacin usa las operaciones Cuando ocurre un fallo del sistema es necesario
y Undo (Deshacer) y Redo (Rehacer) usando consultar la bitcora para ver cules
transacciones deben rehacerse y cules
informacin de la bitcora. deshacerse.
Cuando se produce un fallo, el esquema de
recuperacin consulta a la bitcora para Esto implica revisar TODA la bitcora.
El proceso de bsqueda consume tiempo.
determinar que transacciones deben deshacerse

La mayor parte de las transacciones que, segn el

o rehacerse. algoritmo, deben volver a hacerse, ya escribieron sus
UNDO (T): cuando la bitcora contiene el registro actualizaciones en la base de datos en memoria
<T,start> pero no contiene el registro <T,commit>. estable.
Volver a hacerlas no causa dao (redo es
REDO (T): cuando la bitcora contiene tanto el registro idempotente) pero consume tiempo.
<T,start> como el registro <T,commit>
Checkpoints: pasos a seguir

Checkpoints: pasos a seguir Bitcora
M. Principal M. Estable
Base de Datos
M. Principal M. Estable
Los checkpoints buscan reducir los tiempos extra en Registros
sobre datos Escrituras
los procesos de bsqueda en la bitcora.
A1An sobre datos
Al disparar un checkpoint el sistema realiza la A1An
siguiente secuencia de acciones: (*) Inicio de
checkpoint
Grabar en memoria estable todos los registros de
bitcora que estn en memoria principal. Registros
Grabar en disco los bloques modificados de los registros sobre datos
intermedios (buffer). A1An
Grabar un registro de bitcora <checkpoint> en Escrituras
memoria estable. sobre datos
A1An
El checkpoint es una actividad del sistema de base <Checkpoint>
de datos peridica y programada.
Elementos de Bases de Datos Tiempo Elementos de Bases de Datos
2
Checkpoints: pasos a seguir ante fallos Checkpoints: pasos a seguir

Para cada transaccin Ti tal que aparece en la
ante fallos
bitcora el registro <Ti,commit> antes del registro Pasos a seguir con el resto de las transacciones:
<checkpoint>, no es necesario ejecutar un REDO. Ejecutar Redo(Tk) para todas las transacciones
Despus de un fallo, se examina la bitcora para cuyo registro <Tk,commit> aparece en la bitcora.
determinar cul fue la ltima transaccin Ti que Ejecutar Undo(Tk) de la transaccin cuyo registro
comenz a ejecutarse antes del ltimo checkpoint. <Tk,commit> no aparece en la bitcora (slo si se
usa modificacin inmediata).
Esto se hace examinando la bitcora hacia atrs
buscando el primer registro <checkpoint> y cual es el
Hasta ahora el algoritmo de recuperacin slo considera un
registro <Ti,start> ms cercano.
ambiente de trabajo centralizado y no concurrente. Al
Luego, se aplica Redo o Undo sobre Ti y todas las momento de un fallo de sistema, a lo sumo existe una nica
transacciones Tk que le suceden. transaccin activa
Checkpoints: un ejemplo Checkpoints con transacciones

T0 concurrentes
T1 En el esquema de recuperacin slo En un esquema sin concurrencia, en el proceso de
deben reconsiderarse T67, T68,..., T100. recuperacin solamente se consideraban:
... Aquellas transacciones que comenzaron despus del
checkpoint ms reciente.
T66
La nica transaccin (si exista) que estaba activa al
T67 momento del ms reciente checkpoint.
<Checkpoint>
En un esquema concurrente puede haber ms de
T68 una transaccin activa al momento del checkpoint.
... Por lo tanto, el esquema de checkpoints debe ser
levemente modificado cuando se utilizan
T100 transacciones concurrentes.
Checkpoints con transacciones

Recuperacin y
concurrentes Concurrencia
En lugar de agregar un registro <checkpoint> Hasta ahora, consideramos recuperaciones en
solamente, se agrega un registro de la forma: entornos donde solamente se ejecuta una
<checkpoint L> transaccin por vez.
donde L denota a la lista de transacciones activas
al momento del checkpoint. Un sistema centralizado, an cuando incorpora
La lista L limita la bsqueda hacia atrs del facilidades de concurrencia, cuenta con un
checkpoint en la bitcora. nico buffer de disco y un nico registro de
bitcora.
Como en el caso anterior, no existen
actualizaciones a los bloques de buffer ni a la Los bloques de buffering son compartidos por
bitcora durante el proceso de checkpointing.
todas las transacciones.
3
Tipos de Fallos y Concurrencia Retroceso de Transacciones

Fallo de una transaccin Una transaccin puede ser retrocedida (rolled
Cualquiera sea el motivo por el que falle una back) no solamente cuando se produce una falla
transaccin T (lgico o del sistema) el rollback
puede involucrar a otras transacciones adems de la en el sistema sino cuando es abortada.
transaccin T abortada (retrocesos en cascada).
Las transacciones no involucradas continuan su Una transaccin puede ser abortada por
ejecucin. diferentes razones:
Caida del Sistema Por un usuario, por ejemplo, cuando decide abortar.
La recuperacin involucra a todas las transacciones Por si misma, por ejemplo, por algn error inesperado.
ejecutadas o en ejecucin a partir del ltimo punto
de verificacin. Por el sistema, por ejemplo, cuando una transaccin
En ambos casos se usa la informacin de est en deadlock con otras transacciones.
bitcora para proceder a la recuperacin.
Recuperacin y Concurrencia
El esquema de recuperacin depende fuertemente del
Retroceso de Transacciones
esquema de control de concurrencia utilizado. El retroceso de una transaccin T fallada implica
El retroceso de una transaccin fallada, debe deshacer recorrer la bitcora hacia atrs, ya que una
los cambios hechos por la misma. transaccin puede realizar ms de un cambio sobre
Ejemplo: Si una transaccin T0 modific el dato Q y tiene que el mismo dato.
ser retrocedida, entonces debe restaurarse el valor anterior
de Q. ,<T,A,10,20>, ,<T,A,20,30>,
Pero si una transaccin T1 realiz otro cambio sobre Q
Esto es, T primero modifica A de 10 a 20 y luego de

despus del cambio de T0 pero antes de que T0 sea
retrocedida, el cambio realizado por T1 se perder. 20 a 30.
Por lo tanto, si una transaccin T actualiza un item Q, El orden en que se recorre la bitcora es importante
es deseable que cualquier otra transaccin que desee ya que si no la recorremos hacia atrs, se
modificar Q espere que T est cometida. restaurara el valor 20 a A (cuando debe ser 10).
Crash o Caidas de Sistemas Undo-List y Redo-List

La recuperacin involucra a todas las
transacciones ejecutadas o en ejecucin Se realiza un recorrido hacia atrs de los
(posiblemente ms de una) a partir del ltimo registros almacenados en la bitcora hasta el
punto de verificacin. primer <checkpoint, L>:
El sistema de recuperacin recorre la bitcora Por cada item <Ti,commit>, se agrega Ti a redo-list.
para construir dos listas: Por cada item <Ti,start>, si Ti no est en redo-list
undo-list entonces se agrega a la lista undo-list
redo-list, Luego se examina la lista L de transacciones
activas la momento del <checkpoint, L>
Estas listas contienen a las transacciones que
deben deshacerse y rehacerse respectivamente. Por cada transaccin Ti de L si Ti no esta includa en
redo-list se agrega a undo-list.
Inicialmente estas listas estn vacas.
4
Recuperacin ante Fallos Recuperacin ante Fallos

1 Se vuelve a recorrer la bitcora hacia atrs, realizando Es importante respetar el orden de ejecucin de las
un undo por cada transaccin en la lista undo-list. El operaciones para la recuperacin.
proceso se detiene cuando se encuentra en la bitcora
el item <Ti,start> de cada transaccin Ti en la lista Las operaciones undo deben realizarse antes que las
undo-list. operaciones redo.
Las operaciones de undo se realizan recorriendo la
2 Se ubica el ms reciente <checkpoint> en la bitcora.
bitcora desde abajo hacia arriba, esto es, en orden
Este paso puede involucrar un recorrido hacia adelante
inverso al que se ejecutaron.
si el checkpoint fue pasado en el paso 1.
Las operaciones de redo se realizan recorriendo la
3 Se recorre hacia adelante desde el ms reciente bitcora desde arriba hacia abajo, esto es, en el
<checkpoint> y se realiza un redo de cada transaccin mismo orden en que se actualiz.
Ti en la lista redo-list.
Ejemplo Fallo de sistema de

Recuperacin ante fallos una transaccion
Ejemplo: Estampillas Bitacora
T1 T2
<Ti,A,10,20> R-ts(A)= ts(T1)
read (A) <T1 start>
<Tj,A,20,30> W-ts(A)=ts(T1)
write (A) <T1, A, 100, 200>
read (A) R-ts(A)=ts(T2)
<Tj,commit> Ti aborta pero Tj comete <T2 start>
read (B)
R-ts(B)=ts(T2) <T2, B, 400, 200>
Si se realiza un redo primero, A quedar en 30 y write (B)
el posterior undo dejar a A con 10. read (B) W-ts(B)=ts(T2)
El valor final de A debera ser 30, y eso es Protocolo: Estampilla de tiempo con ts(T1) < ts(T2)
posible de alcanzar si se realiza primero el undo T1 debe retroceder por no cumplir las condiciones del protocolo
y luego el redo. T2 debe retroceder en cascada.
Ejemplo Fallo de sistema de

una transaccin Crash de Sistema
Acciones llevadas a cabo durante la <T1,start> Dada la siguiente foto de la bitcora
recuperacin : <T1,B,50,20> antes de un crash de sistema.
<T2,start>
Undo (T2)
<T2,A,20,30> Undo-List: T3, T2
Undo (T1) <checkpoint, <T1, T2>>
Cuando una transaccin retrocede deben <T1,commit> Redo-List: T1, T4
deshacerse TODAS sus modificaciones, en el <T3,start>
ejemplo que se esta siguiendo, esto incluye <T3,B,20,40>
deshacer las modificaciones de estampillas de <T4,start> B: 20,
20, 80
tiempo realizadas por T1 y T2 <T4,B,40,80> A: 20,
R-ts(A) = W-ts(A) = R-ts(B)= W-ts(B)= 0 <T4,C,100,50> C: 50,
<T4,commit>
... Crash ...
5
Garantizar la atomicidad Organizacin de la Memoria

La transaccin T entra en el estado cometido despus
de haberse grabado en memoria estable el registro
de bitcora <T,commit>.
Memoria
Base de Datos Bitcora
No Voltil
Antes de que el registro de bitcora <T,commit>
pueda grabarse en memoria estable, deben haberse
grabado en memoria estable todos los registros de
bitcora que pertenecen a T.
Antes de grabar en la base de datos un bloque que Buffer de
Memoria Buffer de
est en memoria principal (voltil) deben haberse la Base
Bitcora
grabado en memoria estable todos los registros de Voltil
de Datos
bitcora que pertenecen a los datos de ese bloque.
Checkpoints: pasos a seguir Buffering de registros de

Bitcora
M. Voltil M. No Voltil
Base de Datos
M. Voltil M. No Voltil
bitcora
Registros Anteriormente supusimos que cada registro de bitcora
sobre datos Escrituras se graba en memoria estable en el momento en que se
A1An sobre datos crea.
A1An
(*) Inicio de Esto genera un gasto extra (overhead) pues la
checkpoint informacin normalmente se graba en bloques.
Registros Como cada registro de bitcora es mucho ms pequeo
sobre datos que un bloque, la grabacin de cada registro de
A1An bitcora se traduce en una grabacin mucho mayor en
Escrituras el nivel fsico.
sobre datos
A1An Grabar un bloque en memoria estable puede requerir
<Checkpoint> varias operaciones de grabacin en el nivel fsico.
Tiempo Elementos de Bases de Datos Elementos de Bases de Datos
Buffering de la base de Buffering de la base de

datos datos
La base de datos se almacena en memoria no voltil Supongamos que la entrada del bloque B2
(disco) y se van trayendo a memoria principal segn se hace que el bloque B1 deba salir de memoria
requiera. Esto se hace mediante un esquema de
bloques. principal:
Si un bloque B1 en memoria principal fue modificado Deben grabarse en memoria estable todos los
pero debe ser reemplazado por otro bloque B2, registros de bitcora pertenecientes al bloque
entonces debe hacerse lo siguiente: B1.
Grabar B1 (Output(B1)). Debe grabarse el bloque B1 en el disco.
Luego cargar B2 (Input(B2)). Recin despus puede cargarse el bloque B2
Este es el concepto estndar de memoria virtual de los desde el disco a memoria principal.
sistemas operativos.
6
Buffering de la base de datos Rol del SO en el manejo del

Transaccin T Bitcora
buffer
El buffer puede manejarse de dos maneras:
<T,start>
El SMBD reserva parte de memoria principal para
Se graba en
... <T,A,1000,950> usarla como buffer.
memoria estable:
El tamao del buffer est acotado por los requerimientos
Read(B,b1) 1) <T,A,1000,950> de memoria por parte de otras aplicaciones.
... 2) Bloque donde Aunque no se use el espacio del buffer, no puede usarse
reside el dato A. para otro fines.
El SMBD implementa el buffer en un espacio de
memoria virtual provisto por el sistema operativo.
Bloque donde reside Se elige sacar bloque El SO decide sacar los bloques de memoria, de modo tal
B fuera de MP donde reside A que el SMBD nunca tiene control de las salidas de bloques
de buffer.
Esto genera accesos extras al disco.
Falla con prdida de informacin Falla con prdida de informacin

no voltil no voltil
Hasta ahora abordamos fallas que resultan en Si falla el almacenamiento no voltil, se
prdida de informacin que reside en memoria restaura el contenido de la ltima copia.
voltil. Esto restaura la base de datos al estado en
Aunque rara vez se producen fallos en la que se encontraba cuando se realiz la copia
memoria no voltil, debemos estar preparados de la bases de datos completa a memoria
para este tipo de fallos. estable.
La tcnica es copiar peridicamente el Luego, el sistema usa la bitcora para llevar
contenido entero (dump) de la base de datos la base de datos al estado consistente ms
a un almacenamiento estable (por ejemplo, reciente posible.
cintas magnticas).
Implementacin de Memoria
Copias de Seguridad Estable
Ninguna transaccin debe estar activa durante La informacin que reside en memoria estable nunca se
el proceso de dump y se ejecuta un proceso pierde.
similar al checkpointing: Para alcanzar ello, debe repetirse la informacin (de
manera controlada) en varios medios de almacenamiento.
Se vuelcan los registros de bitcora residiendo
actualmente en memoria principal al almacenamiento La transferencia de bloques entre la memoria y el disco
estable. puede resultar en:
Terminacin con xito: la informacin transferida lleg ntegra a su
Se vuelcan todos los bloques de buffer al disco.

destino.
Se copian los contenidos de la base de datos al Fallo Parcial: ocurri un fallo durante la transferencia y el bloque
almacenamiento estable. destino tiene informacin incorrecta.
Se vuelca un registro de bitcora <dump> al Fallo Total: ocurri un fallo al inicio de la transferencia y el bloque
almacenamiento estable. destino queda intacto.
7
Estable La Operacin Output(B)
Si ocurre un fallo en la transferencia de datos, Una operacin de salida se ejecuta
el sistema debe detectarlo e invocar un sistema
de recuperacin que restaure el bloque a un
como sigue:
estado consistente. Escribir la informacin en el primer
Para hacerlo, el sistema debe mantener dos bloque fsico.
bloques fsicos por cada bloque lgico de la Una vez que se completa con xito la
base de datos. primera escritura, escribir la misma
En el caso de discos espejados, ambos bloques estn informacin en el segundo bloque fsico.
fisicamente en la misma locacin.
En el caso de copias remotas, uno de los bloques es
La salida est completa slo despus de
local y el otro est en un sitio remoto. terminar con xito la segunda escritura.
Estable Puntos de Verificacin Difusos
Durante la recuperacin, se examina cada par de Los puntos de verificacin (checkpoints) requieren que
bloques fsicos. todas las actualizaciones a las base de datos se
suspendan temporariamente.
Si los dos son iguales y no existen errores detectables,
no es necesario tomar ms acciones. La tcnica de puntos de verificacin difusos (fuzzy
checkpointing) permite que se reinicien las
Si un bloque contiene un error detectable (checksum), actualizaciones despus de grabar el registro de
se sustituye su contenido por el valor del segundo checkpoint en bitcora en memoria estable pero antes
bloque. de que los bloques modificados se escriban en disco.
Si ambos bloques no contienen errores detectables, En lugar de recorrer hacia atrs la bitcora hasta
pero el contenido es diferente, entonces se sustituye el encontrar un registro de checkpoint (donde se hizo la
contenido del primer bloque por el valor del segundo. ltima escritura segura), se almacena en una posicin
Este procedimiento garantiza que una escritura en fija del disco la ubicacin del ltimo checkpoint (last-
almacenamiento estable termine con xito o no checkpoint).
produzca cambio alguno.
Puntos de Verificacin Difusos Temas de la clase de hoy

Antes de escribir el registro de checkpoint, se crea una
lista de todos los buffers modificados. Recuperacin de Fallos
La informacin de last-checkpoint se actualiza despus de Puntos de Verificacin. Modificacin para
que todos los bloques de buffer en la lista de modificados ambientes concurrentes.
han sido grabados (output) en disco.
Puntos de Verificacin Difusos.
Los bloques de buffer no deben modificarse mientras
estn siendo grabados en disco. Implementacin de Memoria Estable
Se debe contar con un protocolo de escritura por
adelantado (write-ahead) para que se graben antes los
Bibliografa
registros de bitcora pertenecientes a los bloques que Fundamentos de Bases de Datos A.
estn siendo grabados en memoria estable. Silberschatz. Captulo 15.
La bitcora slo se utiliza para los efectos de deshacer.
Los puntos de verificacin difusos tienen problemas.

3 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

3 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Nacional del Sur Departamento de Ciencias e Ingeniera de la Computacin

Elementos de Bases de Datos 2do. Cuatrimestre de 2004

Modificacin diferida: pasos a

Modificacin inmediata: pasos a

La mayor parte de las transacciones que, segn el

Checkpoints: pasos a seguir

Checkpoints: pasos a seguir ante fallos Checkpoints: pasos a seguir

Checkpoints: un ejemplo Checkpoints con transacciones

Checkpoints con transacciones

Tipos de Fallos y Concurrencia Retroceso de Transacciones

Crash o Caidas de Sistemas Undo-List y Redo-List

Recuperacin ante Fallos Recuperacin ante Fallos

Ejemplo Fallo de sistema de

Ejemplo Fallo de sistema de

Garantizar la atomicidad Organizacin de la Memoria

Checkpoints: pasos a seguir Buffering de registros de

Buffering de la base de Buffering de la base de

Buffering de la base de datos Rol del SO en el manejo del

Falla con prdida de informacin Falla con prdida de informacin

Puntos de Verificacin Difusos Temas de la clase de hoy

Vous aimerez peut-être aussi