MERCADOS FINANCIEROS

miércoles, 27 de mayo de 2015

Clonación RMAN sin conexión a target



Clonación RMAN sin conexión a target


Una tarea frecuente para el DBA es crear una copia de una base de datos existente. Hay varias opciones que dependen de la versión de Oracle en uso,sin considerar el procedimiento clásico de copia manual de archivos por filesystem mientras la base está baja (sin usar utilitarios).
El utilitario RMAN en la versión 11.2 ofrece el comando DUPLICATE para realizar la clonación de una base, con las siguientes variantes:
  • Tomar los datos de una instancia activa
  • Usar un respaldo ya existente
La primera opción es nueva en 11g, y fue mejorada en 12ccon la posibilidad de generar backupsets (http://docs.oracle.com/cd/E16655_01/backup.121/e17630/rcmdupdb.htm#BGBICHDG). Usar un respaldo existente es la opción clásica, y a partir de 11g se introdujeron variantes: podemos conectarnos o no a la base origen (target) y al catálogo RMAN.El detalle completo de lo que implica cada una de estas alternativas se puede ver en la documentación en línea: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm#BRADV010
Me interesa mostrar aquí un ejemplo completo de creación de una nueva base en el mismo servidor que la base origen, usando el método de clonación RMAN a partir de respaldos sin conexión a la base origen para una base single instance usando archivos en filesystem (no ASM).
¿Por qué esta opción? Este mecanismo es usado frecuentemente en servidores donde hay varias bases y donde periódicamente se actualizan varias a partir de una. Algo habitual en ambientes de test, capacitación o similares.
También es la forma más simple de crear o actualizar una copia de producción con una sintaxis que permite hacerlo con muy poco código (y en este caso, siempre que se disponga de un respaldo de la base original).
El hecho de que sea en el mismo servidor lo hace más complicado que si fuera en otro, ya que los directorios cambian. Simplificando este procedimiento se puede hacer la copia a otro servidor manteniendo la estructura de directorios, algo también muy frecuente.
No incluyo detalles de la clonación a partir de una instancia activa porque es algo menos frecuente de usar en un entorno de producción, ya que genera mucha actividad de lectura en la base de datos origen. Con las nuevas opciones agregadas en 12c esto se mejora (backup sets y section size) y los detalles amerita otro artículo.
En este ejemplo vamos a crear una base de datos de nombre TEST (SID) a partir de la base origen PROD, siguiendo la recomendación OFA para los directorios: datos en /u02/oradata, binarios en /u01/app/oracle (asumimos que ya existen y se comparten con la base origen), y usando Oracle 11gR2 (11.2.0.2) en Linux x86-64 (OpenSuse 12.3).
Primero vemos los pasos a seguir, luego un ejemplode ejecución completa, y finalmente algunos errores que pueden surgir.

Pasos para realizar la duplicación

1) Crear los directorios donde se va a ubicar la nueva base ($ORACLE_BASE/diag/rdbms/test no es necesario porque se crea de forma automática al crear la base).
mkdir -p /u01/app/oracle/admin/TEST/adump
mkdir /u02/oradata/TEST
mkdir /u01/app/oracle/fast_recovery_area/TEST 

2) Crear archivo de parámetros (pfile).
En versiones anteriores era necesario copiar el archivo de parámetros de la base origen, y luego modificarlo cambiando el nombre de la base y directorios, y agregando los parámetros DB_FILE_NAME_CONVERT / LOG_FILE_NAME_CONVERT. A partir de 11g esto ya no es más obligatorio, pudiendo crear el spfile como copia de la base origen y hacer ajustes de parámetros en la misma sentencia de clonación. Más adelante los detalles. Aprovechando esto, lo único que se precisa en el archivo de parámetros es el nombre de la base:
echo "dbname=TEST" > $ORACLE_HOME/dbs/initTEST.ora

3) Crear el password file de la nueva base. Esto se puede hacer manualmente o agregando el parámetro PASSWORD FILE al comando DUPLICATE.
orapwd file=$ORACLE_HOME/dbs/orapwTEST password=xxxxx entries=10

4) Levantar la nueva base en modo nomount.
set ORACLE_SID=TEST
sqlplus / as sysdba
startup nomount

5) Ejecutar la duplicación.
Vamos a usar el último respaldo completo de la base original, ubicado en /u01/app/oracle/fast_recovery_area/PROD (destino por defecto de respaldos RMAN usando Fast Recovery Area). Notar que en este directorio puede haber muchos respaldos, y el comando DUPLICATE va a tomar el más reciente. Si quisiéramos usar otro respaldo, hay que indicar el path completo (incluyendo backupset/AAAA_MM_DD).
Al elegir no incluir parámetros que conviertan nombres en el archivo pfile, ahora necesitamos hacer más largo este comando:
  • Antes del DUPLICATE usamos la nueva funcionalidad en 11.2 de renombrar varios archivos a la vez, con "SET NEWNAME FOR DATABASE" indicando el nuevo path y la regla para nombrar los nuevos archivos. El modificar “%b” deja el nombre original. Más detalles sobre los valores posibles aquí: http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta2014.htm
  • Al comando DUPLICATE agregamos el parámetro SPFILE para que copie el original, y PARAMETER_VALUE_CONVERT para cambiar nombres de directorios que aparezcan en los parámetros copiados. Hay que tener cuidado en este punto de incluir todos los directorios que referencien a archivos de la base original, ya que si no se cambian se intentarán usar por la nueva base. Una forma simple de no olvidar ninguno es buscarlos en el original:
oracle@oraculo:>strings $ORACLE_HOME/dbs/spfilePROD.ora | grep -i PROD | grep '/'
PROD.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
*.audit_file_dest='/u01/app/oracle/admin/PROD/adump'
*.control_files='/u02/oradata/PROD/control01
.ctl','/u01/app/oracle/fast_recovery_area/PROD/control02.ctl'

Ahora sí, el comando a ejecutar para duplicar es:
run {
SET NEWNAME FOR DATABASE TO '/u02/oradata/TEST/%b'; 
DUPLICATE DATABASE TO "TEST" 
    SPFILE PARAMETER_VALUE_CONVERT '/u02/oradata/PROD/','/u02/oradata/TEST/',
    '/u01/app/oracle/fast_recovery_area/PROD/','/u01/app/oracle/fast_recovery_area/TEST/', 
    '/u01/app/oracle/admin/PROD/', '/u01/app/oracle/admin/TEST/'
     BACKUP LOCATION '/u01/app/oracle/fast_recovery_area/PROD/';
}

Ejemplo completo de duplicación

A continuación vemos un ejemplo completo de ejecutar los comandos mostrados antes.
Primero, validamos si tenemos un respaldo completo de la base origen. Para hacer completo el ejemplo suponemos que no lo tenemos, así que tomamos uno.
Resaltamos en negrita lo ingresado en la terminal, y en rojo las validaciones importantes del resultado de los comandos.
oracle@oraculo:~>. oraenv
ORACLE_SID = [ent11g] ? PROD
The Oracle base remains unchanged with value /u01/app/oracle

oracle@oraculo:~>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 20 08:36:46 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

08:37:13 SYS@PROD>archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     136
Next log sequence to archive   138
Current log sequence           138
08:37:19 SYS@PROD>exit

Disconnected from Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

oracle@oraculo:~>rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Wed Aug 21 09:01:46 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: PROD (DBID=462231560)

RMAN>show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/std/dbs/snapcf_PROD.f'; # default

RMAN>list backup summary;
using target database control file instead of recovery catalog

List of Backups
===============
Key     TY LV S Device Type Completion Time      #Pieces #Copies Compressed Tag
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
14      B  F  A DISK        08/AUG/2012 21:07:42 1       1       NO         TAG20120808T210739
16      B  F  A DISK        08/AUG/2012 21:13:15 1       1       NO         TAG20120808T211308
18      B  F  A DISK        10/AUG/2012 21:18:23 1       1       NO         TAG20120810T211818
20      B  F  A DISK        10/AUG/2012 21:31:41 1       1       NO         TAG20120810T213136
22      B  F  A DISK        10/AUG/2012 21:32:13 1       1       NO         TAG20120810T213209
23      B  F  A DISK        20/AUG/2013 00:08:54 1       1       YES        TAG20130820T000000
24      B  F  A DISK        20/AUG/2013 00:09:01 1       1       NO         TAG20130820T000857
25      B  F  A DISK        20/AUG/2013 08:38:40 1       1       YES        TAG20130820T083839
26      B  F  A DISK        20/AUG/2013 08:38:43 1       1       NO         TAG20130820T083841

RMAN>backup database plus archivelog;
Starting backup at 21/AUG/2013 09:02:10
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=143 device type=DISK
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=135 RECID=10 STAMP=790808277
input archived log thread=1 sequence=136 RECID=11 STAMP=790809179
input archived log thread=1 sequence=137 RECID=12 STAMP=790982292
input archived log thread=1 sequence=138 RECID=13 STAMP=823942366
input archived log thread=1 sequence=139 RECID=14 STAMP=824029333
channel ORA_DISK_1: starting piece 1 at 21/AUG/2013 09:02:14
channel ORA_DISK_1: finished piece 1 at 21/AUG/2013 09:02:29
piece handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/
2013_08_21/o1_mf_annnn_TAG20130821T090213_919c26ob_.bkp tag=TAG20130821T090213 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 21/AUG/2013 09:02:29

Starting backup at 21/AUG/2013 09:02:30
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/oradata/PROD/system01.dbf
input datafile file number=00002 name=/u02/oradata/PROD/sysaux01.dbf
input datafile file number=00003 name=/u02/oradata/PROD/undotbs01.dbf
input datafile file number=00004 name=/u02/oradata/PROD/users01.dbf
input datafile file number=00005 name=/u02/oradata/PROD/prueba.dbf
channel ORA_DISK_1: starting piece 1 at 21/AUG/2013 09:02:30
channel ORA_DISK_1: finished piece 1 at 21/AUG/2013 09:04:35
piece handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/
2013_08_21/o1_mf_nnndf_TAG20130821T090230_919c2tnz_.bkp tag=TAG20130821T090230 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:05
Finished backup at 21/AUG/2013 09:04:35

Starting backup at 21/AUG/2013 09:04:36
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=140 RECID=15 STAMP=824029477
channel ORA_DISK_1: starting piece 1 at 21/AUG/2013 09:04:38
channel ORA_DISK_1: finished piece 1 at 21/AUG/2013 09:04:39
piece handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/
2013_08_21/o1_mf_annnn_TAG20130821T090438_919c6plp_.bkp tag=TAG20130821T090438 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 21/AUG/2013 09:04:39

