Backup & Recovery Oracle 9i

Transcripción

1 Configuración de Copia de Seguridad y Recuperación Cómo ya sabemos, todas las transacciones se registran en los ficheros redo log online. Esto permite la recuperación automática de las transacciones en caso de producirse un fallo de la instancia. Pero, Que ocurrirá si fallan los ficheros de la BBDD? Habremos perdido toda la información? Habremos perdido todos los datos porque no teníamos ninguna copia de seguridad. Para poder evitar estas pérdidas de datos, se nos plantea una de las decisiones más importantes que tendremos que tomar como DBA: Archivelog o No Archivelog? Archivelog o No Archivelog? Nuestra BBDD puede estar configurada en modo No Archivelog o en modo Archivelog. SI Modo No Archivelog Por defecto, una BBDD se crea en modo No Archivelog. Las características de ejecución en este modo son las siguientes:?? Los ficheros de redo log se utilizan de forma circular (siempre es así)?? Una vez haya finalizado el punto de comprobación, un fichero de redo log se puede volver a utilizar, es decir, la información anotada en el fichero de redo log se sobrescribe?? Una vez sobrescrito, no se puede recuperar la información anterior del fichero y la recuperación de medios sólo es posible hasta la última copia de seguridad completa - 4 -

2 Consideraciones?? Sólo se pueden realizar copias de seguridad del Sistema Operativo de la Base de Datos cuando ésta se encuentra cerrada. La BBDD no está disponible durante los backups?? Cada copia de seguridad debe incluir el juego completo de archivos de la BBDD. No se puede hacer un backup de sólo una porción de la BBDD?? Si fuera requerida una recuperación debido a la pérdida de archivos de datos, el DBA sólo podría recuperar el último backup offline. Cualquier cambio realizado en la Base de Datos desde entonces se perdería. Por tanto, es necesario realizar backups offline con más frecuencia?? No se pueden realizar copias de seguridad online (con la BBDD operativa)?? Si un Tablespace deja de estar disponible debido a un fallo, no se puede seguir utilizando la BBDD hasta que se borre el Tablespace o se restaure la BBDD entera a partir de las copias de seguridad?? Los tablespaces no se pueden desactivar con la opción IMMEDIATE?? En el supuesto que se produzca algún fallo en algún fichero de la BBDD, se deben restaurar todos los ficheros de la Base de Datos a partir de la copia de seguridad de la BBDD completa - 5 -

3 Modo Archivelog Si decidimos que la BBDD trabaje en modo Archivelog?? Cuando se produce un cambio de log, el proceso en segundo plano ARCn (creado al indicar el modo de archivado automático) se encarga de copiar el contenido del fichero de redo log lleno en los Archivos Log Archivados. En el fichero de control se registra el número de secuencia de los del archivo log archivado en el historial de log?? Las copias del archivo redo log pueden utilizarse para la recuperación de medios Consideraciones?? La emisión del comando necesario para poner la BBDD en modo Archivelog actualiza el fichero de control?? La BBDD está protegida contra la pérdida de datos en caso de producirse un fallo del medio físico?? Se puede realizar una copia de seguridad en caliente (BBDD online)?? Un Tablespace (excepto SYSTEM) puede recuperarse mientras la BBDD está abierta y se pueden poner en offline con la opción IMMEDIATE?? Se puede restaurar la Base de Datos hasta un punto en el tiempo específico, hasta el final de un archivo log archivado especificado e incluso, hasta un número de SCN específico?? A nivel de desventaja, en modo Archivelog se necesita espacio en disco adicional para almacenar los archivos log archivados - 6 -

