Tecnicas De Recuperacion De Bd

Técnicas de recuperación

En este capítulo estudiaremos algunas de las técnicas que pueden servir para la recuperación de fallos en las bases de datos. Ya examinamos en la Sección 19.1.4 las diferentes causas de fallos, como caídas del sistema y errores en las transacciones. También hemos explicado ya, en la Sección 19.2 muchos de los conceptos empleados por los procesos de recuperación, como son el diario del sistema y los puntos de confirmación.

Empezamos la Sección 21.1 con una introducción sobre los procedimientos de recuperación típicos y la clasificación de algoritmos de recuperación, y después estudiaremos algunos conceptos de recuperación, incluyendo la escritura anticipada en el diario, las actualizaciones en-el-lugar frente a las actualizaciones sombra, y el proceso de restaurar (deshacer) el efecto de una transacción incompleta o frustrada. En la Sección 21.2, presentaremos técnicas de recuperación basadas en la actualización diferida, conocida también como técnica NO-DESHACER/REHACER. En la Sección 21.3, analizaremos técnicas de recuperación basadas en la actualización inmediata; éstas incluyen los algoritmos DESHACER/REHACER y DESHACER/NO-REHACER. En la Sección 21.4 trataremos la técnica conocida como sombreado o paginación en la sombra, que puede ser clasificada como un algoritmo NO-DESHACER/NO-REHACER. En la Sección 21.5 presentaremos un ejemplo de un esquema de recuperación de un SGBD práctico, llamado ARIES. En la Sección 21.6 haremos un breve análisis de la recuperación en bases de datos múltiples. Por último, analizaremos las técnicas de recuperación frente a fallos catastróficos en la Sección 21.7. Nuestra intención es describir conceptualmente varias estrategias diferentes para la recuperación. Si el lector desea descripciones de las características de recuperación en sistemas específicos, deberá consultar las notas bibliográficas y los manuales de usuario de esos sistemas. A menudo las técnicas de recuperación están entrelazadas con los mecanismos de control de concurrencia. Ciertas técnicas de recuperación funcionan mejor con métodos específicos de control de concurrencia.

Intentaremos analizar los conceptos de recuperación independientemente de los mecanismos de control de concurrencia, pero trataremos las circunstancias bajo las cuales un mecanismo de recuperación determinado funciona mejor con un cierto protocolo de control de concurrencia.

2 1 .1 . Conceptos de recuperación

21.1.1. Introducción a la recuperación y clasificación de algoritmos de recuperación

La recuperación de fallos en las transacciones casi siempre equivale a una restauración de la base de datos al estado consistente más reciente antes del momento-del fallo. Para lograr esto, el sistema y debe conservar información sobre cambios aplicados a los elementos de datos por las diversas transacciones. Por lo general, dicha información se guarda en el diario del sistema. Una estrategia de recuperación típica podría resumirse informalmente como sigue:

l. Si hay daños extensos en una amplia porción de la base de datos debido a un fallo catastrófico, como un fallo del disco, el método de recuperación restaurará una copia anterior de la base de datos que se habría respaldado en almacenamiento de archivo (generalmente encinta) y reconstruirá un estado más actual, volviendo a aplicar o rehaciendo las operaciones de las transacciones confirmadas desde el diario respaldado hasta el momento del fallo.

2. Cuando la base de datos no presenta daños físicos pero se ha vuelto inconsistente debido a fallos no catastróficos de los tipos 1 a 4 de la Sección 19.1.4, la estrategia consiste en invertir los cambios que provocaron la inconsistencia, deshaciendo algunas operaciones.

También puede ser necesario rehacer algunas operaciones a fin de restaurar un estado consistente de la base de datos, como veremos más adelante. En este caso, no necesitamos la copia archivada de la base de datos completa. Mejor dicho, las entradas mantenidas en el diario del sistema on-line se consultan durante la recuperación.

Conceptualmente, podemos distinguir dos técnicas principales para recuperarse de fallos no-catastróficos en las transacciones: (1) actualización diferida y (2) actualización inmediata. Las técnicas de actualización diferida no actualizan físicamente la base de datos en disco hasta después de que una transacción llega a su punto de confirmación; en ese momento, las actualizaciones se graban en la base de datos. Antes de ser confirmadas, todas las actualizaciones se graban en el espacio de transacciones local (o bufers). Durante la confirmación, las actualizaciones se graban primero definitivamente en el diario y luego se escriben en la base de datos. Si una transacción falla antes de llegar a su punto de confirmación, no habrá modificado en absoluto la base de datos, por lo que no es necesario DESHACER. Puede ser necesario REHACER el efecto de las operaciones de una transacción confirmada desde el diario, ya que es posible que su efecto todavía no se haya grabado en la base de datos. Por ello, la actualización diferida se conoce también como algoritmo NO-DESHACER/REHACER.

