09 adm bases de datos abd5501 (03 unidad 2 oracle)

Jaime Amigo P. © 2006, Santiago - Chile

Instituto Profesional DuocUCEscuela de Ingeniería

Redo Log File

2


Objetivos

Después de completar esta lección, usted deberá saberlo siguiente:• Explicar el propósito de los archivos de redo log• Conocer la estructura de los archivos de redo log• Control de log switches y checkpoints• Multiplexar y mantener archivos de redo log• Manejar archivos de redo log con OMF

3


Usando archivos de Redo Log

Los archivos de Redo Log registran todos los cambios hechos en los datos y proveen mecanismos de recuperación de un sistema ante una falla.• Los archivos de redo log estan organizados dentro de

grupos• Una base de datos Oracle requiere al menos de 2 grupos• Cada redo log esta dentro de un grupo llamado member

(asociado fíisicamente a un archivo en disco)

Propósito de los Archivos de Redo Log

Los archivos de redo log proveen información de las transacciones ante un evento de falla de la base de datos. Cada transacción es escrita sincrónicamente en los archivos de redo log con el propósito de proveer un mecanismo de recuperación en caso de falla (con excepciones como cargas o lecturas hechas con la opcionNOLOGGING). Esto incluye transacciones que no han sido comiteadas, información del segmento de undo, y sentencias de administración de schemas y objetos. Los archivos de redo log son usados en situaciones como falla de una instancia para recuperar los datos comiteados que no han sido escritos a los datafiles. Los archivos de redo log son usados solo para recuperación.

Obteniendo información de Redo Log

El comando archive log list nos muestra si la base de datos está en modo archivelog o noarchivelog y si el archivado automático está funcionando

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /archive1/expl1

Oldest online log sequence 2029

Next log sequence to archive 2031

Current log sequence 2031

4


Estructura de Archivos de Redo Log

Estructura de Archivos de Redo Log

El DBA puede setear la base de datos Oracle para mantener copias de archivos de redo log y asi evitar tener un único punto de falla en una base de datos.

Grupos de Redo Log Online

•Es un conjunto de copias idénticas de archivos de redo log online

•El proceso LGWR escribe concurrentemente la misma información en todos los miembros de redo log del grupo

•El Oracle Server necesita un mínimo de 2 grupos de archivos de redo log online para la normal operación de la base de datos

5

Miembros Redo Log Online

•Cada archivo de redo log online en un grupo es llamado miembro

•Cada miembro en un grupo tiene idéntico número de secuencia de logs y del mismo tamaño. El número de secuencia de logs es asignado cada vez que el Oracle Server comienza a escribir un grupo de log e identifica cada archivo de redolog de forma única. El número de secuencia de log es almacenado en el archivo de control y en la cabecera de todos los datafiles.

Creando un archivo de redo log inicial

El seteo inicial de los grupos de redolog online y miembros son creados durante la creación de la base de datos.

Los siguientes parámetros limitan el número de archivos de redo log online:•El MAXLOGFILES en el comando CREATE DATABASE específica el máximo absoluto de grupos de redo logs online•El máximo y el valor por defecto para MAXLOGFILES depende en tu sistema operativo•El parámetro MAXLOGMEMBERS usado en el comando CREATE DATABASE determina el número máximo de miembros por grupo. El máximo y el valor por defecto de MAXLOGMEMBERS depende de tu sistema operativo

6


¿Cómo trabajan los Redo Log?

• Los redo log son usado de manera clicica• Cuando un archivo de redo log esta lleno, LGWR

continua con el siguiente grupo de log– Este proceso se llama LOG SWITCH– También ocurren operaciones de checkpoint– Esta información es escrita al archivo de control

¿Cómo trabajan los Redo Log?

El Oracle Server secuencialmente registra todos los cambios hechos en la base de datos al buffer de redo log. Las entradas a los redo son escritas desde el buffer de redo log a uno de los grupos de redo logs llamado grupo actual de redo log online (current online redo log group) por el proceso LGWR. El LGWR escribe bajo las siguientes situaciones:

- Cuando se hacen commits a transacciones

- Cuando el buffer de redo log se llena (become one-third full)