4 Proceso ARCn Si la base de datos está funcionando en modo ARCHIVELOG automático se inicia un proceso en segundo plano llamado ARCn el cual se activa cuando se produce un cambio de log. El archivado automático se puede habilitar activando el parámetro LOG_ARCHIVE_START (indicando un valor TRUE) del fichero de parámetros o mediante un comando que se explicará más adelante. A partir de la versión 7 de Oracle, el proceso esclavo ARC se hizo más robusto. En la versión 6, únicamente se limitaba a realizar una simple copia de bloques desde el archivo redo log online hasta el archivo de log archivado. A partir de la versión 7, cada bloque del archivo redo log online se verifica antes de la copia. Esto asegura que si un bloque del redo log es incorrecto, ARC genera un error antes de realizar la copia y el DBA puede tener constancia de ello de forma inmediata, en vez de darse cuenta durante la recuperación. Archivos Log Archivados Cuando la Base de Datos se define en modo ARCHIVELOG, el proceso LGWR espera a que los ficheros de redo log online se archiven (manualmente o mediante el proceso ARCn) antes de volver a utilizarlos. Si un fichero redo log online está corrupto, se utiliza otro miembro del mismo grupo (de ahí la importancia de multiplexar los ficheros de redo log). Los logs archivados son útiles para el proceso de copia de seguridad y recuperación porque una copia de seguridad de la Base de Datos combinada con los archivos redo log archivados garantiza que se puedan recuperar todos los datos validados hasta el punto de fallo

5 Dónde se archiva el redo log online? Hemos de indicar dónde se van a almacenar las copias de los ficheros de redo log. Para ello hemos de editar el PFILE (o modificar SPFILE) y modificar los siguientes parámetros: LOG_ARCHIVE_DEST_1 = destino = fichero donde destino puede ser Un directorio local, indicado con la palabra clave LOCATION Un alias de Net9 para una BBDD remota, especificado con la palabra SERVICE. El nombre de servicio se resuelve mediante el TNSNAMES.ORA para identificar la instancia remota. La versión inicial de 8i sólo soporta el envío de archive logs a un nodo remoto mediante TCP/IP y sólo se puede especificar un destino de archivo por cada BBDD remota fichero es una cadena de texto que representa la ubicación por defecto de archivos log archivados Ejemplo UNIX: NT: LOG_ARCHIVE_DEST_1 = LOCATION=/disk1/archive/ LOG_ARCHIVE_DEST_1 = LOCATION=d:\archive\ LOG_ARCHIVE_FORMAT = extensión donde extensión debería incluir las variables %s o %S para el número de secuencia de log Ejemplo UNIX y NT: LOG_ARCHIVE_FORMAT = arch%s.arc Opciones de nombre de fichero?? %s o %S: incluye el número de secuencia de log como parte del nombre de archivo?? %t o %T: incluye el número de thread como parte del nombre de archivo?? El uso de %S en mayúscula hace que el valor del número de secuencia que se añade al nombre del fichero sea de longitud fija, rellenando con ceros a la izquierda - 8 -

6 Varias Ubicaciones de Archivado Con el objetivo de aumentar la seguridad, podemos proteger los archivos log archivados mediante su duplicación. Con Oracle 9i podemos indicar hasta 10 destinos de archivado. Al configurar la duplicación, se escriben copias de los archivos logs archivados en un destino especificado en el archivo de parámetros mediante el parámetro LOG_ARCHIVE_DEST_n = destino = fichero Este parámetro es dinámico y puede modificarse a nivel de sesión Cuando se utilizan los parámetros LOG_ARCHIVE_DEST_n, se puede designar un destino como obligatorio u opcional: MANDATORY implica que el archivado en este destino es obligatorio y hasta que no se realice correctamente no se podrá sobrescribir el redo log online. Debería existir un destino como obligatorio OPTIONAL implica que, aunque no se haya archivado correctamente, el archivo redo log online se puede volver a sobrescribir. Es el valor por defecto Atributo REOPEN Debido a que durante la escritura de los redo logs online en los archive logs archivados puede producirse algún error, mediante el atributo REOPEN indicamos al proceso en segundo plano ARC que debe volver a intentar realizar la copia. Cuando volverá a intentarlo? Por defecto lo intentará cada 300 segundos pero nosotros podemos indicar cada cuando ha de intentarlo de nuevo. No existe límite de número de intentos. Los posibles errores se anotan en el archivo de alertas. Ejemplo: LOG_ARCHIVE_DEST_1 = LOCATION=/archive1 MANDATORY REOPEN LOG_ARCHIVE_DEST_2 = LOCATION=/archive2 MANDATORY REOPEN=500 Si no se especifica REOPEN, los errores que se produzcan en los destinos opcionales se registran y se ignoran. Si el error se produce en un destino obligatorio, impedirá que se vuelva a utilizar el redo log online hasta que el archivado se realice correctamente