Starting Control File and SPFILE Autobackup at 21/AUG/2013 09:04:40
piece handle=/u01/app/oracle/fast_recovery_area/PROD/autobackup/
2013_08_21/o1_mf_s_824029480_919c6tsr_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 21/AUG/2013 09:04:47

RMAN>exit
Recovery Manager complete. 

Listado 1 – Toma de respaldo inicial
Ahora sí podemos ejecutar la duplicación:
oracle@oraculo:~>mkdir -p /u01/app/oracle/admin/TEST/adump
oracle@oraculo:~>mkdir -p /u02/oradata/TEST
oracle@oraculo:~>mkdir /u01/app/oracle/fast_recovery_area/TEST
oracle@oraculo:~>orapwd file=/u01/app/oracle/product/11.2.0/std/dbs/
orapwTEST password=secreta entries=10
oracle@oraculo:~>export ORACLE_SID=TEST
oracle@oraculo:~>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Wed Aug 21 09:03:16 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to an idle instance.

09:03:42 SYS@TEST>startup nomount;
ORACLE instance started.

Total System Global Area  217157632 bytes
Fixed Size                  2225064 bytes
Variable Size             159386712 bytes
Database Buffers           50331648 bytes
Redo Buffers                5214208 bytes
09:03:55 SYS@TEST>exit
Disconnected from Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

oracle@oraculo:~>rman auxiliary sys
Recovery Manager: Release 11.2.0.2.0 - Production on Wed Aug 21 09:04:12 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
auxiliary database Password: 
connected to auxiliary database: TEST (not mounted)

RMAN>run {
SET NEWNAME FOR DATABASE TO '/u02/oradata/TEST/%b'; 
DUPLICATE DATABASE TO "TEST" SPFILE PARAMETER_VALUE_CONVERT '/u02/oradata/PROD/',
'/u02/oradata/TEST/','/u01/app/oracle/fast_recovery_area/
PROD/','/u01/app/oracle/fast_recovery_area/TEST/' BACKUP LOCATION '/u01/app
/oracle/fast_recovery_area/PROD/' ;
}
executing command: SET NEWNAME
Starting Duplicate Db at 21/AUG/2013 09:05:14
contents of Memory Script:
{
   restore clone spfile to  '/u01/app/oracle/product/11.2.0/std/dbs/spfileTEST.ora' from 
 '/u01/app/oracle/fast_recovery_area/PROD/autobackup/2013_08_21/o1_mf_s_824029480_919c6tsr_.bkp';
   sql clone "alter system set spfile= ''/u01/app/oracle/product/11.2.0/std/dbs/spfileTEST.ora''";
}
executing Memory Script

Starting restore at 21/AUG/2013 09:05:15
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=96 device type=DISK

channel ORA_AUX_DISK_1: restoring spfile from AUTOBACKUP /u01/app/oracle/fast_recovery_area/
PROD/autobackup/2013_08_21/o1_mf_s_824029480_919c6tsr_.bkp
channel ORA_AUX_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 21/AUG/2013 09:05:16

sql statement: alter system set spfile= ''/u01/app/oracle/product/11.2.0/std/dbs/spfileTEST.ora''

contents of Memory Script:
{
   sql clone "alter system set  db_name = ''TEST'' comment= ''duplicate'' scope=spfile";
   sql clone "alter system set  control_files = ''/u02/oradata/TEST/control01.ctl'', 
   ''/u01/app/oracle/fast_recovery_area/TEST/control02.ctl'' comment= '''' scope=spfile";
   shutdown clone immediate;
   startup clone nomount;
}
executing Memory Script

sql statement: alter system set  db_name =  ''TEST'' comment= ''duplicate'' scope=spfile

sql statement: alter system set  control_files =  ''/u02/oradata/TEST/control01.ctl'', 
''/u01/app/oracle/fast_recovery_area/TEST/control02.ctl'' comment= '''' scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area    1043886080 bytes

Fixed Size                     2233088 bytes
Variable Size                603983104 bytes
Database Buffers             432013312 bytes
Redo Buffers                   5656576 bytes

contents of Memory Script:
{
   sql clone "alter system set  db_name = 
 ''PROD'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set  db_unique_name = 
 ''TEST'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile from  '/u01/app/oracle/fast_recovery_area/
   PROD/autobackup/2013_08_21/o1_mf_s_824029480_919c6tsr_.bkp';
   alter clone database mount;
}
executing Memory Script

sql statement: alter system set  db_name =  ''PROD'' comment= ''Modified by RMAN duplicate'' 
scope=spfile

sql statement: alter system set  db_unique_name =  ''TEST'' comment= ''Modified by RMAN duplicate'' 
scope=spfile

Oracle instance shut down

Oracle instance started

Total System Global Area    1043886080 bytes

Fixed Size                     2233088 bytes
Variable Size                603983104 bytes
Database Buffers             432013312 bytes
Redo Buffers                   5656576 bytes

Starting restore at 21/AUG/2013 09:05:35
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=134 device type=DISK

channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u02/oradata/TEST/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/TEST/control02.ctl
Finished restore at 21/AUG/2013 09:05:36

database mounted
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=134 device type=DISK

contents of Memory Script:
{
   set until scn  2718101;
   set newname for datafile  1 to 
 "/u02/oradata/TEST/system01.dbf";
   set newname for datafile  2 to 
 "/u02/oradata/TEST/sysaux01.dbf";
   set newname for datafile  3 to 
 "/u02/oradata/TEST/undotbs01.dbf";
   set newname for datafile  4 to 
 "/u02/oradata/TEST/users01.dbf";
   set newname for datafile  5 to 
 "/u02/oradata/TEST/prueba.dbf";
   restore
   clone database
   ;
}
executing Memory Script

executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME

Starting restore at 21/AUG/2013 09:05:43
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /u02/oradata/TEST/system01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00002 to /u02/oradata/TEST/sysaux01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to /u02/oradata/TEST/undotbs01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to /u02/oradata/TEST/users01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00005 to /u02/oradata/TEST/prueba.dbf
channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/
PROD/backupset/2013_08_21/o1_mf_nnndf_TAG20130821T090230_919c2tnz_.bkp
channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/PROD/backupset/
2013_08_21/o1_mf_nnndf_TAG20130821T090230_919c2tnz_.bkp tag=TAG20130821T090230
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:01:25
Finished restore at 21/AUG/2013 09:07:09

contents of Memory Script:
{
   switch clone datafile all;
}
executing Memory Script

datafile 1 switched to datafile copy
input datafile copy RECID=6 STAMP=824029629 file name=/u02/oradata/TEST/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=7 STAMP=824029629 file name=/u02/oradata/TEST/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=8 STAMP=824029629 file name=/u02/oradata/TEST/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=9 STAMP=824029629 file name=/u02/oradata/TEST/users01.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=10 STAMP=824029630 file name=/u02/oradata/TEST/prueba.dbf

contents of Memory Script:
{
   set until scn  2718101;
   recover
   clone database
    delete archivelog
   ;
}
executing Memory Script

executing command: SET until clause

Starting recover at 21/AUG/2013 09:07:11
using channel ORA_AUX_DISK_1

starting media recovery

archived log for thread 1 with sequence 139 is already on disk as file /u01/app/oracle/
fast_recovery_area/PROD/archivelog/2013_08_21/o1_mf_1_139_919c23sz_.arc
archived log for thread 1 with sequence 140 is already on disk as file /u01/app/oracle/
fast_recovery_area/PROD/archivelog/2013_08_21/o1_mf_1_140_919c6okc_.arc
archived log file name=/u01/app/oracle/fast_recovery_area/PROD/archivelog/2013_08_21/
o1_mf_1_139_919c23sz_.arc thread=1 sequence=139
archived log file name=/u01/app/oracle/fast_recovery_area/PROD/archivelog/2013_08_21/
o1_mf_1_140_919c6okc_.arc thread=1 sequence=140
media recovery complete, elapsed time: 00:00:02
Finished recover at 21/AUG/2013 09:07:14
Oracle instance started

Total System Global Area    1043886080 bytes

Fixed Size                     2233088 bytes
Variable Size                603983104 bytes
Database Buffers             432013312 bytes
Redo Buffers                   5656576 bytes

contents of Memory Script:
{
   sql clone "alter system set  db_name = 
 ''TEST'' comment=
 ''Reset to original value by RMAN'' scope=spfile";
   sql clone "alter system reset  db_unique_name scope=spfile";
   shutdown clone immediate;
   startup clone nomount;
}
executing Memory Script

sql statement: alter system set  db_name =  ''TEST'' comment= ''Reset to original value by RMAN'' 
scope=spfile

sql statement: alter system reset  db_unique_name scope=spfile

Oracle instance shut down

connected to auxiliary database (not started)
Oracle instance started

Total System Global Area    1043886080 bytes

Fixed Size                     2233088 bytes
Variable Size                603983104 bytes
Database Buffers             432013312 bytes
Redo Buffers                   5656576 bytes
sql statement: CREATE CONTROLFILE REUSE SET DATABASE "TEST" RESETLOGS ARCHIVELOG 
  MAXLOGFILES     16
  MAXLOGMEMBERS      3
  MAXDATAFILES      100
  MAXINSTANCES     8
  MAXLOGHISTORY      292
 LOGFILE
  GROUP  1  SIZE 50 M ,
  GROUP  2  SIZE 50 M ,
  GROUP  3  SIZE 50 M 
 DATAFILE
  '/u02/oradata/TEST/system01.dbf'
 CHARACTER SET WE8ISO8859P15


contents of Memory Script:
{
   set newname for tempfile  1 to 
 "/u02/oradata/TEST/temp01.dbf";
   switch clone tempfile all;
   catalog clone datafilecopy  "/u02/oradata/TEST/sysaux01.dbf", 
 "/u02/oradata/TEST/undotbs01.dbf", 
 "/u02/oradata/TEST/users01.dbf", 
 "/u02/oradata/TEST/prueba.dbf";
   switch clone datafile all;
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to /u02/oradata/TEST/temp01.dbf in control file

cataloged datafile copy
datafile copy file name=/u02/oradata/TEST/sysaux01.dbf RECID=1 STAMP=824029648
cataloged datafile copy
datafile copy file name=/u02/oradata/TEST/undotbs01.dbf RECID=2 STAMP=824029648
cataloged datafile copy
datafile copy file name=/u02/oradata/TEST/users01.dbf RECID=3 STAMP=824029648
cataloged datafile copy
datafile copy file name=/u02/oradata/TEST/prueba.dbf RECID=4 STAMP=824029648

datafile 2 switched to datafile copy
input datafile copy RECID=1 STAMP=824029648 file name=/u02/oradata/TEST/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=2 STAMP=824029648 file name=/u02/oradata/TEST/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=3 STAMP=824029648 file name=/u02/oradata/TEST/users01.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=4 STAMP=824029648 file name=/u02/oradata/TEST/prueba.dbf

contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at 21/AUG/2013 09:07:51

RMAN>exit

Recovery Manager complete. 


Listado 2 – Ejecución de RMAN Duplicate
Vemos que finalizó OK. Validamos cómo quedó la nueva base:
oracle@oraculo:~>ls -lrt /u02/oradata/TEST
total 1430580
-rw-r----- 1 oracle oinstall 744497152 Aug 21 09:07 system01.dbf
-rw-r----- 1 oracle oinstall  99622912 Aug 21 09:07 undotbs01.dbf
-rw-r----- 1 oracle oinstall   5251072 Aug 21 09:07 users01.dbf
-rw-r----- 1 oracle oinstall   5251072 Aug 21 09:07 prueba.dbf
-rw-r----- 1 oracle oinstall 303046656 Aug 21 09:07 temp01.dbf
-rw-r----- 1 oracle oinstall 597696512 Aug 21 09:07 sysaux01.dbf
-rw-r----- 1 oracle oinstall  10076160 Aug 21 09:08 control01.ctl

oracle@oraculo:~>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Wed Aug 21 09:08:47 2013

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

Connected to:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

09:08:48 SYS@TEST>select instance_name, status from v$instance;

INSTANCE_NAME   STATUS
-------------------- ----------------------
TEST   OPEN


Elapsed: 00:00:00.11
09:08:51 SYS@TEST>exit
Disconnected from Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

oracle@oraculo:~>strings $ORACLE_HOME/dbs/spfileTEST.ora
PROD.__db_cache_size=268435456
TEST.__db_cache_size=432013312
PROD.__java_pool_size=4194304
TEST.__java_pool_size=4194304
PROD.__large_pool_size=4194304
TEST.__large_pool_size=4194304
PROD.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
TEST.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
PROD.__pga_aggregate_target=364904448
TEST.__pga_aggregate_target=419430400
PROD.__sga_target=683671552
TEST.__sga_target=629145600
PROD.__shared_io_p
ool_size=0
TEST.__shared_io_pool_size=0
PROD.__shared_pool_size=390070272
TEST.__shared_pool_size=176160768
PROD.__streams_pool_size=4194304
TEST.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/TEST/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/u02/oradata/TEST/control01.ctl','/u01/app/oracle/fast_recovery_area/
TEST/control02.ctl'#Restore Controlfile
*.db_block_size=8192
*.db_domain=''
*.db_name='TEST'#Reset to original value by RMAN
*.db_
recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=10485760000
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=PRODXDB)'
*.memory_target=1048576000
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1' 

Listado 3 – Validaciones
Con esto la nueva base queda funcionando, y podemos ver todos los pasos que fueron realizados por el comando DUPLICATE, lo que sirve para investigar en caso que se genere algún error en el proceso de duplicación.

Errores posibles

Si algunos de los requisitos previos no se cumplen, o no se utilizan los parámetros correctos en el comando DUPLICATE, es posible encontrarse con errores. A continuación se repasan algunos errores que generé de forma intencional omitiendo alguna de las partes del procedimiento descripto antes, para ver las distintas situaciones que se pueden dar y cómo resolverlas.
Si luego de un error vamos a reintentar la duplicación, hay que recordar borrar el nuevo spfile creado por el DUPLICATE (pudo quedar creado con valores incorrectos), y volver a reiniciar la nueva base en modo nomount:
oracle@oraculo:~>rm $ORACLE_HOME/dbs/spfileTEST.ora
oracle@oraculo:~>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Wed Aug 21 08:46:09 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production

08:46:19 SYS@TEST>shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.

08:46:32 SYS@TEST>startup nomount
ORACLE instance started.

Total System Global Area  217157632 bytes
Fixed Size                  2225064 bytes
Variable Size             159386712 bytes
Database Buffers           50331648 bytes
Redo Buffers                5214208 bytes
08:46:43 SYS@TEST>exit

Listado 4 – Previo a reintentar duplicaciones fallidas
Ahora sí, estos son algunos errores que pueden encontrarse y su explicación:
1) RMAN-05569: SPFILE backup not found
Starting Duplicate Db at 20/AUG/2013 08:35:51
RMAN-00571: ====================================================
RMAN-00569: ============= ERROR MESSAGE STACK FOLLOWS ==========
RMAN-00571: ====================================================
RMAN-03002: failure of Duplicate Db command at 08/20/2013 08:35:51
RMAN-05501: aborting duplication of target database
RMAN-05569: SPFILE backup not found in /u01/app/oracle/fast_recovery_area/PROD/backupset/2013_08_20/ 

