LOGGING o NOLOGGING, he ahi el dilema - Parte I
Introducción
La pregunta medular sobre NOLOGGING que escucho todo el tiempo es: ¿Crear una tabla con la opción NOLOGGING significa que “jamás habrá generación de redo”, o solo la operación inicial de creación no tiene generación de redo. Otras interrogantes como: ¿Que sentencias DML generan redo? ¿Cómo y cuando se puede emplear la opción NOLOGGING?
La generación de redo es una parte vital del mecanismo de recuperación de Oracle. Sin él, una instancia no podría recuperarse en caso de caída y tampoco podría iniciar en un estado consistente. La generación excesiva de redo, es el resultado del trabajo excesivo en la base de datos.
Este documento aborda el tema de la reducción en la generación de redo, utilizando las opciones LOGGING y NOLOGGING, las diferencias entre ellas, sus mecanismos, como reducirla y cuando usarlas.
Adicionalmente, encontrará ejemplos y tips sobre el uso de cada una de ellas.
Los beneficios principales de la opción NOLOGGING sugeridos en la Guía de Administración de Base de Datos Oracle®, son:
- Ahorro de espacio en los archivos de redo log
- El tiempo que toma crear la tabla o índice disminuye
- Mejora el desempeño en la creación en paralelo de tablas grandes
“Una regla importante respecto los datos, es nunca colocarte a ti mismo en una situación no recuperable. La importancia de este lineamiento no puede tener más énfasis, sin embargo no significa que jamás puedas utilizar alternativas que ahorren tiempo o mejoren el desempeño”.
¿Que es el Redo?
Sumariemos brevemente el proceso de redo. Cuando los bloques en Oracle son modificados, incluyendo los bloques de undo, Oracle registra los cambios en forma de vectores de cambio, los cuales son conocidos como entradas de redo o registros de redo. Las modificaciones son escritas por el proceso de servidor al buffer de redo log en la SGA. Posteriormente el buffer de redo log es vaciado a los archivos en-línea de redo log, casi en tiempo real por el proceso de escritura de logs (LGWR). (Ver la figura 1)
Los redo logs son escritos por el LGWR cuando:
- Cuando un usuario envía un commit.
- Cuando el Buffer de Logs esta a 1/3 de su capacidad.
- Cuando la cantidad de entradas de redo es 1MB.
- Cada tres segundos
- Cuando sucede en la base de datos un punto de control (checkpoint). Las entradas de redo son escritas antes del checkpoint para asegurar recuperabilidad.
“Si el buffer de logs es muy reducido, entonces observaremos esperas por espacio en buffer de logs (buffer log space waits) durante la generación de redo. Es posible que el proceso LGWR no comience a escribir redo hasta alcanzar el umbral definido por _log_io_size (el valor por defecto es 1/3 del buffer de logs o 1M, lo que sea menor) ha sido excedido, y el remanente del buffer de logs pueda ser llenado antes de que el LGWR pueda completar la escritura y liberar espacio en el buffer de logs.
En el caso ideal, el buffer de logs debería ser lo suficientemente grande para hacer frente a todas las ráfagas de generación de redo, sin que se observen esperas por espacio del buffer de logs.
Comúnmente, las ráfagas mas severas de generación de redo ocurren inmediatamente después de un cambio de log, cuando la generación de redo ha sido deshabilitada por un tiempo, y existe una lista de espera de demanda por espacio en el buffer de logs” por Steve Adams.
Los archivos de redo log registran cambios a la base de datos como resultado de transacciones (Una transacción es una unidad lógica de trabajo, consistente de una o mas sentencias SQL ejecutadas por un usuario) o acciones internas del servidor Oracle. Los archivos de redo log protegen a la base de datos de la perdida de integridad en casos de fallos causados por perdidas de suministro eléctrico, errores en discos duros y así algunas otras causas. Los archivos de redo log deben ser multiplexados para asegurar que la información almacenada en ellos no se pierda en caso de un fallo en disco. Consiste en grupos de archivos de redo log y cada grupo esta integrado por un archivo de redo log y sus copias multiplexadas. Se dice que cada copia idéntica es miembro de un grupo, y cada grupo es identificado por un número. El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de redo log a todos los miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita una operación de cambio de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los archivos del siguiente grupo. Los grupos de redo log son usados de una forma circular (ver la figura 2).
Recomendación de Mejor Práctica:
Oracle recomienda que los grupos de archivos de redo logs posean al menos dos archivos por grupo, con los archivos distribuidos en discos o controladoras separadas para que de esta forma en caso fallos en el hardware no se destruya el grupo completo.
La perdida de un grupo entero de redo logs es una de las posibles fallas de medios mas serias ya que puede resultar en perdida de datos. La perdida de uno de los miembros de un grupo de redo logs, considerando un grupo con múltiples miembros, es trivial y no afecta la operación de la base de datos más allá de provocar la publicación de un mensaje de alerta en el alert log.
Hay que recordar que los redo logs influencian fuertemente el desempeño de una base de datos, ya que un commit no puede darse por realizado hasta que la información de la transacción ha sido escrita a los redo logs. Los archivos de redo log se deberán ubicar en los discos mas rápidos disponibles, atendidos por las controladoras mas rápidas. Si es posible, no compartir con ningún otro archivo de la base de datos los discos destinados a los archivos de redo log. Esto es porque solo un grupo es accesado para escritura en un momento dado; no hay implicaciones en tener miembros de distintos grupos en el mismo disco.
Para evitar la perdida de información que podría ser requerida al recuperar la base de datos a un punto especifico, Oracle posee un proceso de archivado que trabaja en segundo plano (ARCn), el cual archiva los redo logs cuando estos se llenan. Sin embargo, es importante notar que no todas las bases de datos Oracle tienen habilitado el proceso de archivado. Una instancia con el archivado habilitado, se dice que opera en modo ARCHIVELOG y una instancia con el archivado desactivado se dice que opera en modo NOARCHIVELOG.
Para determinar en que modo esta o si el archivado esta siendo usado en una instancia tenemos las siguientes alternativas: se puede verificar el valor del parámetro LOG_ARCHIVE_START que se encuentra en el archivo de parámetros de inicio (pfile o spfile - este parametro se derogo a partir de la versión 10g), ejecutar un query SQL a la vista v$database (”ARCHIVELOG” indica que el archivado esta activado, y “NOARCHIVELOG” indica que el archivado esta deshabilitado) o ejecutando el comando ARCHIVE LOG LIST.
SQL> Select log_mode from v$database;
LOG_MODE
——————-
ARCHIVELOG
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 8
Next log sequence to archive 10
Current log sequence 10
Estén pendientes de la siguiente parte, donde hablare sobre Generación de Redo y Recuperabilidad: como, cuando y porqué.
Muchos saludos,
Francisco Munoz Alvarez