Avisos de recuperación de datos

Los términos recuperación y restauración tienen sentidos precisos en el ambiente de Oracle.

Restaurar un archivo: Es extraerlo de la copia de seguridad y ponerlo donde se hizo, si un archivo fuera dañado o no estuviera, la restauración lo reemplazara por una copia de seguridad, pero este archivo no estará actualizado comparado con el resto de la base de datos.

Recuperar un archivo: Es extraer los vectores de cambio relevante del redo log y aplicarlo para que los archivos estén sincronizados con el resto de la base de datos. DRA: DRA significa Asesor de Recuperación de Datos, y se encarga de diagnosticar y reparar problemas de una base datos, se usa con RMAN y Enterprise Manager. El asesor es capaz de generar scripts para reparar ficheros dañados y el controlfile, pero no aconseja sobre el SPFILE y ONLINE REDO LOG FILES.

Trabaja con la información que proporciona el ADR (AUTOMATIC DIAGNOSTIC RESPOSITORY) y el Health Monitor, realizando el proceso más rápido y menos propenso al error. Para evitar perder datos tenemos que realizar las siguientes operativas:

• Multiplexacion del fichero de control.

• Multiplexacion de los Online Redo log Files.B

• Backup del fichero de control y de los ficheros.

• Poner la base de datos en modo archivelog.

Dependiendo del fichero perdido, se utilizará diferentes técnicas de recuperación.

Recuperacion de la pérdida del fichero de control.

Haciendo copias multiplexadas nos aseguramos de que el fichero de control nunca sea perdido, de forma que si una copia se perdiera otra estará disponible y la sustituirá.

Si una copia del fichero de control es dañada la instancia de la base de datos abortara inmediatamente, si intentamos inicializarla, la instancia pasara al modo nomount, pero se parara ahí, no montara la base de datos hasta que todas las copias, especificadas en el parámetro de la instancia CONTROL _ FILES estén bien.

Para saber si el fichero de control esta multiplexado se puede usar la siguiente sentencia:

• SELECT NAME FROM V$CONTROLFILE

Mostrará todas las copias en una lista, si esta devuelve tan solo una fila, no estará multiplexado. Entoncesdebemos multiplexar el fichero de control en tiempo de indisponibilidad de la base datos. El proceso seria:

• Shutdown de la base de datos.

• Copiar el controlfile.

• Startup de la instancia en modo no mount.

• Cambiar el parámetro control_files para incluir la nueva copia.

• Shutdown nuevamente.

• Startup de la base de datos en modo open.

Si el fichero de control es copiado cuando la base de datos esta en open o mount la copia no será válida, para conocer que copias del controfile buscamos, podemos hacer la siguiente consulta:

• SELECT VALUE FROM V$PARAMETER WHERE NAME=[CONTROL_FILES]

Para encontrar una copia dañada o perdida hay que consultar el fichero ALERT_LOG, este fichero se encuentra donde indica el parámetro BACKGORUND_DUMP_DEST y el nombre del fichero sería ALERT_INSTANCENAME.LOG

Una vez localizado el fichero de control malo y los buenos, solo es necesario copiar una de las copias buenas sobre el archivo dañado.

Recuperación de un miembro del online redo log file.

Si hay copias multiplexadas de los grupos del Online Redo Log File y se pierde un miembro no habrá problemas, mientras un mientras sea valido, pero el Alert Log nos avisará de esto.

La perdida de un miembro del redo log file no será registrado en el sistema de alerta. Para ver si los Online Redo Log File son multiplexados y ver el estado de cada uno se puede realizar la siguiente consulta:

• SELECT * FROM V$LOGFILE

Si alguno de ellos está en estado invalido, habrá que corregir la situación, para reparar el miembro dañado lo más simple es usar el siguiente comando que borrará y recreará todos los miembros del grupo.

Si el grupo del Online Redo Log File no es el activo se puede usar el siguiente comando:

• ALTER DATABASE CLEAR LOGFILE GROUP 3

Pero si el grupo es el actual o activo, el comando fallará y se tendrá que usar los siguientes comandos:

• ALTER SYSTEM SWITCH LOGFILE

• ALTER SYSTEM CHECKPOINT

• ALTER SYSTEM ARCHIVE LOG ALL

Pérdida de datafiles en modo noarchivelog.

En modo noarchivelog no es posible recuperar un fichero, redo necesita realizar un backup forward en el tiempo que no está disponible, y no es posible abrir una base de datos con fichero de datos que no están actualizados.

Si algún fichero de datos es dañado, solo hay 2 opciones:

• Es hacer que Oracle nunca busque el fichero de datos, borrando el tablespace. O hacer una restauración completa de la base de datos, actualizando todos los ficheros de datos y el fichero de control desde el último backup.

Si no se tiene copias de los Online Redo Log Files, se puede recrear abriendo la base de datos con el comando:

• ALTER DATABASE OPEN RESETLOGS

Pérdida de datafiles en modo archivelog.

Los ficheros de datos que hacen el tablespace SYSTEM y UNDO son críticos. Si algunos de ellos son dañados mientras la base datos está abierta, está abortará. Los demás tablespace no son críticos, la base de datos los pondrá offline automáticamente y permanecerá abierta. Si la base de datos se apaga y el archivo dañado o perdido es crítico, no será posible volver a abrirla hasta que haya sido restaurado y recuperado, si no es crítico se pondrá offline manualmente antes de abrir la base de datos y luego será restaurado y recuperado.

Con la base de datos abierta y algunos archivos no críticos offline, esta puede comportarse de modo inesperado, cualquier índice con extents en los archivos offline será inservible, lo que puede llevar a la degradación de la interpretación, o a poner bloqueos por la imposibilidad de chequear los constraints. Algunas de las tablas también pueden estar inservibles, si da el caso de que tengan extent en el fichero offline.

Para diagnosticar el daño de los archivos de datos, ejecutamos la siguiente consulta en modo montado u open:

• SELECT NAME, ONLINE_STATUS, ERROR FROM V$DATAFILE JOIN V$RECOVER_FILE USING (FILE#)

Si la base de datos está en shutdown, los pasos a seguir para reparar un archivo de datos no crítico son los siguientes:

• La base de datos estará