Este error se produjo porque el autobackup del controlfile/spfile no está en el directorio indicado en el parámetro LOCATION. Notar que este path no es el usado en el ejemplo exitoso anterior, sino que tiene un día en particular, 2013_08_20. Los autobackup se generan bajo el directorio FRA/PROD/autobackup/2013_08_20, por eso no lo encuentra ahí.La solución es copiar a este directorio el archivo de respaldo que incluye el spfile.
2) RMAN-05576: CONTROLFILE backup not found
Starting Duplicate Db at 20/AUG/2013 08:39:09
RMAN-00571: ====================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: ====================================================
RMAN-03002: failure of Duplicate Db command at 08/20/2013 08:39:09
RMAN-05501: aborting duplication of target database
RMAN-05576: CONTROLFILE backup not found for database PROD with DBID 462231560 in 
/u01/app/oracle/fast_recovery_area/PROD/backupset/2013_08_20/ 

Este error es similar al anterior, pero esta vez se pudo encontrar el spfile (o no se copió si no incluyeron la clausula SPFILE en el comando DUPLICATE), pero no pudo encontrar un respaldo del controlfile. En este caso también se apunta a un directorio que no lo tiene, por lo que se resuelve de igual forma, copiando allí el archivo que incluye el respaldo del controfile.
3) ORA-00205: error in identifying control file
RMAN-00571: ===================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: ===================================================
RMAN-03002: failure of Duplicate Db command at 08/20/2013 08:40:52
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-00205: error in identifying control file, 
check alert log for more info 

Este error es delicado porque compromete los controfile de la base original, que pudieron ser sobrescritos al ejecutar el duplicate. Es consecuencia de omitir alguno de los path donde existen controlfiles en el parámetro PARAMETER_VALUE_CONVERT. Esto se puede ver fácilmente inspeccionando la salida previa al error, del mismo comando DUPLICATE, al comienzo cuando ejecuta "alter system set control_files". Para generar este error de ejemplo, omití el par '/u01/app/oracle/fast_recovery_area/PROD/','/u01/app/oracle/fast_recovery_area/TEST/' al final de PARAMETER_VALUE_CONVERT.
También se ve con claridad cuál es el controlfile que no se ubicó correctamente en el alert.log de la nueva base:
oracle@oraculo:~>tail $ORACLE_BASE/diag/rdbms/test/TEST/trace/alert_TEST.log

alter database mount
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/fast_recovery_area/PROD/control02.ctl'
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 8
Additional information: 4089
Tue Aug 20 08:40:35 2013
Checker run found 1 new persistent data failures
ORA-205 signalled during: alter database mount...
Tue Aug 20 08:40:35 2013
License high water mark = 3
USER (ospid: 5952): terminating the instance
Instance terminated by USER, pid = 5952 

Se resuelve agregando el path de este controlfile junto con el nuevo directorio al parámetro PARAMETER_VALUE_CONVERT. Se debe validar que no se dañó el controlfile de la base origen al ejecutar este comando.
4) ORA-19504: failed to create file
RMAN-00571: ====================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: ====================================================
RMAN-03002: failure of Duplicate Db command at 08/20/2013 08:55:18
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-19504: failed to create file "/u01/app/oracle/fast_recovery_area/TEST/control02.ctl"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
ORA-19600: input file is control file  (/u02/oradata/TEST/control01.ctl)
ORA-19601: output file is control file  (/u01/app/oracle/fast_recovery_area/TEST/control02.ctl) 

Este error es claro, no existe el directorio /u01/app/oracle/fast_recovery_area/TEST/
5) RMAN-05001: auxiliary file name ... conflicts
Errors in memory script
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01507: database not mounted
ORA-06512: at "SYS.X$DBMS_RCVMAN", line 13371
ORA-06512: at line 1
RMAN-05501: aborting duplication of target database
RMAN-05001: auxiliary file name /u02/oradata/PROD/prueba.dbf conflicts with a file used 
            by the target database
RMAN-05001: auxiliary file name /u02/oradata/PROD/undotbs01.dbf conflicts with a file used 
            by the target database
RMAN-05001: auxiliary file name /u02/oradata/PROD/sysaux01.dbf conflicts with a file used 
            by the target database
RMAN-05001: auxiliary file name /u02/oradata/PROD/system01.dbf conflicts with a file used 
            by the target database
RMAN-00571: ====================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: ====================================================
RMAN-03002: failure of Duplicate Db command at 08/20/2013 08:58:25
RMAN-00567: Recovery Manager could not print some error messages 

En este caso no incluí el primer paso de "SET NEWNAME..", y al no tener los parámetros DB_FILE_NAME_CONVERT y LOG_FILE_NAME_CONVERT en el pfile de la nueva base, el controlfile trata de usar los de la base origen sin renombrarlos

Migración de Base de Datos a ASM “Zero Downtime”

Migración de Base de Datos a ASM “Zero Downtime”


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 de migración o traslado de una base de datos ( BBDD ) Oracle a ASM utilizando RMAN ( Oracle Recovery Manager ).
A partir de la versión de servidor de base de datos 10g contamos con la tecnología de almacenamiento ASM ( Automatic Storage Management ) la cual revoluciono la forma de almacenar y administrar nuestras base de datos.
Anterior al surgimiento de ASM , las opciones típicas de almacenamiento eran filesystems o Raw devices. Los raw devices eran y siguen siendo dispositivos rápidos en acceso, debido a que el sistema operativo no tiene la necesidad de establecer una capa adicional de manejo de volúmenes para trabajar con los mismos.
La desventaja de ellos son varias:
  • Las particiones no pueden ser redimensionadas una vez establecidas
  • Los archive logs de la base de datos no pueden estar almacenados en raw devices por lo poco flexible de sus constitución
  • Si existiese la necesidad de crear nuevos datafiles, se tendría la necesidad de crear nuevos dispositivos raw
  • Y en general son poco flexibles para su administración
