17.01 GENERALIDADES DEL DATAR RECOVERY ADVISOR

OBJETIVO DE CERTIFICACION 17.01

GENERALIDADES DEL DATAR RECOVERY ADVISOR.

El Data Recovery Advisor (DRA) es una instalación para diagnostico y reparación de problemas con una Base de Datos. Hay dos interfaces: el ejecutable RMAN y Enterprise Manager.  El DRA es capaz de generar script para reparar daños a DataFiles y (en algunas circunstancias) ControlFile: no asesora problemas con spfile o con online redo log files. Depende del Automatic Diagnostic Repository (ADR) y el Health Monitor. La información que reúne el Health Monitor y el consejo del DRA da a seguir el mismo diagnostico y método de reparación que el DBA seguirá sin ellos-pero hacen el proceso más rápido y menos propenso a error.

La perdida de Archivos de Bases de Datos no es razón para perder datos-siempre que las precauciones apropiadas han sido tomadas:

·         Multiplexar los ControlFiles.

·         Multiplexar los Online Redo Log Files.

·         Backup a ControlFiles y los DataFiles.

·         Ejecutando la Base de Datos en Modo archivelog

Dependiendo el tipo de archivo que se pierde, hay diferentes técnicas para la recuperación.

RECUPERACION DE LA PÉRDIDA DEL CONTROLFILE.

Un punto a enfatizar es que el ControlFile nunca debe ser completamente perdido: debe ser multiplexado, de modo que si una copia de este es perdido, otra copia todavía estará disponible. Si una copia de ControlFile está dañada. La instancia de Base de Datos inmediatamente abortará. Si usted intenta  iniciarla, la instancia ira a modo NOMOUNT pero se detendrá ahí: no va a montar la Base de Datos a menos que todas las copias del ControlFile, según lo especificado por el parámetro de instancia CONTROL_FILES, son validos.

EXAMEN

El daño a cualquier copia de ControlFile abortará la instancia inmediatamente. No será posible montar la Base de Datos hasta que el problema ha sido resuelto.

Para confirmar que el ControlFile está multiplexado, cuando en modo MOUNT u OPEN emita esta consulta:

            select name from v$controlfile;

El cual listara todas las copias de los ControlFiles. Si esta consulta regresa solo un registro, el ControlFile no está multiplexado. Corregir esta situación durante el próximo periodo  de inactividad programado, y si no está programado el tiempo de inactividad, debe programar un periodo pronto como sea posible. El proceso es:

·         Shutdown a la Base de Datos.

·         Copie el ControlFile.

·         Inicie la instancia en modo NOMOUNT.

·         Cambie el parámetro CONTROLFILES para incluir la nueva copia.

·         Shutdown nuevamente.

·         Inicie la Base de Datos en modo OPEN.

Ejecute la consulta dada previamente ahora listara ambas copias. La necesidad de un Shutdown es obtener unacopia consistente del ControlFile.  Si fueron copiados cuando la Base de Datos estaña OPEN o MOUNT, la copia no sería válida.
Si el inicio se detiene en modo NOMOUNT porque la Base de Datos no puede ser montada, determine que copia de ControlFiles, busque con esta consulta.

            select value from v$parameter where name='control_files';

Para saber que copia está dañada o perdida, busque en el Alert Log. Este es el archivo alert_instancename.ora en el directorio señalado por el parámetro BACKGROUND_DUMP_DEST. Las ultimas líneas será algo como esto:

ALTER DATABASE MOUNT

ORA-00210: cannot open the specified control file

ORA-00202: control file: 'D:\APP\ORACLE\ORADATA\ORCL11G\CONTROL02.CTL'

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 2) The system cannot find the file specified.

Mon Fe:b 18 09:01:10 2008

Checker run found 1 new persistent data failures

ORA-205 signalled during: ALTER DATABASE MOUNT...

Para reparar el daño, copia un archivo sobreviviente (uno de los archives listado en la consulta contra V$PARAMETER) sobre el archivo dañado (el archivo mencionado en el Alert Log).

EN EL TRABAJO

Este método de recuperación, aunque es manual, es generalmente el más rápido.  Pero estar absolutamente seguro de que no accidentalmente copie el archivo dañado sobre el bueno. No te rías. Es muy fácil cometer un error como ese, sobre todo cuando se trabaja a toda prisa.

RECUPERACION DE LA PERDIDA DE UN ONLINE REDO LOG FILE MEMBER.

Si su Online Redo Log File Groups son multiplexados, la pérdida de un solo miembro no es un problema. Mientras haya al menos un miembro valido de cada Online Redo Log File Group, la Base de Datos continuará ejecutándose, y si se apaga, se abrirá sin problemas. Pero Oracle no estará feliz: habrá muchos mensajes escritos en el Alert Log.

EN EL TRABAJO

Un Redo Log File Member perdido no será reportado por el Server Alert System.