- Cuando hay mas de 1 MB de registros modificados en el buffer de redo log

- Antes que el proceso DBWn escriba los bloques modificados en el database buffer cache a los datafiles

Los redo logs son usados de manera ciclica. Cada grupo de archivos de redo log esta identificado por un número de secuencia que es sobreescrito cada vez que el log es reusado

Log Switches

LGWR escribe secuencialmente a los archivos de redolog online. Cuando el grupo de redo log actual se llena, LGWR comienza a escribir en el siguiente grupo. Este proceso es llamado LOG SWITCH.

Cuando el último archivo de redo log online se llena, LGWR retorna al primer grupo de redo log y comienza a escribir nuevamente

7

Checkpoints

Consiste en escribir a disco los buffers modificados en en la SGA, asegurándose que se escriban en los datafiles y no solo en los redo log files. Esto asegura consistencia en la BD.

Durante un checkpoint:

- Los buffers sucios de la base de datos son escritos a los datafiles por el procesos DBWn. El número de buffers que esta siendo escrito por DBWn esta determinado por el parametro FAST_START_MTTR_TARGET

- El proceso Checkpoint CKPT actualiza las cabezaras (headers) de todos los datafiles y archivos de control, reflejando que esto a sido completado exitosamente

Checkpoints pueden ocurrir para todos los datafiles de una base de datos o para datafiles específicos.

Un checkpoint ocurre por ejemplo, en las siguientes situaciones:

-En cada log switch

-Cuando una instancia ha sido bajada con la opción normal, transactional o immediate

-Cuando es forzado por un seteo del parámetro FAST_START_MTTR_TARGET

-Cuando se cumple un tiempo desde el último checkpoint indicado en el parámetro LOG_CHECKPOINT_TIMEOUT

-Cuando se alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL

-Cuando manualmente es requerido por un DBA (ALTER SYSTEM CHECKPOINT)

-Cuando se ejecuta un ALTER TABLESPACE [OFFLINE NORMAL | READ ONLY | BEGIN BACKUP], esto causa un checkpoint sobre un datafile específico

La información de cada checkpoint es registrada en el archvo alertSID.log si el parámetro de inicialización LOG_CHECKPOINTS_TO_ALERT esta seteado en TRUE. El valor por defecto es FALSE y no registra los log de checkpoint

8

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN FIRST_TIME

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------------------------

1 1 1576 52428800 1 NO CURRENT 234960305 12/19/05 08:26:09

2 1 1572 52428800 1 YES INACTIVE 211974124 04/04/05 11:56:21

3 1 1573 52428800 1 YES INACTIVE 225420507 04/15/05 18:23:39

4 1 1574 52428800 1 YES INACTIVE 225423060 04/19/05 16:40:06

5 1 1575 52428800 1 YES INACTIVE 225425126 04/25/05 10:24:35

5 rows selected.

SVRMGR> alter system switch logfile;

Statement processed.

SVRMGR> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN FIRST_TIME

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------------------------

1 1 1576 52428800 1 NO INACTIVE 234960305 12/19/05 08:26:09

2 1 1577 52428800 1 NO CURRENT 235000655 04/25/06 01:49:34

3 1 1573 52428800 1 YES INACTIVE 225420507 04/15/05 18:23:39

4 1 1574 52428800 1 YES INACTIVE 225423060 04/19/05 16:40:06

5 1 1575 52428800 1 YES INACTIVE 225425126 04/25/05 10:24:35

5 rows selected.

9


Agregando Grupos de Redo Log Online

Agregando Grupos de Redo Log

En algunos casos es preciso agregar grupos de log adicionales. Por ejemplo, agregar grupos se puede resolver problemas de disponibilidad. Para crear un nuevo grupo de archivos de redo log online, se utiliza el siguiente comando:

ALTER DATABASE [database]

ADD LOGFILE [GROUP integer] filespec

[, [GROUP integer] filespec ] ... ]

Usted específica el nombre y ubicación del miembro en filespec. El valor del parámetro GROUP puede ser seleccionado de cada grupo de archivo de redo log. Si se omite este parámetro, el Oracle Server genera este valor automáticamente

10


Agregando Miembros Redo Log Online

