Instituto Profesional DuocUC Escuela de Ingeniería Redo Log File

Transcripción

1 Redo Log File Jaime Amigo P. 2006, Santiago - Chile

2 Objetivos Después de completar esta lección, usted deberá saber lo 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 2

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 opcion NOLOGGING). 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

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 4

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 5

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 6

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 7

8 SVRMGR> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN FIRST_TIME NO CURRENT /19/05 08:26: YES INACTIVE /04/05 11:56: YES INACTIVE /15/05 18:23: YES INACTIVE /19/05 16:40: YES INACTIVE /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 NO INACTIVE /19/05 08:26: NO CURRENT /25/06 01:49: YES INACTIVE /15/05 18:23: YES INACTIVE /19/05 16:40: YES INACTIVE /25/05 10:24:35 5 rows selected. 8

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 9

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: ALTER DATABASE [database] 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 10

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: ALTER DATABASE [database] DROP LOGFILE {GROUP integer ( filename [, filename ]...)} Restricciones [, {GROUP integer ( filename [, filename ]...)} ]... 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 11

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 12

13 Limpiando, Reubicando o Renombrando Archivos de Redo Log Online Limpiando archivos de redo log online ALTER DATABASE CLEAR LOGFILE $HOME/oradata/u01/log2a.rdo Para reubicar o renombrar archivos de redo log online 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 13

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. 14

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. 15

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 16

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 log dentro 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 17

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 18

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 19

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 Archivado de Redo Log 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. 20

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. 21

22 Archivado de Redo Log 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 Archivado de Redo Log Información de los log archivados puede ser obtenida desde V$LOGHIST y V$ARCHIVED_LOG SQL> select * from v$loghist 22

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. Para ver este parámetro: SELECT LOG_CHKPT_TIMEOUT_REDO_BLKS FROM V$INSTANCE_RECOVERY; Para modificar este parámetro: ALTER SYSTEM SET LOG_CHECKPOINT_TIMEOUT=<nuevo valor>; 23

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. Para ver este parámetro: SELECT LOG_CHKPT_INTERVAL_REDO_BLKS FROM V$INSTANCE_RECOVERY Para modificar este parámetro: 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. 24

25 QUICK REFERENCE Contexto Parámetro de inicialización Referencia LOG_CHECKPOINTS_TO_ALERT UTL_FILE_DIR Parámetros dinámicos de inicialización Vistas dinámicas de rendimiento Vistas del diccionario de datos Comandos LOG_CHECKPOINT_TIMEOUT LOG_CHECKPOINT_INTERVAL FAST_START_MTTR_TARGET V$THREAD V$LOG V$LOGFILE V$DATABASE, V$LOGHIST, V$ARCHIVED_LOG Ninguna ALTER SYSTEM SWITCH LOGFILE ALTER SYSTEM CHECKPOINT ARCHIVE LOG LIST ALTER DATABASE ADD LOGGILE ALTER DATABASE ADD LOGFILE MEMBER ALTER DATABASE RENAME FILE ALTER DATABASE DROP LOGFILE ALTER DATABASE DROP LOGFILE MEMBER ALTER DATABASE CLEAR LOGFILE 25

26 Fin de la Lección Jaime Amigo P. 2006, Santiago - Chile