La situación donde todos los miembros de un grupo son perdidos ( en cuyo caso la instancia abortará y no se puede abrir) esta mas allá del alcance del primer examen.

Para confirmar si el Online Redo Log File Members está multiplexados y para ver el status de cada archivo, ejecute esta consulta:

            select * from v$logfile;

Si cualquier miembro tiene un STATUS de INVALID, usted debe tomar medidas inmediatas para corregir la situación. El status STALE puede ser reportado-esto no es un problema; solo muestra que el archivo no se ha usado todavía. Para reparar un miembro dañado, la técnica más simple es utilizar el comando CLEAR. Este instruirá a Oracle a Eliminar y Recrear todos los miembros del Log File Group 3:

            alter database clear logfile group 3;

           

Si el Log File Group es actual, activo, o (en modo archivelog) unarchived, el CLEAR fallará con un mensaje de error apropiado. Este comando solucionará estas cuestiones:

alter system switch logfile;

alter system checkpoint;

alter system archive log all;

EXAMEN

El daño a un miembro Online Redo Log File no hará que la instancia aborte o evitar la apertura de la Base de Datos, siempre y cuando haya al menos un miembro en funcionamiento por cada grupo.

PERDIDA DE CUALQUIER DATAFILE EN MODO NOARCHIVELOG

En modo NOARCHIVELOG, no puede haber concepto de recuperación: El Redo es necesario para traer un Backup restaurado hacia adelante en el tiempo no está disponible. No es posible abrir una Base de Datos con un DataFile que esta fuera de fecha. Si lo fuera, la integridad del Sistema se vería comprometida. Si cualquier archivo está dañado, las únicas opciones son instruir a Oracle nunca a buscar el archivo otra vez para eliminar el Tablespace del cual es parte, o restaurar la Base de Datos completamente: el conjunto completo de DataFiles y los ControlFiles desde el último Backup. Si usted tiene el Online Redo Log Files así (que por lo general tienen si está haciendo copias de seguridad gestionados por el usuario) restaurar estos también y abra la Base de Datos. Si usted no tiene Backups de Online Redo Log Files, vuelva a crear mediante la apertura de la Base de Datos con este comando:

alter database open resetlogs;

PERDIDA DE UN DATAFILE EN MODO ARCHIVELOG

Los DataFiles que conforman los Tablespace SYSTEM y UNDO son críticos. Si alguno de estos es dañado mientras la Base de Datos está abierta, abortará. Los otros DataFiles son no críticos: La Base de Datos los tomará fuera de línea automáticamente, y la Base de Datos se mantendrá abierta. Si la Base de Dato se cierra, si el DataFile Dañado o perdido es crítico no será posible abrir la Base de Datos hasta que se haya restaurado y recuperado. Si el DataFile es no crítico, debe ser tomado fuera de línea manualmente antes de que la Base de Datos pueda ser abierta, y entonces puede ser restaurado y recuperado mientras las Base de Datos es abierta.

Durante el periodo que la Base de Datos es abierta  pero un archivo no crítico es fuera de línea, las aplicaciones pueden comportarse de maneras inesperadas. Cualquier índice con Extents en el archivo fuera de línea será inutilizable, cual puede conducir a una degradación del rendimiento y también bloqueos a tablas por la imposibilidad de comprobar restricciones. Cualquier tabla con Extents en el archivo fuera de línea será inutilizable, aunque las consultas que se pueden satisfacer con columnas incluidas en los índices pueden todavía trabajar.

