En informática , Algorithms for Recovery and Isolation Exploiting Semantics , o ARIES , es un algoritmo de recuperación diseñado para funcionar con un enfoque de base de datos sin forzar y robar; lo utilizan IBM Db2 , Microsoft SQL Server y muchos otros sistemas de bases de datos . [1] El Dr. C. Mohan, miembro de IBM, es el inventor principal de la familia de algoritmos ARIES. [2]
Tres principios fundamentales se encuentran detrás de ARIES:
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 el denominado "almacenamiento estable", es decir, un medio de almacenamiento que se supone que sobrevive a fallos de hardware y caídas.
Para recopilar la información necesaria para los registros, se deben mantener dos estructuras de datos : la tabla de páginas sucias (DPT) y la tabla de transacciones (TT).
La tabla de páginas sucias mantiene un registro de todas las páginas que se han modificado y que aún no se han escrito en el disco, y el primer número de secuencia que provocó que esa página se volviera sucia. La tabla de transacciones contiene todas las transacciones que se están ejecutando actualmente y el número de secuencia de la última entrada de registro que crearon.
Creamos registros de registro del tipo (Número de secuencia, ID de transacción, ID de página, Rehacer, Deshacer, Número de secuencia anterior). Los campos Rehacer y Deshacer guardan información sobre los cambios que guarda este registro de registro y cómo deshacerlos. El Número de secuencia anterior es una referencia al registro de registro anterior que se creó para esta transacción. En el caso de una transacción cancelada, 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 el primer tipo de entrada "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 mientras se deshacen las acciones de una transacción abortada, se escribe un tipo especial de registro, el Registro de compensación (CLR), para registrar 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 funciona en tres fases. La primera fase, Análisis, calcula toda la información necesaria del archivo de registro. La fase Rehacer restaura la base de datos al estado exacto en el que se produjo el fallo, incluidos todos los cambios de las transacciones no confirmadas que se estaban ejecutando en ese momento. La fase Deshacer deshace todos los cambios no confirmados y deja la base de datos en un estado coherente.
Durante la fase de análisis restauramos el DPT y el TT como estaban en el momento del accidente.
Recorremos el archivo de registro (desde el principio o el último punto de control) y agregamos todas las transacciones para las que encontramos entradas de inicio de transacción al TT. Siempre que se encuentra una entrada de registro final, se elimina la transacción correspondiente. También se mantiene el último número de secuencia de cada transacción.
Durante la misma ejecución, también completamos la tabla de páginas sucias agregando una nueva entrada cada vez que encontramos una página que se modificó y aún no está en la DPT. Sin embargo, esto solo calcula un superconjunto de todas las páginas sucias en el momento del bloqueo, ya que no verificamos el archivo de base de datos real para ver si la página se volvió a escribir en el almacenamiento.
A partir del DPT, podemos calcular el número de secuencia mínimo de una página sucia. A partir de ahí, tenemos que empezar a repetir las acciones hasta el fallo, en caso de que no se hayan conservado ya.
Al recorrer el archivo de registro, verificamos para cada entrada si la página modificada P en la entrada existe en la DPT. Si no existe, entonces no tenemos que preocuparnos por rehacer esta entrada ya que los datos persisten en el disco. Si la página P existe en la tabla DPT, entonces vemos si el Número de secuencia en la DPT es menor que el Número de secuencia del registro de registro (es decir, si el cambio en el registro es más reciente que la última versión que se persistió). Si no lo es, entonces no rehacemos la entrada ya que el cambio ya está allí. Si lo es, recuperamos la página del almacenamiento de la base de datos y verificamos el Número de secuencia almacenado en la página con el Número de secuencia en el registro de registro. Si el primero es menor que el segundo, la página debe escribirse en el disco. Esa 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. También es importante para la recuperación de un fallo durante la fase de rehacer, ya que la acción de rehacer no se aplica dos veces a la misma página.
Después de la fase de rehacer, la base de datos refleja el estado exacto en el que se produjo el fallo. Sin embargo, los cambios de las transacciones no confirmadas deben deshacerse para restaurar la base de datos a un estado consistente.
Para ello, recorremos el registro en sentido inverso para cada transacción en la TT (esas ejecuciones, por supuesto, se pueden combinar en una sola) utilizando los campos de Número de secuencia anterior en los registros. Para cada registro, deshacemos los cambios (utilizando la información en el campo Deshacer) y escribimos un registro de 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 poco común como se podría pensar, ya que es posible que la fase de recuperación tarde bastante tiempo. Los registros de compensación se leen durante la fase de análisis y se rehacen durante la fase de rehacer.
Para evitar volver a escanear todo el archivo de registro durante la fase de análisis, es recomendable guardar el DPT y el TT periódicamente en el archivo de registro, formando un punto de control. En lugar de tener que recorrer todo el archivo, solo es necesario recorrerlo hacia atrás hasta encontrar un punto de control. A partir de ese punto, es posible restaurar el DPT y el TT como estaban en el momento del bloqueo leyendo el archivo de registro hacia adelante nuevamente. Luego es posible continuar como de costumbre con Rehacer y Deshacer.
La forma más sencilla de crear puntos de control consiste en 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 evita esto escribiendo dos registros de registro. Un registro de inicio de registro difuso aquí y, después de preparar los datos del punto de control, el punto de control real. Entre los dos registros se pueden crear otros registros de registro. Durante la recuperación, es necesario encontrar ambos registros para obtener un punto de control válido.