7 Min. de lectura

¿Que son y como se configuran ? REDOLOGS

En las bases de datos de Oracle, entre los archivos más importantes siempre encontraremos al menos los siguientes tres:

1.- CONTROLFILES: Archivos de control que hacen el match entre la instancia y los archivos de la base de datos

2.- DATAFILES : Archivos de datos que contienen nuestra información escrita en binario, la cual accedemos por medio de la base de datos.

3.- REDOLOGFILES: Archivos online encargados de almacenar el registro de las transacciones que se llevan acabo en la base de datos.

Hoy nos enfocaremos superficialmente en los REDOLOGFILES, a pesar de que son archivos muy importantes para nuestra base de datos, esta entrada esta orientada a explicar como realizar una configuración adecuada para nuestra instancia.

Si eres una persona experimentada en base de datos, puedes saltar aquellos puntos en rojo de lo contrario es importante que entiendas el concepto antes de intentar cualquier acción.

¿ Qué son ?

Como ya se menciono, son archivos escritos en binario, entendibles solo por el gestor de la base de datos, llevan el registro de las transacciones realizadas ya sea por parte del usuario o por parte del gestor y su función principal es proveernos seguridad, respaldo y recuperación en caso de ser necesario, así cuando la instancia tiene una falla, estos serán utilizados para re-hacer todas aquellas transacciones no guardadas en disco, haciendo empatar el SCN entre datafiles-controlfiles-redologs.

Las transacciones se guardan en una parte de la instancia de la base de datos, específicamente en el redolog buffer que se encuentra en la SGA, todas las transacciones tienen un SCN (System Change Number) el cual permite que sean identificadas de forma única, esta información es guardada en memoria constantemente y esta siendo escrita a los archivos de redolog por el proceso LGWR (Log Writter) , tal vez en este punto te estés preguntando ¿Porque se escribe en archivos y cada cuando se hace?.

Sobre el porque se escribe en archivos, como recordaras la definición formal de instancia es " un conjunto de procesos y estructuras de memoria de background" lo que significa que su existencia es temporal y en caso de cualquier problema o falla, puede llegar a ser borrada la misma, lo que representaría perder información existente en memoria y peor aún perder información con cambios confirmados que aún no han sido escritos a disco.

Es de allí donde nace el concepto de REDO-LOG o por su interpretación en español registro de rehacer, al guardar la información sobre las transacciones confirmadas, el gestor tiene la capacidad de garantizar que estas están protegidas en caso de falla y si es necesario puede re crearlas, para llevar la base de datos a un punto en el tiempo hasta el momento antes de la falla, por eso es que estos archivos son tan importantes, prácticamente sin ellos tendríamos el riesgo de perder todos aquellos cambios que se realizaron en la base de datos y que no se alcanzaron a escribir a disco.

Respecto a cada cuanto se hace, daremos una explicación sencilla de este proceso tan complejo, en otras entradas se explicara más a detalle, en general el proceso de escritura a disco es llevado por un proceso llamado DBWn, el cual escribe buffers

modificados ( conocidos como dirty buffers) a disco, pero esto lo hace en un tiempo muy lento, aproximadamente cada 3 segundos, como regla general no puede hacer una escritura a disco sin antes haber confirmado que la transacción ya se encuentra en algún redologfile, si no es así, entonces manda una señal a LGWr para que vacié el buffer en disco y pueda escribir, con esto el gestor podría confirmar que tiene la información necesaria para re hacer una transacción si no fue persistente en disco, en general la escritura a los redologs, se hace cuando pase alguno de los siguientes eventos:

* Cada tres segundos o antes de que DBWn escriba a disco.

* Cuando exista un commit o rollback .

* Cuando exista un siwtch en los REDOLOGS .

* Cuando el REDOLOG buffer se encuentra e 1/3 de su capacidad.

* Cuando el REDOLOG buffer ocupa 1MB de espacio.

¿ Como se configuran?

Es importante recordar que existen dos conceptos en el manejo de los redlogs :

1.- Grupo : Un grupo es un conjunto de al menos uno o más miembros.

2.- Miembro : Es un archivo que existe en un grupo, uno donde se guardaran las transacciones.

Cuando tenemos más de un miembro en un grupo, se dice que el grupo se encuentra "multiplexado" o en espejo, ya que todos los miembros del grupo tendrán la misma información, solamente sirven como copias para estar protegidos, es por ello que cada miembro de un grupo debe pertenecer a un File System o ubicación distinta, de lo contrario, si perdemos un disco perderíamos todos los miembros.