7 Número Mínimo de Destinos Locales Podemos obligar a ARC a escribir en un número determinado de destinos antes de que se pueda reutilizar el redo log online mediante los siguientes valores: El número de destinos que hayamos definido como MANDATORY El valor definido mediante el parámetro LOG_ARCHIVE_MIN_SUCCEED_DEST Este parámetro especifica el límite inferior del número de destinos locales que es necesario archivar. Ejemplo: Si este número es menor que el número de destinos locales obligatorios (los definidos como MANDATORY), este valor es obviado Si este número es mayor que el número de destinos locales obligatorios, el número de destinos locales archivados debe ser al menos igual a este valor para que se pueda volver a utilizar un archivo redo log online Vamos a suponer que LOG_ARCHIVE_MIN_SUCCEED_DEST = 3 Si el número de destinos locales obligatorios es 4, será necesario archivar en estos 4 destinos antes de poder volver a utilizar de nuevo el archivo redo log online. Por otra parte, si el número de archivados obligatorios es 2, será necesario archivar también en un destino opcional para poder volver a utilizar un archivo redo log online. Control del Archivado en un Destino El parámetro LOG_ARCHIVE_DEST_STATE_n permite desactivar un destino de archivado de forma dinámica. Por ejemplo, para detener temporalmente el archivado en una ubicación obligatoria cuando se produce un error, podemos definir el valor DEFER para el parámetro. Sus posibles valores son ENABLE DEFER indica que Oracle Server puede utilizarlo indica que no se puede utilizar Este parámetro se puede alterar de forma dinámica o editando el fichero de parámetros: SQL> ALTER SYSTEM SET log_archive_dest_state_4 = DEFER; log_archive_dest_state_4 = ENABLE

8 Ejemplo de configuración de logs:

9 Activado del Modo ARCHIVELOG Antes de activar el modo archivelog hemos de verificar el modo de trabajo mediante el comando SQL> archive log list; Al ejecutar este comando, se nos informa, entre otras cosas de?? Modo log de la BBDD (Archivelog o Noarchivelog)?? Archivado Automático (Activado o Desactivado)?? Destino del archivado (donde ha de copiar los ficheros de redo log)?? Secuencia de log a archivar?? Secuencia de log actual??... Si se decide trabajar en modo ARCHIVELOG es tarea del DBA indicarlo mediante el comando ALTER DATABASE [ archivelog noarchivelog ] Donde archivelog noarchivelog activa el modo archivado de redo logs desactiva el modo archivado de redo logs Para poder activar o desactivar el modo de archivado, la BBDD no puede estar operativa, ha de estar montada, con lo cual, los pasos para alterar el modo de archivado son los siguientes: 1. Conectado como un usuario con privilegios de alterar el sistema, cerraremos la BBDD SQL> SHUTDOWN IMMEDIATE; 2. Iniciaremos la BBDD en estado MOUNT SQL> STARTUP MOUNT; 3. Definiremos el nuevo modo de archivado SQL> ALTER DATABASE archivelog; 4. Abrir la Base de Datos SQL> ALTER DATABASE open;

10 El archivado de los redo log online puede hacerse de forma AUTOMÁTICA MANUAL mediante el proceso en segundo plano ARCn el DBA es el encargado de realizar la copia Mediante el parámetro LOG_ARCHIVE_START del fichero de parámetros indicamos si el archivado se realizará de forma automática (TRUE) o manual (FALSE). Archivado automático Si queremos que el proceso de copiado de los redo logs online a los archivos logs archivados se realice de forma automática, hemos de definir el parámetro LOG_ARCHIVE_START con un valor TRUE. Al ser un parámetro dinámico, podemos activar el archivado automático con la BBDD abierta mediante el comando SQL> archive log start; Antes deberíamos asegurarnos que nuestra Base de Datos está trabajando en modo ARCHIVELOG mediante el comando SQL> archive log list; Una vez definido el archivado automático, el DBA no ha de preocuparse de lanzar ningún comando para el copiado del redo log cada vez que se llene, esto será tarea de ARC. Archivado manual Si decidimos que sea el DBA el encargado de realizar la copia de los redo logs a los archivos logs archivados, deberá seguir una serie de pasos: 1. Definir el parámetro LOG_ARCHIVE_START a FALSE 2. Asegurarse que la Base de Datos está en modo ARCHIVER 3. Copiar el fichero redo log actual cada vez que este se llene y se produzca un cambio de log. Esto se consigue mediante el comando alter system archive log sequence n; Donde n es el número de secuencia del redo log actual que acaba de ser llenado. Este número se obtiene, por ejemplo, consultando la columna SEQUENCE# de la vista V$ARCHIVED_LOG

