Recuperacin de fallos del sistema - Pg.

1
BASES DE DATOS curso 2002-2003

Tema 15. Recuperacin de fallos del sistema

Objetivos
Apreciar la necesidad de establecer un producto fiable, capaz de proteger la informacin
frente a fallos del sistema.
Identificar los tipos de fallos que pueden ocurrir en un sistema de bases de datos.
Comprender el propsito del fichero de bitcora y los puntos de validacin del sistema.
Conocer y entender diferentes tcnicas del sistema gestor de bases de datos para la recupe-
racin de fallos.

Contenidos
15.1. CONCEPTOS GENERALES DE RECUPERACIN _________________________________________ 1
15.1.1. Clasificacin de los fallos de un sistema de base de datos................................................................................2
15.1.2. Recuperabilidad de los planes de transacciones.................................................................................................2
15.1.3. La bitcora del sistema.........................................................................................................................................3
15.1.4. Acceso a los datos almacenados..........................................................................................................................5
15.1.5. Punto de confirmacin de una transaccin.........................................................................................................6
15.2. EL PROCESO DE RECUPERACIN DEL FALLO DE UNA TRANSACCIN _____________________ 6
15.2.1. Escritura anticipada en el fichero de bitcora.....................................................................................................7
15.2.2. Puntos de validacin del sistema.........................................................................................................................9
15.3. TCNICAS DE RECUPERACIN DE FALLOS DEL SISTEMA_______________________________ 11
15.3.1. Tcnica de actualizaciones diferidas.................................................................................................................11
15.3.2. Tcnica de actualizaciones inmediatas .............................................................................................................13
BIBLIOGRAFA_______________________________________________________________________ 14

15.1. CONCEPTOS GENERALES DE RECUPERACIN
Siempre que se introduce una transaccin T en un sistema de bases de datos (SBD), el SGBD debe
asegurar que todas las operaciones de T secompleten con xito y su efecto quedeconfirmado permanente-
menteen la basededatos (BD), o bien que la transaccin T no tenga efecto alguno sobrela BD ni sobre
cualquier otra transaccin.

El SGBD no debe permitir que se apliquen a la BD algunas operaciones de T y otras no. Esto puede
suceder si T falla despus de realizar algunas de sus operaciones pero antes de ejecutar otras.
Esto est muy relacionado con las propiedades de atomicidad y durabilidad de las transacciones. De
hecho, los problemas de recuperacin frente a fallos (y de control de la concurrencia) estn muy
relacionados con los conceptos del procesamiento de transacciones, ya vistos en temas anteriores.

La recuperacin en un SBD consiste en (volver a) dejar la informacin almacenada en la base de
datos en un estado consistente (correcto), despus de un fallo (o cada) del sistema que ha llevado
la BD a un estado inconsistente, o por lo menos sospechoso de serlo.

Los SBD pequeos no suelen proporcionar soporte para la recuperacin. S lo hacen los grandes
sistemas de base de datos multiusuario. El mdulo componente del SGBD encargado de que el
SBD sea seguro frente a posibles fallos, es el Subsistema Gestor de Recuperacin, cuya funcin es,
entre otras cosas, velar por que...
- las transacciones no se pierdan (es decir, que se ejecuten),
- las transacciones no se realicen parcialmente (deben ejecutarse en su totalidad),
- no se ejecute una operacin ms de una vez o, si se hace, que el resultado sea equivalente al
obtenido si se hubiera realizado una nica vez.
Recuperacin de fallos del sistema - Pg. 2
15.1.1. Clasificacin de los fallos de un sistema de base de datos
Existen diversas causas por las que el sistema de bases de datos puede fallar. Algunos tipos de
fallos son los siguientes:

1. Errores locales previstos por la aplicacin (rollback explcito o programado)
Durante la ejecucin de una transaccin pueden presentarse condiciones que requieran la can-
celacin de la misma (por ejemplo, un saldo insuficiente en una cuenta bancaria implica la cancelacin
de una transaccin de reintegro sobre dicha cuenta).

2. Errores locales no previstos (overflow, divisin por cero...)
Errores lgicos de programacin (bugs), o interrupciones provocadas (ctrl-C en entornos Unix...).

Un fallo local slo afecta a la transaccin que se est ejecutando donde ha ocurrido el fallo. Nor-
malmente supone la prdida de los datos en memoria principal y en los bferes de entrada/ salida.

3. Fallos por imposicin del control de concurrencia
El Subsistema de Control de Concurrencia puede decidir abortar una transaccin T (para reini-
ciarla posteriormente) bien porque viola la seriabilidad o porque varias transacciones estn en
un estado de bloqueo mortal y se ha seleccionado T como vctima.

4. Fallos del sistema (cadas suaves)
Consisten en un mal funcionamiento del hardware, errores software (del SGBD o del SO) o de
red, que afectan a todas las transacciones en progreso de ejecucin en el sistema de BD. No da-
an fsicamente el disco (el contenido de la BD permanece intacto y no se corrompe), pero se
pierden los datos en la memoria principal y en los bferes de entrada/ salida.

5. Fallos de disco (cadas duras)
Son fallos en los dispositivos de almacenamiento (por ejemplo, si ocurre una rotura o un aterri-
zaje de alguna cabeza lectora-escritora en el disco, si funciona mal la lectura o la escritura, o si
ocurre un fallo durante una transferencia de datos). Afectan a todas las transacciones en curso
y suponen la prdida de informacin en disco (es decir, algunos bloques del disco pueden per-
der sus datos).

6. Fallos catastrficos o fsicos
Algunos ejemplos son el corte del suministro elctrico, robo del disco, incendio, sabotaje, so-
breescritura en discos o cintas por error, etc.

Los fallos de tipo 5 y 6 suceden con menos frecuencia que el resto y su recuperacin es ms com-
plicada.