Entre las múltiples configuraciones y características de los REDOLOGS, existen dos preguntas fundamentales que todo DBA llega a hacerse en algún punto

-¿ Cuantos grupos y miembros debo tener?

-¿ Cual es el tamaño optimo para los redologs?

En una respueta simple podrían decirle que todo depende de la base de datos, pero en esta entrada se darán planteamientos más detallados sobre como obtener el tamaño indicado.

¿ Cuantos grupos y miembros ?

Por regla de Oracle y por cuestiones obvias, debemos tener al menos dos grupos con un miembro cada uno, de aquí en adelante dependerá de nuestro sistema, la transaccionalidad de la base de datos y nuestro almacenamiento, en una instalación común con DBCA se crean tres grupos con un miembro cada uno.

No podemos simplemente agregar archivos y llenar nuestro almacenamiento de REDOLOGS multiplexados, también un factor muy importante a considerar es el rendimiento, ya que tener más archivos implica más tiempo en escritura a disco por parte de la base de datos, recordemos que estos se actualizan en tiempo real y si agregamos que tenemos la base de datos en modo ARCHIVELOG, posiblemente tengamos problemas en rendimiento o sistemas congelados, por ello aquí no es aplicable el decir "mejor que sobre a que haga falta".

Piense en un número justo dependiendo de la cantidad de discos con los que cuente y del procesador de su servidor, también considere la memoria destinada a la instancia, finalmente tenga en mente que cada miembro de un grupo debe estar en un disco distinto a los otros miembros, esta ultima premisa le ayudara a determinar el número de miembros de cada grupo.

Un REDOLOG puede tener tres estados, ACTIVE, INACTIVE y CURRENT, donde CURRENT es aquel que se encuentra en uso por el gestor y es necesario para una recuperación, ACTIVE no se encuentra en uso pero aún es necesario para recuperación, INACTIVE ya no es necesario para recuperación, por ello considere tener al menos tres grupos, dando oportunidad al gestor de que los vea como un proceso circular donde siempre exista un grupo INACTIVE.

Un factor muy importante es el tamaño del cual hablaremos a continuación, pero antes de comenzar con el tema recuerde los grupos y miembros dependerán del número de discos disponibles, si tiene tres discos máximo podrá tener tres miembros cada uno, si tiene 5 discos máximo podrá 5 miembros cada grupo, la regla se aplica de la misma manera siempre.

¿ Cual es el tamaño optimo ?

Equivocadamente pensamos que entre más grande sea un archivo de REDOLOG, más seguridad y respaldo nos proveera, para empezar como regla general considere que máximo deben existir 5 log switch en 60 minutos, idealmente deben ser entre dos y cuatro, si logra controlar el switch de un log a un comportamiento persistente, tendra un muy buen rendimiento.

Un logswitch es cuando un archivo de REDO se encuentra lleno y el gestor hace un cambio para comenzar a escribir en otro grupo, por supuesto que el tiempo de llenado depende mucho del tamaño y la transaccionalidad de la base de datos, por lo que existen dos estrategías para calcular el tamaño ideal de un REDOLOG, las cuales son :

1.- Establesca el parámetro de instancia MTTR: El gestor nos permite configurar un parámetro llamado como FAST_START_MTTR_TARGET el cual en pocas palabras es un número en segundos que nosotros le damos al gestor para que se encuentre lista y disponible la instancia, despues de una falla o de un reeinicio de la instancia, esto lo que hace es establecer la velocidad de lectura y sincronización para lectura de los redologs, una vez establecido este parámetro podremos consultar un advisor conocido como Recovery Advisor, el cual resume sus recomendaciones en la vista V$INSTANCE_RECOVERY, el cual dentro de la información más importante que nos ofrece se encuentra :

RECOVERY_ESTIMATED_IOS : Número estimado promedio de buffers sucios que se encuentran en el dbbc.
ACTUAL_REDO_BLKS : Número actual de bloques de REDO necesarios para la recuperación
LOG_FILE_SIZE_REDO_BLKS: Número de bloques de REDO necesarios para un checkpoint
TARGET_MTTR : Valor recomendado para ajustar el parámetro.
ESTIMATED_MTTR : Tiempo estimado que le lleva a la instancia recuperarse.
CKPT_BLOCK_WRITES : Número de bloques escritos en cada checkpoint.
OPTIMAL_LOGFILE_SIZE : Tamaño optimo y recomendado para nuestros REDOLOGS de acuerdo a los criterios analizados y tiempo de recuperación de la instancia, este valor nos dira el número de bytes al que debemos dimensionar nuestros grupos de REDOLOGS, le recomiendo tomar este valor como una base y elegir siempre un valor con el 30% o 50% más grande para dimensionar los REDOLOGS.

