La propiedad de atomicidad de DBMS establece que se deben realizar todas las operaciones de transacciones o ninguna. Las modificaciones realizadas por una transacción abortada no deberían ser visibles para la base de datos y las modificaciones realizadas por una transacción confirmada deberían ser visibles.
Para lograr nuestro objetivo de atomicidad, el usuario primero debe generar información de almacenamiento estable que describa las modificaciones, sin modificar la base de datos en sí. Esta información puede ayudarnos a garantizar que todas las modificaciones realizadas por transacciones comprometidas se reflejen en la base de datos. Esta información también puede ayudarnos a garantizar que ninguna modificación realizada por una transacción abortada persista en la base de datos.
Registro y registros de registro:
el registro es una secuencia de registros que registra todas las actividades de actualización en la base de datos. En un almacenamiento estable, se mantienen registros de cada transacción. Cualquier operación que se realiza en la base de datos se registra en el registro. Antes de realizar cualquier modificación en la base de datos, se crea un registro de actualización para reflejar esa modificación.
Un registro de actualización representado como: <Ti, Xj, V1, V2> tiene estos campos:
- Identificador de transacción: Identificador único de la transacción que realizó la operación de escritura.
- Elemento de datos: Identificador único del elemento de datos escrito.
- Valor antiguo: valor del elemento de datos antes de la escritura.
- Nuevo valor: valor del elemento de datos después de la operación de escritura.
Otro tipo de registros de registro son:
- <Ti inicio> : Contiene información acerca de cuándo se inicia una transacción Ti.
- <Ti commit> : Contiene información sobre cuándo se compromete una transacción Ti.
- <Ti abort> : Contiene información de cuando una transacción Ti aborta.
Operaciones de deshacer y rehacer:
debido a que todas las modificaciones de la base de datos deben estar precedidas por la creación de un registro, el sistema tiene disponible tanto el valor anterior antes de la modificación del elemento de datos como el valor nuevo que se escribirá para el elemento de datos. Esto permite que el sistema realice operaciones de rehacer y deshacer según corresponda:
- Deshacer: el uso de un registro establece el elemento de datos especificado en el registro en el valor anterior.
- Rehacer: el uso de un registro establece el elemento de datos especificado en el registro en un nuevo valor.
La base de datos se puede modificar utilizando dos enfoques:
- Técnica de modificación diferida: si la transacción no modifica la base de datos hasta que se haya comprometido parcialmente, se dice que utiliza la técnica de modificación diferida.
- Técnica de modificación inmediata: si se produce una modificación de la base de datos mientras la transacción aún está activa, se dice que utiliza la técnica de modificación inmediata.
Recuperación mediante registros de registro:
después de que se produzca un bloqueo del sistema, el sistema consulta el registro para determinar qué transacciones se deben rehacer y cuáles se deben deshacer.
- La transacción Ti se debe deshacer si el registro contiene el registro <Ti start> pero no contiene el registro <Ti commit> ni el registro <Ti abort>.
- La transacción Ti debe volver a realizarse si el registro contiene el registro <Ti start> y el registro <Ti commit> o el registro <Ti abort>.
Uso de puntos de control:
cuando se produce un bloqueo del sistema, el usuario debe consultar el registro. En principio, es necesario buscar en todo el registro para determinar esta información. Hay dos grandes dificultades con este enfoque:
- El proceso de búsqueda lleva mucho tiempo.
- La mayoría de las transacciones que, según nuestro algoritmo, deben rehacerse ya han escrito sus actualizaciones en la base de datos. Aunque rehacerlos no causará daño, hará que la recuperación tarde más.
Para reducir este tipo de gastos generales, el usuario introduce puntos de control. Se utiliza un registro de registro de la forma <punto de control L> para representar un punto de control en el registro donde L es una lista de transacciones activas en el momento del punto de control. Cuando se agrega un registro de punto de control para registrar todas las transacciones que se han confirmado antes de este punto de control, tiene un registro de registro <Ti commit> antes del registro de punto de control. Cualquier modificación de la base de datos realizada por Ti se escribe en la base de datos antes del punto de control o como parte del propio punto de control. Por lo tanto, en el momento de la recuperación, no es necesario realizar una operación de rehacer en Ti.
Después de que se produzca un bloqueo del sistema, el sistema examina el registro para encontrar el último registro de <punto de control L>. Las operaciones de rehacer o deshacer deben aplicarse solo a las transacciones en L y a todas las transacciones que comenzaron a ejecutarse después de que el registro se escribiera en el registro. Denotemos este conjunto de transacciones como T. Las mismas reglas de deshacer y rehacer son aplicables en T como se menciona en la parte Recuperación usando registros.
Tenga en cuenta que el usuario solo debe examinar la parte del registro que comienza con el último registro del punto de control para encontrar el conjunto de transacciones T y averiguar si se produce un registro de confirmación o cancelación en el registro para cada transacción en T. Por ejemplo, considere el conjunto de transacciones {T0, T1, . . ., T100}. Suponga que el punto de control más reciente tuvo lugar durante la ejecución de las transacciones T67 y T69, mientras que T68 y todas las transacciones con subíndices inferiores a 67 se completaron antes del punto de control. Por lo tanto, solo las transacciones T67, T69, . . ., T100 debe ser considerado durante el esquema de recuperación. Cada uno de ellos debe rehacerse si se completó (es decir, si se confirmó o se abortó); de lo contrario, estaba incompleto y debe deshacerse.