15.1.2. Recuperabilidad de los planes de transacciones
En el tema anterior identificamos los planes que se consideran correctos cuando se estn ejecutan-
do transacciones concurrentes. En este apartado caracterizaremos los planes que facilitan la recu-
peracin cuando ocurren fallos en las transacciones.

Un primer criterio es asegurar que una vez que una transaccin T se ha confirmado, nunca ser
necesario deshacerla (anularla, cancelarla, revertirla, abortarla). Un plan que cumple este criterio
es un plan recuperable. Un plan P es recuperable si ninguna transaccin T de P se confirma antes de
haberse confirmado toda transaccin T que haya escrito un dato que T lee.

Recuperacin de fallos del sistema - Pg. 3
Se dice que una transaccin T
j
lee de otra T
k
en un plan P, si T
k
escribe un elemento X que ms tarde
lee T
j
. Es importante observar que T
j
no lee de T
k
, si T
k
aborta antes de que T
j
lea X, o si otras transac-
ciones escriben X despus de T
k
y antes de que lo lea T
j
.

En un plan recuperable nunca tiene que deshacerse una transaccin confirmada. Sin embargo pue-
de ocurrir el fenmeno de la reversin en cascada, en el cual una transaccin no confirmada ha de
deshacerse por haber ledo un elemento de una transaccin que ha fallado. La cancelacin en
cascada puede consumir mucho tiempo, si hubiera que deshacer una gran cantidad de transaccio-
nes, as que es interesante caracterizar los planes en los que se garantiza que nunca ocurrir este
fenmeno. Un plan sin cascada es aquel en el que toda transaccin slo lee datos escritos por tran-
sacciones confirmadas. As, nunca ocurrir que T aborte despus de haber escrito un dato que lue-
go haya ledo T, pues T no leer un elemento a menos que se haya confirmado toda transaccin
que lo haya escrito (en particular T).

Por ltimo definimos un plan estricto, en el que las transacciones no pueden leer ni escribir un
elemento hasta que se haya confirmado (o abortado) toda transaccin que lo haya escrito. Los
planes estrictos evitan un problema que puede surgir a la hora de recuperar el fallo de una tran-
saccin, tal y como explicamos seguidamente mediante un ejemplo.
Si una transaccin falla y por tanto ha de revertirse, hay que deshacer sus operaciones de escritura.
Deshacer una operacin de escritura, por ejemplo e(X,5), consiste en restaurar X a su valor anterior
(el que tena justo antes de realizar dicha escritura). Pero esto puede no funcionar correctamente si
el plan no es estricto, como ocurre con el siguiente plan de dos transacciones:

P
1
: e
1
(X,5) ; e
2
(X,8) ; r
1
;

Supongamos que el valor original de X es 10. La primera operacin del plan P
1
indica que T
1
cambia
el valor de X a 5 y la segunda, que T
2
deja el valor de X a 8. A continuacin T
1
aborta, lo cual implica
deshacer la operacin e
1
(X,5) de modo que X queda 10... aunque T
2
lo haba cambiado a 8! Vemos
que este plan lleva a resultados potencialmente incorrectos. La causa es que, aunque P
1
es sin cas-
cada, no es estricto.

Para terminar este apartado, es interesante observar lo siguiente con respecto a los tres tipos de
planes de transacciones que hemos identificado:
un plan sin cascada es un plan recuperable
un plan estricto es un plan recuperable y evita la reversin en cascada

15.1.3. La bitcora del sistema
En un SBD, la recuperacin de fallos en las transacciones suele equivaler a la restauracin de la BD
a alguno de sus estados anteriores (al fallo), a partir del cual sea posible reconstruir un estado con-
sistente de la BD cercano al momento del fallo.

La cuestin es que, cuando ocurre un fallo...qu ocurre con los cambios realizados por las tran-
sacciones que quedaron a medio y pueden haber dejado inconsistente la BD? cmo podemos re-
cuperar un estado consistente?

La recuperacin se basa en unos principios bastante sencillos y que pueden resumirse en una sola
palabra: redundancia (redundancia de informacin, por supuesto al nivel fsico y por tanto de
forma transparente al usuario, pues no es visible al nivel lgico).
Dicho de otro modo, la forma de garantizar la recuperacin del sistema tras fallos o cadas del
mismo, es asegurar que cualquier trozo de informacin que contiene la BD, pueda ser reconstruido
a partir de alguna otra informacin almacenada, de forma redundante, en algn lugar del sistema.

Recuperacin de fallos del sistema - Pg. 4
En primer lugar, es necesario saber (anotar) cundo se inicia, se confirma o se aborta cada transac-
cin, y tambin qu operaciones
1
sobre qu elementos de la BD realiza cada una de ellas.

Y en segundo lugar, despus de ocurrir un fallo y reiniciar el sistema, ser necesario realizar una
serie de acciones para restablecer el contenido de la BD a un estado que asegure la consistencia de
la misma, la atomicidad de las transacciones y la durabilidad.

El sistema se mantiene al tanto de lo que hacen las transacciones mediante un fichero especial lla-
mado bitcoradel sistema de BD, tambin conocido como fichero log, diario o registro histrico.

La bitcora es un fichero en el que se almacena detalles sobre las operaciones efectuadas como
parte de las transacciones que afectan a los valores de los elementos de informacin de la BD. Por
ejemplo, para las actualizaciones se puede guardar el valor que tenan los datos afectados antes de
la modificacin y el que contienen despus.
La bitcora se mantiene en disco, fuera del rea de la BD donde se almacenan los datos. Por tanto,
no le afecta ningn tipo de fallo, salvo (claro est!) los de tipo 5 y 6. Precisamente para protegerlo
contra posibles fallos de estos tipos se suele realizar peridicamente una copia de seguridad (en
cinta, por ejemplo) del fichero bitcora.
Cada registro almacenado en la bitcora se llama entrada, y ser de uno de los siguientes tipos:

< INICIAR, T >
Indica que la transaccin T ha comenzado
2
.
< ESCRIBIR, T, X, valor_anterior, valor_nuevo >
Indica que la transaccin T ha cambiado el valor del elemento X de la BD
3
. X contena el
valor_anterior antes de la escritura y contendr el valor_nuevo despus de la escritura.
< LEER, T, X >
Indica que T ley el valor del elemento X de la base de datos
< COMMIT, T >
Indica que T finaliz con xito y su efecto puede ser confirmado en la base de datos en
disco; es decir, todos los cambios que ha realizado pueden ser consolidados o asentados
(quedar permanentes) en la BD.
< ROLLBACK, T >
Indica que la transaccin T ha sido anulada (abortada, cancelada), de forma que ninguna
de sus operaciones tendr efecto sobre la base de datos en disco, como si T nunca se
hubiera ejecutado: la transaccin ser revertida, todas sus operaciones sern deshechas.
Suponemos que las transacciones no se pueden anidar (sabra explicar por qu?).
Tambin suponemos que todos los cambios permanentes de la base de datos ocurren dentro de
transacciones, as que recuperarse de un fallo de cierta transaccin consiste en rehacer
4
o deshacer
5

individualmente sus operaciones recuperables, a partir del contenido del fichero bitcora.
Por operacin recuperable entendemos aquella susceptible de ser deshecha o rehecha. Las operaciones
de manipulacin de datos (INSERT, UPDATE, DELETE, SELECT) por ejemplo, son operaciones recupe-
rables. Toda operacin recuperable implica la anotacin de una entrada en bitcora.

1
Ya se estudiaron las distintas operaciones que poda llevar a cabo una transaccin, as como los estados por los que puede pasar.
2
T se refiere a un identificador de transaccin nico que el sistema genera de forma automtica y que identifica a cada transaccin.
3
X es un identificador nico del elemento de datos que se lee o escribe.
4
Para rehacer el efecto de una operacin ESCRIBIRde T se utiliza la entrada correspondiente en bitcora: se cambia el valor del ele-
mento alterado en dicha operacin, por su valor_nuevo.
5
Es posible deshacer el efecto de una operacin ESCRIBIRde T usando la entrada en bitcora correspondiente: se restablece el valor
del elemento alterado a su valor_anterior.
Recuperacin de fallos del sistema - Pg. 5
Tras una cada del sistema, se restablece un estado consistente de la base de datos (anterior y cer-
cano al momento del fallo) examinando la bitcora y usando una tcnica de recuperacin determi-
nada (veremos varias ms adelante).
Los protocolos de recuperacin que evitan la reversin en cascada, no necesitan anotar en bitcora
la ejecucin de operaciones LEER. Pero otros protocolos s las necesitan para la recuperacin. Ade-
ms, si la bitcora se utiliza para otros propsitos, como la auditora, deber incluir este tipo de
entradas.
Adems, algunos protocolos requieren que en las entradas de tipo ESCRIBIR siempre incluyan
campos para valor_nuevo y para valor_anterior, mientras que otros protocolos necesitan entradas ES-
CRIBIR ms simples que slo incluyan el valor_nuevo, o bien, como los protocolos estrictos, que slo
incluyan el valor_anterior.

15.1.4. Acceso a los datos almacenados
En este momento, hemos de recordar algunos conceptos acerca del almacenamiento y el acceso a
los datos almacenados en un sistema de base de datos, para comprender cmo pueden ser
garantizadas las propiedades de atomicidad y durabilidad de las transacciones.

Cada transaccin T posee un rea de trabajo privada (un espacio de memoria principal local a di-
cha transaccin) en la que guarda una copia de todo elemento de informacin accedido y actuali-
zado por T. Dicho rea se crea cuando T comienza y se libera cuando T se confirma o se aborta.

Por otro lado el sistema mantiene un bfer de base de datos, que consiste en uno o varios bloques
de memoria principal. Este bfer est almacenado en lo que se conoce como cach de SGBD, que es
comn a todas las transacciones. En el bfer de BD residen temporalmente los bloques de la base
de datos, cuando las transacciones necesitan los datos almacenados en ellos.

Cuando T realiza una operacin de lectura, si el elemento buscado no est ya en el bfer de BD, el
bloque que lo contiene se trae desde la BD en disco hasta dicho bfer. Una vez all, se copia el valor
del dato en el espacio local de la transaccin (normalmente en una variable local de la transaccin).

Cuando T realiza una operacin de escritura, si el elemento que se va a modificar no est ya en el
bfer de BD, el bloque que lo contiene se trae desde el disco hasta el bfer. Una vez all, se actuali-
za el valor del elemento en el bfer, asignndole el valor que contiene la variable local.
Por tanto, las modificaciones realizadas por cada transaccin se llevan a cabo en su espacio local y
quedan almacenadas en el bfer de BD.

Ntese que ambas operaciones pueden necesitar la transferencia de un bloque desde la BD en dis-
co hasta el bfer de BD en memoria, pero ninguna de ellas requiere especficamente que se trans-
fiera un bloque desde memoria principal (bfer de BD) al disco.

El SGBD llevar un bloque del bfer a la BD en disco bien porque el gestor de la memoria inter-
media necesita ese espacio para otros bloques, o bien porque el sistema de BD desea reflejar en
disco los cambios sufridos por elementos guardados en dicho bloque.

Por tanto, una operacin de escritura por parte de una transaccin, no tiene por qu provocar la
inmediata escritura (del bloque modificado) desde el bfer de BD hasta el disco, porque ese bloque
puede contener otros datos que estn siendo accedidos an. La escritura real en disco ser realiza-
da despus por parte del sistema.

Todos estos conceptos sern utilizados y ampliados a lo largo de este tema.

Recuperacin de fallos del sistema - Pg. 6
15.1.5. Punto de confirmacin de una transaccin