Es importante mencionar que mientras no hayamos establecido algún valor para este parámetro, las recomendaciones del ad visor pueden ser nulas o incorrectas, también tener en mente que entre más pequeño sea el tiempo que establezcamos, más grande sera la carga de operaciones de I/O al abrir nuestra base de datos, por lo que siempre debemos mantener un equilibro o podría tener contra producciones valores muy bajos.

2.- Consultando el switch en los REDOLOGS: Si bien este método requiere un poco de experiencia no solo en la adminsitración de base de datos, si no también en el negocio de la información que se almacena, podemos calcular el tamaño de nuestros redologs tomando en cuenta el criterio de número de switch anteriormente mencionado, para lo que el siguiente query le ayudara a obtener un estadistico del número de switches que han tenido sus redologs por hora :

SELECT to_char(first_time,'YYYY-MON-DD') day, to_char(sum(decode(to_char(first_time,'HH24'),'00',1,0)),'99') "00", to_char(sum(decode(to_char(first_time,'HH24'),'01',1,0)),'99') "01", to_char(sum(decode(to_char(first_time,'HH24'),'02',1,0)),'99') "02", to_char(sum(decode(to_char(first_time,'HH24'),'03',1,0)),'99') "03", to_char(sum(decode(to_char(first_time,'HH24'),'04',1,0)),'99') "04", to_char(sum(decode(to_char(first_time,'HH24'),'05',1,0)),'99') "05", to_char(sum(decode(to_char(first_time,'HH24'),'06',1,0)),'99') "06", to_char(sum(decode(to_char(first_time,'HH24'),'07',1,0)),'99') "07", to_char(sum(decode(to_char(first_time,'HH24'),'08',1,0)),'99') "08", to_char(sum(decode(to_char(first_time,'HH24'),'09',1,0)),'99') "09", to_char(sum(decode(to_char(first_time,'HH24'),'10',1,0)),'99') "10", to_char(sum(decode(to_char(first_time,'HH24'),'11',1,0)),'99') "11", to_char(sum(decode(to_char(first_time,'HH24'),'12',1,0)),'99') "12", to_char(sum(decode(to_char(first_time,'HH24'),'13',1,0)),'99') "13", to_char(sum(decode(to_char(first_time,'HH24'),'14',1,0)),'99') "14", to_char(sum(decode(to_char(first_time,'HH24'),'15',1,0)),'99') "15", to_char(sum(decode(to_char(first_time,'HH24'),'16',1,0)),'99') "16", to_char(sum(decode(to_char(first_time,'HH24'),'17',1,0)),'99') "17", to_char(sum(decode(to_char(first_time,'HH24'),'18',1,0)),'99') "18", to_char(sum(decode(to_char(first_time,'HH24'),'19',1,0)),'99') "19", to_char(sum(decode(to_char(first_time,'HH24'),'20',1,0)),'99') "20", to_char(sum(decode(to_char(first_time,'HH24'),'21',1,0)),'99') "21", to_char(sum(decode(to_char(first_time,'HH24'),'22',1,0)),'99') "22", to_char(sum(decode(to_char(first_time,'HH24'),'23',1,0)),'99') "23" from v$log_history GROUP by to_char(first_time,'YYYY-MON-DD') order by 1 DESC;

En conclusión

Como consejo, tome ambos métodos como base para decidir el dimensionamiento de sus REDOLOGS, recuerde siempre tener al menos dos miembros en cada grupo y sobre todo no abusar en tamaño o miembros, no por querer proteger su base de datos, debe exagerar en respaldos, analice bien los datos que ha recopilado y tenga como base al menos un més de transaccionalidad, así podrá tener una muestra generosa de el número de switches que llega a tener su base de datos, aunque la experimentación siempre es buena, no todos los archivos son aplicables, por lo que si puede, siempre tenga un ambiente de prueba y como regla de oro, respalde todo antes de realizar cambios, inclusive en scripts, siempre tenga a la mano el inverso de un script para des hacer los cambios si es posible.