RMAN: Como hacer para Restaurar y/o Recuperar solo los "Tablespaces" esenciales.

Por Joel Pérez & Yenugula Venkata RaviKumar (OCM)
Publicado en Junio 2014

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de visualizar y adentrarnos un poco en el tema restauración/recuperación de base de datos ( BBDDs ) utilizando la opción “Skip Tablespace”.
En el contexto de recuperaciones de BBDDs existen extensas y diversas técnicas para llevar a feliz termino el objetivo. Tal cual como un traje hecho a la medida, no se conocerá de las medidas hasta no tener al cliente al frente. Todos los casos siempre son distintos, las situaciones siempre son diversas en su mayoría. En una infraestructura que contenga una BBDD jamás sabremos que va a fallar, ni bajo que condiciones ocurrirá. De nosotros dependerá tener la experticia a mano para resolver el evento con rapidez, sapiencia y eficiencia.
Los comandos y opciones de RMAN son como las clases distintas de bisturíes para un cirujano. Se utilizan de forma adecuada y justa de acuerdo al caso. 
Planteemos el siguiente escenario: día 31 de cualquier mes del año. 6:00pm de la tarde. Día oscuro y lluvioso con mucha existencia de rayos. Un rayo impacta cerca de las instalaciones eléctricas de la compañía y causa un evento de desnivel de energía eléctrica. La infraestructura de servidores, SAN y demás componentes no estaban protegidos para desniveles de energía. Todos los componentes ( Servidores, SAN ) tuvieron caídas abruptas de energía eléctrica. Cuando ya la misma estaba restablecida, se decide encender los equipos y aparece el siguiente mensaje al ejecutar el startup de la BBDD; …. “problemas con el datafile 1, ORA-01110: data file 1….” el de system… . BBDD de 400GB ( 100GB en data con perfil transaccional “OLTP” activo y 300GB en históricos ).
Tiempo de Recuperación total estimado : 8 horas.
Misión: recuperar la BBDD lo más pronto posible para poder realizar el cierre del mes antes de las 12:00 de la media noche.
Particularidad del caso: solo 100GB de data son los más importantes y claves para el cierre, los otros 300GB son de históricos. Ambas divisiones del negocio ( Transaccional e Histórico ) se encuentran en “Tablespaces” bien distribuidos.
Pregunta: hay alguna opción para recuperar la BBDD solo con los “Tablespaces” necesarios para el cierre con opción a recuperar el resto posteriormente… ?
Respuesta: si… si hay una opción: “SKIP TABLESPACE” de RMAN…
Escenario: tenemos un caso de fallo total de la BBDD respecto a sus “datafiles”, deseamos recuperar de forma inmediata solo aquellos críticos para el negocio y posteriormente recuperaremos el resto manteniendo una consistencia lineal en la historia de la data. Veamos como hacerlo:
Nota: se utilizo “Oracle Database 10gR2” para el presente caso pero la misma es valida para todas las versiones superiores de Oracle incluyendo “Oracle Database 12c”.
BBDD Origen: MYDB
Datafiles en Filesystem: /tmp/MYDB
Modo Archive: Activo
Visualización de Datafiles y Tablespaces
Reconocimiento de Datafiles:

[oracle@MyjpServer ~]$ export ORACLE_SID=MYDB
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.5.0 - Production on Wed Aug 8 15:10:36 2012
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
SQL> select tablespace_name from dba_tablespaces;

TABLESPACE_NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     1
Next log sequence to archive   1
Current log sequence           1
SQL>
SQL>

Visualizado de archivos físicos de BBDD:

[oracle@MyjpServer ~]$ cd /tmp/MYDB/
[oracle@MyjpServer MYDB]$ ls -lt
total 902384
-rw-r----- 1 oracle oinstall   7061504 Aug  8 15:10 control01.ctl
-rw-r----- 1 oracle oinstall   7061504 Aug  8 15:10 control02.ctl
-rw-r----- 1 oracle oinstall   7061504 Aug  8 15:10 control03.ctl
-rw-r----- 1 oracle oinstall  52429312 Aug  8 15:10 redo01.log
-rw-r----- 1 oracle oinstall 251666432 Aug  8 15:05 sysaux01.dbf
-rw-r----- 1 oracle oinstall 461381632 Aug  8 15:05 system01.dbf
-rw-r----- 1 oracle oinstall  26222592 Aug  8 15:05 undotbs01.dbf
-rw-r----- 1 oracle oinstall  52429312 Aug  8 15:00 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Aug  8 15:00 redo03.log
-rw-r----- 1 oracle oinstall   5251072 Aug  8 15:00 users01.dbf
-rw-r----- 1 oracle oinstall  20979712 Aug  8 14:59 temp01.dbf
[oracle@MyjpServer MYDB]$