Cuando una transaccin T termina de ejecutar una operacin de COMMIT, significa que:
- Todas sus operaciones de acceso a la base de datos han sido ejecutadas con xito,
- El efecto de tales operaciones se ha anotado en la bitcora, incluida una ltima entrada
<COMMIT, T>.
As que T ha llegado a su punto de confirmacin (el final de una unidad lgica de trabajo)
6
.
Y a partir de este momento se puede suponer que:
T est confirmada,
Los cambios que ha realizado ya han sido consolidados. Esto significa que se ha de supo-
ner que se han llevado a la BD, y por tanto ya son permanentes; hasta ese momento los
cambios eran provisionales y podan ser anulados.
Los cursores abiertos han sido cerrados, y los bloqueos
7
han sido liberados.

Cuando T termina de ejecutar una operacin de ROLLBACK, significa que:
- T ha resultado fallida,
- Se ha anotado <ROLLBACK, T> en la bitcora como ltima entrada para T.
Y a partir de este momento se puede suponer que:
T ha sido cancelada
Los cambios que ha realizado han sido anulados. Esto significa que se ha de suponer que
la BD ha quedado en el estado en que se encontrara si nunca se hubiera iniciado T.
Los cursores abiertos han sido cerrados y los bloqueos han sido liberados.

Nota1: una operacin COMMIT o ROLLBACK finaliza una transaccin, no un programa. La ejecucin de
un programa suele consistir en una secuencia de transacciones ejecutadas una tras otra.
Nota2: el punto de confirmacin es un concepto lgico; no queda reflejado fsicamente como tal en
ningn lugar.

15.2. EL PROCESO DE RECUPERACIN DEL FALLO DE UNA TRANSACCIN
Supongamos que se est ejecutando una transaccin T que ha realizado modificaciones sobre ele-
mentos de la BD, algunas de las cuales pueden haberse llevado a disco.
Es posible que ocurra un fallo de T en un momento en el que la transaccin est en curso (ejecu-
tndose), o bien cuando ya haya terminado.

Est claro que T deber ser anulada
8
si ha quedado a medio, puesto que no alcanz su punto de
confirmacin (no lleg a anotar su entrada <COMMIT, T> en la bitcora).

*#*Ntese que para que sea posible deshacer cambios realizados sobre elementos de BD, es nece-
sario que en el fichero de bitcora existan las entradas correspondientes a dichos cambios, tal y
como se indica en la nota a pi de pgina nmero 5.

Y qu sucede si la transaccin haba finalizado cuando ocurre el fallo?
Podramos pensar algo como esta transaccin s ha llegado a su punto de confirmacin, luego
podemos darla por terminada con xito, y olvidarnos de ella....
Sin embargo, no es seguro que esta transaccin est confirmada realmente, pues es posible que
algn cambio sobre un elemento de la BD todava no se hubiera llevado a la BD en disco.
Esto ocurre si el fallo tiene lugar mientras se estn grabando en disco los elementos de la BD
modificados: algunos cambios pueden quedar grabados en la BD en disco, pero otros no.

6
Corresponde con el estado CONFIRMADA de T (vase tema de Conceptos de procesamiento de transacciones)
7
Vase tema de Control de la concurrencia.
8
revertida, rolledback
Recuperacin de fallos del sistema - Pg. 7

Por esto, si la transaccin haba terminado con xito (s lleg a escribir <COMMIT, T> en la bitcora),
es necesario rehacer sus modificaciones para asegurar que quedan realmente consolidadas en dis-
co.

*##*Ntese que para que sea posible rehacer cambios, es necesario que en el fichero de bitcora,
existan las entradas correspondientes a los mismos tal y como se indica en la nota a pi de p-
gina nmero 4.

15.2.1. Escritura anticipada en el fichero de bitcora

Hemos de tener en cuenta que la bitcora es un fichero en disco. As que, como ya sabemos, ac-
tualizar la bitcora en disco implica:
1. copiar el bloque adecuado de la bitcora en disco en la memoria principal,
2. actualizar el bloque en memoria (insertar una nueva entrada) y
3. copiar el bloque desde la memoria al fichero de bitcora en disco.

Esto supondra una escritura en disco cada vez que se inserta una nueva entrada en la bitcora (es
decir, cada vez que se anota la ejecucin de una operacin de transaccin!).

Para conseguir una nica escritura por bloque, en la prctica...
- se mantiene un bloque completo de bitcora en memoria: un bfer de bitcora
9
, y
- cuando se llena de entradas, el bloque completo se escribe en disco (en el fichero de bitcora)

Con esto se evita escribir varias veces en disco un mismo bloque de la bitcora, pero provoca otros
problemas, que ilustramos a continuacin mediante un ejemplo.

Supongamos una transaccin T en ejecucin y que en el fichero de bitcora en disco ya est alma-
cenada la correspondiente entrada <INICIAR,T>.
Tras modificar los elementos X e Y de la BD, se anotan las siguientes entradas slo en el bfer de
bitcora en memoria:

<ESCRIBIR,T,X,7,15>
<ESCRIBIR,T,Y,2,5>

Supongamos tambin que algunos de estos cambios se consolidan en la BD en disco
10
, por ejemplo
estos dos anteriores: en la base de datos se tiene por tanto X=15 e Y=5.

T realiza dos modificaciones ms sobre los elementos Z y V, y despus finaliza con xito, as que se
anota, todava slo en el bfer de bitcora, las entradas:

<ESCRIBIR,T,Z,6,3>
<ESCRIBIR,T,V,8,1> y
<COMMIT,T>

El COMMIT de T indica al sistema que puede confirmar en disco los cambios (hechos por T) an no
llevados a la BD, es decir los que modifican los valores Z de 6 a 3 y V de 8 a 1.

Supongamos ahora que el sistema comienza a escribir en la BD en disco los elementos Z y V modi-
ficados por T, pero, recordemos, la realizacin de estos cambios todava no se ha anotado en la

9
En particular, el bfer de bitcora tambin est en la cach del SGBD, al igual que el bfer de BD.
10
Posteriormente se ver que esto es posible en algunas tcnicas de recuperacin y en otras no.
Recuperacin de fallos del sistema - Pg. 8
bitcora en disco (sino que las entradas correspondientes siguen en el bfer de bitcora, que no
est lleno an).

