Un excelente ejercicio para verificar que los backups se realizan correctemente, es preparar un script que nos haga una restauración a demanda en otro servidor (normalmente preproducción).

Digo una restauración y no un clonado (que es algo realmente impresionante el poder clonar una BD sin pararla hasta el momento actual), porque el clonado necesita que la BD de origen (producción seguramente) tiene que estar abierta y en caso de desastre esto no lo vamos a terner claro.

La restauración que se muestra aquí se realiza sin catálogo RMAN externo (es decir usando el controlfile como catálogo), esto nos obliga tener activa la opción:

Source

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Activada durante el backup de la BD de producción y a tener bien anotado el dbid (esto se puede ver directamente entrando en RMAN en la BD de origen).

El principal problema aparece cuando se intenta restaurar una BD y no se especifica bien hasta donde se quiere restaurar. Si trabajamos por fecha y se han realizado backups de forma frecuente o el backup es de hace algunas horas, es posible que no tengamos éxito y nos indique RMAN que algunos datafiles necesitan más recuperación.

Para solucionar este problema lo mejor es consultar el número máximo de secuencia que tenemos en el controlfile recien restaurado. Esto lo podemos obtener con  (fichero «obtiene_secuencia.sql»):

Source

SELECT max(SEQUENCE#) as secuencia from v$archived_log;
exit

Que durante la ejecución del siguiente script es llamado (fichero «restaura_rman.sh»):

Source

#!/bin/bash
export ORACLE_HOME=/oracle/u02/app/oracle/product/10.2.0/db_1
export ORACLE_BASE=/oracle/u02/app/oracle
export ORACLE_SID=FPYS
export PATH=$ORACLE_HOME/bin:$PATH
export TNS_ADMIN=$ORACLE_HOME/network/admin
echo `date`
echo "##### Para bd"
sqlplus / as sysdba << EOF
shutdown abort;
EOF
echo `date`
echo "##### Elimina todos los ficheros de BD "
rm /oracle/u03/datafiles/FPYS/*
rm /oracle/u03/archivelog/fpys/*
echo `date`
echo "##### Arranca en nomount, restaura controlfile y mount"
rman target=/ nocatalog << EOF
set dbid=2213028659;
run {
startup nomount;
allocate channel t1 type 'SBT_TAPE';
send 'NB_ORA_POLICY=P_Oracle_Full_Semanal, NB_ORA_SERV=serverfpsbackup,NB_ORA_CLIENT=FPYSS53';
restore controlfile from autobackup;
alter database mount;
}
EOF
echo `date`
echo "##### Buscar num secuencia"
secuencia=`sqlplus / as sysdba @/home/oracle/scripts/restauracion_prod/obtiene_secuencia.sql | grep SECUENCIA -A2 | tail -1 | awk {'print $1'}`
echo $secuencia
echo `date`
echo "##### Restaura BD"
rman nocatalog target=/ log=/home/oracle/scripts/restauracion_prod/restaura.rman.log << EOF
run {
allocate channel t1 type 'SBT_TAPE';
send 'NB_ORA_POLICY=P_Oracle_Full_Semanal, NB_ORA_SERV=serverfpsbackup,NB_ORA_CLIENT=FPYSS53';
SET UNTIL SEQUENCE=$secuencia;
restore database;
recover database;
}
EOF
echo `date`
echo "##### Saca la BD del modo archivelog y la abre con resetlogs"
sqlplus / as sysdba << EOF
alter database noarchivelog;
alter database open resetlogs;
EOF
echo `date`
echo "##### Reiniciar BD para una alert limpio y redimensiona tablespace TEMP"
sqlplus / as sysdba << EOF
shutdown immediate;
startup;
ALTER DATABASE TEMPFILE '/oracle/u03/datafiles/FPYS/temp01.dbf' RESIZE 1024M;
EOF
rm /oracle/u03/archivelog/fpys/*

Este script lo que hace es:

1. Para la BD con abort.
2. Elimina todos los datafiles del destino, en este caso está todos en /oracle/u03/datafiles/FPYS
3. Arranca en nomount, restaura controlfile y mount
4. Buscar último número secuencia en el controlfile restaurado.
5. Restaura y recupera la BD.
6. Saca la BD del modo archivelog y abre con resetlogs.
7. Redimensiona el tablespace TEMP, esto hay que hacerlo porque este tablespace no es copiado nunca, simplemente se crea uno de 20M, que es insuficiente.

Por supuesto el servidor de destino tiene que tener el fichero de passwords y parámetros creado para el SID con el que estamos trabajando.

Esta es la forma más segura que he encontrado para verificar que un backup es correcto y está todo correctamente configurado, aseguramos que somos capaces de restaurar en otra máquina, esto es necesario porque algunos sistemas de backup han de ser parametrizados para permitir restaruaciones hechas en una máquina diferente (por ejemplo NetBackup).

En caso de desastre tener todo está más que probado y es muy importante para evitar situaciones «tensas».