Algoritmos para la recuperación y el aislamiento que explotan la semántica

En informática , ARIES ( Algoritmos para la Recuperación y el Aislamiento mediante la Explotación Semántica ) es un algoritmo de recuperación diseñado para funcionar con un enfoque de robo de base de datos sin forzar la recuperación; es utilizado por IBM Db2 , Microsoft SQL Server y muchos otros sistemas de bases de datos . ^{[ 1 ]} Chandrasekaran Mohan, miembro de IBM , es el principal inventor de la familia de algoritmos ARIES. ^{[ 2 ]}

Detrás de ARIES subyacen tres principios fundamentales:

• Registro de escritura anticipada : Cualquier cambio en un objeto se registra primero en el registro , y este debe escribirse en un almacenamiento permanente antes de que los cambios en el objeto se escriban en el disco.
• Repetición del historial durante la recuperación: Al reiniciar tras un fallo, ARIES reconstruye las acciones de la base de datos previas al fallo y restaura el sistema al estado exacto en el que se encontraba antes del fallo. A continuación, deshace las transacciones que seguían activas en el momento del fallo.
• Registro de cambios durante la operación de deshacer: Los cambios realizados en la base de datos mientras se deshacen las transacciones se registran para garantizar que dicha acción no se repita en caso de reinicios repetidos.

El algoritmo ARIES se basa en el registro de todas las operaciones de la base de datos con números de secuencia ascendentes. Normalmente, el archivo de registro resultante se almacena en un medio de almacenamiento estable, es decir, un medio de almacenamiento que se supone que sobrevivirá a fallos del sistema y del hardware.

Para recopilar la información necesaria para los registros, se deben mantener dos estructuras de datos : la tabla de páginas modificadas (DPT) y la tabla de transacciones (TT).

La tabla de páginas modificadas registra todas las páginas que se han modificado pero que aún no se han escrito en el disco, así como el primer número de secuencia que provocó que esa página se marcara como modificada. La tabla de transacciones contiene todas las transacciones que se están ejecutando y el número de secuencia de la última entrada de registro que crearon.

Creamos registros de transacciones con el formato (Número de secuencia, ID de transacción, ID de página, Rehacer, Deshacer, Número de secuencia anterior). Los campos Rehacer y Deshacer contienen información sobre los cambios guardados en este registro y cómo deshacerlos. El Número de secuencia anterior hace referencia al registro anterior creado para esta transacción. En caso de una transacción abortada, es posible recorrer el archivo de registro en orden inverso utilizando los Números de secuencia anteriores, deshaciendo todas las acciones realizadas dentro de la transacción específica.

Cada transacción comienza implícitamente con la primera entrada de tipo "Actualización" para el ID de transacción dado, y se confirma con la entrada "Fin del registro" (EOL) para la transacción.

Durante una recuperación o al deshacer las acciones de una transacción abortada, se escribe un registro especial, el Registro de Compensación (CLR), para dejar constancia de que la acción ya se ha deshecho. Los CLR tienen el formato (Número de secuencia, ID de transacción, ID de página, Rehacer, Número de secuencia anterior, Número de secuencia de deshacer siguiente). El campo Rehacer contiene la aplicación del campo Deshacer de la acción revertida, y el campo Deshacer se omite porque el CLR nunca se revierte.

La recuperación se realiza en tres fases. La primera fase, Análisis, calcula toda la información necesaria a partir del archivo de registro. La fase Rehacer restaura la base de datos al estado exacto en el que se encontraba en el momento del fallo, incluyendo todos los cambios de las transacciones no confirmadas que estaban en ejecución. La fase Deshacer revierte todos los cambios no confirmados, dejando la base de datos en un estado coherente.

Durante la fase de análisis, restauramos el DPT y el TT a los valores que tenían en el momento del accidente.

Recorremos el archivo de registro (desde el principio o el último punto de control) y añadimos a la tabla de transacciones (TT) todas las transacciones para las que encontramos entradas de "Inicio de transacción". Cuando se encuentra una entrada de "Fin de registro", se elimina la transacción correspondiente. También se conserva el último número de secuencia de cada transacción.

