Introducción al Archive Log

El archivado de los redo log, es un concepto básico que debemos conocer para administrar cualquier base de datos Oracle. Para ello existen dos opciones, tener la base en modo NOARCHIVELOG, que es la que está por defecto cuando se crea una base de datos, o en modo ARCHIVELOG, que, como veremos a continuación, es el más recomendado cuando tenemos la base de datos en producción. MODO NOARCHIVELOG: El modo NOARCHIVELOG indica que esta desactivado el archivado de los redo log, Oracle reutiliza de forma circular (LGWR es el proceso encargado de esta tarea) los redo log y en este modo los reutilizará sin realizar el archivado. En NOARCHIVELOG tendremos que realizar nuestros backup en frio (cold), es decir, con la base datos parada, y si tenemos que realizar un RESTORE perderemos todos los cambios que se hayan producido en ella desde que realizo el último backup. La base de datos en modo NOARCHIVELOG se debería utilizar solo para entornos donde no sea importante la pérdida de datos en caso de un RESTORE, por ejemplo en entornos de desarrollo o en entornos de pruebas, en entornos de producción es imprescindible que nuestras bases de datos estén ejecutándose en modo ARCHIVELOG.

Veamos este proceso de forma gráfica, supongamos que tenemos dos ficheros de la base de datos, Fichero 1 y Fichero 2:

• Y hacemos un backup, el lunes a las 6 am, para tener una copia del contenido de esos ficheros, antes que empiece la jornada laboral del lunes. De esta manera sabemos que tenemos nuestra base de datos salvaguardada, hasta el lunes a las 6 am.

• Cuando se vuelve a arrancar la base de datos, las transacciónes que se realizan, se van guardando en los archivos redo log, que a la vez que se van llenado, van pasando de uno a otro en anillo. Una vez llegado al último redo log, vuelve a guardar las transacciónes en el primero de ellos, sobrescribiéndolo.

Por ejemplo: en el primer redo log se van a guardar las transacciónes desde las 6 am hasta las 9 am, intervalo en cual, digamos se va a llenar el archivo, y va a comenzar el proceso que ya conocemos. Se produce un SWITCH, pasando a guardar los datos en el siguiente redo log (en nuestro ejemplo redo log 2), a la vez que se crea un CHECKPOINT y sincroniza los la información del redo log 1 con el fichero de datos.

Después, se irán guardando las transacciónes en el redo log 2. Una vez que se llene, por ejemplo, a la 1 pm, vuelve a comenzar el proceso de SWITCH hacia el redo log 3, a le vez que sincroniza la información que tiene el redo log 2, con los ficheros de datos.

En el redo log 3, debido quizá a una suba en las operaciones en la base de datos, solo va a contener las transacciónes realzadas en el intervalo de una hora, momento en el cual se va a llenar el archivo y entonces es cuando se hace un SWITCH al redo log 1.

Entonces Oracle comienza a sobrescribir el redo log 1 con las transacciónes a partir de las 2 pm, haciendo que se pierda el contenido que tenia el redo log 1 en cuanto a las transacciónes realizadas desde las 6 am hasta las 9 am. Cosa que no debiera importar mucho, toda vez que cuando se hizo el SWITCH al redo log 2, esta información se sincronizó con los ficheros de datos. O sea, esta información que se va a perder cuando comiencen las transacciónes de las 2 pm, está contenida de antemano con los ficheros de datos.

¿Qué pasaria si se dañan por alguna razón los ficheros de datos? Pues, como tenemos la base de datos en modo NOARCHIVELOG, perderíamos toda la información que se haya realizado a partir del último backup, en nuestro caso, solo podríamos recuperar la base de datos hasta como se encontraba a las 6 de la mañana del lunes. No importa incluso que aún los redo log 2 y 3 contengan las transacciónes a partir de las 9 am, como quiera que ya no tenemos las transacciónes del intervalo de 6 a 9 de la mañana, la base de datos solo se podría restaurar correctamente al punto como se encontraba el lunes a las 6 am, justo en el momento que hicimos el backup.

Por esta razón es que siempre que tengamos una base de datos en producción, debe estar en modo ARCHIVELOG. De lo contrario, pudiera pasar que se pierda información al dañarse algunos ficheros de la base de datos, como recién vimos. Es cierto que hay formas de evitarlo, pero básicamente, si la base de datos está en modo NOARCHIVELOG, puede correr peligro la integridad de los datos al dañarse uno o varios ficheros de la misma. En resumen, en modo NOARCHIVELOG, no se garantiza la restauración completa de la base de datos en caso de dañarse los ficheros de la misma. Sólo se puede restaurar hasta el punto donde hizo el backup. MODO ARCHIVELOG: El modo ARCHIVELOG hace que Oracle realice un archivado (ARCO proceso encargado de realizarlo) del grupo de redo log antes de que el LGWR lo reutilice, con la base de datos en modo ARCHIVELOG podemos hacer backups en caliente (hot), es decir, con la base de datos arrancada, lo que nos permitirá realizar RESTORES de la base de datos sin pérdida de datos.

Cuando tenemos la base de datos en modo ARCHIVELOG, el proceso de los redo log es el mismo, o sea, una vez se llena un archivo del redo log, se hace un SWITCH al siguiente, a la vez que se sincroniza todo lo que hay en memoria con el fichero de datos. De esta forma, todo lo que tenemos en el redo log 1, lo tendremos también en el fichero de datos. El mismo proceso se repite una y otra vez por cada SWITCH que haga Oracle una vez que se llene un archivo redo log.

La diferencia cuando tenemos la base de datos en modo ARCHIVELOG, es que además de sincronizar los datos que tengamos en los redo log con el fichero de datos, Oracle guarda en algún lugar el contenido del redo log que acabamos de sincronizar.

De esta manera, cuando el manejo interno de los redo log, de la vuelta en anillo y comience a sob