Agregando Miembros Redo Log Online

Se puede agregar nuevos miembros a los grupos existentes usando el comando ALTER DATABASE ADD LOGFILE MEMBER:


ADD LOGFILE MEMBER

[ ‘filename’ [REUSE] [, ‘filename’ [REUSE]] ...

TO {GROUP integer | (‘filename’ [, ‘filename’] ...) }

] ...

Use el path completo para identificar el nombre del miembro del archivo de log, de otra forma los archivos son creados en el directorio por defecto el servidor de base de datos

Si el archivo ya existe, este debe tener el mismo tamaño y se debe especificar la opción REUSE. Se puede identificar el grupo TARGET especificando uno o mas miembros del grupo o especificando el número del grupo

11


Borrando Grupos Redo Log Online

Borrando Grupos Redo Log Online

Incrementar o decrementar el tamaño de los grupos de redo log online, agregar nuevos grupos (con el nuevo tamaño) y borrar los viejos

Una entrada en el grupo de redo log online puede ser borrada con el comando ALTER DATABASE DROP LOGFILE:


DROP LOGFILE {GROUP integer| (‘filename’ [, ‘filename’] ...)}

[, {GROUP integer| (‘filename’ [, ‘filename’] ...)} ] ...

Restricciones

•Una instancia requiere de al menos 2 grupos de redo log online

•Un grupo activo o actual (current) no puede ser borrado

•Cuando un grupo de redo log online es borrado, el sistema operativo no borra el archivo

12


Borrando Miembros Redo Log Online

Borrando Miembros de Redo Log Online

Uno puede desear borrar un miembro de un redo log online porque este puede estar inválido. Usar el comando ALTER DATABASE DROP LOGFILE para borrar uno o más miembros de redo log online.

ALTER DATABASE [database] DROP LOGFILE MEMBER ‘filename’ [, ‘filename’] ...

Restricciones• Si el miembro que se desea borrar es el último del grupo, no se puede eliminar dicho

miembro• Si el grupo esta CURRENT, primero debes forzar un Log Switch antes de borrar el

miembro• Si la base de datos esta corriendo en modo ARCHIVELOG y el grupo de log file que esta

siendo usado no esta archivado, entonces el miembro no puede ser borrado• Cuando un miembro de redo log online es borrado, el archivo del sistema operativo no es

borrado

13


Limpiando, Reubicando o Renombrando Archivos de Redo Log Online

• Limpiando archivos de redo log onlineALTER DATABASE CLEAR LOGFILE ‘$HOME/oradata/u01/log2a.rdo’

• Para reubicar o renombrar archivos de redo logonline se necesita agregar nuevos miembros y borrar los miembros viejos

Limpiando, Reubicando o Renombrando Archivos de redo Log Online

Si el archivo de redo log esta corrupto en todos los miembros, el DBA debe resolver este problema reinicializando estos archivos de redo log usando el comando ALTER DATABASE CLEAR LOGFILE:

ALTER DATABA [database]

CLEAR [UNARCHIVED] LOGFILE

{GROUP integer | (‘filename’ [,’filename’] ...)}

[,{GROUP integer | (‘filename’ [,’filename’] ...)}] ...

Usar este comando es equivalente a agregar o borrar un archivo de redo log online. Pero se puede usar este comando solo si hay 2 grupos de log con un archivo cada uno y cuando el grupo es limpiado esta disponible pero no ARCHIVED

14

Restricciones

Se puede limpiar un grupo de archivos de redo log online que este archivado o no. Sin embargo, cuando no esta archivado se debe incluir la palabra clave UNARCHIVED. Esto hace inutilizable el backup si el archivo de redo log online es necesario para la recuperación.

Reubicando y renombrando archivos de redo log

La ubicación de los archivos de redo log puede ser modificada agregando nuevos archivos de log y borrando los viejos. Otro método es a través de ALTER DATABASE RENAME FILE pero requiere colocar la base de datos en modo MOUNT. Esto es mucho mas fácil que estar agregando y borrando archivos.

15


Configuración de Redo Log Online

Número de Archivos de Redo Log Online

Para determinar el número apropiado de archivos de redo log para una instancia de base de datos, se deben testear varias configuraciones.