Si el fallo ocurre justo durante la consolidacin de los cambios de la BD en disco (transferencia),
entonces es posible que algunos cambios de T s se graben en disco (en BD queda Z=3), pero otros
no (en BD sigue V=8).

Lo ms normal es que el fallo haya provocado la prdida del contenido de la memoria principal (es
decir, el rea local a T, el bfer de bitcora y el bfer de BD). El proceso de recuperacin accede al
fichero de bitcora en disco donde hallar la entrada <INICIAR,T>, pero no encontrar ninguna de
las entradas del bfer de bitcora que todava no se haban volcado en disco cuando ocurri el fa-
llo. En particular no encontrar la entrada <COMMIT,T>, as que intentar anular T.

Sin embargo T no debe ser anulada, pues se realiz totalmente y con xito. Lo nico que ocurre
es que no se complet la confirmacin en disco de sus cambios. Tan slo se debera rehacer cada
una de sus operaciones.

Este error se hubiera evitado si, antes de comenzar la consolidacin de cambios de BD en disco,
se hubiera grabado en disco (y con xito) la porcin de bitcora que slo estaba en el bfer de
bitcora: el sistema hubiera detectado la confirmacin de T (pues en la bitcora en disco estara
la entrada <COMMIT,T>), y adems s sera posible rehacer las modificaciones de T, porque estaran
en bitcora (en disco) todas las entradas <ESCRIBIR,T,...>
11
.

Pero an existe un problema adicional. Decamos que el sistema intentar anular T. Dos de las en-
tradas perdidas a causa del fallo son:

<ESCRIBIR,T,X,7,15> y
<ESCRIBIR,T,Y,2,5>

as que no se tiene anotado en bitcora en disco ni el valor_anterior ni el valor_nuevo para X ni para Y.

Pero ambos cambios fueron llevados a la BD en disco, de forma que X e Y ya contienen sus nue-
vos valores 15 y 5. No es posible deshacer estas operaciones de forma correcta.
Otra entrada perdida es <ESCRIBIR,T,Z,6,3>, que corresponde a otro cambio de T que s ha dado
tiempo a consolidar en disco antes del fallo. Tampoco en este caso se puede deshacer esta opera-
cin, por la misma razn que antes.
Vemos que es imposible recuperar la base de datos a un estado de consistencia anterior.

Todo esto tambin se hubiera evitado si, antes de comenzar la grabacin de cambios de BD en
disco, se hubiera grabado en disco la porcin de bitcora que slo estaba en el bfer de bitcora:
s sera posible deshacer las modificaciones de T (si ello fuera necesario, claro), porque estaran en
bitcora (en disco) todas las entradas <ESCRIBIR,T,...>
12
necesarias.

En realidad, lo que hemos hecho es razonar que, para evitar estos problemas, es necesario seguir
un protocolo de bitcora adelantada, puesto que asegurar que la base de datos podr ser recupe-
rada de forma correcta.

El protocolo de bitcora adelantada indica que ...


11
Por esto ltimo se afirm anteriormente la frase marcada con *##*.
12
Por esto se afirm anteriormente la frase etiquetada con *#*.
Recuperacin de fallos del sistema - Pg. 9
1. No se puede grabar en disco los cambios realizados por una transaccin
13
T, hasta que se haya
forzado la escritura en disco de toda entrada de bitcora para T, hasta el momento actual
14
.

2. La operacin confirmar de una transaccin no se puede completar
15
hasta que se haya forzado la
escritura en disco de cualquier entrada de bitcora para esa transaccin
16
.

Es decir, fuerza la escritura de la bitcora en disco antes de consolidar cualquier cambio realizado
por T. Ya sea para consolidar cambios en disco antes de que T alcance su punto de confirmacin, o
para consolidarlos despus de que T lo haya alcanzado
17
.

As que nunca va a ocurrir que 1) se lleven a disco los cambios de elementos de BD realizados por
T y 2) el sistema falle al ir a grabar en disco la parte de bitcora.

Pero s puede ocurrir que 1) se grabe fsicamente la parte de la bitcora de una modificacin y 2)
el sistema falle cuando va a aplicar el cambio a la BD en disco.

En este ltimo caso, al recuperar T, el Gestor de Recuperacin ver si cada modificacin pudo
hacerse o no fsicamente, pues est registrada en bitcora. Podr deshacerla o rehacerla usando la
entrada correspondiente en bitcora.

Con el uso del protocolo de bitcora adelantada, siempre estamos seguros de que podemos llevar
la base de datos a un estado consistente, aunque ocurra un fallo mientras se graban en disco los
cambios de elementos de BD, pues ser posible rehacer y/ o deshacer los cambios.

Y qu pasa si el fallo ocurre mientras se graba en disco la parte de bitcora?

15.2.2. Puntos de validacin del sistema
Supongamos que ocurre una cada en un sistema de BD en el que se ejecutaban varias transaccio-
nes de forma concurrente. Al rearrancar el sistema, el Gestor de Recuperacin accede al fichero de
bitcora (en disco). En l estn anotadas todas las entradas correspondientes a modificaciones so-
bre elementos de la base de datos, realizadas por las transacciones. Para aquellas que alcanzaron
su punto de confirmacin, tambin estarn anotadas las entradas COMMIT correspondientes.

Cmo sabe el sistema qu transacciones estaban activas (en ejecucin) cuando ocurri el fallo y,
por tanto, debe deshacer? Y cmo sabe el sistema cules transacciones debe rehacer?
Pues el sistema debe examinar la bitcora desde el principio, y rastrearla hacia adelante para de-
terminar que ...
a) T estaba activa en el momento del fallo si ha escrito una entrada <INICIAR,T>, pero no ha escri-
to ninguna entrada <COMMIT,T> ni <ROLLBACK,T>, y que
b) T alcanz su punto de confirmacin si ha escrito <COMMIT,T> en bitcora.