Para nosotros los DBAs ASM constituyo un giro de 360 grados de cómo seria la tendencia de almacenamiento y administración de nuestras bases de datos.
  • Ya no habría necesidad de crear varios puntos de montaje o filesystems
  • Los datafiles tendrían mayor protección respecto a su almacenamiento en filesystems
  • Tendríamos a la mano nuevas filosofías de arquitectura de storage: solo 2 Diskgroups para todas las bases de datos
  • Los problemas de I/O por saturación y cuellos de botellas en puntos de monturas serian elementos del pasado al existir el concepto de “Rebalance” entre ASM Disks, etc
  • Estas y 1000 razones mas hay para justificar la migración de nuestras bases de datos de filesystem a ASM
Para el presente artículo desarrollaremos el traslado de una base de datos de filesystem a ASM implementando técnica para realizarlo en concepción “Zero Downtime”.
Una estrategia de migración y/o traslado “Zero Downtime” tiene consigo la concepción de llevar a cabo la tarea en el menos tiempo posible ( segundos…, minutos… ) y por lo general esta asociada a empresas con negocios y servicios de alta criticidad que generalmente trabajan 24x7x365. Este mismo articulo esta desarrollado para llevar a cabo la tarea en filosofía “No Zero Downtime”.
Escenario: se posee una base de datos single instance con todos sus elementos ( Controlfiles, Datafiles, Redo Logs & Archives ) en filesystem y se desea trasladar la misma a ASM. Asumiendo que previamente el software necesario esta instalado, vamos a iniciar la actividad. La técnica utilizada en este articulo es valida para los “Oracle Servers 10g” en adelante
BBDD Origen: SOURCE
Diskgroups disponibles para la migración: +DATA & +FRA
Reconocimiento de los elementos a trasladar de la BBDD “Source”
Reconocimiento de Datafiles:
oracle@MyjpServer ~]$ export ORACLE_SID=SOURCE
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Sat Jul 28 18:34:39 2012

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


Connected to:
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production
With the Real Application Clusters option

SQL> select file_name from dba_data_files;

FILE_NAME
--------------------------------------------------------------------------------
/home/oracle/SOURCE/users01.dbf
/home/oracle/SOURCE/undotbs01.dbf
/home/oracle/SOURCE/sysaux01.dbf
/home/oracle/SOURCE/system01.dbf

Reconocimiento de Tempfiles:
SQL> select file_name from dba_temp_files;

FILE_NAME
--------------------------------------------------------------------------------
/home/oracle/SOURCE/temp01.dbf

Reconocimiento de Controlfiles:
SQL> show parameters control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /home/oracle/SOURCE/control01.
                                                 ctl, /home/oracle/SOURCE/contr
                                                 ol02.ctl, /home/oracle/SOURCE/
                                                 control03.ctl
SQL>
SQL> select NAME from v$controlfile;
NAME
---------------------------------
/home/oracle/SOURCE/control01.ctl
/home/oracle/SOURCE/control02.ctl
/home/oracle/SOURCE/control03.ctl

SQL>

Reconocimiento de Redo Log files:
SQL> select GROUP#, MEMBER from v$logfile;

    GROUP# MEMBER
---------- ---------------------------------
         3 /home/oracle/SOURCE/redo03.log
         2 /home/oracle/SOURCE/redo02.log
         1 /home/oracle/SOURCE/redo01.log

“Backup as Copy” de la BBDD
En esta etapa hemos de iniciar la actividad. La BBDD se encontrara en modo “open” y se estará llevando a cabo un “Hot backup full”. Es de importancia denotar que el objetivo de las técnicas utilizadas en este artículo estarán enfocadas en generar el menor tiempo de “Downtime” posible.
RMAN> backup as copy database format '+DATA';

Starting backup at 06-08-2012 00:05:43
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/home/oracle/SOURCE/system01.dbf
output file name=+DATA/source/datafile/system.270.790560345 tag=TAG20120806T000543 RECID=7 
 STAMP=790560348
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/home/oracle/SOURCE/sysaux01.dbf
output file name=+DATA/source/datafile/sysaux.277.790560351 tag=TAG20120806T000543 RECID=8 
 STAMP=790560353
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/home/oracle/SOURCE/undotbs01.dbf
output file name=+DATA/source/datafile/undotbs1.278.790560355 tag=TAG20120806T000543 RECID=9 
 STAMP=790560354
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=+DATA/source/controlfile/backup.279.790560355 tag=TAG20120806T000543 RECID=10 
 STAMP=790560355
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/home/oracle/SOURCE/users01.dbf
output file name=+DATA/source/datafile/users.280.790560357 tag=TAG20120806T000543 RECID=11 
 STAMP=790560356
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 06-08-2012 00:05:57
channel ORA_DISK_1: finished piece 1 at 06-08-2012 00:05:58
piece handle=+DATA/source/backupset/2012_08_06/nnsnf0_tag20120806t000543_0.281.790560357 
 tag=TAG20120806T000543 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 06-08-2012 00:05:58

RMAN>

Bajando la BBDD para establecerla en modo mount y aplicar “Switch Database to copy”
Mientras se realiza el “Hot backup full” de la BBDD, se generan archive redo logs. Para que la BBDD se encuentre en un estado consistente respecto a los datafiles alojados en ASM, procederemos a realizar una recuperación completa de la misma para establecer consistencia de todos sus datafiles. En un caso real, el realizar el paso de “Recover” es realmente lo que representara en un 98% el “Downtime” de la actividad. Para ello tenemos que divisar cual es la tasa de generación de archive redo logs de la BBDD en la cual aplicaremos la técnica y cual es el tiempo promedio de “recover” de de archive redo logs en base a su tamaño.
Existen diversos factores que influirán en la rapidez de la etapa de “recover”:
  • Velocidad de acceso en modo lectura del área en la cual se encuentren alojados los archive redo logs
  • Nivel de Paralelismo establecido para la etapa de recuperación si así fuese establecido.
Mientras mejor estén afinadas las condiciones para obtener un rápido proceso de “recover”, en esa misma medida tendremos un “Downtime” mas corto, lo cual es el objetivo a lograr. Es oportuno destacar también que mientras mas tiempo consuma la realización del backup full, en esa medida también se acumularan mas Archive Redo Logs a aplicar en la etapa de “recover”, por lo tanto es importante afinar la rapidez del backup full para tal fin.
A partir de este momento inicia nuestro periodo de “Downtime”. Estableceremos la BBDD en modo “mount” para llevar a cabo el respectivo “Switch Database to copy” y “Recover Database”
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>

Nota: se aconseja en este punto tomar backup de alguno de los controlfiles originales. Por estar en filesystem, bastara con realizar una simple copia con comando cp del sistema operativo ( Linux, Unix ), copy ( Windows ).
SQL>startup mount
ORACLE instance started.

Total System Global Area  651378688 bytes
Fixed Size                  2162520 bytes
Variable Size             184549544 bytes
Database Buffers          461373440 bytes
Redo Buffers                3293184 bytes
Database mounted.
SQL>

RMAN Report schema antes de la aplicación de “Switch Database to copy”
RMAN> report schema;

Report of database schema for database with db_unique_name SOURCE

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    700      SYSTEM               ***     /home/oracle/SOURCE/system01.dbf
2    550      SYSAUX               ***     /home/oracle/SOURCE/sysaux01.dbf
3    30       UNDOTBS1             ***     /home/oracle/SOURCE/undotbs01.dbf
4    5        USERS                ***     /home/oracle/SOURCE/users01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    20       TEMP                 32767       /home/oracle/SOURCE/temp01.dbf

RMAN>

“Switch Database to copy”
RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DATA/source/datafile/system.270.790560345"
datafile 2 switched to datafile copy "+DATA/source/datafile/sysaux.277.790560351"
datafile 3 switched to datafile copy "+DATA/source/datafile/undotbs1.278.790560355"
datafile 4 switched to datafile copy "+DATA/source/datafile/users.280.790560357"

RMAN>

RMAN Report schema posterior a la aplicación de “Switch Database to copy”
RMAN> report schema;

Report of database schema for database with db_unique_name SOURCE

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    700      SYSTEM               ***     +DATA/source/datafile/system.270.790560345
2    550      SYSAUX               ***     +DATA/source/datafile/sysaux.277.790560351
3    30       UNDOTBS1             ***     +DATA/source/datafile/undotbs1.278.790560355
4    5        USERS                ***     +DATA/source/datafile/users.280.790560357

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    20       TEMP                 32767       /home/oracle/SOURCE/temp01.dbf

RMAN>

Trabajo sobre Tempfiles
Tal como es apreciado en el cuadro anterior. Ya todos los datafiles se encuentran alojados en ASM a excepción de los tempfiles asociados a los tablespaces temporal. En nuestro caso, tenemos solo un tablespace temporal. Teniendo la BBDD aun en modo “mount” estableceremos el único tempfile existente en el ASM Diskgroup +DATA
rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Mon Aug 6 00:34:52 2012

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

connected to target database: SOURCE (DBID=2908920228, not open)

RMAN> run { set newname for tempfile 1 to '+DATA';
2> switch tempfile all; }

executing command: SET NEWNAME
using target database control file instead of recovery catalog

renamed tempfile 1 to +DATA in control file

RMAN>

En el articulo ”Migracion de Base de Datos a ASM “No Zero Downtime” reubicamos el tablespace temporal a través de la creación de un nuevo tablespace temporal en ASM y removiendo el anterior. La técnica utilizada en este articulo posee mayor eficiencia que la anterior, sin embargo quise denotar los dos procedimientos para plasmar diversas técnicas para lograr el mismo objetivo.
Recover Database
Estando aun en modo “mount”, llevaremos a cabo el recover de la BBDD para establecer consistencia en todos los datafiles alojados en ASM.
RMAN> recover database;

Starting recover at 06-08-2012 00:10:33
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=143 device type=DISK

starting media recovery