11 Debido a que el archivado será manual, el DBA deberá copiar el fichero redo log cuando se produzca un cambio de log. La BBDD puede pasar a un estado de espera si se llenan todos los redo logs y no se ha archivado el primero que se llenó. Por ejemplo Supongamos que mi BBDD tiene 3 grupos de redo log (grupo 1, grupo 2 y grupo 3) de un solo miembro cada grupo. Mi modo de trabajo es ARCHIVELOG MANUAL (lo cuál indica que seré yo el encargado de realizar las copias de los redo logs). Mi Base de Datos está trabajando y?? se llena el grupo 1, se produce un cambio de log y se pasa a escribir en el grupo 2. En este momento yo debería hacer el copiado del grupo 1; pero no lo hago?? se llena el grupo 2, se produce un cambio de log y se pasa a escribir en el grupo 3. En este momento yo debería hacer el copiado del grupo 2 (en el caso en el que hubiese hecho ya el copiado del grupo 1); no lo hago?? se llena el grupo 3 y se intenta producir un cambio de log. Qué ocurre? No se puede reutilizar el grupo 1 ya que no ha sido archivado. Hasta que no se archive, la BBDD está suspendida ; no se pueden realizar operaciones que generen información en redo hasta que no se lance el comando alter system archive log sequence n indicando para n el valor de secuencia correspondiente al primer grupo de redo que se llenó (en este caso el grupo 1). Si se produce un cambio de log y no se ha archivado antes el grupo 2, volverá a ocurrir lo mismo Para evitar más gestión por parte del DBA, normalmente, el archivado de realiza de forma automática

12 Definir varios procesos ARCn Debido a que existen operaciones (principalmente DDL y DML paralelas) que pueden generar gran cantidad de información redo, Oracle permite activar varios procesos ARC. Cómo? Mediante el parámetro LOG_ARCHIVE_MAX_PROCESSES. El valor mínimo es 1 y el máximo 10. Este parámetro es dinámico con lo cuál el DBA puede, en cualquier momento, iniciar o detener procesos adicionales de archivado SQL> ALTER SYSTEM SET 2 LOG_ARCHIVE_MAX_PROCESSES = 3; Desactivar el Proceso de Archivado El proceso de desactivado de la opción de archivado automático se puede realizar con la BBDD abierta, pero para desactivar el modo Archivelog hemos de cerrarla y abrirla en fase MOUNT. Pasos: 1. Ejecutar el comando para detener los procesos ARCn (si estaban activados) SQL> alter system archive log stop; 2. Cerrar la Base de Datos SQL> SHUTDOWN; 3. Desactivar el archivado automático (si estaba activado). Editando el fichero de parámetros y modificando el parámetro LOG_ARCHIVE_START = FALSE 4. Definir la BBDD en modo NOARCHIVELOG SQL> STARTUP MOUNT; SQL> ALTER DATABASE noarchivelog; SQL> ALTER DATABASE open;

13 Vistas Dinámicas relacionadas A continuación se detallan algunas vistas relacionadas con el archivado Vista V$ARCHIVED_LOG Descripción Muestra información de log archivado del archivo de control V$ARCHIVED_DEST Describe todos los destinos de archive log, valor, modo y estado actual de la instancia V$LOG_HISTORY Contiene información sobre el archivo log del archivo de control V$DATABASE Entre otras cosas, muestra información actual de archivado V$ARCHIVE_PROCESSES Información sobre el estado de los distintos procesos ARC de la instancia