Automatizar recover UNTIL CANCEL

Relacionado a mi post anterior, otra de las cosas que ocurre frecuentemente al actualizar una base Oracle de test con un respaldo de producción, es la necesidad de realizar recuperación incompleta UNTIL CANCEL. En este caso la sentencia RECOVER nos va a preguntar qué archivelogs se debe aplicar para dejar la base en un estado consistente.

08:41:07 SYS@test>recover database until cancel using backup controlfile;
ORA-00279: change 2691063472 generated at 03/12/2013 01:30:02 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58643_%u_.arc
ORA-00280: change 2691063472 for thread 1 is in sequence #58643


08:41:29 Specify log: {=suggested | filename | AUTO | CANCEL}

Si estamos recuperando al momento en que se tomó el respaldo, éste incluye archivelogs y ya los copiamos desde el respaldo al directorio sugerido (/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13), entonces podemos indicar AUTO para que los aplique sin mayores problemas.
Como referencia, la restauración de archivelogs con RMAN se hace con el comando 'restore archivelog ...'.

Cuando es necesario ir a un momento en el tiempo posterior, usando respaldos adicionales de archivelogs, y sin tener definido con exactitud el tiempo al que queremos llegar, debemos ir aceptando manualmente cada archivelog para luego ver si es hasta ahí donde queremos llegar (por ejemplo si interesa recuperar hasta el momento previo en que se borraron datos en una tabla, y no contamos con la funcionalidad FLASHBACK).

Al presionar enter y aceptar la sugerencia, si el archivo existe en el destino se aplica:

08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
 
ORA-00279: change 2691076177 generated at 03/12/2013 02:02:53 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/TEST/archivelog/2013_03_13/o1_mf_1_58644_%u_.arc
ORA-00280: change 2691076177 for thread 1 is in sequence #58644
ORA-00278: log file '/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58643_8n0rj3kr_.arc' no
longer needed for this recovery

Si todavía no trajimos este archivelog desde el respaldo, o lo dejamos en otro directorio, va a dar este error:

08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
 
ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58645_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Luego que aplicamos todos los archivelogs que nos parecen necesarios para llegar al tiempo que nos interesa, ingresamos CANCEL. Y aquí es donde puede aparecer el problema: la base todavía no está en un punto consistente.

08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u02/oradata/test/system01.dbf'

Esto es un aviso de que nos faltó aplicar archivelogs, o que nos pasamos del punto que nos interesaba (si tenemos varios respaldos de archivelogs y los trajimos todos, podemos estar aplicando ya el siguiente grupo de archivos).

Cuando cancelamos la recuperación y llegamos a un punto consistente, el mensaje es claro:

09:07:53 Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

Ahora sí queda la base lista para ser usada después de abrirla con resetlogs.

09:08:00 SYS@test>alter database open resetlogs;

Database altered.

Si tenemos muchos archivelogs para aplicar, estar pendiente de la pregunta para presionar enter es algo tedioso, y se puede automatizar fácilmente con un script en bash, que continúa la aplicación mientras el resultado de cancelar el recovery no sea exitoso:

#/bin/bash
###############################
# reco.sh
#
# ncalero 5/2010 - recupera aplicando
# archivelogs hasta que CANCEL sea exitoso
#
###############################

RESULT=/tmp/reco.txt
LOG=/tmp/reco-full.txt

# flag que cuenta si aparecen estos errores. Termina cuando sea cero
SIGO=1
while [ $SIGO -gt 0 ]; do
echo "..."
sqlplus / as sysdba <$RESULT 2>&1
recover database until cancel using backup controlfile;
CANCEL
exit;
EOF

# buscamos mensaje "ORA-01194: file 1 needs more recovery to be consistent"
SIGO=`grep -c 01194 $RESULT`
echo "ora-1194 = $SIGO"

if [[ $SIGO -gt 0 ]] ; then
   # se dio el error, hacemos doble validacion con el otro error
   # ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
   SIGO=`grep -c 01547 $RESULT`
   echo "ora-1547 = $SIGO"
fi
cat $RESULT >>$LOG
done

echo " ### Se puede recuperar!!! ### "

Al ejecutar este script, se muestran dos líneas por errores de intentar cancelar, y termina cuando la base queda en un estado consistente:

oracle@oraculo:/local/work/scripts> ./reco.sh
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
### Se puede recuperar!!! ###

Una última consideración: si cuando ingresamos cancel nos dice que necesita más recovery e intentamos resolver el problema dejando la base en un punto anterior en el tiempo al último archivelog aplicado, vamos a obtener el siguiente error:

RMAN> recover database until scn 2691031554;
Starting recover at 12/MAR/2013 09:14:47
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/12/2013 09:14:48
RMAN-06556: datafile 1 must be restored from backup older than scn 2691031554

Esto se debe a que no podemos deshacer la aplicación de archivelogs que hicimos antes con el comando RECOVER. Tenemos que volver a traer los datafile desde el respaldo con el que empezamos esta maniobra y aplicar los archivelogs hasta ese punto, sin volver a pasarnos.

Espero que les sea útil.
Un saludo.