archived log for thread 1 with sequence 2 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_2_81yqsdbo_.arc
archived log for thread 1 with sequence 3 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_3_81yqsfhn_.arc
archived log for thread 1 with sequence 4 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_4_81yqsgck_.arc
archived log for thread 1 with sequence 5 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_5_81yqshh4_.arc
archived log for thread 1 with sequence 6 is already on disk as file /u01/app/oracle/
 flash_recovery_area/SOURCE/archivelog/2012_08_06/o1_mf_1_6_81yqsjlq_.arc
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_2_81yqsdbo_.arc thread=1 sequence=2
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_3_81yqsfhn_.arc thread=1 sequence=3
archived log file name=/u01/app/oracle/flash_recovery_area/SOURCE/archivelog/2012_08_06/
 o1_mf_1_4_81yqsgck_.arc thread=1 sequence=4
media recovery complete, elapsed time: 00:00:01
Finished recover at 06-08-2012 00:10:34

En este punto ya poseemos Datafiles & Tempfiles alojados en ASM de forma consistente. Ahora trabajaremos en reubicar los grupos de Redo Log
Creación de Directorio para Redo Log
ASMCMD> pwd
+DATA/source
ASMCMD>
ASMCMD> mkdir ONLINELOG
ASMCMD>
ASMCMD

Sustitución y/o cambios de Redo Logs
En esta base de datos tenemos originalmente 3 grupos de “Redo Logs” ( en filesystem ). El objetivo es crear grupos de redo logs con alojamiento en ASM. Para realizar esta tarea existen diversas técnicas.
Aperturamos la BBDD para crear los nuevos grupos de Redo Logs en ASM. Es importante destacar que esta etapa se puede llevar a cabo enteramente antes de iniciar el “Downtime” y así podríamos minimizar el mismo. Se utilizaría la misma técnica que se aplica para adicionar nuevos grupos de Redo Logs con distinta medida, ubicación o atributos en general.
Estado de la BBDD: “open”
Por estar trabajando en “Single Instance” no será necesario incluir el atributo “thread”. Si dicha técnica se estuviese aplicando para una BBDD en RAC se estableciera el parámetro “thread” para definir la asociación del grupo de Redo Log con el correspondiente “thread” ( thread=1/thread=2, etc )
Adición de Grupos de Redo Logs 4 y 5:
SQL> ALTER DATABASE
  2  ADD LOGFILE GROUP 4 ('+DATA/source/ONLINELOG/redo04.log') SIZE 50M;

Database altered.

SQL> ALTER DATABASE
  2  ADD LOGFILE GROUP 5 ('+DATA/source/ONLINELOG/redo05.log') SIZE 50M;

Database altered.

Visualización de grupos de Redo Logs después de la adiciones:
SQL> select GROUP#, MEMBER from V$LOGFILE

    GROUP# MEMBER
---------- --------------------------------------------------
         3 /home/oracle/SOURCE/redo03.log
         2 /home/oracle/SOURCE/redo02.log
         1 /home/oracle/SOURCE/redo01.log
         4 +DATA/source/onlinelog/redo04.log
         5 +DATA/source/onlinelog/redo05.log

SQL>

Borrado del grupo de Redo Log 1:
SQL> alter database drop logfile group 1;

Borrado del grupo de Redo Log 2. El mismo no puede ser removido aun debido a que la operación de redo log group para la BBDD se encuentra apuntando al mismo.
Database altered.
SQL> alter database drop logfile group 2;
alter database drop logfile group 2
*
ERROR at line 1:
ORA-01623: log 2 is current log for instance SOURCE (thread 1) - cannot drop
ORA-00312: online log 2 thread 1: '/home/oracle/SOURCE/redo02.log'

Borrado del grupo de Redo Log 3:
SQL> alter database drop logfile group 3;

Database altered.

SQL>

Visualización de grupos de Redo Logs posterior a las remociones:
SQL> select GROUP#, MEMBER from V$LOGFILE;

    GROUP# MEMBER
---------- --------------------------------------------------
         2 /home/oracle/SOURCE/redo02.log
         4 +DATA/source/onlinelog/redo04.log
         5 +DATA/source/onlinelog/redo05.log

SQL>

Estatus de los mismos. Tal como podemos visualizar. El grupo de redo log 1 se encuentra en “status”:current, con dicho estatus no podrá ser removido. Tenemos que aplicar diversos “switch logfile” para que el mismo se establezca en “status”:inactive y pueda ser removido ( esto aplica si la BBDD se encuentra abierta ), si la BBDD esta cerrada solo bastara que el grupo de redo log “current” sea el 4 o 5:
SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 CURRENT          NO
         4 UNUSED           YES
         5 UNUSED           YES

SQL>

Realizaremos los “switchs” correspondientes:
SQL> alter system switch logfile;

System altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 ACTIVE           NO
         4 CURRENT          NO
         5 UNUSED           YES


SQL> alter system switch logfile;

System altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         2 ACTIVE           NO
         4 ACTIVE           NO
         5 CURRENT          NO

Tal cual fue el objetivo, el grupo de Redo log “current” actual es el 5. Podríamos haber escogido el 4 también. Lo importante es que no fuese el grupo de redo log 2, debido a que removeremos el mismo. Procederemos a cerrar la BBDD, establecimiento en modo “mount” de la misma y la remoción final del grupo de Redo Log 2:
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  680607744 bytes
Fixed Size                  2162800 bytes
Variable Size             188747664 bytes
Database Buffers          486539264 bytes
Redo Buffers                3158016 bytes
Database mounted.
SQL>

SQL> alter database drop logfile group 2;

Database altered.

SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         5 CURRENT          NO
         4 INACTIVE         NO

SQL>

SQL> alter database open;

Database altered.

SQL> alter system switch logfile;

System altered.

SQL> r
  1* alter system switch logfile

System altered.

SQL> r
  1* alter system switch logfile

System altered.

En este punto ya llevamos a cabo el objetivo de establecer operativamente solo grupos de Redo Logs en ASM:
SQL> select GROUP#, STATUS, ARCHIVED from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         4 CURRENT          NO
         5 INACTIVE         NO

SQL>

Reubicación de Controlfiles
Realizaremos cambios de parámetros a nivel de spfile ( Server Parameter File ) por lo tanto procederemos a respaldar el mismo para su restaurado en caso de ser necesitado.
Nota: Para respaldar el server parameter file la BBDD debe estar en estado “mount or open “
Estado actual de la BBBD: abierta.
rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Sat Jul 28 18:49:07 2012

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

connected to target database: SOURCE (DBID=2908208036)

RMAN> backup spfile format '/home/oracle/SOURCE/MySpfileBackup.ora';

Starting backup at 28-07-2012 18:49:11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=147 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 28-07-2012 18:49:12
channel ORA_DISK_1: finished piece 1 at 28-07-2012 18:49:13
piece handle=/home/oracle/SOURCE/MySpfileBackup.ora tag=TAG20120728T184911 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 28-07-2012 18:49:13

RMAN>

Procedemos a cambiar los parámetros (controlfile y db_create_file_dest) a su nueva ruta. La ruta escogida va alineada a las rutas “Oracle Managed Files” para base de datos en ASM. Los nuevos datafiles serán creados por defecto en la ruta especificada por el parámetro db_create_file_dest. Se establecera en esta misma etapa l nueva ubicacion para el area “Flash”.
Choosing a Location for the Flash Recovery Area
Oracle® Database Backup and Recovery Basics
10g Release 2 (10.2)

http://docs.oracle.com/cd/B19306_01/backup.102/b14192/setup005.htm
SQL> Alter System set control_files=’+DATA/source/controlfiles/control01.ctl’ scope=spfile;
SQL> alter system set db_create_file_dest='+DATA' scope=spfile;
SQL> alter system set db_recovery_file_dest='+FRA' scope=spfile;



SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

Creación de Directorio en ASM donde se alojara el o los controlfiles
Para el presente caso trabajaremos creando solo 1 controlfile, si se desean crear controlfiles en distintos Diskgroups lo cual es el “best practice”, se podrá llevar a cabo de la misma manera. Se deberán crear los directorios respectivos en los Diskgroups respectivos y se deberá asignar rutas múltiples en el valor del parámetro control_files a nivel de spfile.
Recordemos que esta base de datos esta originalmente creada en filesystem y no posee ninguna relación con los ASM Diskgroups, por lo tanto es necesario crear los directorios de alojamiento de los Controlfiles, Datafiles, Redo Logs y otros. Para algunos de los elementos el procedimiento asociado ( RMAN restore ) los crea automáticamente, para otros no. En el caso del controlfile, el directorio tiene que ser creado
Nota: para el presente caso estamos trabajando con un Oracle Server 11g R1 el cual posee la misma la misma arquitectura de “homes” a implementarse en ( 10g R1, 10g R2 & 11g R1 ). Dicha arquitectura cuenta con un home para ASM cuyo dueño típicamente es el usuario oracle. Este “home” trabaja de la mano con un “home” de nivel superior ( en escala de “stack” de componentes ) perteneciente al Oracle Server cuyo dueño es el usuario oracle también. Es por ello que establecemos el “home” de ASM a través del mecanismo ( . oraenv ).
Si trabajáramos en 11g R2 el “best practice” será que el “Grid Infraestructure Software” pertenezca al usuario “grid” y el Oracle Server al usuario “oracle”, en caso de estar en esta arquitectura, este paso se realizaría conectado al usuario grid.
Creación de directorios necesarios para poseer finalmente la siguiente ruta: +DATA/SOURCE/controlfiles
[oracle@MyjpServer ~]$ . oraenv
ORACLE_SID = [TEST] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm1 is /u01/app/oracle
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ asmcmd
ASMCMD>
ASMCMD> cd +DATA
ASMCMD>
ASMCMD> mkdir SOURCE
ASMCMD>
ASMCMD> cd SOURCE
ASMCMD>
ASMCMD> mkdir CONTROLFILES
ASMCMD>
ASMCMD> cd controlfiles
ASMCMD>
ASMCMD> pwd
+DATA/SOURCE/controlfiles
ASMCMD>

Restaurado de Controlfiles en ASM
SQL> startup nomount
ORACLE instance started.

Total System Global Area  680607744 bytes
Fixed Size                  2162800 bytes
Variable Size             180359056 bytes
Database Buffers          494927872 bytes
Redo Buffers                3158016 bytes
SQL>

RMAN> restore controlfile from '/home/oracle/SOURCE/control01.ctl';

Starting restore at 28-07-2012 19:12:25
using channel ORA_DISK_1