Creación de tablespace TBSP_JP

En el tablespace “TBSP_JP” estará alojada la información equivalente a la data histórica de la cual hicimos mención en el planteamiento del escenario.

SQL> create tablespace tbsp_jp
2  datafile '/tmp/MYDB/tbsp_jp01.dbf' size 30m;
Tablespace created.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
TBSP_JP

6 rows selected.

SQL> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
/tmp/MYDB/tbsp_jp01.dbf

SQL>


Creacion de Usuario “jp”

El usuario “jp” contendrá data de muestra que se utilizara para comprobar el concepto de recuperación parcial de la BBDD.

SQL> create user jp identified by jp
2  default tablespace TBSP_JP
3  quota unlimited on TBSP_JP;

User created.

SQL> grant create session, create table to jp;

Grant succeeded.

SQL>
SQL> conn jp/jp
Connected.
SQL>
SQL> create table MyjpTable ( c1 number );

Table created.

SQL> insert into MyjpTable values (1000);

1 row created.

SQL> commit;

Commit complete.

SQL>
SQL> select OWNER, TABLESPACE_NAME from dba_segments
2  where SEGMENT_NAME='MYJPTABLE';

OWNER                          TABLESPACE_NAME
------------------------------ ------------------------------
JP                             TBSP_JP


Asegurado de la transacción en Archive Redo Logs:

SQL> alter system switch logfile;
System altered.
SQL> 


Backup Full de la BBDD

Realizamos un backup full a la BBDD

SQL> ho rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:20:54 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database: MYDB (DBID=2705782573)
RMAN> backup database;
Starting backup at 08/08/2012
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/tmp/MYDB/system01.dbf
input datafile fno=00003 name=/tmp/MYDB/sysaux01.dbf
input datafile fno=00005 name=/tmp/MYDB/tbsp_jp01.dbf
input datafile fno=00002 name=/tmp/MYDB/undotbs01.dbf
input datafile fno=00004 name=/tmp/MYDB/users01.dbf
channel ORA_DISK_1: starting piece 1 at 08/08/2012
channel ORA_DISK_1: finished piece 1 at 08/08/2012
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/ 2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 08/08/2012
channel ORA_DISK_1: finished piece 1 at 08/08/2012
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/ 2012_08_08/o1_mf_ncsnf_TAG20120808T152111_825p31hm_.bkp tag=TAG20120808T152111 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 08/08/2012
RMAN>


Simulamos un “crash” de BBDD

Removiendo todos los datafiles

SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
/tmp/MYDB/users01.dbf
/tmp/MYDB/sysaux01.dbf
/tmp/MYDB/undotbs01.dbf
/tmp/MYDB/system01.dbf
/tmp/MYDB/tbsp_jp01.dbf