Para el diagnostico daño a DataFiles, ejecute esta consulta en modo MOUNT o OPEN.

            select name,online_status,error from v$datafile join v$recover_file using (file#);

Si la Base de Datos esta abajo, los pasos para reparar un DataFile dañado no critico son:

·         Montar la base de Datos (MOUNT).

·         Tomar los archivos dañados fuera de línea.

·         Abrir la Base de Datos (OPEN).

·         Restaurar los archivos dañados (RESTORE).

·         Recuperarlos (RECOVER).

·         Traer los archivos dañado online.

El paso 3 debe ser pospuesto hasta el final si no te importa el periodo de tiempo de inactividad. Si la Base de Datos es abierta, solo los últimos tres pasos son necesarios.

Daño a un DataFile crítico solo puede ser reparado en modo MOUNT, por lo que hay cuatro pasos:

·         Montar la Base de Datos (MOUNT).

·         Restaurar el Archivo Dañado (RESTORE).

·         Recuperarlo (RECOVER).

·         Abrir la Base de Datos.

EXAMEN

            Abrir una Base de Datos es posible a partir de daños causados a cualquier DataFiles  que no pertenecen al Tablespace SYSTEM o UNDO.

EL HEALTH MONITOR Y EL ADR

            El Health Monitor es un conjunto de comprobaciones que se ejecutan automáticamente cuando se presentan ciertas condiciones de error, o manualmente en respuesta a instrucciones del DBA. Los resultados de las comprobaciones no son almacenadas en la Base de Datos, sino en el Sistema de Archivos. Esto es porque la naturaleza de algunos errores es tal que la Base de Datos no está disponible. Es por lo tanto esencial tener un repositorio externo para los resultados del Health Monitor. Este repositorio es el ADR, que se encuentra en el directorio especificado por el parámetro de instancia DIAGNOSTIC_DEST.

            Diferentes comprobaciones del Health Monitor pueden ejecutarse en varias etapas:

·         En modo NOMOUNT, solo la comprobación “DB Structure Integrity” puede ejecutarse, y puede únicamente comprobar la integridad del ControlFiles.

·         En modo MOUNT, la comprobación “DB Structure Integrity”  comprobará la integridad de los ControlFiles, y de los Online Redo Log File y los DataFile Headers. El “Redo Integrity Check” puede también ejecutarse, que comprobará los Online  y Archive Log Files por la accesibilidad y corrupción.

·         En modo OPEN, es posible ejecutar comprobaciones  que escanearan cada Data Block por corrupción, y comprobara la integridad del Diccionario de Datos y los Segmentos UNDO.

Las interfaces que permitirán la ejecución manual de comprobaciones del  Health Monitor están disponibles solo cuando la Base de Datos está abierta (OPEN). Hay dos interfaces: utilizando  SQL*PLUS para invocar procedimientos del paquete PL/SQL DBMS_HM, y el Database Control. La figura 17-1 muestra la interfaz Database Control. Para alcanzar esta ventana desde la pagina principal del Database Control, tome el Link Advisor Central en la sección de enlaces relacionados, y luego la ficha Checkers.

Desde la ventana mostrada en la figura 17-1, usted puede ver los resultados de todas las ejecuciones de Health Monitor (se ejecutan en respuesta a errores y ejecuciones manuales) y también ejecutar comprobaciones en demanda.

LAS CAPACIDADES Y LIMITACIONES DEL DRA.

 El DRA no puede hacer nada a menos que la instancia este en el Modo NOMOUNT o más. Viene que no puede ayudar si hay un problema con el archivo de inicialización. En modo NOMOUNT, puede diagnosticar problemas con el ControlFile y generar script para restaurar, ya sea mediante el uso de una copia valida o (si no está disponible) mediante la extracción de una copia desde un conjunto de Backup – lo proporciono para encontrar uno. Una vez que la Base de Datos puede llegar a modo MOUNT, el DRA puede diagnosticar problemas con la falta o daño a DataFiles y falta de Online Log File Groups y generar script para reparar.

El DRA (en la actual versión) solo soporta Bases de Datos de single-instance. Si un fallo trae abajo una Base de Datos RAC, usted puede montar en modo Single-Instance, utilizar el DRA para reparar el daño,  y luego apagarlo y abrirlo en modo RAC.  Esta técnica puede no ser capaz para reparar daños que es local a una instancia. El DRA no puede reparar fallos en una Base de Datos primaria  mediante el uso de Blocks o archivos desde una base de datos standby, y no puede reparar fallos en una Base de Datos standby.

EXAMEN

El DRA solo funcionará para Bases de Datos Single-Instance. No puede trabajar con una Base de Datos en cluster RAC, ni con una Base de Datos Data Guard en espera.

EJERCICIO 17-1

UTILICE EL DRA PARA DIAGNOSTICAR Y ASESORAR SOBRE LOS PROBLEMAS.

En este ejercicio, usted causará un problema con la Base de Datos y utilizará el DRA para informar sobre el mismo.

1.     Desde un prompt de sistema operativo, lance el ejecutable RMAN:

rman target /

2.     Confirme que existe una copia Backup completa de todo el Tablespace SYSAUX.

list backup of tablespace sysaux;

Si esta no regresar por lo menos un conjunto backup de tipo FULL, repita el ejercicio 16-2, pasos 6-8.

3.     Baje la instancia y salir de RMAN.

shutdown immediate;

exit;

4.     Utilizando una Utilidad de sistema operativo, elimine los DataFiles del Tablespace SYSAUX que fueron listados en el paso 2. Si utilizas Windows, puede que tenga que detener el Servicio Windows con la instancia que se está ejecutando para liberar el bloqueo a archivos antes de la eliminación.

5.     Conectese a la Base de Datos con SQL*PLUS, y intente iniciar:

startup;

Esta se detendrá en modo MOUNT, con un error recuperando el archivo perdido. Si utiliza Windows, asegúrese que el servicio ha sido iniciado.

6.     Lance el ejecutable RMAN y conéctese, como el paso 1.

7.     Diagnosticar el problema:

8.     Generar recomendación sobre el fallo:

advise failure;

esto sugiere que debe restaurar y recuperar el DataFile, y generar un script de reparación. Abrir el script con cualquier editor de sistema operativo y estudiar el contenido.