channel ORA_DISK_1: copied control file copy
output file name=+DATA/source/controlfiles/control01.ctl
Finished restore at 28-07-2012 19:12:26

RMAN>

Visualizando el Controlfile creado
ASMCMD> pwd
+DATA/SOURCE/controlfiles
ASMCMD>
ASMCMD> ls -lt
Type  Redund  Striped  Time   Sys  Name
                              N    control01.ctl => 
                                    +DATA/SOURCE/CONTROLFILE/current.261.789851545
ASMCMD>

Establecimiento de spfile en ASM Diskgroup
Una vez alcanzado este punto solo nos quedaría afinar la nueva ubicación para el archivo de parámetros de la BBDD.
[oracle@MyjpServer ~]$ rman target /

Recovery Manager: Release 11.1.0.7.0 - Production on Sun Aug 5 23:56:07 2012

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

connected to target database: SOURCE (DBID=2908920228)


RMAN> run { BACKUP AS BACKUPSET SPFILE;
2> RESTORE SPFILE TO '+DATA/SOURCE/spfilesource.ora';
3> }

Starting backup at 05-08-2012 23:57:45
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=140 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 05-08-2012 23:57:46
channel ORA_DISK_1: finished piece 1 at 05-08-2012 23:57:47
piece handle=+FRA/SOURCE/backupset/2012_08_05/o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp 
 tag=TAG20120805T235746 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 05-08-2012 23:57:47

Starting restore at 05-08-2012 23:57:47
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: restoring SPFILE
output file name=+DATA/SOURCE/spfilesource.ora
channel ORA_DISK_1: reading from backup piece +FRA/SOURCE/backupset/2012_08_05/
 o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp
channel ORA_DISK_1: piece handle=+FRA/SOURCE/backupset/2012_08_05/
 o1_mf_nnsnf_TAG20120805T235746_81yq6tkl_.bkp tag=TAG20120805T235746
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 05-08-2012 23:57:50

RMAN>

Visualización de spfile generado en ASM Diskgroup
[oracle@MyjpServer ~]$ . oraenv
ORACLE_SID = [TEST] ? +ASM
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm1 is /u01/app/    oracle
[oracle@MyjpServer ~]$
[oracle@MyjpServer ~]$ asmcmd
ASMCMD>
ASMCMD> cd data
ASMCMD>
ASMCMD> cd source
ASMCMD>
ASMCMD> ls -lt
Type Redund Striped Time Sys Name
                         N   ONLINELOG/
                         N   CONTROLFILES/
                         Y   CONTROLFILE/
                         N   spfilesource.ora => +DATA/  DB_UNKNOWN/PARAMETERFILE/SPFILE.261.790559869
ASMCMD>

Ajuste de archivo initsource.ora
[oracle@MyjpServer ~]$ rm $ORACLE_HOME/dbs/spfileSOURCE.ora
[oracle@MyjpServer ~]$ cd $ORACLE_HOME/dbs/
[oracle@MyjpServer ~]$ echo "SPFILE=+DATA/SOURCE/PARAMETERFILE/spfilesource.ora" > initsource.ora

De esta manara la instancia tomara como primera opción el “Parameter File” de nuestra BBDD, el cual apunta internamente al spfile que se encuentra en ASM. Aperturamos la BBDD y hemos completado la tarea.
Reflexión
Si comparamos las técnicas, implicaciones, criticidad y orden de pasos realizados en el articulo Migracion de Base de Datos a ASM “No Zero Downtime” respecto a este, podremos notar que a pesar de que el objetivo sea llevar a cabo la misma tarea. El ciclo de vida de la misma cambia considerablemente. En líneas generales las tareas que impliquen siempre su realización con filosofía “Zero Downtime”, requerirá de técnicas de mayor criticidad y por consiguiente de mayor “expertice” por parte del DBA encargado. Siempre existirán tareas que puedan ser de duración muy cortas pero en ambientes muy críticos; cuando este es el cuadro, el DBA debe prepararse para las posibles implicaciones que conlleve la tarea.
Ej: puede usted pensar que por perdidas de grupos de redo logs posiblemente tenga que restaurar una BBDD completa… ?. Respuesta: si es posible… entonces, Pregunta: cualquier DBA puede cambiar, adicionar, administrar grupos de Redo Logs ?... Respuesta: si… Pregunta: cualquier DBA toma las precauciones de estar preparado ante los posibles escenarios al realizar un “task”… Respuesta: En mi experiencia. No todos… es allí donde puede estar la diferencia…
Para el presente articulo, la técnica a aplicar no es tan compleja pero posiblemente seria un poco más complejo diseñar un plan para que todo siga operando en caso de fallo en la aplicación de la misma. Esto se denomina “Plan de Contingencia”. Siempre que se va a realizar algo altamente critico en empresas con sistemas de alta criticidad, generalmente la misma solicita por escrito esto mencionado, pero… es necesario que lo soliciten para construirlo en nuestras mentes… Respuesta: No… por lo tanto, todo DBA debería de pensar en un plan para restituir la infraestructura en caso de fallo de la técnica a ser aplicada. Es por ello que plasmare lo siguiente:
Entonces:
  • Uno de los primeros pasos que realizamos es realizar un “Switch Database to Copy”, esto cambia las referencias dentro de los controlfiles. Por lo tanto es de precaución tomar un backup de controlfile cuando se cierra la BBDD por primera vez debido a que la información de contenido del mismo será cambiada.
    Estando la BBDD cerrada bastara con realizar una copia a nivel de filesystem de uno de los controlfiles. En este backup tomado, se encontrara la referencia de los datafiles, tempfiles y redo log los cuales están ubicados en filesystem.
  • Y en que condición quedaran mis datafiles, tempfiles and redo logs ?. Respuesta: consistentes en filesystem por lo tanto podremos volver a trabajar con la BBDD en filesystem si la técnica fallara. Para que los mismos queden en estado consistente es importante cerrar la BBDD con opción “immediate”
  • Otro elemento que se cambiara en el proceso es el spfile de la BBDD. Tomaremos un backup del mismo para su utilización en caso de ser necesitado en un reverso.
  • Teniendo estas precauciones podremos iniciar el “Task”.
Vamos a dibujar un escenario de falla para el mismo:
Iniciamos la actividad:
  • Se realizo el “Backup as Copy” sin problemas
  • “Switch Database to copy” sin problemas
  • Procedemos a la etapa de “recover database”, se aplicaran 100 archives. Los archives se encuentran en un filesystem de origen de discos no pertenecientes al servidor. El filesystem esta asociado a una LUN perteneciente a una SAN.
  • Cuando la BBDD estaba recuperando el archive 44, la SAN obtiene una falla parcial y se pierde el acceso al filesystem en el cual se encuentran los archives y no se posee backup de los mismos en otra locación.
  • Se había destinado 30min para la actividad. En medio de lo ocurrido se diagnostica que esa partición posee un problema que no será resuelto prontamente…
  • Nuestra BBDD quedo recuperada hasta el archive 44…
  • Se toma la decisión de que se realice lo necesario para que la BBDD continúe con su operación en filesystem o ASM al punto original. Al dpto. de IT y a la empresa solo le interesa en este momento, continuar con las actividades… con la data tal cual estaba al principio del “Task”
  • Es aquí en este punto donde jugara un papel fundamental el “expertice” del DBA y sobretodo las precauciones que tuvo que haber tomado para posibles escenarios de falla de la actividad.
  • Pasos a realizar:
         • Detener la BBDD
         • Restaurar a la locación original el controlfile respaldado y crear copias del mismo si fuese el caso de que estuviesen multiplexados los controlfiles. Notas: estos controlfiles referencian sus elementos totalmente a filesystem
         • Si el spfile fue cambiado. Restaurar el original
         • Si la ruta tradicional de archives no esta disponible. Cambiar a nivel de spfile la nueva ruta para el parámetro ( DB_RECOVERY_FILE_DEST )
         • Iniciar la BBDD y continuar con las operaciones
Aplicaciones y uso
Las técnicas para trasladar y/o alojar elementos de una base de datos en filesystem a ASM son llevados a cabo en situaciones como las siguientes:
  • Traslado de BBDD “Single Instance” de filesystem a BBDD “Single Instance” en ASM
  • Traslado de BBDD “Single Instance” de filesystem a BBDD “RAC” en ASM/OCFS/Certified NFS
  • Poseer una copia de BBDD en ASM o locación diversa para recuperaciones rápidas de datafiles
  • Poseer una copia de BBDD en ASM o locación diversa para recuperaciones rápidas de la BBDD completa
  • Y muchos otros casos mas

Recuperacion de una tabla a partir de un backup de RMAN

Recuperacion de una tabla a partir de un backup de RMAN


Esta característica de DB 12c me llamó mucho la atención a mí personalmente. Si bien se podía realizar en versiones anteriores, en 12c se siguen los mismos pasos, pero esta vez RMAN se hace cargo de todo.