En algunos casos, una instancia puede necesitar solo 2 grupos. En otras situaciones, se pueden requerir grupos adicionales para garantizar que los grupos estén siempre disponibles para LGWR. Por ejemplo, si los mensajes de LGWR en los archivos de trazas o archivos de alertas indican que LGWR frecuentemente esta esperando para un grupo porque un checkpoint no se ha completado o un grupo no ha sido archivado, es preciso agregar mas grupos.

Si bien es posible tener grupos multiplexados de diferentes números de miembros, es recomendable construir una configuración simétrica. Una configuración asimétrica debería ser solo el resultado temporal de una situación inusual como falla en un disco.

16

Ubicación de los archivos de redo log online

Cuando se multiplexan los archivos de redo log online, se colocan los miembros de estos en diferentes discos físicos. Para hacer esto a menudo un miembro esta disponible y otro no, no es necesario bajar la instancia.

Separe los archivos de archive log y redo log en diferentes discos para reducir la contención entre los procesos ARCn y LGWR.

Los datafile y archivos de redo deben ser colocados en diferentes discos para reducir la contención de LGWR y DBWn y así, reducir el riesgo de pérdida de datafiles y archivos de redo log ante un evento de falla de medios.

Tamaño de archivos de redo log

El tamaño mínimo de un archivo de redo log es 50 KB y el máximo tamaño esta dado por el Sistema Operativo. Miembros de diferentes grupos pueden tener diferentes tamaños, sin embargo, no hay beneficios de tener esta configuración.

Grupos de diferentes tamaños podrian ser requeridos como resultado temporal si se desea cambiar el tamaño de los miembros de los grupos de redo log online. En este caso, se deben crear un nuevos grupos con diferentes tamaños y borrar los antiguos.

Las siguientes situaciones pueden influir en la configuración de los archivos de redo log:

•Número de log switches y checkpoint•Número y cantidad de entradas de redo•Cantidad de espacio en el medio de almacenamiento; por ejemplo: sobre una cinta si ARCHIVING esta habilitada

17


Manejando Archivos Redo Log con OMF

• Un grupo puede ser agregado sin especificación de archivos– ALTER DATABASE ADD LOGFILE;

• Si un grupo es borrado, todos los archivos correspondientes a OMF son borrados a nivel de sistema operativo– ALTER DATABASE DROP LOGFILE GROUP 3;

Manejando Archivos Redo Log con OMF

Agregar un grupo

Para crear un nuevo grupo de archivos de redo log online, el DBA debe utilizar el comando ALTER DATABASE ADD LOGFILE. El comando ha sido modificado y no se requiere la especificación de archivo. En el ejemplo se agrega un nuevo archivo de logdentro de un miembro en la ubicación DB_CREATE_ONLINE_LOG_DEST_1 y el miembro en la ubicación DB_CREATE_ONLINE_LOG_DEST_2

Los nombres son únicos para los miembros generados automáticamente

Borrar un grupo

La claúsula GROUP se usa para eliminar un archivo de log. En el ejemplo, el archivo asociado al sistema operativo dentro de cada miembro de OMF es borrado automáticamente

Archived Redo Log y OMF

No pueden archivarse archivos de redo log con OMF. La ubicación de archivos de redolog para archiving debe ser especificada dentro del parámetro LOG_ARCHIVE_DEST_n

18


Obteniendo Información de Grupos y Miembros

La información de grupos y miembros se obtiene consultando el diccionario de datos• V$LOG• V$LOGFILE

Obteniendo información de grupos y miembros

V$LOG

La siguiente consulta retorna información de los archivos de redo log online desde el archivo de control

SQL> SELECT group#, sequence#, bytes, members, status FROM V$LOG;

Los siguientes items son los valores comúnmente desplegados para la columna STATUS:

•UNUSED: indica que el grupo de redo log online nunca a sido escrito. Es el estado de un archivo recientemente agregado•CURRENT: indica que el grupo de redo log online esta CURRENT (EN USO) o ACTIVO•ACTIVE: indica que el grupo de redo log online esta ACTIVE pero no EN USO (CURRENT). Es necesario para recuperación ante fallas. Puede estar o no en modo ARCHIVED