En las técnicas de actualización inmediata, es posible que algunas operaciones de una transacción actualicen la base de datos antes de "que la transacción llegue a su punto de confirmación. Sin embargo, estas operaciones casi siempre se graban en el diario en disco mediante escritura forzada antes de aplicarse a la base de datos, lo que hace posible la recuperación. Si una transacción falla después de grabar algunos cambios en la base de datos pero antes de llegar a su punto de confirmación, será preciso anular el efecto de sus operaciones sobre la base de datos; es decir, la transacción deberá deshacerse.

En el caso general de actualización inmediata, puede ser preciso deshacer y rehacer durante la recuperación. Esta técnica, conocida como algoritmo DESHACER/REHACER, requiere ambas operaciones y se usa más frecuentemente en la práctica. Una variación del algoritmo en la que todas las actualizaciones se graban en la base de datos antes de que se confirme una transacción.

21.1.2. Movimiento de bloques de disco a la memoria caché

El proceso de recuperación a menudo está íntimamente ligado a las funciones del sistema operativo, en particular, al uso de bufers y a mantener páginas de disco en la memoria principal (caching).

Por lo general, una o más páginas de disco que contienen los elementos de información que han de actualizarse se colocan en bufers de la memoria principal y luego se actualizan en la memoria antes de ser escritos otra vez en el disco. Este mantenimiento de páginas de disco en la memoria es tradicionalmente una función del sistema operativo, pero debido a su importancia en la eficiencia de los procedimientos de recuperación, lo maneja el SGBD llamando a rutinas de bajo nivel del sistema operativo.

En general, es conveniente considerar la recuperación en términos de páginas de disco de la base de datos (bloques). Por lo general, hay un grupo de bufers dentro de la memoria, llamado caché del SGBD, que se mantiene bajo control del SGBD con el fin de almacenar estos bufers. Se utiliza un directorio de la caché para seguir la pista a los elementos de la base de datos que están en los bufers. Éste puede ser una tabla de entradas dirección de página de disco, ubicación del búfer. Cuando el SGBD necesita hacer algo sobre un elemento, primero examina el directorio de la caché para determinar si el elemento contenido en la página de disco está en la cache. Si no es así, entonces el elemento debe ser localizado en el disco, y ese copian las páginas de disco apropiadas en la caché. Puede ser necesario reemplazar (o limpiar) algunos de los bufers de la caché para disponer de espacio para el nuevo elemento. Para seleccionar los bufers que han de ser reemplazados se pueden utilizar algunas estrategias de reemplazo de páginas provenientes de los sistemas operativos, como la «menos recientemente usado» (LRU) o la «primero en entrar, primero en salir» (FIFO).

Cada búfer en la cache tiene asociado un bit de ensuciado (dirty bit) que se puede incluir en la entrada del directorio para indicar si el búfer ha sido o no modificado. Cuando se lee por primera vez una página desde el disco de la base de datos al búfer de la cache’, el directorio de la caché se actualiza con la nueva dirección de la página del disco y se asigna O (cero) al bit de ensuciado. Tan pronto como se reemplazan (evacuan) los contenidos del búfer de la caché, deben ser escritos en la correspondiente página del disco solo si el bit de ensuciado es 1. También es necesario otro bit, llamado bit de reserva (una página en la cache está en estado de reserva, cuando este bit vale (uno) si aún no se puede escribir en disco).

Se pueden emplear dos estrategias principales cuando se evacua un búfer modificado hacia disco. La primera estrategia, conocida como actualización en el lugar, escribe el búfer en la misma ubicación original del disco, sobre escribiendo el valor antiguo de cualquier elemento de datos modificado en el disco. Con ello, se mantiene una única copia de cada bloque de disco de la base de datos. La segunda estrategia, conocida como sombreado, escribe un búfer actualizado en una ubicación diferente del disco, lo que hace posible mantener múltiples versiones de elementos de datos.

En general, el valor antiguo del elemento de datos antes de la actualización se denomina imagen «antes» (BFIM, del inglés BeFore IMage), y el nuevo valor después de la actualización

...