Modos de mejorar la recuperación

Una de las principales leyes de Oracle es que nunca se puede perder una transacción confirmada (commit) y nunca mostrar una transacción no confirmada.

Si una base de datos esta corrompida, Oracle realizará la recuperación de la instancia para borrar las corrupciones, realizando los siguientes pasos:

• Deshabilitará cualquier transacción confirmada que no había sido guardada en los ficheros de datos en el momento del fallo.

• Y echará atrás cualquier transacción no confirmada. Esta recuperación es totalmente automática y no se puede parar ni aunque se quiera ya que para poder acceder a la base de datos y realizar alguna operación es necesario que la recuperación se haya realizado y terminado.

Mecanismo de recuperación de una instancia.

La recuperación de la instancia es la utilización de los contenidos de los ficheros Online Log para reconstruir el Cache Buffer de la Base de Datos al estado anterior al fallo.

La fase de la recuperación conocida como roll forward restaura todos los cambios (cambios de los bloques de datos y cambios de los bloques undo) para transacciónes confirmadas y no confirmadas.

Cada registro de redo tiene la información necesaria para reconstruir los cambios un bloque de dirección y el nuevo valor.

Durante el roll forward, cada registro redo es leído, y el bloque apropiado es cargado del fichero de datos en el Cache Buffer de la Base de Datos y el cambio es aplicado. Entonces el bloque es escrito al disco.

Una vez que el roll forward es completado, es como si el fallo del sistema nunca hubiera ocurrido. Pero en este punto, habrá transacciónes no confirmadas en la base de datos y Oracle hará un rollback sobre estas transacciónes.

La recuperación de la instancia es automática al publicar la orden STARTUP. El SMON para abrir una base de datos primero leerá el controlfile cuando pasa a estado montado. Entonces en la transición del estado montado a open, el SMON comprueba los encabezamientos de los ficheros de todos los ficheros de datos y el Online Redo Log Files. En este punto, si hubiese una instancia fallida los encabezamientos de archivo estarán desincronizados. Entonces SMON entrará en estado de recuperación de la instancia, y la base de datos solo será abierta después de que el roll forward se termine.

Mejora de recuperación de la instancia.

La recuperación de una instancia puede llevar un tiempo para hacer el roll forward antes de que se pueda abrir la base de datos. Este tiempo depende de:

• Cuanto redo hay que leer.

• Cuantas operaciones de lectura y escritura serán necesarias en los ficheros de datos cuando el redo sea aplicado.

Estos dos factores pueden ser controlados por checkpoints ya que su función es grabar los datos del Caché Buffer a los ficheros de datos y los datos del Log Buffer al Online Redo Log File. De esta forma se garantiza que desde un tiempo en concreto, todos los cambios de datos hechos hasta un SCN (SYSTEM CHANGE NUMBER), han sido escritos a disco.

Si una instancia falla, solo será necesario para el SMON volver a utilizar el redo generado desde el último checkpoint ya que todos los cambios confirmados o no confirmados que se hayan realizado antes del checkpoint están ya en los ficheros de datos, por lo que no hay ninguna necesidad de usar el redo para reconstruir las transacciónes confirmadas antes del checkpoint.

Esto también, pasa con los cambios hechos por transacciónes no confirmadas antes del checkpoint ya que también están en los archivos de datos, por lo que no hay ninguna necesidad de reconstruir datos undo antes del checkpoint.

Por lo tanto hay que entender que:

• Contra más actual sea el checkpoint más rápido será la recuperación de la instancia, pero realizar un chepkpoint requiere que el proceso DBWn debe escribir los bloques cambiados al disco, lo que provocará excesivas operaciones de entrada y salida con la consecuente bajada de rendimiento del sistema.

• Contra más lejano sea el checkpoint mas tiempos llevará la recuperación del sistema, y que el proceso SMON tendrá que tratar cientos de megas de datos redo y millones de operaciones de entrada y salida en el fichero de datos, el MTTR después del fallo de la instancia puede tardar horas.

El parámetro FAST_START_MTTR_TARGET especifica el tiempo deseado de recuperación al levantar la BD cuando ésta no se ha cerrado ordenadamente. Cuando fijamos este parámetro, la BD empieza a ejecutar checkpoint incrementales periódicamente para que la recuperación antes de una caída de BD no supere el tiempo establecido en FAST_START_MTTR_TARGET.

El Database Control también provee de un consejero MTTR, que da una idea de cuánto tiempo tardará una recuperación. Esta información también está en V$INSTANCE_RECOVERY.<