Consideraciones importantes antes de cambiar tablas a modo nologging

Las tablas en una base Oracle por default registran en redo todos los cambios (transacciones) que se le fueron aplicando. Esto sirve para recuperar, ante una caida abrupta de la base de datos, aplicando un procedimiento denominado rolling forward, las transacciones confirmadas que no llegaron a impactarse en los datafiles. El grabado en redo es sincronico y muchas veces es causante de demoras generales en la base de datos, en especial en bases OLTP con alta concurrencia y alta tasa transaccionabilidad, uno de los eventos de espera mas comunes es el log file sync.

Cuando en un reporte AWR o statspack vemos entre los TOp 5 events este tipo de eventos y buscamos en manuales, metalink o en foros, las dos recomendaciones principales son: a) bajar la transaccionabilidad, esto es minimizar los commits, y/o rollbacks, todo lo que sea posible sin afectar las reglas de negocio modeladas ó b) optimizar la escritura en redo, usando por ejemplo discos mas rápidos, recordemos que la escritura en redos, al contrario de la escritura en datafiles, es escritura secuencial, ideal es poner los redos sobre discos de estado solido, por la muy baja latencia y tambien verificar que no esten alojados sobre raid 5, siempre se recomienda raid 1 para estos archivos.

Otra opción interesante es pensar en generar la minima cantidad de redo sin modificar ninguno de los dos puntos tratados en el parrafo anterior. Cambiar a un tabla a nologging permite minimizar el redo generado para ciertas operaciones. Un mito muy común es poner todas las tablas en nologging y pensar que esto impide la registración de cambios en redo, nada mas lejos. La anulación de redo es imposible, ya que es un mecanismo fundamental del funcionamiento de la base de datos, lo que si se logra es reducir bastante la cantidad de redo, con la consecuencia que esto implica, que es ni mas ni menos que ante una falla de la instancia la operacion realizada en modo nologging no se puede recuperar, la unica opción es reprocesar. Las siguientes operaciones son las unicas disponibles para usar nologging:

1. create table...as select
2. create index
3. direct load con SQL*Loader
4. direct load INSERT (usando el hint APPEND)
5. alter table...move partition
6. alter table...split partition
7. alter index...split partition
8. alter index...rebuild
9. alter index...rebuild partition

Ahora, como siempre, comprobemos las operaciones que registran, y las que no, los cambios sobre redo:

Voy a crear una tabla en modo logging (default) y luego voy a a ver el redo que consumió dicha operación.

SQLPLUS> create table t as select * from dba_tables

SQLPLUS>@myredosize.sql

SQLPLUS> 1610k

La cantidad de redo fue de 1610k, veamos que sucede si creamos la tabla en modo nologging:

SQLPLUS> create table t nologging as select * from dba_tables

SQLPLUS>@myredosize.sql

SQLPLUS> 100k

El redo usado no fue nulo pero si mucho menor, en el caso aproximadamente 16 veces inferior al de crear la tabla en modo logging.

En el siguiente ejemplo vamos a comparar el redo insumido en una operacion de insert convencional con un insert en modo directo, ambos sobre una tabla nologging:

SQLPLUS> create table t nologging as select * from dba_tables where 1=0

SQLPLUS> insert into t select * from dba_tables

SQLPLUS>@myredosize.sql

SQLPLUS> 1497k

SQLPLUS> insert into t select /*+ APPEND */ * from dba_tables

SQLPLUS>@myredosize.sql

SQLPLUS> 34k

Lo que se puede observar es que en el primer caso, el consumo de redo fue similar al del create table del ejemplo anterior en modo logging. Esto muestra claramente que no todas las operaciones inhiben el redo, en el caso del insert convencional sobre una tabla en nologging no hay diferencia de hacerlo sobre una tabla logging. La diferencia se ve en el insert directo, que justamente es una de las pocas tipos de sentencias que aprovechan el nologging.

Como siempre, es recomendable leer la documentación detenidamente para ver si tal funcionalidad o tal caracteristica es beneficiosa para lo que queremos hacer. Si por el contrario no entendemos bien cierto funcionamiento, tal vez, como es en el caso descripto en esta nota, tendemos a setear todas las tablas que podamos en nologging sin reducir como esperabamos el redo. Además hay que saber evaluar las consecuencias negativas que podría ocasionar tener tablas en nologging y perder la información al no estar sustentada con los redo's.