Estos son los pasos, desde cómo poner la base de datos en modo archive hasta la recuperación de la tabla:
  1. Conectarse a la base de datos como sysdba
  2. sqlplus / as sysdba

  3. Verificar si la base de datos está en modo Archive
  4. archive log list

  5. Si no está en modo archive, bajar la base de datos, subirla en modo mount y ponerla en modo archivelog.
  6. shutdown immediate  -- a los
    startup mount  --just one node3
    alter database archivelog;
    alter database open
    archive log list
    exit

  7. Conectarse a RMAN
  8. rman target=/

  9. Generar un backup de la base de datos:
  10. Backup database

  11. En una ventana conectarse como sys o system
  12. select timestamp_to_scn(sysdate) from v$database;

  13. En otra ventana conectarse a la base de datos con el usuario y realizar una transacción u operación que afecte una tabla
  14. Y volver a revisar el timestamp en la ventana de system
  15. Prerrequisitos para la recuperación:
    • Base de datos en modo archive
    • Contar con el backup del que se quiere restaurar los datos
    • Tener espacio para restaurar system, sysaux, temporal, undo y el tablespace donde estaba la tabla, se necesita este espacio de manera temporal, los archivos se borran automáticamente cuando se termina la restauración
    • Tener espacio para recuperar la tabla en la base de datos
    • En el caso de generar export , tener espacio para este archivo
    • Tener el punto en el tiempo en que se quiere recueprar una tabla
  16. NOTA: También se pueden recuperar particiones
  17. Conectarse a RMAN, y recuperar al punto previo al update
  18. RECOVER TABLE 'SCOTT'.'EMP'
    UNTIL SCN 1759715
    AUXILIARY DESTINATION '/u01/aux'  
    REMAP TABLE 'SCOTT'.'EMP':'REC_EMP';
    
    
  19. Notar que se hace el procedimiento, verificar el directorio de destino de base de datos auxiliar
  20. Otra forma de restaurar la tabla es generando un export de la tabla
  21. RECOVER TABLE 'SCOTT'.'EMP'
    UNTIL SCN 1759715
    AUXILIARY DESTINATION '/u01/aux'
    DATAPUMP DESTINATION '/u01/exp'
    DUMP FILE 'scott_emp_prev.dmp'
    NOTABLEIMPORT;
    
    
  22. Notar que se hace el procedimiento, verificar directorio del destino de base de datos auxiliar, y al final del proceso que el export se haya generado
  23. Pasos  ejecutados:
    • Crea base de datos auxiliar
    • Recupera los datafiles de system, sysaux, undo hasta el punto en el tiempo que se requiere
    • Abre la base de datos auxiliar en modo lectura e identfica el tablespace donde está la tabla o las particiones y lo restaura y recupera
    • Abre la base de datos
    • Exporta los datos
    • Importa los datos
  24. También podemos hacer recuperación en el tiempo:
  25. RECOVER TABLE 'SCOTT'.'EMP'
    UNTIL TIME to_date('08/17/2014 21:01:15','mm/dd/yyyy hh24:mi:ss')"
    AUXILIARY DESTINATION '/u01/aux'  
    REMAP TABLE 'SCOTT'.'EMP':'REC_EMP';
    
    
    Limitaciones:
    • No se restauran tablas de SYS
    • Tablas y particiones en tablespaces SYSTEM Y SYSAUX no se recuperan
    • Las particiones de una tabla se pueden recuperar sólo para bases de datos desde 11g R1
    • Tablas con contraints not null no se pueden recuperar con la opción de REMAP
    • Si la tabla tienen índices solo se recupera si los tablespaces donde están los índices están incluidos en el backup
    • Borrar la base de datos auxiliar y sus datafiles. 

Más información en :
https://docs.oracle.com/database/121/BRADV/rcmresind.htm#BRADV686

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

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.

Consejos y trucos: Crear pequeñas copias de una base de datos de producción


Consejos y trucos: Crear pequeñas copias de una base de datos de producción

Una de las áreas más comunes de un Administrador de Base de Datos es crear una copia de una base de producción para un ambiente de desarrollo o propósitos de pruebas, pero el problema es que algunas veces tu no tienes los recursos de espacio suficientes para crear una copia completa de la base de datos de producción, entonces algunas personas deciden organizar los datos en términos de meses y años de modo que ellos puedan crear el nuevo ambiente con solamente aquellos tablespaces de los últimos meses pero ¿qué sucede si se necesitara datos de otros meses en el nuevo ambiente? Algunas veces ciertamente no necesitamos solo unos cuantos tablespaces desde producción sino lo que necesitamos es un porcentaje de todos los datos de la base de datos completa de producción. Una vez nosotros conozcamos el porcentaje que necesitamos la pregunta sería con qué tamaño debería de crear los datafiles en el nuevo ambiente ya que usualmente nosotros no tenemos mucho espacio para ambientes secundarios. ¿Que sucede si creamos un tablespace con un tamaño grande cuyos datos en él serán pocos y a la vez creamos un tablespace pequeño que realmente necesita mucho espacio? Tomando en cuenta que disponemos de espacio limitado, esto sería un problema. Luego podríamos reducir el tamaño de todos los datafiles que se crearon sobredimensionados, pero esto es más trabajo ¿no?. Existen muchas otras preguntas que vienen bajo este contexto y la tarea empieza a tornarse más difícil. Bien, te vamos a mostrar que hay una manera muy fácil de realizar esta tarea que estamos planteando, cómo hacerlo es lo que te enseñaremos a lo largo de nuestro articulo. Al final de este articulo serás capaz de crear ambientes de pruebas o desarrollo donde lo único que necesitas es saber qué porcentaje de la base de datos de producción quieres recrear.
La tarea consta de dos partes:
  • Extraer el porcentaje de datos desde la base de datos de producción.
  • Importar los datos pero creando todos los datafiles y sus  extensiones con un porcentaje de producción.
La primer parte puede ser fácilmente resuelta usando el parámetro SAMPLE de el utilitario expdp de datapump y la segunda parte puede también ser fácilmente resuelta  usando PCTSPACE en la herramienta impdp. Vamos a darte una pequeña definición de ambos parámetros:
SAMPLE:X – Extrae un porcentaje X de dato. Dicho porcentaje extraído aplica a cada objeto dentro de la base de datos fuente. Esta es una opción de la herramienta expdp de data pump. El parámetro SAMPLE te permite exportar subconjuntos de datos especificando únicamente un número, el porcentaje. El porcentaje únicamente es una probabilidad de que un bloque de datos sea seleccionado como parte del archivo resultante de la operación de exportación. Tu puedes indicar el porcentaje que tu quieras pero no puedes especificar el valor 0, solamente puedes elegir entre (0,100] dicho numero debe estar precediendo el esquema y la tabla. Si se especifica un esquema, también debe especificarse la tabla. Si solo especificas el nombre de la tabla y no el nombre del esquema, data pump asumirá que la tabla es parte del esquema del usuario que está realizando la operación de exportación. Si ninguna tabla es especificada, entonces dicho porcentaje aplica a todos los objetos que se estén extrayendo.
PCTSPACE:X – Reduce todas las extensiones hasta un determinado porcentaje X. Mientras la importación de los datos esté creando todas las extensiones, automáticamente data pump reducirá cada extensión hasta el porcentaje especificado. La opción PCTSPACE es usada con el parámetro TRANSFORM para reducir el tablespaces y también sus datafiles de manera física cuando muchas filas han sido removidas y se quiere tomar ventaja de ese espacio liberado. Todos las operaciones de redimensionado son hechas por la herramienta impdp automáticamente, tu solo necesitas especificar un valor, un número, el cuál es el porcentaje.
Ahora te mostraremos cómo es que funciona todo esto, crearemos un ambiente de pruebas basándonos en un porcentaje del ambiente de producción.
Creando un ambiente de pruebas con el 10% de los datos del ambiente de producción
Ambiente de Producción
En nuestro ambiente de producción tenemos 2 tablas, T1 y T2 con 96MB y casi 900,000 filas en el esquema OraWorld.
Revisando los tamaños de las tablas:
SQL> select segment_name, 
            segment_type, 
            tablespace_name, 
            bytes/1024/1024 MB_Size 
     from dba_segments 
     where owner='ORAWORLD';
 
SEGMENT_NA SEGMENT_TYPE       TABLESPACE    MB_SIZE
---------- ------------------ ---------- ----------
T1         TABLE              DATA1              96
T2         TABLE              DATA2              96
IND_T1     INDEX              INDEX1             15
IND_T2     INDEX              INDEX2             15
 

Revisando el numero de filas:
SQL> select table_name, 
            num_rows 
      from dba_tables 
      where owner='ORAWORLD';
 
TABLE_NAME                         NUM_ROWS
------------------------------ ------------
T2                                   881000
T1                                   881000
 

Revisando los datafiles y sus tamaños:
SQL> select file_name, 
            bytes/1024/1024 MB_Size 
     from dba_data_files 
     where tablespace_name in ('DATA1','DATA2','INDEX1','INDEX2');
 
FILE_NAME                                   MB_SIZE
---------------------------------------- ----------
+DATA/orcl/datafile/data1.342.860024365         150
+DATA/orcl/datafile/data2.265.860024375         150
+DATA/orcl/datafile/index1.353.860024387        100
+DATA/orcl/datafile/index2.354.860024397        100

Revisando el spfile a copiar hacia el ambiente de pruebas:
SQL> select name from v$database;
 
NAME
---------
ORCL
 
SQL> show parameter spfile
 
NAME      TYPE        VALUE
-------   ----------- ----------------------------------------------------
spfile    string      /u01/app/oracle/product/11.2/db_1/dbs/spfileorcl.ora
 

Copiando el spfile hacia el ambiente de pruebas:
[oracle@prod ~]$ scp /u01/app/oracle/product/11.2/db_1/dbs/spfileorcl.ora 
oracle@dev.oraworld.com:/u01/app/oracle/product/11.2/db_1/dbs/
 
oracle@dev.oraworld.com's password: 
 
spfileorcl.ora                             100% 3584     3.5KB/s   00:00:01    
 

Ambiente de pruebas
El spfile fue transferido correctamente:
[oracle@dev dbs]$ pwd
/u01/app/oracle/product/11.2/db_1/dbs
 
[oracle@dev dbs]$ ls -ltr spfileorcl.ora 
-rw-r----- 1 oracle oinstall 3584 Oct 31 22:55 spfileorcl.ora
 
[oracle@dev dbs]$ echo $ORACLE_SID
orcl
 

Creando el ambiente de pruebas:
[oracle@dev dbs]$ sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.4.0 Production on Fri Oct 31 22:57:20 2014
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
Connected to an idle instance.
 
SQL> startup nomount;
ORACLE instance started.
 
Total System Global Area  1068937216 bytes
Fixed Size                   2260088 bytes
Variable Size              578814856 bytes
Database Buffers           482344960 bytes
Redo Buffers                 5517312 bytes
 
SQL> 
 

Revisando los parámetros:
SQL> show parameters db_create
 
NAME                                     TYPE     VALUE
------------------------------------  ----------  ------------
db_create_file_dest                     string    +DATA
db_create_online_log_dest_1             string    +DATA
db_create_online_log_dest_2             string
db_create_online_log_dest_3             string
db_create_online_log_dest_4             string
db_create_online_log_dest_5             string
 

Ajustando el parámetro controlfile:
SQL> alter system set control_files='+DATA' scope=spfile;
System altered.
 
SQL> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
 
SQL> startup nomount;
ORACLE instance started.
 
Total System Global Area  1068937216 bytes
Fixed Size                   2260088 bytes
Variable Size              587203464 bytes
Database Buffers           473956352 bytes
Redo Buffers                 5517312 bytes
SQL> 
 

Creando la base de datos de pruebas:
SQL> CREATE DATABASE orcl
USER SYS IDENTIFIED BY manager1
USER SYSTEM IDENTIFIED BY manager1
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE temp
UNDO TABLESPACE undotbs1
DEFAULT TABLESPACE users;
 
Database created.

