RMAN: Como hacer para Restaurar y/o Recuperar solo los "Tablespaces" esenciales.
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.
No hay comentarios:
Publicar un comentario