19

•CLEARING: indica que el log esta siendo recreado como un log vacío después de un ALTER DATABASE CLEAR LOGFILE. Después que el log ha sido limpiado, el estado cambia a UNUSED

•CLEARING_CURRENT: El log actual esta siendo limpiado.

V$LOGFILE

Vista dinámica de rendimiento para obtener los nombres de todos los miembros de un grupo,

SQL> SELECT member FROM V$LOGFILE;

El valor de la columna STATUS puede ser uno de los siguientes:

•INVALID: indica que el archivo esta inaccesible

•STALE: indica que el contenido del archivo esta incompleto

•DELETED: indica que el archivo no esta largamente usado (IS NO LONGER USED)

•Blanco indica que el archivo esta en uso

20


Archivado de Redo Log

Cuando los archivos de redo log online se llenan, pueden ser archivados• Existen 2 ventajas del archivado de redo log:

– Recuperación : Un backup de BD junto con el archivado online de los redo log puede garantizar la recuperación de todas las transacciones “comiteadas”

– Respaldo : Puede ser ejecutado mientras la BD esta abierta

• Por defecto una BD es creada en modo NOARCHIVELOG


Una de las decisiones más importantes de un DBA esta en determinar si una BD trabajara en modo ARCHIVELOG o en modo NOARCHIVELOG

NOARCHIVELOG

En este modo, los archivos de redo log online son sobrescritos cada vez que el archivo se llena y ocurre un log switch. LGWR no sobreescribe un grupo hasta que el checkpoint para el grupo se completa.

ARCHIVELOG

Si la base de datos esta corriendo en este modo, los grupos inactivos y llenos son archivados. Todos los cambios realizados en la BD son registrados en los archivos de redo log online, el DBA puede usar los respaldos físicos y los archivos de redo log para recuperar la base de datos sin perder la información comiteada.

21

Hay dos formas en la que los archivos de redo log son archivados:•Manualmente•Automáticamente : Metodo recomendado

El parámetro de inicialización LOG_ARCHIVE_START indica si el archivado será automático o manual cuando suba la instancia. Puede tener dos valores:

•TRUE indica que el archivado es automático. ARCn inicia el archivado de los grupos de logs llenos después de cada log switch•FALSE valor por defecto, indica que el DBA respalda manualmente los archivos de redo llenos. El DBA debe ejecutar manualmente por comandos cada vez que desee archivar el archivo de redo log online. Todos o algún archivo de redo log puede ser archivado manualmente.

22



• El archivado de redo log es ejecutado por ARCn (Archiver) o manualmente a través de sentencias SQL

• Una entrada en el archivo de control registra el nombre del log archivado, número de secuencia y otros datos de interes

• Los archivos de redo log no pueden ser reusados hasta que un checkpoint se ejecuta y el proceso ARCn respalde dicho archivo en los Archive Redo Log

• El archivo de redo log puede ser multiplexado• Los archivos de archive de redo log debe ser mantenidos

por el DBA• Mayores informaciones hay en V$LOGHIST y

V$ARCHIVED_LOG


Información de los log archivados puede ser obtenida desde V$LOGHIST y V$ARCHIVED_LOG

SQL> select * from v$loghist

23

Parámetros de Redo Log

FAST_START_MTTR_TARGET

Parámetro expresado en segundos, que determina el tiempo deseado para que ocurra la recuperación de una instancia , es decir, permite controlar el tiempo en que tarda en volver a levantarla. Si este valor es muy pequeño, de modo que no pueda completarse la recuperación en dicho instante de tiempo, entonces el TARGET_MTTR (tiempo efectivo para la recuperación) equivale al tiempo mínimo que el sistema permite para la recuperación de la instancia. Por el contrario si el valor es muy grande, tanto que ni en el peor de los casos la recuperación puede tardarse dicha cantidad de tiempo, entonces el TARGET_MTTR toma el valor estimado para la recuperación.

Este parámetro toma por defecto el valor 0, lo que significa que dicho parámetro no será tomado en cuenta en la recuperación. El máximo valor que puede tomar es 3600, que equivale a 1 hora.

