Recuperación con RMAN

PROBLEMA:

Dos servidores linux Red Hat 2.1 AS con Oracle 9.2.0.4 en RAC con sistema de ficheros OCFS.
El sistema de ficheros ‘muere’ y no es posible su recuperación del cajón de discos. Solo disponemos de un backup de RMAN en cinta.

SOLUCIÓN:

1. Se recupera el backup de RMAN en el servidor nuevo.
Nota: Yo no tenía espacio y lo hice en otro servidor y lo exporté por NFS.
2. Instalo un servidor con Red Hat 4.7.
3. Creo los mismos File System en el servidor nuevo pero con sistema de fichero ext3 en vez de OCFS, ya que no voy a instalar un RAC.
4. Instalo la base de datos Oracle 9.2.0.4, instalando el software para crear una instancia.
5. Creo el Listener. ($ORACLE_HOME/bin/netca)
6. Creo la instancia. ($ORACLE_HOME/bin/dbca)
7. Bajo la instancia nueva. (SQL> shutdown immediate)
7. Paso el fichero de password del servidor antiguo al nuevo. (fichero de password en $ORACLE_HOME/dbs/orapw[nombre instancia])
8. Creo un init con los valores aproximados de la instancia vieja en el nuevo servidor, sin los valores RAC.
9. Compruebo los tnsnames.ora, sqlnet.ora y listener.ora nuevos. ($ORACLE_HOME/network/admin).
10. Me conecto a RMAN.

# rman target sys/[contraseña] nocatalog * Conexión

set DBID 1874149980; * DBID de la base de datos. Desde sql sería (select DBID from v$database;)
startup nomount * se inicia la instancia en estado 'nomount'
run {
 restore controlfile from '[ruta]/[fichero de CTL o pieza handle donde está].cf'; * Se recuperan los CTLs (Ficheros de control)
}

11. Después de recuperar los CTLs se cambia el estado de la instancia a ‘mount’ desde RMAN:

alter database mount; * Se cambia la instancia a estado mount.

12. Para recuperar hasta un ‘SCN’ en concreto se puede realizar una query con la instancia montada:

sqlplus "/as sysdba" * Conexión con SYS.

SQL> SELECT min(scn)
FROM (SELECT max(next_change#) scn
FROM v$archived_log
GROUP BY thread#);

Nota: El problema es que la primera recuperación que hice terminó en error, ya que en los backup pieces de RMAN no iban los últimos archivelogs que se crearon mientras se hacía el RMAN (no se incluyeron en el script de backup) por lo que tuve que optar por hacer
un (RMAN> list backup;) para averiguar cuál era el último ‘SCN’ válido, que fue el que puse en el script de recuperación.

13. Desde el estado ‘mount’ se lanza el script de recuperación en RMAN:

run {
 set until scn = 9484606967; * SCN asegurando que está en la pieza de RMAN, no el que dice el CTL.
 ALLOCATE CHANNEL disk1 DEVICE TYPE DISK;
 restore database;
 recover database;
 alter database open resetlogs;
 release channel disk1; }

14. Después de muchas horas el ‘restore’ y el ‘recover’ terminaron correctamente pero el (alter database open resetlogs) no funcionó bien:

ORA-01092: ORACLE instance terminated. Disconnection forced
Así que después de comprobar el alert descubrí en una traza lo siguiente:
ORA-30012: undo tablespace ‘UNDOTBS1’ does not exist or of wrong type

Así que seguí los siguientes pasos:

15. Con la instancia caída pero con el ‘restore’ y el ‘recover’ correcto levanto la instancia en ‘nomount’.

# sqlplus "/as sysdba" *Conexión con SYS

SQL> startup nomount * Instancia en estado 'nomount'
SQL> alter system set UNDO_TABLESPACE=”; * Para que deje de apuntar al tablespace corrupto
SQL> alter database mount; * Se cambia a estado 'mount'
SQL> alter database open; * Se abre la instancia
SQL> create undo tablespace UNDOTBS10 datafile '[ruta]/undotbs10.dbf' size 8000M; * Se crea un nuevo tablespace para 'UNDO'
SQL> alter system set UNDO_TABLESPACE=’UNDOTBS10'; * Se apunta 'UNDO_TABLESPACE' al nuevo 'UNDO'
SQL> shutdown immediate; * Se cierra la instancia
SQL> exit;

# vi init[instancia].ora

*.undo_tablespace='UNDOTBS10' * Se cambia en el init el 'UNDO_TABLESPACE'

# sqlplus "/as sysdba" * Conexión con SYS

SQL> startup * Se inicia y se abre la instancia.

16. Ya debería estar todo OK. La base de datos recuperada y la instancia abierta con todos los datos.