Estadísticas de generación de Redo Log en instancias RAC y no RAC

Existe cierto tipo de información que no se encuentra en los manuales y que por lo general, muy poca gente suele publicar en sus blogs ó en las famosos "White Paper".

Cuántos errores dejaríamos de cometer, si la información estuviera ahí, antes de tomar una mala decisión.

Por lo general, dimensionamos el monto de espacio del área de FlashRecovery, con base a la información de cambios de archivos de redo log, que se produce en nuestra base de datos. Y es que algo tan sencillo, como lo que podemos obtener a partir de la ejecución del siguiente script, nos puede ayudar increíblemente o no sub-dimensionar el espacio del FlashRecovery Area, que se necesita en apróximadamente para nuestras instancias, si estas son migradas a un RAC y activando el modo archive log de la base de datos.

Y es, que si existe, diferencia importante, entre ambos modo de operación de la base de datos.

El siguiente gráfico, esta basado en datos reales, obtenidos de una instalación Oracle 10g RAC en funcionamiento activo.

En promedio, cada instancia de base de datos en RAC, me genera un 66.5% más de redo log que una instancia en no RAC y un 84.5% más como máximo.

Esto ha causado, que el monto de Gbytes reservados para el área de FlashRecovery, sea insuficiente, para poder trabajar sobre un supuesto de "n" cantidad de días de rentención de información. Si ha esto le abonamos, que como mínimo tenemos dos nodos por RAC, los porcentajes de incremento en espacio utilizado son de, 233% y 269% más como promedio y máximo, de espacio por el archive log.

Con estos números, cualquier proyección de espacio requerido, se viene abajo.

Espero que este artículo, le sirva como consejo: "Las proyecciones no son lineales, cuando hablamos de base de datos Oracle en RAC.".

Tal vez, ya sea demasiado tarde y tenga su hardware en funcionamiento, pero al menos, espero que esta información, le pueda ayudar a explicar, porqué su área de FlashRecovery, se llena tan fácilmente?.