You are hereLOGGING o NOLOGGING, he ahi el dilema - Parte 1

LOGGING o NOLOGGING, he ahi el dilema - Parte 1


By OracleDisected - Posted on 01 July 2008

Introduccion

La pregunta medular sobre NOLOGGING que escucho todo el tiempo es: ¿Crear una tabla con la opción NOLOGGING significa que “jamas habra generacion 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 generacion de redo es una parte vital del mecanismo de recuperación de Oracle. Sin él, una instancia no podría recuperarse en caso de caida 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, encontará ejemplos y tips sobre el uso de cada una de ellas.

Los beneficios principales de la opcion NOLOGGING sugeridos en la Guia de Administración de Base de Datos Oracle® Database, son:

• Ahorro de espacio en los archivos de redo log
• El tiempo que toma crear la tabla o indice 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 enfasis, sin embargo no significa que jamas puedas utilizar alternativas que ahorren tiempo o mejoren el desempeño.“

¿Que es el Redo?

Sumarizemos 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-linea de redo log, casi en tiempo real por el proceso de escritura de logs (LGWR). (Vea la figura 1)

Los redo logs son escritos por el LGWR cuando:
• Cuando un usuario envia 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 deberia ser lo suficientemente grande para hacer frente a todas las rafagas de generacion de redo, sin que se observen esperas por espacio del buffer de logs.

"Comunmente, las rafagas mas severas de generacion de redo ocurren inmediatamente despues 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 archvos de redo log registran cambios a la base de datos como resultado de transacciones (Una transaccion 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 electrico, 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 identica 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).

Recomendacion de Mejor Práctica:

Oracle recominda 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 multiples miembros, es trivial y no afecta la operación de la base de datos más alla 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 deberan ubicar en los discos mas rapidos disponibles, atendidos por las controladoras mas rapidas. Si es posible, no compartir con ningun 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 podria 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 parametro LOG_ARCHIVE_START que se encuentra en el archivo de parametros 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

Esten pendientes de la siguiente parte, donde hablare sobre Generacion de Redo y Recuperabilidad: como, cuando y porqué.

Autor: Francisco Muñoz (fmunoz)


Distribuir

Distribuir contenido

Follow DatabasesLA on Twitter

En línea

En este momento hay 0 usuarios y 1 invitado en línea.

Estadisticas

Locations of visitors to this page

hidden hit counter