Sistemas de Bases de Datos

Ricardo Valdivia Pinto

rvaldivi@uta.cl

Departamento de Computacion Facultad de Ingeniera Universidad de Tarapaca Arica, CHILE.

revp 2003 p.1/18

 Recuperacion en los SABD

La recuperacion de fallos en las transacciones equivale a una restauracion de la base de datos al estado consistente mas reciente antes del momento del fallo. Para lograr esto, el sistema debe conservar la informacion sobre los datos aplicados a los elementos de datos por diversas transacciones. Por lo general, dicha informacion se guarda en el diario del sistema.

revp 2003 p.2/18

 Recuperacion en los SABD

Una falla local afecta solo a la transaccion en la cual se presento esa falla Una falla global, en cambio, afecta a varias transacciones que se estaban efectuando en el momento de la falla. Tales fallas se dividen en dos categoras:
Fallas del sistema (por ejemplo, interrupcion del suministro electrico), las cuales afectan a todas las transacciones que se estan realizando pero no da an fsicamente a la base de datos. Las fallas de sistema n se conocen tambien como cadas suaves. Fallas de los medios de almacenamiento (por ejemplo, un aterrizaje de cabezas en el disco). Las cuales s causan da os a la base de n datos, o a una porcion de ella, y afectan al menos a las transacciones que estan utilizando esa porcion. Las fallas de los medios de almacenamiento se denominan cadas duras.

revp 2003 p.3/18

 Recuperacion en los SABD

Una estrategia de recuperacion puede resumirse en: Cuando la BD presenta una cada suave, la estrategia consiste en invertir los cambios que provocaron la inconsistencia, deshaciendo algunas operaciones y rehaciendo otras a partir de la porcion activa del diario.

Cuando la BD presenta una cada dura, el metodo de recuperacion restaurara una copia anterior de la BD y reconstruira un estado actual, rehaciendo las operaciones de las transacciones conrmadas desde el diario (considerando las porciones activas y respaldadas).

revp 2003 p.4/18

 Recuperacion en los SABD

Conceptualmente podemos distinguir dos tecnicas principales para recuperarse cadas suaves en las transacciones: 1. actualizacion diferida:
Antes de ser conrmadas todas las actualizaciones se graban en un espacio de transaccion local. Durante la conrmacion, las actualizaciones se graban primero en el diario y luego se escriben en la base de datos. Si una transaccion falla antes de llegar a su punto de conrmacion, no habra modicado en absoluto la base de datos, por lo que no es necesario DESHACER. Puede ser necesario REHACER el efecto de las operaciones de una transaccion conrmada desde el diario. La actualizacion diferida se conoce tambien como algoritmo NO-DESHACER/REHACER.

revp 2003 p.5/18

 Recuperacion en los SABD

2. actualizacion inmediata:
Es posible que algunas operaciones de una transaccion actualicen la BD antes de que la transaccion llegue a su punto de conrmacion. Sin embargo, estas operaciones casi siempre se graban en el diario en disco mediante escritura forzada antes de aplicarse a la base de datos. Si una transaccion falla despues de grabar algunos cambios en la base de datos, pero antes de llegar a su punto de conrmacion, sera preciso deshacer la transaccion. La actualizacion diferida se conoce tambien como algoritmo DESHACER/REHACER. Una variacion del algoritmo en la que todas las actualizaciones se graban en la base de datos antes que se conrme una transaccion solo requiere deshacer, por lo que se conoce como algoritmo DESHACER/NO-REHACER.

revp 2003 p.6/18

Movimiento de bloques de disco a memoria ca che

El proceso de recuperacion esta ntimamente ligado a las funciones del SO, en particular, al uso de buffers y al mantener paginas de disco en memoria principal Una o mas paginas se colocan en memoria principal y luego se actualizan en la memoria antes de ser escritos otra vez en disco. Cada buffer en cache tiene asociado un bit de ensuciado (dirty bit ) para indicar si el buffer ha sido (1) o no (0) modicado. Tan pronto como se reemplazan los contenidos del buffer de la cache, deben ser reescritos en la correspondiente pagina en disco solo si el bit de ensuciado es 1.

revp 2003 p.7/18

Movimiento de bloques de disco a memoria ca che

Se puede emplear dos estrategias cuando se lleva un buffer modicado a disco:
1. La actualizacion en el lugar, escribe el buffer en el misma ubicacion original en el disco, sobrescribiendo el valor antiguo de cualquier elemento de datos modicado en el disco. El sombreado, escribe un buffer actualizado en una ubicacion distinta en disco, lo que hace posible mantener multiples versiones del elemento de datos.

2.

En general, el valor antiguo del elemento de datos antes de la actualizacion se denomina BFIM (Before Image), y el nuevo valor despues de la actualizacion se denomina AFIM (After Image).

revp 2003 p.8/18

Escritura anticipada en el diario

Cuando se utiliza la actualizacion en el lugar, es necesario utilizar un diario para la recuperacion. En este caso, el mecanismo de recuperacion debe asegurarse que la BFIM del elemento de datos se grabe en la entrada del diario apropiada y que dicha entrada se lleve a disco antes que la BFIM se sobrescriba con la AFIM en la BD en disco. A este proceso se le conoce como escritura anticipada en el diario.

