Sistemas de recuperación
Sistemas de recuperación.
Objetivos.
- El
alumno entenderá las diferentes fallas mediante la solución de problemas
para el desarrollo de diseños de bases de datos que garanticen la
integridad y eficiente el rendimiento y el espacio de almacenamiento.
- El
alumno entenderá la recuperación y atomicidad mediante la solución de
problemas para el desarrollo de diseños de bases de datos que garanticen
la integridad y eficiente el rendimiento y el espacio de almacenamiento.
- El
alumno entenderá y aplicará los algoritmos de recuperación mediante la
solución de problemas para el desarrollo de diseños de bases de datos que
garanticen la integridad y eficiente el rendimiento y el espacio de
almacenamiento.
- El
alumno entenderá los sistemas de respaldo remoto mediante la solución de
problemas para el desarrollo de diseños de bases de datos que garanticen
la integridad y eficiente el rendimiento y el espacio de almacenamiento.
Introducción.
Los sistemas de recuperación en bases de datos son
necesarios para proteger la información contra la pérdida o el daño causados
por diferentes factores, como errores humanos, fallas técnicas, ataques
externos o desastres naturales. Estos sistemas permiten restaurar los datos a
partir de una copia de seguridad que se almacena en otra ubicación, ya sea en
un disco o en algún medio físico. La recuperación de datos es un proceso que
puede implicar diferentes estrategias y procedimientos, dependiendo del tipo de
copia de seguridad, del nivel de daño y de los objetivos de recuperación de la
empresa.
Existen dos tipos principales de copias de seguridad: las
físicas y las lógicas. Las copias de seguridad físicas son respaldos de los
archivos físicos que se utilizan para almacenar y recuperar la información,
como archivos de datos, archivos de control y registros. Las copias de
seguridad lógicas son respaldos de los datos lógicos, como tablas o
procedimientos almacenados, que se exportan desde una base de datos y se
almacenan en un archivo binario. Las copias de seguridad físicas son la base de
cualquier estrategia de copia de seguridad y recuperación, mientras que las
copias de seguridad lógicas son un complemento útil en muchas circunstancias.
La importancia de asegurar la información en las bases de
datos radica en que los datos son un activo valioso para cualquier negocio, y
su pérdida o corrupción puede tener consecuencias negativas, como la
interrupción de las operaciones, la pérdida de clientes, la disminución de la
competitividad, el incumplimiento de normativas o la exposición a riesgos
legales. Por eso, es fundamental contar con un plan de copia de seguridad y
recuperación que cumpla con los requisitos de la empresa y que se actualice periódicamente.
Clasificación de fallas
En un sistema pueden producirse varios tipos de fallos, cada
uno de los cuales requiere un tratamiento diferente. El tipo de fallo más fácil
de tratar es el que no conduce a una pérdida de información en el sistema. Los
fallos más difíciles de tratar son aquellos que provocan una pérdida de
información.
- Fallo
en la transacción. Hay dos tipos de errores que pueden hacer que una
transacción falle:
- Error
lógico. La transacción no puede continuar con su ejecución normal a causa
de alguna condición interna, como una entrada incorrecta, datos no
encontrados, desbordamiento o exceso del límite de recursos.
- Error
del sistema. El sistema se encuentra en un estado no deseado (por
ejemplo, de interbloqueo) como consecuencia del cual una transacción no
puede continuar con su ejecución normal. La transacción, sin embargo, se
puede volver a ejecutar más tarde.
- Caída
del sistema. Un mal funcionamiento del hardware o un error en el software
de la base de datos o del sistema operativo causa la pérdida del contenido
de la memoria volátil y aborta el procesamiento de una transacción. El
contenido de la memoria no volátil permanece intacto y no se corrompe.
La suposición de que los errores de hardware o software fuercen una parada del sistema, pero no corrompan el contenido de la memoria no volátil, se conoce como supuesto de fallo-parada.
Los sistemas bien diseñados tienen numerosas comprobaciones internas, al nivel de hardware y de software, que abortan el sistema cuando existe un error. De aquí que el supuesto de fallo parada sea razonable. - Fallo
de disco. Un bloque del disco pierde su contenido como resultado de una
colisión de la cabeza lectora, o de un fallo durante una operación de
transferencia de datos. Las copias de los datos que se encuentran en otros
discos o en archivos de seguridad en medios de almacenamiento secundarios,
como cintas, se utilizan para recuperarse del fallo.
Para determinar el medio por el que el sistema debe
recuperarse de los fallos, es necesario identificar los modos de fallo de los
dispositivos de almacenamiento. A continuación se verá cómo afectan estos modos
de fallo al contenido de la base de datos. Por tanto, se pueden proponer
algoritmos para garantizar la consistencia de la base de datos y la atomicidad
de las transacciones a pesar de los fallos. Estos algoritmos, conocidos como
algoritmos de recuperación, constan de dos partes:
- Acciones
llevadas a cabo durante el procesamiento normal de transacciones para
asegurar que existe información suficiente para permitir la recuperación
frente a fallos.
- Acciones
llevadas a cabo después de ocurrir un fallo para restablecer el contenido
de la base de datos a un estado que asegure la consistencia de la base de
datos, la atomicidad de la transacción y la durabilidad
Recuperación y atomicidad
Considérese de nuevo el sistema bancario simplificado y una
transacción Ti que transfiere $50 desde la cuenta A a la cuenta B, siendo los
saldos iniciales de A y de B de $1,000 y de $2,000, respectivamente.
Supóngase que el sistema cae durante la ejecución de Ti
después de haberse ejecutado salida(BA), pero antes de la ejecución de
salida(BB), donde BA y BB denotan los bloques de memoria intermedia en los que
residen BA y BB. Al perderse el contenido de la memoria no se sabe la suerte de
la transacción; así, podríamos invocar uno de los dos procedimientos posibles
de recuperación.
- Volver
a ejecutar Ti
Este procedimiento hará que el saldo de A se quede en 900 en vez de en 950. De este modo el sistema entra en un estado inconsistente. - No
volver a ejecutar Ti
El estado actual del sistema otorga los valores de 950 y 2.000 para A y B respectivamente. Por tanto, el sistema entra en un estado inconsistente.
En cualquier caso se deja a la base de datos en un estado
inconsistente y, por tanto, este esquema simple de recuperación de datos no
funciona. El motivo de este mal funcionamiento es que se ha modificado la base
de datos sin tener la seguridad de que la transacción se comprometa realmente.
El objetivo es realizar todos los cambios inducidos por Ti o no llevar a cabo
ninguno. Sin embargo, si Ti realiza varias modificaciones en la base de datos,
pueden necesitarse varias operaciones de salida y puede ocurrir un fallo
después de haberse concluido alguna de estas modificaciones, pero antes de
haber terminado todas.
Para conseguir el objetivo de la atomicidad se debe efectuar
primero la operación de salida de la información que describe las
modificaciones en el almacenamiento estable sin modificar todavía la base de
datos. Como se verá, este procedimiento permitirá realizar la salida de todas
las modificaciones realizadas por una transacción comprometida aunque se
produzcan fallos. Supondremos que las transacciones se ejecutan
secuencialmente; es decir, sólo una transacción está activa en cada momento.
Recuperación basada en el registro histórico
La estructura más ampliamente utilizada para guardar las
modificaciones de una base de datos es el registro histórico. El registro
histórico es una secuencia de registros que almacena todas las actividades de
actualización de la base de datos. Existen varios tipos de registros del
registro histórico. Un registro de actualización del registro histórico
describe una única escritura en la base de datos y tiene los siguientes campos:
El identificador de la transacción es un
identificador único de la transacción que realiza la operación escribir.
El identificador del elemento de datos es un identificador único
del elemento de datos que se escribe. Normalmente suele coincidir con la
ubicación del elemento de datos en el disco.
El valor anterior es el valor que tenía el elemento de datos
antes de la escritura.
El valor nuevo es el valor que tendrá el elemento de datos
después de la escritura.
Existen otros registros del registro histórico especiales
para registrar sucesos significativos durante el procesamiento de una
transacción, tales como el comienzo de una transacción y el éxito o aborto de
la misma. Denotaremos como sigue los diferentes tipos de registros del registro
histórico:
- <Ti
iniciada>. La transacción Ti ha comenzado.
- <Ti,
Xj , V1, V2>. La transacción Ti ha realizado una escritura sobre el
elemento de datos Xj. Xj tenía el valor V1 antes de la escritura y tendrá
el valor V2 después de la escritura.
- <Ti
comprometida>. La transacción Ti se ha comprometido.
- <Ti
abortada>. La transacción Ti ha sido abortada.
Cuando una transacción realiza una escritura es fundamental
que se cree el registro del registro histórico correspondiente a esa escritura
antes de modificar la base de datos. Una vez que el registro del registro
histórico existe, se puede realizar la salida de la modificación a la base de
datos si se desea. Además, es posible deshacer una modificación que ya haya
salido a la base de datos. Se deshará utilizando el campo valor-anterior de los
registros del registro histórico.
Para que los registros del registro histórico sean útiles
para recuperarse frente a errores del disco o del sistema, el registro
histórico debe residir en almacenamiento estable. Por ahora supóngase que cada
registro del registro histórico se escribe, tan pronto como se crea, al final
del registro histórico en almacenamiento estable.
Obsérvese que en el registro histórico se tiene constancia
de todas las actividades de la base de datos. Como consecuencia, el tamaño de
los datos almacenados en el registro histórico puede llegar a ser
extremadamente grande.
Un ejemplo del registro histórico para la transferencia de
$50 entre las cuentas A y B, sería:
<T1 iniciada>
<T1, A, 1000, 950>
<T1, B, 2000, 2050>
<T1 comprometida>
Puntos de revisión
Cuando ocurre un fallo en el sistema se debe consultar el
registro histórico para determinar las transacciones que deben rehacerse y las
que deben deshacerse. En principio es necesario recorrer completamente el
registro histórico para hallar esta información. En este enfoque hay dos
inconvenientes principales:
- El
proceso de búsqueda consume tiempo.
- La
mayoría de las transacciones que deben rehacerse de acuerdo con el
algoritmo ya tienen escritas sus actualizaciones en la base de datos.
Aunque el hecho de volver a ejecutar estas transacciones no produzca
resultados erróneos, sí repercutirá en un aumento del tiempo de ejecución
del proceso de recuperación.
Para reducir este tipo de sobrecarga se introducen los
puntos de revisión. Durante la ejecución, el sistema actualiza el registro
histórico. Además, el sistema realiza periódicamente puntos de revisión, en los
cuales tiene lugar la siguiente secuencia de acciones:
- Escritura
en almacenamiento estable de todos los registros del registro histórico
que residan en ese momento en memoria principal.
- Escritura
en disco de todos los bloques de memoria intermedia que se hayan
modificado.
- Escritura
en almacenamiento estable de un registro del registro histórico
<revisión>.
Mientras se lleva a cabo un punto de revisión no se permite
que ninguna transacción realice acciones de actualización, tales como escribir
en un bloque de memoria intermedia o escribir un registro del registro
histórico.
La presencia de un registro <revisión> en el registro
histórico permite que el sistema pueda hacer más eficiente su procedimiento de
recuperación. Considérese una transacción Ti que se comprometió antes del punto
de revisión. Para esa transacción el registro <Ti comprometida> aparece
en el registro histórico antes que el registro <revisión>. Todas las
modificaciones sobre la base de datos hechas por Ti se deben haber escrito en
la base de datos antes del punto de revisión o formando parte del propio punto
de revisión. Así, en el momento de la recuperación, no es necesario ejecutar
una operación rehacer sobre Ti.
Esta observación permite perfeccionar los esquemas
anteriores de recuperación (sigue siendo válido el supuesto de que las
transacciones se ejecutan secuencialmente). Cuando se produce un fallo, el
esquema de recuperación examina el registro histórico para determinar la última
transacción Ti que comenzó su ejecución antes de que tuviera lugar el último
punto de revisión. Para encontrar una transacción de este tipo se recorre el
registro histórico hacia atrás, esto es, se empieza a buscar por el final del
registro histórico hasta que se encuentra el primer registro <revisión>
(como se va recorriendo el registro histórico hacia atrás, el registro
encontrado corresponde al último registro <revisión> del registro
histórico); después se continúa la búsqueda hacia atrás hasta que se encuentra
el siguiente registro <Ti iniciada>.
Este registro identifica a la transacción Ti.
Una vez que ha sido identificada la transacción Ti sólo es
necesario aplicar las operaciones rehacer y deshacer a las transacciones Tj que
comenzaron su ejecución después que Ti. Sea T este conjunto de transacciones.
Puede ignorarse el resto del registro histórico (la parte del principio) y
puede borrarse cuando se desee. El conjunto exacto de operaciones de
recuperación que han de llevarse a cabo depende de si se está usando la técnica
de modificación inmediata o la de modificación diferida. Si se emplea la
técnica de modificación inmediata, las operaciones de recuperación deben ser
las siguientes:
- Ejecutar
deshacer(Tk) para todas las transacciones Tk de T para las que no exista
un registro <Tk comprometida> en el registro histórico.
Ejecutar execute rehacer(Tk) para todas las transacciones Tk de T para las que aparece un registro <Tk comprometida> en el registro histórico.
Obviamente no es necesario aplicar la operación deshacer
cuando se está utilizando la técnica de modificación diferida. A modo de
ejemplo, considérese el conjunto de transacciones {T0, T1, . . ., T100} de modo
que su ejecución se produce en el orden determinado por los subíndices.
Supóngase que el último punto de revisión tiene lugar durante la ejecución de
la transacción T67. Así, durante el esquema de recuperación, sólo deben
considerarse las transacciones T67, T68, . . ., T100. Será necesario rehacer
cada una de ellas si éstas se comprometieron y será necesario deshacerlas en
caso contrario.
Método de modificación inmediata.
El método de modificación inmediata es una técnica de
recuperación de bases de datos que consiste en aplicar los cambios de las
transacciones directamente sobre el disco, sin esperar a que se confirmen o se
cancelen. Esto implica que, en caso de una falla del sistema, la base de datos
puede quedar en un estado inconsistente, con algunas transacciones incompletas
o incorrectas. Para evitar este problema, el método de modificación inmediata
utiliza un archivo de bitácora o registro, donde se almacenan todas las
operaciones realizadas por las transacciones, junto con sus identificadores y
sus estados. De esta forma, si ocurre una falla, el sistema puede consultar el
archivo de bitácora y deshacer o rehacer las operaciones necesarias para
restaurar la consistencia de la base de datos.
El método de modificación inmediata tiene la ventaja de que
reduce el tiempo de respuesta de las transacciones, ya que no requiere mantener
los datos modificados en memoria hasta que se confirmen.
Método de modificación diferida
El método de modificación diferida es una técnica de
recuperación de bases de datos que consiste en retrasar los cambios de las
transacciones hasta que se confirmen o se cancelen. Esto implica que, en caso
de una falla del sistema, la base de datos no se ve afectada por las
transacciones incompletas o incorrectas. Para evitar la pérdida de los datos
modificados, el método de modificación diferida utiliza un archivo de bitácora
o registro, donde se almacenan todas las operaciones realizadas por las transacciones,
junto con sus identificadores y sus estados. De esta forma, si ocurre una
falla, el sistema puede consultar el archivo de bitácora y rehacer las
operaciones necesarias para aplicar los cambios de las transacciones
confirmadas.
El método de modificación diferida tiene la ventaja de que
preserva la integridad de la base de datos, ya que no se alteran los datos
originales hasta que se garantiza la consistencia de las transacciones. Sin
embargo, también tiene la desventaja de que consume más memoria para almacenar
los datos modificados y más tiempo para rehacer las operaciones en caso de una
falla. Además, el método de modificación diferida requiere un mayor espacio de
disco para almacenar el archivo de bitácora y un mayor tiempo de respuesta de
las transacciones, ya que se debe esperar a que se confirmen para aplicar los
cambios.
Algoritmos para la recuperación
Los algoritmos de recuperación de una base de datos son
técnicas para asegurar la integridad y la disponibilidad de los datos en caso
de que ocurra alguna falla o error que afecte al sistema. Estos algoritmos se
basan en el uso de copias de seguridad y registros de transacciones que
permiten restaurar los datos a un estado consistente y coherente.
Existen diferentes tipos de algoritmos de recuperación,
dependiendo del modelo de recuperación que se utilice en la base de datos. El
modelo de recuperación define cómo se registran y se aplican los cambios de las
transacciones en la base de datos, y cómo se pueden restaurar esos cambios en
caso de una falla.
Registro de deshacer lógico.
El algoritmo de recuperación “Registro de deshacer lógico”
es una técnica que utiliza el registro de deshacer para restaurar la base de
datos a un estado consistente después de una falla. El registro de deshacer es
un archivo que almacena las operaciones inversas a las que realizan las
transacciones sobre la base de datos. Por ejemplo, si una transacción inserta
un registro, el registro de deshacer almacena la operación de eliminar ese
registro. De esta forma, si la transacción falla o se cancela, se puede deshacer
su efecto sobre la base de datos aplicando las operaciones inversas del
registro de deshacer.
El algoritmo de recuperación “Registro de deshacer lógico”
se basa en el principio de que una transacción solo puede confirmarse cuando se
ha escrito su registro de deshacer en el disco. Esto garantiza que, en caso de
una falla, se pueda recuperar la base de datos a partir de la última copia de
seguridad y del registro de deshacer. El algoritmo consiste en los siguientes
pasos:
- Identificar
las transacciones que estaban en progreso en el momento de la falla,
consultando el registro de transacciones.
- Para
cada transacción en progreso, localizar su registro de deshacer y aplicar
las operaciones inversas sobre la base de datos, en orden inverso al que
se realizaron.
- Confirmar
las transacciones que habían terminado antes de la falla, consultando el
registro de transacciones.
- Liberar
los recursos y los bloqueos asociados a las transacciones.
El algoritmo de recuperación “Registro de deshacer lógico”
tiene la ventaja de que preserva la atomicidad y la consistencia de las
transacciones, ya que permite cancelar las transacciones incompletas o
incorrectas. Sin embargo, también tiene la desventaja de que consume más
espacio de disco para almacenar el registro de deshacer y más tiempo de
recuperación para analizar y procesar las operaciones inversas.
Inicio
//Leer
el registro de transacciones desde el final hasta el principio
Para
cada transacción T en el registro de transacciones en orden inverso hacer
Si
la transacción T está en estado “en progreso” o “cancelada”
//Leer
el registro de deshacer de la transacción T
Para
cada operación O en el registro de deshacer de T en orden inverso hacer
//Aplicar
la operación inversa de O sobre la base de datos
Ejecutar
O.inversa sobre la base de datos
Fin
para
//Cambiar
el estado de la transacción T a “deshecha”
T.estado
= “deshecha”
Fin
si
//Si
la transacción T está en estado “terminada”
Si T.estado ==
“terminada” entonces
//Cambiar
el estado de la transacción T a “confirmada”
T.estado
= “confirmada”
Fin
si
Fin
para
//Liberar
los recursos y los bloqueos asociados a las transacciones
Liberar
recursos y bloqueos
Fin
Retroceso de transacciones
El algoritmo de recuperación Retroceso de transacciones es
una técnica que utiliza el registro de deshacer para restaurar la base de datos
a un estado consistente después de una falla o un aborto de una transacción. El
registro de deshacer es un archivo que almacena las operaciones inversas a las
que realizan las transacciones sobre la base de datos. Por ejemplo, si una
transacción inserta un registro, el registro de deshacer almacena la operación
de eliminar ese registro. De esta forma, si la transacción falla o se cancela,
se puede deshacer su efecto sobre la base de datos aplicando las operaciones
inversas del registro de deshacer.
El algoritmo de recuperación Retroceso de transacciones se
basa en el principio de que una transacción solo puede confirmarse cuando se ha
escrito su registro de deshacer en el disco. Esto garantiza que, en caso de una
falla, se pueda recuperar la base de datos a partir de la última copia de
seguridad y del registro de deshacer. El algoritmo consiste en los siguientes
pasos:
- Identificar
las transacciones que estaban en progreso en el momento de la falla,
consultando el registro de transacciones.
- Para
cada transacción en progreso, localizar su registro de deshacer y aplicar
las operaciones inversas sobre la base de datos, en orden inverso al que
se realizaron.
- Confirmar
las transacciones que habían terminado antes de la falla, consultando el
registro de transacciones.
- Liberar
los recursos y los bloqueos asociados a las transacciones.
El algoritmo de recuperación Retroceso de transacciones
tiene la ventaja de que preserva la atomicidad y la consistencia de las
transacciones, ya que permite cancelar las transacciones incompletas o
incorrectas. Sin embargo, también tiene la desventaja de que consume más
espacio de disco para almacenar el registro de deshacer y más tiempo de
recuperación para analizar y procesar las operaciones inversas.
Inicio
// Leer el registro
de transacciones desde el final hasta el principio
Para cada
transacción T en el registro de transacciones en orden inverso hacer
// Si la
transacción T está en estado "en progreso" o "cancelada"
Si T.estado ==
"en progreso" o T.estado == "cancelada" entonces
// Leer el
registro de deshacer de la transacción T
Para cada
operación O en el registro de deshacer de T en orden inverso hacer
// Aplicar la
operación inversa de O sobre la base de datos
Ejecutar
O.inversa sobre la base de datos
Fin para
// Cambiar el
estado de la transacción T a "deshecha"
T.estado =
"deshecha"
Fin si
// Si la
transacción T está en estado "terminada"
Si T.estado ==
"terminada" entonces
// Cambiar el
estado de la transacción T a "confirmada"
T.estado =
"confirmada"
Fin si
Fin para
// Liberar los
recursos y los bloqueos asociados a las transacciones
Liberar recursos y
bloqueos
Fin
Puntos de revisión
El algoritmo de recuperación “Puntos de revisión” es una
técnica que utiliza puntos de revisión o checkpoints para reducir el tiempo de
recuperación después de una falla. Un punto de revisión es un momento en el que
se garantiza que todos los cambios de las transacciones confirmadas se han
escrito en el disco, y que el registro de transacciones se ha truncado hasta
ese punto. De esta forma, si ocurre una falla, el sistema solo tiene que
analizar y procesar las operaciones que se realizaron después del último punto
de revisión, y no todo el registro de transacciones.
El algoritmo de recuperación “Puntos de revisión” se basa en
el principio de que una transacción solo puede confirmarse cuando se ha escrito
su registro de rehacer en el disco. El registro de rehacer es un archivo que
almacena las operaciones que realizan las transacciones sobre la base de datos.
Por ejemplo, si una transacción inserta un registro, el registro de rehacer
almacena la operación de inserción de ese registro. De esta forma, si la
transacción se confirma, se puede rehacer su efecto sobre la base de datos
aplicando las operaciones del registro de rehacer.
El algoritmo de recuperación “Puntos de revisión” consiste
en los siguientes pasos:
- Identificar
el último punto de revisión, consultando el registro de transacciones.
- Leer
el registro de transacciones desde el último punto de revisión hasta el
final.
- Identificar
las transacciones que estaban en progreso o que se confirmaron después del
último punto de revisión, consultando el registro de transacciones.
- Para
cada transacción en progreso, localizar su registro de deshacer y aplicar
las operaciones inversas sobre la base de datos, en orden inverso al que
se realizaron.
- Para
cada transacción confirmada, localizar su registro de rehacer y aplicar
las operaciones sobre la base de datos, en el mismo orden en que se
realizaron.
- Liberar
los recursos y los bloqueos asociados a las transacciones.
- El
algoritmo de recuperación “Puntos de revisión” tiene la ventaja de que
reduce el tiempo de recuperación, ya que solo se procesan las operaciones
que se realizaron después del último punto de revisión. Sin embargo,
también tiene la desventaja de que consume más espacio de disco para
almacenar los registros de rehacer y de deshacer, y más tiempo para
realizar los puntos de revisión periódicamente.
Inicio
// Identificar el
último punto de revisión, consultando el registro de transacciones
ultimo_punto =
Buscar_ultimo_punto_de_revision(registro_de_transacciones)
// Leer el registro
de transacciones desde el último punto de revisión hasta el final
Para cada
transacción T en el registro de transacciones desde ultimo_punto hasta el final
hacer
// Si la
transacción T está en estado "en progreso" o "cancelada"
Si T.estado ==
"en progreso" o T.estado == "cancelada" entonces
// Leer el
registro de deshacer de la transacción T
Para cada
operación O en el registro de deshacer de T en orden inverso hacer
// Aplicar la
operación inversa de O sobre la base de datos
Ejecutar
O.inversa sobre la base de datos
Fin para
// Cambiar el
estado de la transacción T a "deshecha"
T.estado =
"deshecha"
Fin si
// Si la
transacción T está en estado "terminada"
Si T.estado ==
"terminada" entonces
// Leer el
registro de rehacer de la transacción T
Para cada
operación O en el registro de rehacer de T en el mismo orden hacer
// Aplicar la
operación de O sobre la base de datos
Ejecutar O
sobre la base de datos
Fin para
// Cambiar el
estado de la transacción T a "confirmada"
T.estado =
"confirmada"
Fin si
Fin para
// Liberar los
recursos y los bloqueos asociados a las transacciones
Liberar recursos y
bloqueos
Fin
Recuperación al reiniciar
El algoritmo de recuperación al reiniciar es una técnica que
se utiliza para restaurar la consistencia de una base de datos después de una
falla del sistema. Este algoritmo se basa en el uso de un registro de
transacciones, donde se almacenan todas las operaciones que realizan las
transacciones sobre la base de datos, y de puntos de revisión, donde se
garantiza que todos los cambios de las transacciones confirmadas se han escrito
en el disco.
El algoritmo de recuperación al reiniciar consiste en los
siguientes pasos:
- Identificar
el último punto de revisión, consultando el registro de transacciones.
- Leer
el registro de transacciones desde el último punto de revisión hasta el
final.
- Identificar
las transacciones que estaban en progreso o que se confirmaron después del
último punto de revisión, consultando el registro de transacciones.
- Para
cada transacción en progreso, localizar su registro de deshacer y aplicar
las operaciones inversas sobre la base de datos, en orden inverso al que
se realizaron.
- Para
cada transacción confirmada, localizar su registro de rehacer y aplicar
las operaciones sobre la base de datos, en el mismo orden en que se
realizaron.
- Liberar
los recursos y los bloqueos asociados a las transacciones.
El algoritmo de recuperación al reiniciar tiene la ventaja
de que reduce el tiempo de recuperación, ya que solo se procesan las
operaciones que se realizaron después del último punto de revisión. Sin
embargo, también tiene la desventaja de que consume más espacio de disco para
almacenar los registros de rehacer y de deshacer, y más tiempo para realizar
los puntos de revisión periódicamente.
Inicio
// Identificar el
último punto de revisión, consultando el registro de transacciones
ultimo_punto =
Buscar_ultimo_punto_de_revision(registro_de_transacciones)
// Leer el registro
de transacciones desde el último punto de revisión hasta el final
Para cada
transacción T en el registro de transacciones desde ultimo_punto hasta el final
hacer
// Si la
transacción T está en estado "en progreso" o "cancelada"
Si T.estado ==
"en progreso" o T.estado == "cancelada" entonces
// Leer el
registro de deshacer de la transacción T
Para cada
operación O en el registro de deshacer de T en orden inverso hacer
// Aplicar la
operación inversa de O sobre la base de datos
Ejecutar
O.inversa sobre la base de datos
Fin para
// Cambiar el
estado de la transacción T a "deshecha"
T.estado =
"deshecha"
Fin si
// Si la
transacción T está en estado "terminada"
Si T.estado ==
"terminada" entonces
// Leer el
registro de rehacer de la transacción T
Para cada
operación O en el registro de rehacer de T en el mismo orden hacer
// Aplicar la
operación de O sobre la base de datos
Ejecutar O
sobre la base de datos
Fin para
// Cambiar el
estado de la transacción T a "confirmada"
T.estado =
"confirmada"
Fin si
Fin para
// Liberar los
recursos y los bloqueos asociados a las transacciones
Liberar recursos y
bloqueos
Fin
ARIES
El algoritmo de recuperación ARIES es una técnica que se
utiliza para restaurar la consistencia de una base de datos después de una
falla del sistema. Este algoritmo se basa en el uso de un registro de
transacciones, donde se almacenan todas las operaciones que realizan las
transacciones sobre la base de datos, y de puntos de revisión, donde se
garantiza que todos los cambios de las transacciones confirmadas se han escrito
en el disco.
El algoritmo de recuperación ARIES consiste en tres fases:
- Análisis:
El sistema identifica las transacciones que estaban en progreso o que se
confirmaron después del último punto de revisión, consultando el registro
de transacciones. También construye una tabla de transacciones activas y
una tabla de páginas sucias, que contienen información sobre el estado de
las transacciones y las páginas modificadas.
- Rehacer:
El sistema repite todas las operaciones registradas desde el último punto
de revisión hasta el final, aplicando los cambios sobre la base de datos.
Esto restaura el estado de la base de datos a como era en el momento de la
falla.
- Deshacer:
El sistema deshace las operaciones de las transacciones que no se habían
confirmado en el momento de la falla, aplicando las operaciones inversas
sobre la base de datos. Esto cancela el efecto de las transacciones
incompletas o incorrectas.
El algoritmo de recuperación ARIES tiene la ventaja de que
aprovecha la semántica de las operaciones para optimizar el proceso de
recuperación, reduciendo el número de operaciones que se deben rehacer o
deshacer. Además, permite el uso de diferentes políticas de gestión de buffer,
como robar o no forzar, que mejoran el rendimiento del sistema. Sin embargo,
también tiene la desventaja de que requiere más espacio de disco para almacenar
el registro de transacciones y los puntos de revisión, y más tiempo para realizar
el análisis y el rehacer.
Sistemas remotos de copias de seguridad
Los sistemas tradicionales de procesamiento de transacciones
son sistemas centralizados o sistemas cliente-servidor. Esos sistemas son
vulnerables frente a desastres ambientales como el fuego, las inundaciones o
los terremotos. Hay una necesidad creciente de sistemas de procesamiento de
transacciones que ofrezcan una disponibilidad elevada y que puedan funcionar
pese a los desastres ambientales. Estos sistemas deben proporcionar una
disponibilidad elevada, es decir, el tiempo en que el sistema no es utilizable
debe ser extremadamente pequeño.
Se puede obtener una disponibilidad elevada realizando el
procesamiento de transacciones en un solo sitio, denominado sitio principal,
pero tener un sitio remoto copia de seguridad, en el que se repliquen todos los
datos del sitio principal. El sitio remoto copia de seguridad se denomina
también a veces sitio secundario. El sitio remoto debe mantenerse sincronizado
con el sitio principal, ya que las actualizaciones se realizan en el sitio
principal. La sincronización se obtiene enviando todos los registros del
registro histórico desde el sitio principal al sitio remoto de copia de
seguridad. El sitio remoto copia de seguridad debe hallarse físicamente
separado del principal—por ejemplo, se puede ubicar en otra provincia—para que
una catástrofe en el sitio principal no afecte al sitio remoto copia de
seguridad. En la figura se muestra la arquitectura de los sistemas remotos para
copias de seguridad.
Cuando falla el sitio principal, el sitio remoto de copia de
seguridad asume el procesamiento. En primer lugar, sin embargo, lleva a cabo la
recuperación utilizando su copia (tal vez anticuada) de los datos del sitio
principal y de los registros del registro histórico recibidos del mismo. En
realidad, el sitio remoto copia de seguridad lleva a cabo acciones de
recuperación que se hubieran llevado a cabo en el sitio principal cuando éste
se hubiera recuperado. Se pueden utilizar los algoritmos estándar de recuperación
para la recuperación en el sitio remoto copia de seguridad con pocas
modificaciones. Una vez realizada la recuperación, el sitio remoto copia de
seguridad comienza a procesar transacciones.
La disponibilidad aumenta mucho en comparación con los
sistemas con un solo sitio, dado que el sistema puede recuperarse aunque se
pierdan todos los datos del sitio principal. El rendimiento de los sistemas
remotos para copias de seguridad es mejor que el de los sistemas distribuidos
con compromiso de dos fases.
Se deben abordar varios aspectos al diseñar sistemas remotos
para copias de seguridad, tales como:
- Detección
de fallos. Al igual que en los protocolos para el manejo de fallos en
sistemas distribuidos, es importante que el sistema remoto de copia de
seguridad detecte que el sitio principal ha fallado. El fallo de las
líneas de comunicación puede hacer creer al sitio remoto de copia de
seguridad que el sitio principal ha fallado. Para evitar este problema hay
que mantener varios enlaces de comunicaciones con modos de fallo
independientes entre el sitio principal y el sitio remoto copia de
seguridad. Por ejemplo, además de la conexión de red puede haber otra
conexión mediante módem por línea telefónica con servicio suministrado por
diferentes compañías de telecomunicaciones. Estas conexiones pueden
complementarse con la intervención manual de operadores, que se pueden
comunicar por vía telefónica.
- Transferencia
del control. Cuando el sitio principal falla, el sitio de copia de
seguridad asume el procesamiento y se transforma en el nuevo sitio
principal. Cuando el sitio principal original se recupera puede desempeñar
el papel de sitio remoto de copia de seguridad o volver a asumir el papel
de sitio principal. En cualquiera de los casos, el sitio principal antiguo
debe recibir un registro histórico de actualizaciones realizado por el
sitio de copia de seguridad mientras el sitio principal antiguo estaba
fuera de servicio. La manera más sencilla de transferir el control es que
el sitio principal antiguo reciba el registro histórico de operaciones
rehacer del sitio de copia de seguridad antiguo y se ponga al día con las
actualizaciones aplicándolas de manera local. El sitio principal antiguo
puede entonces actuar como sitio remoto de copia de seguridad. Si hay que
devolver el control, el sitio remoto copia de seguridad antiguo puede
simular que ha fallado, lo que da lugar a que el sitio principal antiguo asuma
el control.
- Tiempo
de recuperación. Si el registro histórico del sitio remoto de copia de
seguridad se hace grande, la recuperación puede tardar mucho. El sitio
remoto copia de seguridad puede procesar de manera periódica los registros
rehacer del registro histórico que haya recibido y realizar un punto de
revisión, de manera que se puedan borrar las partes más antiguas del
registro histórico. Como consecuencia se puede reducir el retraso antes de
que el sitio remoto de copia de seguridad asuma el control. Una configuración
de relevo en caliente puede hacer la toma del control por el sitio de
copia de seguridad casi instantáneo. En esta configuración el sitio remoto
copia de seguridad procesa los registros rehacer del registro histórico
según llegan, y aplica las actualizaciones de manera local. Tan pronto
como se detecta el fallo del sitio principal, el sitio de copia de
seguridad completa la recuperación haciendo retroceder las transacciones
incompletas y queda preparado para procesar las nuevas.
- Tiempo
de compromiso. Para asegurar que las actualizaciones de una transacción
comprometida sean duraderas no se debe declarar comprometida una
transacción hasta que sus registros del registro histórico hayan alcanzado
el sitio de copia de seguridad. Este retraso puede dar lugar a una espera
más prolongada para comprometer la transacción y, en consecuencia, algunos
sistemas permiten grados inferiores de durabilidad. Los grados de
durabilidad pueden clasificarse de la manera siguiente.
- Uno
seguro. Las transacciones se comprometen tan pronto como sus registros de
compromiso del registro histórico se escriben en un almacenamiento
estable en el sitio principal. El problema de este esquema es que puede
que las actualizaciones de una transacción comprometida no hayan
alcanzado el sitio de copia de seguridad cuando éste asuma el control del
procesamiento. Por tanto, puede parecer que las actualizaciones se han
perdido. Cuando se recupera el sitio principal, las actualizaciones
perdidas no se pueden mezclar directamente, dado que pueden entrar en
conflicto con actualizaciones posteriores llevadas a cabo en el sitio de
copia de seguridad. Por tanto, puede que se necesite la intervención
humana para devolver a la base de datos a un estado consistente.
- Dos
muy seguro. Las transacciones se comprometen tan pronto como sus
registros de compromiso del registro histórico se escriben en un
almacenamiento estable en el sitio principal y en el sitio de copia de
seguridad. El problema de este esquema es que el procesamiento de
transacciones no puede continuar si alguno de los puntos no está
operativo. Por tanto, la disponibilidad es realmente menor que en el caso
de un solo sitio, aunque la posibilidad de la pérdida de datos es mucho
más reducida.
- Dos
seguro. Este esquema es idéntico al esquema dos muy seguro si tanto el
sitio principal como el sitio de copia de seguridad están activos. Si
sólo está activo el sitio principal se permite que la transacción se
comprometa tan pronto como su registro de compromiso del registro
histórico se escriba en un almacenamiento estable en el sitio principal.
Este esquema proporciona mejor disponibilidad que el esquema dos muy
seguro, al tiempo que evita el problema de las transacciones perdidas
afrontado por el esquema uno seguro. Da lugar a un compromiso más lento
que el esquema uno seguro pero las ventajas generalmente superan los
inconvenientes.
Varios sistemas comerciales de disco compartido proporcionan
un nivel de tolerancia de fallos intermedio entre el de los sistemas
centralizados y el de los sistemas remotos para copias de seguridad. En estos
sistemas el fallo de una CPU no da lugar al fallo del sistema. En lugar de
ello, otra CPU asume el control y lleva a cabo la recuperación. Las acciones de
recuperación incluyen el retroceso de las transacciones que se ejecutaban en la
CPU que falló y la recuperación de los bloqueos mantenidos por dichas
transacciones. Dado que los datos se hallan en un disco compartido, no hace
falta transferir registros del registro histórico. Sin embargo, se deberían
proteger los datos contra el fallo del disco utilizando, por ejemplo, una
organización de discos RAID.
Una forma alternativa de conseguir alta disponibilidad es
usar una base de datos distribuida con los datos replicados en más de un sitio.
Son necesarias transacciones para actualizar todas las réplicas de cualquier
elemento de datos que actualicen.
Comentarios
Publicar un comentario