Ejecutando los scripts post-creación de base de datos:
SQL> show user
USER is "SYS"
 
SQL> @?/rdbms/admin/catalog.sql
SQL> @?/rdbms/admin/catproc.sql
 
SQL> conn system/manager1
Connected.
 
SQL> show user
USER is "SYSTEM"
 
SQL> @?/sqlplus/admin/pupbld.sql
 
SQL> create directory oracle as '/home/oracle';
Directory created.
 
SQL> create user oraworld identified by oraworld;
User created.
 
SQL> grant imp_full_database to oraworld;
Grant succeeded.
 
SQL> grant connect, resource to oraworld;
Grant succeeded.
 
SQL> grant read,write on directory oracle to oraworld;
Grant succeeded.
 
SQL> alter user oraworld quota unlimited on users;
User altered.
 

Especificando un porcentaje de los datos para ser extraídos usando la herramienta expdp del utilitario data pump.
Como puedes ver, 8,180 filas es el 10% de las filas en la tabla T1, recuerda que la tabla tiene actualmente 881,000 filas.
[oracle@prod ~]$ expdp oraworld/oraworld sample=10 full=y directory=oracle 
dumpfile=expdp_10pct.dmp log=expdp_10pct.log
 
Processing object type DATABASE_EXPORT/AUDIT
. . exported "ORAWORLD"."T1"                             8.180 MB   87693 rows 
. . exported "ORAWORLD"."T2"                             8.242 MB   88344 rows 
 
 
[oracle@prod ~]$ scp expdp_10pct.dmp oracle@dev.oraworld.com:/home/oracle
oracle@dev.oraworld.com's password: 
 
expdp_10pct.dmp                                          100%   20MB  20.0MB/s   00:01    
 

Importando los datos desde el ambiente de producción hacia nuestro ambiente de pruebas indicando el porcentaje con que se crearán todas las extensiones y los datafiles físicos. En este ejemplo estamos usando el 10%.

[oracle@dev ~]$  impdp oraworld/oraworld transform=pctspace:10 directory=oracle 
dumpfile=expdp_10pct.dmp log=impdp_10pct.log TABLE_EXISTS_ACTION=SKIP
 
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
. . imported "ORAWORLD"."T1"                             8.180 MB   87693 rows 
. . imported "ORAWORLD"."T2"                             8.242 MB   88344 rows 
 

El parámetro SAMPLE no especifica una cantidad exacta de datos, como habíamos indicado es una probabilidad por lo que nuestro resultado si bien es muy acertado podría variar en pequeñas proporciones.
Actualizando las estadísticas del esquema OraWorld:
SQL> exec dbms_stats.gather_schema_stats('ORAWORLD');
PL/SQL procedure successfully completed.
 

Verificando el 10% de los datos y el 10% en el tamaño de los datafiles:
SQL> select segment_name, 
            segment_type, 
            tablespace_name, 
            bytes/1024/1024 MB_Size 
     from dba_segments 
     where owner='ORAWORLD';
 
SEGMENT_NAME SEGMENT_TYPE       TABLESPACE      MB_SIZE
------------ ------------------ ---------- ------------
T1           TABLE                DATA1              10 
T2           TABLE                DATA2              10 
IND_T1       INDEX                INDEX1              2 
IND_T2       INDEX                INDEX2              2 
 
 
SQL> select table_name, num_rows from dba_tables where owner='ORAWORLD';
 
TABLE_NAME                        NUM_ROWS
------------------------------   ----------
T2                                    88344 
T1                                    87693
 

Cómo puedes ver también las estructuras físicas fueron creadas con el 10% del tamaño con que fueron creadas en el ambiente de producción:
SQL> select file_name, 
            bytes/1024/1024 MB_Size 
     from dba_data_files 
     where tablespace_name in ('DATA1','DATA2','INDEX1','INDEX2');
 
FILE_NAME                                   MB_SIZE
---------------------------------------- ----------
+DATA/orcl/datafile/data1.281.862448977          15 
+DATA/orcl/datafile/data2.282.862448977          15 
+DATA/orcl/datafile/index1.279.862448979         10 
+DATA/orcl/datafile/index2.280.862448979         10
 

Un error muy frecuente
Para evitar cualquier problema mientras estés creando tu ambiente de pruebas queremos que estés consiente de un error muy común cuando se trabaja con opciones como SAMPLE y PCTSPACE, algunas veces puedes llegar a ver que tus datafiles no se crearon con el porcentaje que indicaste en la operación de importación, esto pasa cuando tu realizaste varias operaciones “alter database datafile … resize” sobre los datafiles en el ambiente de producción, dichos operaciones de redimensionado no son replicadas en el archivo resultante de la exportación por lo que los datafiles y sus extensiones serán creadas respetando solamente el tamaño original y el valor MAXSIZE. En este caso debes modificar el valor “maxsize” de los datafiles o también puedes crear todos los tablespaces con los tamaños que tu prefieras antes de realizar la importación. Te mostraremos mas detalles sobre esto con un ejemplo:
Ambiente de producción:
SQL> select file_name, bytes/1024/1024 MB_Size 
     from dba_data_files 
     where tablespace_name in ('DATA1','DATA2','INDEX1','INDEX2');
 
FILE_NAME                                             MB_SIZE
-------------------------------------------------- ----------
+DATA/orcl/datafile/data1.342.860024365                   150 
+DATA/orcl/datafile/data2.265.860024375                   150
+DATA/orcl/datafile/index1.353.860024387                  100
+DATA/orcl/datafile/index2.354.860024397                  100
 
SQL> alter database datafile '+DATA/orcl/datafile/data1.342.860024365' resize 200M;
 
Database altered.
 
[oracle@prod ~]$ expdp oraworld/oraworld sample=10 full=y directory=oracle 
dumpfile=expdp_10pct.dmp log=expdp_10pct.log
Processing object type DATABASE_EXPORT/AUDIT
. . exported "ORAWORLD"."T1"                             8.162 MB   87515 rows
. . exported "ORAWORLD"."T2"                             8.183 MB   87745 rows
 
[oracle@prod ~]$  scp expdp_10pct.dmp oracle@dev.oraworld.com:/home/oracle
oracle@dev.oraworld.com's password: 
expdp_10pct.dmp                                          100%   20MB  20.0MB/s   00:01    
 

Ambiente de desarrollo:
[oracle@dev ~]$  impdp oraworld/oraworld transform=pctspace:10 directory=oracle 
dumpfile=expdp_10pct.dmp log=impdp_10pct.log sqlfile=sqlfile.txt
 
[oracle@dev ~]$ cat sqlfile.txt |grep -A 5 DATA1
 
CREATE TABLESPACE "DATA1" DATAFILE 
SIZE 15728640 
LOGGING ONLINE PERMANENT BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT 
NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;
 
 ¿Por qué 15728640 bytes (15M)? Nuestra base de datos de producción tiene 200MB actualmente porque nosotros redimensionamos dicho datafile, pero como vemos el tamaño actual no fue efectuado. El valor de 10% debería de ser 20M.
Desafortunadamente la tarea de exportación no incluye las sentencias “ALTER DATABASE DATAFILE … RESIZE” que se realizaron después de la creación de los tablespaces. La tarea de exportación únicamente respeta el valor MAXSIZE de cada datafile. Pero algunas veces nosotros no especificamos dicho valor MAXSIZE, en lugar a nosotros nos gusta redimensionar cada datafile cada vez que se necesite (on demand).
Si nosotros miramos dentro del DDL del tablespace ‘DATA1’ nosotros veremos lo siguiente:
SQL> select dbms_metadata.get_ddl('TABLESPACE','DATA1') from dual;
 
DBMS_METADATA.GET_DDL('TABLESPACE','DATA1')
-----------------------------------------------------------------------------
 
CREATE TABLESPACE "DATA1" DATAFILE
SIZE 157286400
LOGGING ONLINE PERMANENT BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
OCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO 
ALTER DATABASE DATAFILE
'+DATA/orcl/datafile/data1.342.860024365' RESIZE 209715200 

La parte de  "ALTER DATABASE DATAFILE .. RESIZE" es la parte que no es incluida en el archivo resultante de la operación de exportación pero cono puedes ver el valor MAXSIZE no fue especificado cuando nosotros creamos el tablespace:
SQL> select file_name, maxbytes 
     from dba_data_files 
     where tablespace_name in ('DATA1','DATA2','INDEX1','INDEX2');
 
FILE_NAME                                  MAXBYTES
---------------------------------------- ----------
+DATA/orcl/datafile/data1.342.860024365           0
+DATA/orcl/datafile/data2.265.860024375           0
+DATA/orcl/datafile/index1.353.860024387          0
+DATA/orcl/datafile/index2.354.860024397          0

Esta es la razón de porque nosotros vimos que el tamaño “15MB” como el 10% del tablespace DATA1 cuando el valor correcto debería ser 20M porque el tamaño actual del datafile en el ambiente de producción es de 200MB. Este comportamiento es el mismo para todos los datafiles que nosotros hemos redimensionado a lo largo de la vida de la base de datos.
¿Cómo solucionarlo?
Opción 1:
  • Pre-crear los tablespaces en la base de datos de pruebas y ejecutar otra vez la tarea de importación. Puedes usar la siguiente sentencia para extraer los DDL’s de los tablespaces:    
select dbms_metadata.get_ddl('TABLESPACE',tablespace_name)  
from dba_tablespaces;
 
Opción 2:
  • En la base de datos fuente, incrementar el valor de MAXSIZE de la clausula AUTOEXTEND hasta el tamaño actual de dicho datafile. Puedes usar la siguiente sentencia para esto:    
select 'ALTER DATABASE DATAFILE '''||file_name||''' AUTOEXTEND ON MAXSIZE '|| bytes||';' 
from dba_data_files where maxbytes < bytes;
 
  • Realice una exportación completa de los datos usando data pump
  • Recree la base de datos de pruebas usando el archivo de exportación que se realizó en el paso 2. Esto debe hacerse con impdp del utilitario data pump.

Referencias:
  • How To Export Only a Percentage Of Data In Tables Using The Datapump SAMPLE Parameter (Doc ID 1422064.1)
  • How To Specify A Percentage Of Data To Be Exported Using DataPump Export (Doc ID 1385364.1)
  • "ORA-02494: invalid or missing maximum file size in MAXSIZE clause" during IMPDP (Doc ID 1670695.1)
  • Oracle Database 12c Backup and Recovery Survival Guide - Franciscy Muñoz Alvarez