Durante la misma ejecución, también llenamos la tabla de páginas modificadas agregando una nueva entrada cada vez que encontramos una página modificada que aún no está en la tabla de páginas modificadas (DPT). Sin embargo, esto solo calcula un superconjunto de todas las páginas modificadas en el momento del fallo, ya que no verificamos si el archivo de base de datos real se escribió de nuevo en el almacenamiento.

A partir del DPT, podemos calcular el número de secuencia mínimo de una página modificada. A partir de ahí, debemos comenzar a rehacer las acciones hasta que se produzca el fallo, en caso de que no se hayan guardado previamente.

Al recorrer el archivo de registro, verificamos para cada entrada si la página modificada P existe en la tabla DPT. Si no existe, no es necesario rehacer la entrada, ya que los datos persisten en el disco. Si la página P existe en la tabla DPT, verificamos si el número de secuencia en la DPT es menor que el número de secuencia del registro (es decir, si el cambio en el registro es más reciente que la última versión persistida). Si no lo es, no rehacemos la entrada, ya que el cambio ya está presente. Si lo es, recuperamos la página del almacenamiento de la base de datos y comparamos el número de secuencia almacenado en la página con el número de secuencia del registro. Si el primero es menor que el segundo, la página debe escribirse en el disco. Esta verificación es necesaria porque la DPT recuperada es solo un superconjunto conservador de las páginas que realmente necesitan que se vuelvan a aplicar los cambios. Por último, cuando todas las comprobaciones anteriores hayan finalizado y hayan fallado, volvemos a aplicar la acción de rehacer y almacenamos el nuevo número de secuencia en la página. Esto también es importante para la recuperación ante un fallo durante la fase de rehacer, ya que la acción de rehacer no se aplica dos veces a la misma página.

Tras la fase de rehacer, la base de datos refleja el estado exacto que tenía en el momento del fallo. Sin embargo, es necesario deshacer los cambios de las transacciones no confirmadas para restaurar la base de datos a un estado coherente.

Para ello, recorremos el registro de cada transacción en la TT en sentido inverso (estas ejecuciones pueden combinarse en una sola) utilizando los campos de Número de Secuencia Anterior. Para cada registro, deshacemos los cambios (utilizando la información del campo Deshacer) y escribimos un registro de compensación en el archivo de registro. Si encontramos un registro de Inicio de Transacción, escribimos un registro de Fin de Registro para esa transacción.

Los registros de compensación permiten recuperarse de un fallo que se produce durante la fase de recuperación. Esto no es tan infrecuente como podría pensarse, ya que la fase de recuperación puede ser bastante larga. Los registros de compensación se leen durante la fase de análisis y se rehacen durante la fase de rehacer.

Para evitar tener que volver a escanear todo el archivo de registro durante la fase de análisis, es recomendable guardar periódicamente el DPT y el TT en el archivo, creando así un punto de control. En lugar de recorrer todo el archivo, basta con retroceder hasta encontrar un punto de control. A partir de ahí, es posible restaurar el DPT y el TT a su estado original en el momento del fallo, leyendo el archivo de registro hacia adelante. A continuación, se puede proceder como de costumbre con las funciones de rehacer y deshacer.

El método ingenuo para crear puntos de control implica bloquear toda la base de datos para evitar cambios en el DPT y el TT durante la creación del punto de control. El registro difuso lo evita escribiendo dos registros: uno que comienza con el inicio del registro difuso y, tras preparar los datos del punto de control, el punto de control propiamente dicho. Entre ambos registros se pueden crear otros. Durante la recuperación, es necesario encontrar ambos registros para obtener un punto de control válido.

• Impacto de la familia de algoritmos de bloqueo y recuperación ARIES - C. Mohan , archivado del original el 19 de agosto de 2012 , consultado el 18 de septiembre de 2013.