Es posible evitar tener que recorrer toda la bitcora, en busca de las transacciones activas (para
anularlas (deshacer sus operaciones) o descartarlas, para reiniciarlas posteriormente).

Tambin se puede evitar tener que rehacer todas las transacciones confirmadas.


13
Es decir, el valor de un elemento de BD no se puede reescribir con su nuevo valor (resultado de una modificacin) ...
14
En particular toda entrada ESCRIBIR que incluya valor_anterior; adems de toda entrada LEER si es posible la reversin en cascada.
15
Es decir, T no llega a su punto de confirmacin...
16
En particular toda entrada ESCRIBIR que incluya tanto valor_anterior como valor_nuevo; adems de toda entrada LEER, si es posible
la reversin en cascada.
17
Esto depender de la tcnica de recuperacin empleada por el SGBD. Se ver ms adelante.
Recuperacin de fallos del sistema - Pg. 10
Ambas cosas se consiguen usando puntos de validacin (tambin llamados puntos de revisin o puntos de
control).

El SGBD, en particular el Gestor de Recuperacin, establece (marca) un punto de revisin de forma
automtica y peridica: por ejemplo cada m minutos, o cuando se han grabado en el bfer de bit-
cora un nmero t de entradas del tipo <COMMIT,T> desde el ltimo punto de validacin
18
.

El uso de puntos de validacin hace necesario un nuevo tipo de entrada en la bitcora, denomina-
do <registro de validacin>, el cual contiene la siguiente informacin:
- Lista de identificadores de las transacciones activas (en el instante del punto de validacin)
- Direccin dentro del fichero bitcora, de la primera y ltima entradas correspondientes a cada transac-
cin activa (para rapidez de acceso si es necesario anular una transaccin)

Marcar un punto de revisin implica lo siguiente:
1. Suspender temporalmente la ejecucin de todas las transacciones en curso.
2. Escribir en disco todas las entradas de bitcora que residan en ese momento en el bfer de bi-
tcora (en memoria).
3. Forzar la escritura en disco de todos los bloques del bfer de BD que se hayan modificado (es
decir, se llevan a disco todas las actualizaciones realizadas
19
).
4. Escribir una entrada <registro de validacin> en la bitcora en disco.
5. Escribir en un fichero especial de arranque del sistema, la direccin fsica del registro de validacin
dentro del fichero bitcora. El Gestor de Recuperacin accede a este fichero especial de
arranque cuando el sistema es reiniciado tras el fallo.
6. Reanudar la ejecucin de transacciones.

As pues, cuando ocurra un fallo slo ser necesario examinar la bitcora desde el ltimo punto
de revisin hacia adelante, y toda transaccin cuya entrada <COMMIT,T> est en la bitcora antes
de dicho punto de validacin no deber rehacer sus operaciones ESCRIBIR, pues ahora estamos se-
guros de que fueron consolidadas por completo (ya que en el punto de revisin se forz la escritu-
ra en disco de tales actualizaciones).

Nota: el que marcar un punto de revisin implique la escritura en disco, no quiere decir que no existan otros
momentos en los que tambin se consoliden cambios en disco, aparte de en estos puntos de validacin
(Sabra indicar cules seran esos otros momentos?).

Por otro lado, recordemos ahora que si una transaccin T1 aborta (y, por tanto, es revertida), cual-
quier otra T2 (no confirmada) que haya ledo elementos escritos por T1, tambin debera ser anula-
da. Esto es la reversin en cascada y puede ocurrir si el protocolo de recuperacin garantiza planes
recuperables, pero no planes sin cascada o planes estrictos.
Como ya hemos indicado antes, la anulacin en cascada puede consumir mucho tiempo, y por esto
los mecanismos de recuperacin se suelen disear de modo que nunca sea necesaria la reversin
en cascada.
Recordemos que para deshacer transacciones es necesario emplear las entradas ESCRIBIR, y ntese
que las entradas LEER se anotan en bitcora para determinar si es necesaria la reversin en casca-
da. Por tanto, si el mtodo de recuperacin garantiza que nunca ocurrir anulacin en cascada, no
ser necesario anotar en bitcora entradas correspondientes a lecturas de elementos.


18
Los valores m y t son parmetros del sistema de base de datos.
19
Importante: como se ver ms adelante, dependiendo de la tcnica de recuperacin que utilice el SGBD, las modificaciones lleva-
das a la BD desde el bfer de BD en un punto de validacin sern a) slo las realizadas por transacciones Tya confirmadas (ac-
tualizacin diferida) o b) todas , independientemente de si la T que las hizo est o no confirmada (actualizacin inmediata).
Recuperacin de fallos del sistema - Pg. 11

15.3. TCNICAS DE RECUPERACIN DE FALLOS DEL SISTEMA
A continuacin describiremos algunas tcnicas de recuperacin. No son descripciones de cmo un
sistema especfico implementa la recuperacin, sino que nuestra intencin es describir concep-
tualmente varias estrategias distintas para la recuperacin de cadas del sistema de BD.

Con frecuencia las tcnicas de recuperacin estn ligadas con los mecanismos de control de la
concurrencia. Es decir, algunas tcnicas funcionan mejor con unos mtodos de control de concu-
rrencia que con otros. Con todo, analizaremos en primer lugar los conceptos de recuperacin sin
tener en cuenta los mecanismos de control de la concurrencia, es decir considerando un sistema
monousuario, y despus indicaremos las circunstancias en las que, si se emplea un protocolo de
control de concurrencia determinado, conviene usar un mecanismo especfico de recuperacin.

Una estrategia de recuperacin representativa podra resumirse informalmente de la siguiente
manera:

Tras un fallo en el sistema de tipo 5 o 6que ha producido daos en una parte considerable de
la BD, el mtodo de recuperacin consistir en restaurar una copia de seguridad anterior de la
BD y reconstruir un estado ms actualizado, rehaciendo las operaciones de las transacciones con-
firmadas anotadas en la bitcora hasta el momento de la cada.

Es conveniente, por tanto realizar peridicamente una copia de seguridad (en cinta, por ejem-
plo) del contenido de la base de datos.

Adems se debe hacer, y con mayor frecuencia, una copia de respaldo del fichero de bitcora
(log) para no perder los efectos de las transacciones ejecutadas desde la ltima copia de seguri-
dad de la BD.

Si el fallo en el sistema es de los tipos 1 a 4la estrategia consistir en invertir los cambios que
provocaron la inconsistencia, es decir deshacer algunas operaciones. Tambin puede ser necesa-
rio rehacer algunas operaciones para restaurar un estado consistente de la BD.
En este caso, slo se necesita consultar las entradas anotadas en la bitcora.

En ambos casos, consideramos que el fichero bitcora en disco no sufre ningn dao.

Dos tipos fundamentales de tcnicas de recuperacin de fallos no catastrficos son las tcnicas
basadas en la actualizacin diferida y en la actualizacin inmediata, que vamos a ver a continuacin.

15.3.1. Tcnica de actualizaciones diferidas
Si el sistema sigue esta tcnica, una transaccin T no modifica la BD antes de completar con xito
su ejecucin y llegar a su punto de confirmacin; es decir, se difiere la grabacin en la BD de los
cambios realizados por T hasta despus de su confirmacin.

Durante la ejecucin de T, todas sus actualizaciones se realizan en su rea de trabajo privada y en el
bfer de BD, y son anotadas en el bfer de bitcora (todo ello en memoria). Una vez que T finaliza con
xito, se fuerza la escritura en disco de la bitcora, momento en el que T alcanza su punto de con-
firmacin. Despus se consolidan los cambios en la BD en disco
20
.

Si ocurre el fallo antes de que T haya llegado a su punto de confirmacin, no habr modificado
la BD en absoluto, por lo que no es necesario deshacer ninguna operacin.

20
La informacin de bitcora asociada a esta transaccin se utiliza para el ejecucin de las escrituras diferidas.
Recuperacin de fallos del sistema - Pg. 12

Si el fallo sucede una vez que T ha alcanzado su punto de confirmacin, habr que rehacer T(a
partir de las entradas de bitcora) porque no es seguro que todos sus cambios se hayan llevado
a disco.

Si el sistema sigue esta tcnica, una vez reiniciado el mismo, el Gestor de Recuperacin ejecutar el
algoritmo de recuperacin NO-DESHACER / REHACER:

1. Crear dos listas de transacciones
21
, llamadas ACTIVAS y CONFIRMADAS, ambas vacas.
2. Inicializar ACTIVAS a la lista de transacciones activas que aparecen en el registro de validacin (co-
rrespondiente al ltimo punto de revisin) escrito en la bitcora.
3. Examinar la bitcora a partir del ltimo punto de revisin hacia adelante.
4. Si se encuentra una entrada <INICIAR,T>, se aade T a la lista ACTIVAS.
5. Si se encuentra una entrada <COMMIT,T>, mover T de la lista ACTIVAS a la lista CONFIRMADAS.
6. Al terminar de examinar la bitcora,
REHACER las operaciones ESCRIBIR de las transacciones de la lista CONFIRMADAS, en el mismo
orden en que se escribieron en bitcora,
REINICIAR las transacciones de la lista ACTIVAS.

El sistema est ahora preparado para aceptar nuevos trabajos (la BD est en un estado consistente).

Rehacer una operacin ESCRIBIR realizada por T consiste en examinar su correspondiente entrada
en bitcora <ESCRIBIR,T,X,valor_nuevo>y asignar valor_nuevo al elemento X de la BD.
Esta operacin rehacer debe ser idempotente (es decir, ejecutarla varias veces debe equivaler a eje-
cutarla una sola vez
22
).
Ntese que en las entradas de bitcora tipo ESCRIBIR slo es necesario almacenar los valores nue-
vos y no los anteriores, puesto que nunca se requiere deshacer operaciones pero s rehacerlas.
Y reiniciar una transaccin significa reintroducirla en el sistema, como si fuera nueva. Puede hacerlo
el sistema de forma automtica, o el usuario manualmente.

Nota: Es importante observar que las operaciones se reharn en el orden en que aparecen anotadas en la
bitcora, aunque pertenezcan a transacciones diferentes. Esto es, no se rehace cada transaccin en aisla-
do, sino que se van rehaciendo a la vez todas las transacciones confirmadas, operacin a operacin.

Si el sistema es monousuario, en la lista ACTIVAS habr como mximo una transaccin.

Si el sistema es multiusuario, dependiendo de los protocolos de control de la concurrencia em-
pleados, el proceso de recuperacin puede ser ms complejo. Cuando mayor sea el grado de con-
currencia, ms complicada ser la tarea de recuperacin:

Consideramos un sistema en el que la bitcora incluye puntos de validacin y el control de la concu-
rrencia utiliza bloqueo en dos fases, por lo que todos los bloqueos de los elementos son manteni-
dos hasta que T llegue a su punto de confirmacin. Despus de ello, los bloqueos pueden libe-
rarse. Esto garantiza planes estrictos y seriables.

Una desventaja de este mtodo es que limita la ejecucin concurrente de las transacciones, pues
los elementos permanecen bloqueados hasta que T llega a su punto de confirmacin.


21
Est claro que dichas listas no almacenarn transacciones en s, sino los identificadores de dichas transacciones, representados aqu
con la letra T.
22
En realidad todo el proceso de recuperacin ha de ser idempotente, puesto que si el sistema falla durante dicho proceso, el segundo
intento de recuperacin podra rehacer operaciones ESCRIBIR que ya hubieran sido restauradas durante el primer intento.
Recuperacin de fallos del sistema - Pg. 13
Pero su principal ventaja es que nunca es necesario deshacer operaciones, porque...