Cuando se utiliza este parámetro, es conveniente deshabilitar los parámetros LOG_CHECKPOINT_TIMEOUT y LOG_CHECKPOINT_INTERVAL.

Para ver este parámetro:

SELECT TARGET_MTTR FROM V$INSTANCE_RECOVERY;

Para modificar este parámetro:

ALTER SYSTEM SET FAST_START_MTTR_TARGET=<nuevo valor>;

LOG_CHECKPOINT_TIMEOUT

Permite especificar el tiempo máximo que puede transcurrir entre el próximo checkpoint y la escritura del último bloque en el redo log. Es decir, limita el tiempo que puede permanecer un bloque sucio en el cache antes de ser escrito a disco.

En el caso en que el número de actualizaciones es significativo es conveniente que el valor que tome este parámetro sea pequeño de modo que dichas actualizaciones sean llevadas a almacenamiento seguro rápidamente, pero en los casos en que no hay gran cantidad de actualizaciones lo más conveniente es que este valor sea grande de modo que el número de escrituras de disco sea menor, dado que no habrá que reflejar muchos cambios.

Este parámetro toma por defecto el valor 1800, que corresponde a 30 minutos entre cada checkpoint.


SELECT LOG_CHKPT_TIMEOUT_REDO_BLKS FROM V$INSTANCE_RECOVERY;


ALTER SYSTEM SET LOG_CHECKPOINT_TIMEOUT=<nuevo valor>;

24

LOG_CHECKPOINT_INTERVAL

Permite especificar el número máximo de bloques que pueden existir entre el próximo checkpoint y la escritura del último bloque en el redo log, esto es, limita el número de bloques que pueden existir entre el checkpoint y el final de la bitácora.

Este parámetro toma por defecto el valor 0 lo cual indica que este parámetro será ignorado.

Al igual que para el parámetro LOG_CHECKPOIN_TIMEOUT si el número de actualizaciones es considerable es conveniente que el número de bloques entre cada checkpoint sea bajo, mientras que si el número de actualizaciones es bajo seria conveniente que el número de bloques fuera alto. Sin embargo para ambos casos puede haber desperdicio en cuanto al rendimiento ya que no se sabe cuántos bloques pueden ser afectados por las actualizaciones.


SELECT LOG_CHKPT_INTERVAL_REDO_BLKS FROM V$INSTANCE_RECOVERY


ALTER SYSTEM SET LOG_CHECKPOINT_INTERVAL = <valor en número de bloques>

LOG_ARCHIVE_START

Parámetro que indica a la base de datos que lleve una bitácora en disco de los archivos de redo log

LOG_CHECKPOINT_TO_ALERT

Parámetro que permite monitorear la actividad del checkpoint en una base de datos. Por defecto el valor es FALSE. Esta información queda registrada en los archivos de Alertas de las base de datos.

DB_CREATE_ONLINE_LOG_DEST_n

Parámetro que define el destino por defecto de los archivos de redo log.

LOG_ARCHIVE_DEST_n

Parámetro que define el destino por defecto de los archivos de archive redo log.

25


QUICK REFERENCE

ALTER SYSTEM SWITCH LOGFILEALTER SYSTEM CHECKPOINTARCHIVE LOG LISTALTER DATABASE ADD LOGGILEALTER DATABASE ADD LOGFILE MEMBERALTER DATABASE RENAME FILEALTER DATABASE DROP LOGFILEALTER DATABASE DROP LOGFILE MEMBERALTER DATABASE CLEAR LOGFILE

Comandos

NingunaVistas del diccionario de datos

V$THREADV$LOGV$LOGFILEV$DATABASE, V$LOGHIST, V$ARCHIVED_LOG

Vistas dinámicas de rendimiento

LOG_CHECKPOINT_TIMEOUTLOG_CHECKPOINT_INTERVALFAST_START_MTTR_TARGET

Parámetros dinámicos de inicialización

LOG_CHECKPOINTS_TO_ALERTUTL_FILE_DIR

Parámetro de inicialización

ReferenciaContexto

09 adm bases de datos abd5501 (03 unidad 2 oracle)

Documents

Transcript of 09 adm bases de datos abd5501 (03 unidad 2 oracle)