SQL> ho rm /tmp/MYDB/*.dbf
SQL>
SQL> ho ls -lt /tmp/MYDB/
total 174504
-rw-r----- 1 oracle oinstall  7061504 Aug  8 15:25 control01.ctl
-rw-r----- 1 oracle oinstall  7061504 Aug  8 15:25 control02.ctl
-rw-r----- 1 oracle oinstall  7061504 Aug  8 15:25 control03.ctl
-rw-r----- 1 oracle oinstall 52429312 Aug  8 15:24 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Aug  8 15:24 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Aug  8 15:24 redo03.log
SQL>

Se intenta consultar la tabla del schema “jp”. Obtenemos el mensaje de error por “crash” de instancia. Se intenta realizar el proceso de “startup” y surge el error esperado relacionado con la no ubicación del primer datafile que el mecanismo de BBDDs Oracle comprueba.

SQL> select * from jp.myjptable;
select * from jp.myjptable
*
ERROR at line 1:
ORA-03135: connection lost contact

SQL> exit;

[oracle@MyjpServer ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 - Production on Wed Aug 8 15:26:35 2012
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.
Total System Global Area  583008256 bytes
Fixed Size                  2097984 bytes
Variable Size             159386816 bytes
Database Buffers          415236096 bytes
Redo Buffers                6287360 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/tmp/MYDB/system01.dbf'


Recuperando solo una parcialidad de la BBDD

Estando la instancia en modo “mount” se procede a realizar la técnica principal del artículo. Restaurar la BBDD con excepción de “Tablespaces” denotados en la sentencia. Si se desean agregar mas “tablespaces” a ser obviados en el “restore” se adicionan con separación de ”,”. Para el presente caso solo estaremos realizando el “skip” del tablespace “tbsp_jp”.

SQL> ho rman target 

Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:26:54 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: MYDB (DBID=2705782573, not open)

RMAN> restore database skip tablespace tbsp_jp;

Starting restore at 08/08/2012
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /tmp/MYDB/system01.dbf
restoring datafile 00002 to /tmp/MYDB/undotbs01.dbf
restoring datafile 00003 to /tmp/MYDB/sysaux01.dbf
restoring datafile 00004 to /tmp/MYDB/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/ 2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 08/08/2012
RMAN>


Recover Database

Si intentamos aplicar la sentencia de “recover database” sin especificar el tablespace que no se restauro, obtendremos el mensaje de que el mismo debe ser restaurado. Para la aplicación de esta técnica, el “recover” debe poseer la misma clausula aplicada al “restore database”.

RMAN> recover database;
Starting recover at 08/08/2012
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/08/2012 15:31:06
RMAN-06094: datafile 5 must be restored
RMAN> recover database skip tablespace tbsp_jp;

Starting recover at 08/08/2012
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 08/08/2012
RMAN>


Startup

Una vez aplicada la técnica, procedemos a la apertura de la BBDD. El mecanismo de consistencia de controlfiles-datafiles no esta anuente de nuestro propósito y realiza el chequeo de todos los datafiles existente en el diccionario de datos. Siendo así, obtenemos el mensaje de que el “Datafile” 5 no es identificable en el sistema operativo.

SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area  583008256 bytes
Fixed Size                  2097984 bytes
Variable Size             159386816 bytes
Database Buffers          415236096 bytes
Redo Buffers                6287360 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/tmp/MYDB/tbsp_jp01.dbf'


Datafile Offline

A todos los “Datafiles” que deseemos obviar en la recuperación, debemos establecerle estatus “offline” cuando la instancia se encuentre en modo “mount”. De esta manera la BBDD podrá aperturarse de forma perfecta. Al final de esta etapa tendremos la BBDD abierta con la recuperación de todos los tablespaces a excepción del tablespace “tbsp_jp”

SQL> alter database datafile 5 offline;
Database altered.
SQL>
SQL>
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area  583008256 bytes
Fixed Size                  2097984 bytes
Variable Size             159386816 bytes
Database Buffers          415236096 bytes
Redo Buffers                6287360 bytes
Database mounted.
Database opened.
SQL>
SQL> select * from dual;
D
-
X
SQL>


Consulta a la data del Schema “jp”
Si tratamos de consultar la data de cualquier objeto contenido en el tablespace “tbsp_jp” naturalmente obtendremos el mensaje de la no disponibilidad del mismo.

SQL> select * from jp.myjptable;
select * from jp.myjptable
*
ERROR at line 1:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/tmp/MYDB/tbsp_jp01.dbf'
SQL>


Continuidad de Trabajo
La BBDD podrá seguir trabajando de forma perfecta acumulando data de forma consistente

SQL> alter system switch logfile;
System altered.
SQL> r
1* alter system switch logfile
System altered.
SQL>


Restaurado del Tablespace “tbsp_jp”

Cuando ya estemos disponible para recuperar parte de la data que no se restauro lo realizamos de la manera tradicional como se lleva a cabo el “restore” & “recover” de un tablespace regular. El tablespace será restaurado; los archives serán aplicados hasta el scn mas actualizado de la BBDD para que así, este tablespace puede formar parte de la BBDD. Esta operación se esta llevando a cabo con la BBDD abierta.

SQL> ho rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Wed Aug 8 15:38:04 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database: MYDB (DBID=2705782573)
RMAN> restore tablespace tbsp_jp;
Starting restore at 08/08/2012
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=143 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to /tmp/MYDB/tbsp_jp01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/product/10.2.0/ flash_recovery_area/MYDB/backupset/2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/backupset/ 2012_08_08/o1_mf_nnndf_TAG20120808T152111_825p2868_.bkp tag=TAG20120808T152111
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 08/08/2012
RMAN> recover tablespace tbsp_jp;
Starting recover at 08/08/2012
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/product/10.2.0/
flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_3_825p8g7n_.arc
archive log thread 1 sequence 4 is already on disk as file /u01/app/oracle/product/10.2.0/ flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_4_825px555_.arc
archive log thread 1 sequence 5 is already on disk as file /u01/app/oracle/product/10.2.0/ flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_5_825q0x3v_.arc
archive log thread 1 sequence 6 is already on disk as file /u01/app/oracle/product/10.2.0/ flash_recovery_area/MYDB/archivelog/2012_08_08/o1_mf_1_6_825q0yof_.arc
archive log filename=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/archivelog/ 2012_08_08/o1_mf_1_3_825p8g7n_.arc thread=1 sequence=3
archive log filename=/u01/app/oracle/product/10.2.0/flash_recovery_area/MYDB/archivelog/ 2012_08_08/o1_mf_1_4_825px555_.arc thread=1 sequence=4
media recovery complete, elapsed time: 00:00:01
Finished recover at 08/08/2012
RMAN> sql 'alter tablespace tbsp_jp online';
sql statement: alter tablespace tbsp_jp online
RMAN>


Chequeo del trabajo realizado

Se visualiza el tablespace “online” y nuestra data recuperada perfectamente

SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces;
TABLESPACE_NAME                STATUS
------------------------------ ---------
SYSTEM                         ONLINE
UNDOTBS1                       ONLINE
SYSAUX                         ONLINE
TEMP                           ONLINE
USERS                          ONLINE
TBSP_JP                        ONLINE
6 rows selected.
SQL>
SQL> select * from jp.myjptable;
C1
----------
1000
SQL>


Nota Importante
: esta técnica solo se podrá llevar a cabo siempre y cuando no exista la necesidad de abrir la BBDD en modo “resetlogs”. Si por algún motivo la BBDD tuviese que apertura se en modo “resetlogs” ya la técnica no aplicaría, debido a que el “Controlfile” obtendría un nuevo nivel de “incarnation” y los “Backups” anteriores ya no tendrían validez. Para lograr una recuperación sin necesidad de apertura de la BBDD en modo “resetlogs” se tendrá que disponer de forma perfecta del ultimo grupo de redo log en estatus “current” al momento de la falla. Si hubiese perdida de al menos el grupo de “Redo Log” en estatus “current” al momento de la falla, se tendrá que restaurar completamente la BBDD y siendo ese el escenario ya no se podría realizar una recuperación parcial con opción a recuperación complementaria posterior tal cual como se desarrollo en el articulo.

Conclusión
“Voila” de esta manera experimentamos una recuperación parcial de una BBDD en base a un objetivo de restablecimiento pronto de servicios. La misma estaba basada en una arquitectura lógica de negocio de separación de “Tablespaces” ( “OLTP” & DWH “Históricos” ).

Para una empresa que posea tiempos de recuperaciones muy lentos, causados por hardware, disco, SAN, etc. Esta técnica podría representar una opción rápida de poseer disponible parte de la BBDD sin necesidad de depender de un restaurado total.

Hago remembranzas de una ocasión cuando tuve un caso parecido; un cliente tenia una BBDD de aproximadamente 1TB. Tuvo una falla y la recuperación tardaba 2 días aproximadamente. En esa caso se recuperaron los “Tablespaces” claves de una BBDD Oracle ( system, undo, sysaux, etc ) y los claves del negocio y de forma progresiva se fue restaurando el resto de los “Tablespaces”. Una vez abierta la BBDD se establecio recuperaciones de “Tablespaces” paralelas a cargo de los nodos del RAC y así se acortaron los tiempos. Era una infraestructura de RAC, en un nodo se establecieron las recuperaciones de ciertos “Tablespaces” y en el otro nodo se establecieron los restantes. Los cuellos de botellas formados por exceso de trabajo a nivel de I/O eran recíprocos porque ambos nodos poseían el “storage” compartido como es natural en RAC pero el consumo de CPU en la actividad si era individual para cada nodo.

Así como este caso podrán existir muchos más. Lo importante para los diversos escenarios es conocer la naturaleza implícita de cada uno de ellos, poseer un amplio abanico de técnicas y comandos para poder ajustarse a las variantes del mismo.
 


Joel es un experto DBA con más de 12 años de experiencia, especializado en bases de datos con especial énfasis en la soluciones de alta disponibilidad (RAC, Data Guard, y otras). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en más de 20 países alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003, Oracle ACE año 2004 y actualmente Oracle ACE Director.

Yenugula Venkata Ravikumar es un DBA con más de 15 años de experiencia especializada en entornos de alta disponibilidad de bases de datos (RAC, Data Guard, entre otros), afinamiento y rendimiento, migraciones, backup y recuperación, Oracle Exadata X2 y X3, es experto en sistemas operativos tales como AIX, HP-UX y Linux. Ha participado como conferencista en varios eventos de Oracle en la India, donde reside actualmente. Obtuvo el título "Oracle Certified Master (OCM 10g)" en el 2009.