1) Una transaccin no modifica la BD hasta que llega a su punto de confirmacin, luego ningu-
na transaccin se revierte por haber fallado durante su ejecucin.

2) Una transaccin T
1
nunca lee un elemento modificado por otra transaccin T
2
no confirmada,
porque los elementos permanecen bloqueados por T
2
hasta que sta alcanza su punto de con-
firmacin, luego nunca hay reversin en cascada.

-----------

Nota: Un buen ejercicio sera pensar en los cambios que sera necesario realizar en el algoritmo anterior
(NO-DESHACER / REHACER), y tambin en los que se vern a continuacin, si el sistema no utilizara puntos de
validacin.

15.3.2. Tcnica de actualizaciones inmediatas
Si el SGBD utiliza esta tcnica, es posible que algunas operaciones de una transaccin T actualicen
la BD en disco antes de que T alcance su punto de confirmacin (es decir, sin esperar a que T fina-
lice con xito). Estas actualizaciones suelen ser denominadas modificaciones no comprometidas.
Recordemos que, para que sea posible la recuperacin, estas actualizaciones deben ser anotadas en
la bitcora en disco antes de ser aplicadas a la BD (protocolo de bitcora adelantada).

Si ocurre el fallo antes de llegar a su punto de confirmacin (y quiz despus de que T haya
grabado algunos cambios en la BD), T debe ser abortada (rolledback) y hay que deshacer sus ope-
raciones (para anular su efecto sobre la BD).

Y, si el fallo sucede despus de que T haya alcanzado su punto de confirmacin, ser necesario
rehacer sus operaciones, por el mismo motivo que en la tcnica anterior.

Si el sistema sigue esta tcnica, una vez reiniciado el mismo, el Gestor de Recuperacin ejecutar el
algoritmo de recuperacin DESHACER / REHACER:

1. Crear dos listas de transacciones, llamadas ACTIVAS y CONFIRMADAS, ambas vacas.
2. Inicializar ACTIVAS a la lista de transacciones activas que aparecen en el registro de validacin (co-
rrespondiente al ltimo punto de revisin) escrito en la bitcora.
3. Examinar la bitcora a partir del ltimo punto de revisin hacia adelante.
4. Si se encuentra una entrada <INICIAR,T>, se aade T a la lista ACTIVAS.
5. Si se encuentra una entrada <COMMIT,T>, mover T de la lista ACTIVAS a CONFIRMADAS.
6. Al terminar de examinar la bitcora,
DESHACER, con base en la bitcora, las operaciones ESCRIBIR de las transacciones en ACTIVAS.
Deben deshacerse en orden inverso a aquel en que se anotaron en bitcora,
REHACER, con base en la bitcora, las operaciones ESCRIBIR de las transacciones en CONFIR-
MADAS, en el mismo orden en que se escribieron en bitcora.

El sistema est ahora preparado para aceptar nuevos trabajos (la BD est consistente).

Deshacer una operacin ESCRIBIR realizada por T consiste en examinar su entrada en bitcora <ES-
CRIBIR,T,X,valor_anterior,valor_nuevo>y asignar valor_anterior al elemento X de la BD.
Esta operacin deshacer debe ser idempotente.
La operacin rehacer ya ha sido descrita anteriormente.

Recuperacin de fallos del sistema - Pg. 14
Nota: Es importante observar que las operaciones se desharn (o se reharn) en orden inverso (o directo) al
que aparecen anotadas en la bitcora, aunque pertenezcan a transacciones diferentes. Esto es, no se des-
hace (o rehace) cada transaccin en aislado, sino que se van deshaciendo (o rehaciendo) todas las tran-
sacciones activas (o confirmadas) a la vez, operacin a operacin.

Si el sistema es monousuario, en la lista ACTIVAS habr como mximo una transaccin.

Si el sistema es multiusuario y se permite la ejecucin concurrente, el proceso de recuperacin
tambin depende de los protocolos empleados para el control de la concurrencia:
Consideramos un sistema en el que la bitcora incluye puntos de validacin y el control de la concu-
rrencia usa bloqueo de dos fases estricto, el cual slo permite que una transaccin T lea o escriba un
elemento si la ltima transaccin que lo ha escrito ya se ha confirmado o abortado. Esto garanti-
za planes estrictos, pero pueden producirse bloqueos mortales, lo cual necesitar deshacer transac-
ciones.

-----------

Una variacin de esta ltima tcnica obliga a que, para que pueda decirse que T ha llegado a su
punto de confirmacin, todas las actualizaciones realizadas por T deben haberse grabado en la
base de datos.
En caso de permitir actualizaciones inmediatas junto con lo indicado en el prrafo anterior, si ocu-
rre un fallo despus de que T ha alcanzado su punto de confirmacin, no se necesitar rehacer nin-
guna operacin. Por supuesto, si el fallo ocurre antes de llegar a su punto de confirmacin (y quiz
despus de que T haya grabado algunos cambios en la BD), ser necesario deshacer sus operaciones.
Si el sistema sigue esta tcnica, una vez reiniciado el mismo, ejecutar el algoritmo de recuperacin
DESHACER / NO-REHACER, cuyos pasos se dejan como ejercicio.




BIBLIOGRAFA

[EN 2002] Elmasri, R.; Navathe, S.B. Fundamentos de Sistemas de Bases de Datos. 3 Edicin. Madrid [etc.]: Addi-
son-Wesley, Pearson Educacin, 2002. (Captulos 19 y 21)
[EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos fundamentales. 2 Edicin. Wilming-
ton, Delaware, USA: Addison-Wesley Iberoamericana, 1997. (Captulos 17 y 19)
[CBS 1998] Connolly, T.; Begg C.; Strachan, A. Database Systems: A Practical Approach to Design, Implementa-
tion and Management. 2
nd
edition. Harlow, England: Addison-Wesley, 1998. (Captulo 17)