revp 2003 p.9/18

Escritura anticipada en el diario

La entrada de un diario debe establecer las diferencias entre los dos tipos de informacion que puede tener una entrada del diario para una operacion de escritura. 1. la informacion necesaria para DESHACER. Las entradas de diario del tipo DESHACER incluyen la BFIM del elemento, ya que son necesarias para deshacer el efecto de la operacion a partir del diario. 2. la informacion necesaria para REHACER. Las entradas del diario del tipo REHACER incluye la AFIM del elemento, ya que se requiere rehacer el efecto de la operacion a partir del diario.

revp 2003 p.10/18

Escritura anticipada en el diario

La terminologa de recuperacion estandar del SABD incluye los terminos robar/no-robar y forzar/no-forzar, que especican cuando una pagina de la base de datos puede escribirse a disco desde la cache:
1. La estrategia no-robar establece que un buffer de la cache actualizada por una transaccion no puede escribirse a disco antes de la conrmacion de dicha transaccion. Si el protocolo permite escribir un buffer actualizado antes de la conrmacion de la transaccion, se le llama estrategia robar. 2. Si todas las paginas actualizadas por una transaccion son escritas inmediatamente a disco cuando se conrma la transaccion, se le llama estrategia forzar. A lo contrario se le llama estrategia no-forzar. Los SABD tpicos emplean una estrategia robar/no-forzar.

revp 2003 p.11/18

Escritura anticipada en el diario

Consideremos el protocolo WAL (Write-Ahead Logging) de escritura anticipada en el diario, para un algoritmo DESHACER/REHACER. 1. La BFIM de un elemento no se puede sobrescribir con la AFIM en la BD es disco hasta que se haya forzado la escritura en disco de todos los registros del diario del tipo DESHACER de la transaccion actualizadora. La operacion conrmar de una transaccion no se puede completar hasta que se haya forzado la escritura en disco de todos los registros del diario del tipo REHACER y del tipo DESHACER de esa transaccion.

2.

revp 2003 p.12/18

Puntos de Control
Periodicamente se escribe en el diario un registro [checkpoint] justo en el momento en que el sistema escribe en disco todos los buffers del SABD que han sido modicados en la BD. Como consecuencia de esto, todas la transacciones que tienen sus entradas [commit,T] en el diario antes de una entrada [checkpoint] no necesitan rehacer sus operaciones. El administrador de transacciones de un SABD debe decidir en que intervalos establecer un punto de control.

revp 2003 p.13/18

Puntos de Control
Establecer un punto de control consiste en las siguientes acciones:
1. 2. 3. 4. Suspension temporal de las transacciones en ejecucion. Escritura forzada de los buffers de memoria principal a disco. Escribir un registro [checkpoint] al diario y escritura forzada del diario al disco. Reactivacion de las transacciones en ejecucion.

Como consecuencia del paso 2, un registro del punto de control en el diario puede incluir informacion adicional, como una lista de identicadores de las transacciones activas y para cada transaccion activa, las ubicaciones de los registros inicial y mas reciente en el diario.

revp 2003 p.14/18

 Ejemplo de Recuperacion

revp 2003 p.15/18

 Recuperacion DESHACER/REHACER
1. Usar dos listas de transacciones mantenidas por el sistema: las transacciones conrmadas desde el ultimo punto de control y las transacciones activas. Deshacer todas las operaciones write item de las transacciones activas. Las transacciones deberan deshacerse en el orden opuesto a aquel en que se escribieron en el diario. 3. Rehacer todas las operaciones write item de las transacciones conrmadas a partir del diario, en el orden en que se escribieron en este.

2.

El paso 3. es mas eciente empezando por el nal del diario y rehaciendo solo la ultima actualizacion de cada elemento X.

revp 2003 p.16/18

 Algoritmo de Recuperacion ARIES

ARIES es un algoritmo de recuperacion utilizado en SABD. ARIES utiliza una estrategia robar/no forzar para la escritura y se basa en tres conceptos:
1. 2. 3. escritura anticipada en el diario repeticion de la historia durante el rehacer anotacion en el diario de las modicaciones durante el deshacer.

La repeticion de la historia signica que ARIES volvera a trazar todas las acciones del sistema de bases de datos antes de la cada para reconstruir el estado de la base de datos cuando ocurrio la cada. La anotacion de modicaciones en el diario durante el deshacer, evitara que ARIES repita las operaciones de deshacer realizadas si se produce un fallo durante la recuperacion que oblige a reiniciar el proceso de recuperacion

revp 2003 p.17/18

SABS Comerciales
Transaction Logs

by Peter Gulutzan

Write-Ahead Logging (WAL) has won the popularity contest. Early DBMSs (System R a SQL/DS) used a different protocol, some current DBMSs (PostgreSQL and MySQL) are cent converts, and one DBMS (InterBase) would rather ght than switch. But among t Big Three its WAL all the way:

Who Uses WALs? DBMS IBM Microsoft Oracle Uses Write-Ahead Logs Yes Yes Yes Claims To Use ARIES? Yes Yes No

Microsoft SQL Server 2000 and IBM DB2 7.2 specically use the ARIES write-ahead l algorithms; Oracle9i uses something quite similar . . .

revp 2003 p.18/18