El gran misterio del log_buffer

Buenas de nuevo, escribo algo muy sencillo, pero que he visto que está extendido en varias bases de datos que he tocado. Lo llamaré “El gran misterio log_buffer”. Y es que he visto en más de una ocasión que el valor de este parámetro está puesto a 10M y hasta 32M. Y me pregunto ¿Por qué y para qué?
He notado que algunos administradores tienden a aumentar el tamaño de este valor cada vez que aumentan el tamaño de su SGA, pero esto sin duda alguna, es una “mala” práctica, y ahora les explico porqué. Para ello primero me pregunto ¿Para que uso ese pedacito de memoria y como funciona? Cada vez que realizo hago cambios (Insert, Delete, Update, y más cosas) estos cambios se guardan en memoria temporalmente, justo ahí, en el redo log buffer, y el tamaño de este buffer lo determina el parámetro log_buffer. Si ocurren ciertos eventos, un proceso llamado Log Writer (LGWR) “escribe” la información que está en esa parte de la memoria a los Online Redo logs, mejor, realmente “vuelca” (flush en ingles) la información de memoria a disco, y reutiliza ese espacio. Con esto se esta intentando guardar la integridad de los datos y de la base de datos (a groso modo).
Pero ¿Cada cuanto vuelco esta información que está en la memoria a disco?
Existen varios eventos por los que se producen estas escrituras. Quien lo describe perfectamente es Tom Kyte en su libro “Expert Oracle database architecture” en la página 176, donde dice que estos eventos (LGWR despierta para trabajar) se ejecutan cada:

- Tres segundos
- “COMMIT” de cualquier transacción
- Cuando se llega a un tercio del tamaño del redo log buffer
- Cuando llega a 1M de información

También pueden encontrar esta información en METALINK en la nota “Tuning the Redolog Buffer Cache and Resolving Redo Latch Contention” con id 147471.1, ó también esto mismo lo podemos leer en el documento "Performance Tuning Guide " ya sea 9i ó 10g, en el capitulo de "Memory Configuration and Use" en la parte de "Configuring and using the Redo Log Buffer".

Entonces teniendo en cuenta que se va a realizar un volcado de esta información cada vez que llegue a 1M, ¿Por qué tengo 14M ó incluso 30M de redo log buffer? La verdad, no lo se y no lo entiendo, el caso es que he encontrado estos “detalles” en muchísimas bases de datos. Y los argumentos de algunos son : que es un OLTP (gran volumen de transacciones), o que su SGA es muy grande, y otra razón que también escucho es que como tienen muchas CPU pues deducen (ejemplo: 32*512K dan 16M de log_buffer) tal y como dice el DBA Reference. Pero realmente creo que muchos DBAs no ven normal que el resto de “pools” de la SGA vayan creciendo según la carga y/o el tipo de uso de la base de datos y que esta parte de la memoria no lo crezca también, y simplemente la aumentan por si acaso, creo.

Pero es cierto es una “mala” practica, sino pruébenlo, pasen de 14M (si lo tienen) a 3M, en sus base de datos (8i, 9i ó 10g), miren si el rendimiento de su base de datos decrece.
Realmente no importa mucho si tienes 32 Gigas de memoria y de SGA tienes 24. Al final lo único que estas haciendo es desperdiciar unos pocos megas, tal y como lo dice Tom.
Este pequeño espacio de memoria le viene muy bien a otras partes de la SGA, y no veo conveniente desperdiciar ni bloque del sistema para nada, solo por un mal mito repartido en muchos sitios.
Si después de esta prueba ven que el rendimiento decrece o es malo por este cambio, por favor envíenme la demostración "real" que estoy deseoso de verla, ya que confío y creo que esto no se produce.

Por cierto, si realmente consumen menos de 300K de información de redo por segundo (el dato aparece en los reportes AWR), no es necesario ni siquiera llegar hasta los 3M, con menos de esto valor nos vale (calcúlalo con lo antes explicado ;). Es poco común, pero este mundo es muy grande. Claro, que tampoco es correcto poner un valor muy pequeño, y ese es el momento donde posiblemente tengas algún problema, reduciéndolo demasiado.