sábado, 30 de junio de 2012

Un buen truco para poder mandar un comando en sqlplus via nohup y poder irte a dormir

Uno de las grandes desventajas que tenemos como DBAs es que mucho de nuestro trabajo son a deshoras, y de igual manera requieren de scripts que toman a veces dos o tres horas en correr, asi que si son las dos de la mañana, tres horas de poder dormir a nadie le caen nada mal, especialmente si lo unico que tienes que es estar monitoreando y asegurandote que un script corra bien.

Asi que una manera para que te puedas ir a dormir y nada mas despertarte es si llega a fallar el script

Lo primero que ahi que hacer, y esto es importante que en el ambiente que lo hagas, tengas el permiso para poder hacerlo, es poner el password en un archivo de texto y con permisos 400

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ ls -ltr passfile.txt
-r-------- 1 oracle oinstall 13 Jun  30 20:58 passfile.txt


oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ cat passfile.txt
hr:12345

En un script de shell de unix vas a poner lo que esta abajo

. ${HOME}/bin/TESTDB
HR_PASS=`cat  /mount/dba01/oracle/DBATEST/admin/passfile.txt | grep hr | cut -d: -f2`
LOG_DIR=${SID_HOME}/audit
sqlplus /nolog <<EOF > ${LOG_DIR}/test.log
connect hr/${HR_PASS}
select sysdate from dual;
exit
EOF

oracle_error=`cat ${LOG_DIR}/test.log | grep "ORA-" | wc -l`
if [ ${oracle_error} -gt 0 ]; then
     echo "###############################################################"
     echo "## ERROR ====> Unable to get the Date"
     cat ${LOG_DIR}/test.log | grep ORA- | awk '{print "##", $0}'
     echo "###############################################################"
     mailx -s "Error in Getting the Time" rene.antunez@blogspot.com < ${LOG_DIR}/test.log
     exit 1
fi

Ya una vez que tengas tu shell script, ya nada mas lo tienes que mandar en modo nohup y te puedes ir a dormir o comer en lo que corre tu script, si llega a fallar, te llegaria un correo con el error y donde es que fallo. De igual manera, puedes cambiar el select por un script de sql.


oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ nohup ./test.sh &

martes, 19 de junio de 2012

Como Flashback Drop me salvo mucho trabajo

Peoplesoft tiene una peculiaridad que no me gusto mucho, una de las maneras que tienen para modificar la estructura de una tabla es que crea una tabla con un nombre temporal,  de ahí hace un insert into de un select , y de aquí lo que hace es tira la tabla original y renombra la tabla temporal al nombre de la tabla original.

Antes de hacer todo esto es altamente recomendable tener un buen respaldo de tu base de datos, si es una tabla pequeña , con un export puede bastar, pero si es una tabla bastante grande un export puede ser tardado y un poco latoso.

El otro día tuve que estar al pendiente de unos cambios hechos de esta manera, como eran pocas tablas con un tamaño relativamente chico de 10 millones de entradas cada una , así que me asegure que el respaldo de la base de datos fuera consistente y también para mi salud mental, tome un export, aunque me tome un poco de espacio y tiempo, quería que cualquier cosa poder recuperar rápido y sin tener que recuperar toda la base de datos, cabe decir que eran catálogos, así que el equipo funcional y yo sabíamos que los datos no iban a cambiar mientras los exportabamos.

Antes de empezar , me asegure que el recyclebin estuviera prendido

TESTDB> show parameter recyclebin

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
recyclebin                           string      on

Al correr uno de los scripts, la Ley de Murphy entro en accion, este trono a la mitad por que uno de los cambios estructurales que se estaba haciendo era pasar un campo a que tuviera la restricción de NOT NULL, pero el script continua aunque haya fallado ahí, así que tiro la tabla original , y renombro la tabla con nombre temporal al que tenia la original, quedandos con una tabla vacía, como se ve abajo :

TESTDB> create table temporal(id number,name varchar2(30) not null);
Table created.

TESTDB> insert into temporal (id,name) select id,name from test;
insert into temporal (id,name) select id,name from test
                                              *
ERROR at line 1:
ORA-01400: cannot insert NULL into ("RENE"."TEMPORAL"."NAME")

TESTDB> drop table TEST;
Table dropped.

TESTDB> rename TEMPORAL to TEST;
Table renamed.

TESTDB> select count(1) from TEST;
 
 COUNT(1)

----------
       
  0

En lugar de ponerme a restaurar la tabla del respaldo que habia tomado antes de empezar, lo unico que tuve que hacer es identificar en el recyclebin la tabla que habia tirado, tirar la tabla que se habia renombrado de TEMPORAL a TEST en el script anterior, ya que esta era la  tabla sin datos y de ahi hacer un flashback before drop para que TEST volviera a tener los datos antes del comando DROP

TESTDB>  SELECT object_name,original_name,droptime  
2  FROM recyclebin;

OBJECT_NAME                    ORIGINAL_NAME                    DROPTIME
------------------------------ -------------------------------- -------------------
BIN$wtQeQ7eoQJ7gQAAAAAAbEQ==$0 TEST_IDX                         2012-06-19:06:27:01
BIN$wtQeQ7epQJ7gQAAAAAAbEQ==$0 TEST                             2012-06-19:06:27:01


TESTDB> drop table TEST;

Table dropped.

TESTDB> FLASHBACK TABLE "BIN$wtQeQ7epQJ7gQAAAAAAbEQ==$0" TO BEFORE DROP;

Flashback complete.

TESTDB> select count(1) from TEST;

  COUNT(1)
----------
         3

En versiones anteriores a 11.2.0.2 si mal no recuerdo, todavia si existia un indice de la tabla , tambien tenias que sacarlo del recyclebin, y es tan facil como renombrar al indice, en 11.2.0.2, los indices se recuperan con el flashback.

Esta tecnica es muy buena para cuando haz hecho un drop de una tabla y rapidamente necesitas recuperarla, espero te ayude como a mi lo ha hecho en ciertas ocasiones.

domingo, 3 de junio de 2012

RMAN: Error al abrir la base de datos ORA-00600 arguments: [2898], [6]

El otro día tratando de recuperar una Base de Datos con RMAN en 11.2.0.3 y RHEL 5 hasta un punto en el tiempo, todo iba funcionando como debería de ser, los datafiles se recuperaron, se aplico los archived redo logs y en el momento de tratar de abrir la base de datos con open resetlogs, me salio, como diria "Chabelo", una espantosisima y tremenda "X", o sea un error ORA-00600.

Y de ahí ya no pude abrir la base de datos, hasta que hice los pasos que hago abajo :(

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 05/31/2012 20:40:47
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2898], [6], [12], [], [], [], [], [], [], [], [], []
Process ID: 17480
Session ID: 443 Serial number: 3

 Aquí  no voy a entrar a detalle de como sucedió el error, si no mas bien como lo puedes solucionar si se te llega a presentar.

Lo que si te voy a decir es que tiene que ver que tiene que ver con las encarnaciones que se encuentran presentes en el controfile y este error lo he podido replicar cuando después de tener varias encarnaciones, hago un reset database to incarnation N;

RMAN-06246: List of Database Incarnations
RMAN-06247: DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
RMAN-06248: ------- ------- -------- ---------------- --- ---------- ----------
RMAN-06249: 1       1       TESTDB  3889289065       PARENT  12296983831137 16-APR-2012 23:58:59
RMAN-06249: 2       2       TESTDB  3889289065       PARENT  12462184333086 09-MAY-2012 22:50:31
RMAN-06249: 3       3       TESTDB  3889289065       ORPHAN  12462184341387 10-MAY-2012 20:16:41
RMAN-06249: 5       5       TESTDB  3889289065       PARENT  12462184341387 11-MAY-2012 02:57:04
RMAN-06249: 4       4       TESTDB  3889289065       ORPHAN  12462184344923 10-MAY-2012 22:11:55
RMAN-06249: 6       6       TESTDB  3889289065       CURRENT 12462187527879 28-MAY-2012 22:20:17

RMAN-08066: database reset to incarnation 5

RMAN-06246: List of Database Incarnations
RMAN-06247: DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
RMAN-06248: ------- ------- -------- ---------------- --- ---------- ----------
RMAN-06249: 1       1       TESTDB  3889289065       PARENT  12296983831137 16-APR-2012 23:58:59
RMAN-06249: 2       2       TESTDB  3889289065       PARENT  12462184333086 09-MAY-2012 22:50:31
RMAN-06249: 3       3       TESTDB  3889289065       ORPHAN  12462184341387 10-MAY-2012 20:16:41
RMAN-06249: 5       5       TESTDB  3889289065       CURRENT 12462184341387 11-MAY-2012 02:57:04
RMAN-06249: 4       4       TESTDB  3889289065       ORPHAN  12462184344923 10-MAY-2012 22:11:55
RMAN-06249: 6       6       TESTDB  3889289065       ORPHAN  12462187527879 28-MAY-2012 22:20:17

Como te decía no me voy a concentrar a decirte como replicarlo, si no como tener una manera de solucionarlo, ya que no te vas a encontrar con mucha información con respecto a este error, ni siquiera en MOS.

Lo primero que hay que hacer es restaurar la base de datos hasta el punto en el tiempo que necesitas, en el ejemplo que te presento también recupere el archivo de parámetros así como el controlfile del respaldo.

No se te olvide antes de iniciar con RMAN tener la variable de ambiente de UNIX NLS_DATE_FORMAT puesta,

export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'

De igual manera, te va a servir esta variable

export ORA_RMAN_SGA_TARGET=1000

Para ponerlo por puntos separados esto fue lo que hice en la primera parte, en un archivo llamado restore_TESTDB_A.rmn:

  1. Restaurara el archivo de parametros del respaldo.
  2. Reiniciar la Base de datos después de restaurar el archive de parametros para que tomara el spfile que acabo de restablecer.
  3. Cambiar el parámetro cluster_database a FALSE (Solamente RAC)
  4. Restaurar el controlfile del respaldo
  5. Reiniciar la base de datos para que el parámetro de cluster_database se tome en cuenta, ya que no es un parametro dinamico.
  6. Cambiar a la Quinta encarnación de la Base de Datos, ya que ahi es donde es a donde quiero llegar
  7. Restaurar la Base de Datos al punto en el tiempo que quiero llegar

Aquí te presento el log de la primera etapa, así como el script que se corrió, lo corte un poco para que no tomara tanto espacio, pero si lo quise poner para que supieras que paso

Recovery Manager: Release 11.2.0.3.0 - Production on Sat Jun 2 20:43:25 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

RMAN-06193: connected to target database (not started)

RMAN> run
2> {
3> set dbid 3889289065;
4> startup nomount ;
5> restore spfile from '/mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-02';
6> shutdown immediate;
7> startup nomount ;
8> sql "alter system set cluster_database = FALSE  scope = spfile";
9> restore controlfile from '/mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-02';
10> alter database mount;
11> shutdown immediate;
12> startup mount;
13> }
14>
15> list incarnation;
16> reset database to incarnation 5;
17> list incarnation;
18> list backup summary;
19> crosscheck backup device type disk;
20>
21>
22> RUN
23> {
24> sql "alter session set max_dump_file_size=''UNLIMITED''";
25> sql "alter session set events ''10046 trace name context forever, level 12''";
26> set until time "to_date('28-MAY-2012 20:46:43','dd-MON-yyyy hh24:mi:ss')";
27> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK ;
28> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK ;
29> ALLOCATE CHANNEL CH3 DEVICE TYPE DISK ;
30> ALLOCATE CHANNEL CH4 DEVICE TYPE DISK ;
31> ALLOCATE CHANNEL CH5 DEVICE TYPE DISK ;
32> RESTORE DATABASE;
33> }
34>
RMAN-03023: executing command: SET DBID

RMAN-04014: startup failed: ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+GBS_HRMS_DATA/TESTDB/PARAMETERFILE/spfileTESTDB.ora'
ORA-17503: ksfdopn:2 Failed to open file +GBS_HRMS_DATA/TESTDB/PARAMETERFILE/spfileTESTDB.ora
ORA-15056: additional error message
ORA-17503: ksfdopn:2 Failed to open file +GBS_HRMS_DATA/TESTDB/parameterfile/spfileTESTDB.ora
ORA-15173: entry 'spfileTESTDB.ora' does not exist in directory 'parameterfile'
ORA-06512: at line 4

RMAN-04024: starting Oracle instance without parameter file for retrieval of spfile
RMAN-06196: Oracle instance started

Total System Global Area    1043886080 bytes

Fixed Size                     2234960 bytes
Variable Size                452986288 bytes
Database Buffers             566231040 bytes
Redo Buffers                  22433792 bytes

RMAN-03090: Starting restore at 02-JUN-2012 20:43:44
RMAN-06009: using target database control file instead of recovery catalog
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=1861 device type=DISK

RMAN-08554: channel ORA_DISK_1: restoring spfile from AUTOBACKUP /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-02
RMAN-08541: channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
RMAN-03091: Finished restore at 02-JUN-2012 20:43:47

RMAN-06402: Oracle instance shut down

RMAN-06193: connected to target database (not started)
RMAN-06196: Oracle instance started

Total System Global Area    2622255104 bytes

Fixed Size                     2231232 bytes
Variable Size               1409287232 bytes
Database Buffers            1174405120 bytes
Redo Buffers                  36331520 bytes

RMAN-06162: sql statement: alter system set cluster_database = FALSE  scope = spfile

RMAN-03090: Starting restore at 02-JUN-2012 20:44:14
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08605: channel ORA_DISK_1: SID=521 instance=TESTDB1 device type=DISK

RMAN-08021: channel ORA_DISK_1: restoring control file
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
RMAN-08505: output file name=+GBS_HRMS_DATA/TESTDB/controlfile/control01.ctl
RMAN-08505: output file name=+GBS_HRMS_DATA/TESTDB/controlfile/control02.ctl
RMAN-03091: Finished restore at 02-JUN-2012 20:44:17

RMAN-06199: database mounted
RMAN-08031: released channel: ORA_DISK_1

RMAN-06404: database dismounted
RMAN-06402: Oracle instance shut down

RMAN-06193: connected to target database (not started)
RMAN-06196: Oracle instance started
RMAN-06199: database mounted

Total System Global Area    2622255104 bytes

Fixed Size                     2231232 bytes
Variable Size               1409287232 bytes
Database Buffers            1174405120 bytes
Redo Buffers                  36331520 bytes

RMAN-06246: List of Database Incarnations
RMAN-06247: DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
RMAN-06248: ------- ------- -------- ---------------- --- ---------- ----------
RMAN-06249: 1       1       TESTDB  3889289065       PARENT  12296983831137 16-APR-2012 23:58:59
RMAN-06249: 2       2       TESTDB  3889289065       PARENT  12462184333086 09-MAY-2012 22:50:31
RMAN-06249: 3       3       TESTDB  3889289065       ORPHAN  12462184341387 10-MAY-2012 20:16:41
RMAN-06249: 5       5       TESTDB  3889289065       PARENT  12462184341387 11-MAY-2012 02:57:04
RMAN-06249: 4       4       TESTDB  3889289065       ORPHAN  12462184344923 10-MAY-2012 22:11:55
RMAN-06249: 6       6       TESTDB  3889289065       CURRENT 12462187527879 28-MAY-2012 22:20:17

RMAN-08066: database reset to incarnation 5

RMAN-06246: List of Database Incarnations
RMAN-06247: DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
RMAN-06248: ------- ------- -------- ---------------- --- ---------- ----------
RMAN-06249: 1       1       TESTDB  3889289065       PARENT  12296983831137 16-APR-2012 23:58:59
RMAN-06249: 2       2       TESTDB  3889289065       PARENT  12462184333086 09-MAY-2012 22:50:31
RMAN-06249: 3       3       TESTDB  3889289065       ORPHAN  12462184341387 10-MAY-2012 20:16:41
RMAN-06249: 5       5       TESTDB  3889289065       CURRENT 12462184341387 11-MAY-2012 02:57:04
RMAN-06249: 4       4       TESTDB  3889289065       ORPHAN  12462184344923 10-MAY-2012 22:11:55
RMAN-06249: 6       6       TESTDB  3889289065       ORPHAN  12462187527879 28-MAY-2012 22:20:17

RMAN-03090: Starting implicit crosscheck backup at 02-JUN-2012 20:45:05
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=456 device type=DISK
RMAN-08030: allocated channel: ORA_DISK_2
RMAN-08500: channel ORA_DISK_2: SID=469 device type=DISK
RMAN-06206: Crosschecked 25 objects
RMAN-03091: Finished implicit crosscheck backup at 02-JUN-2012 20:45:13

RMAN-03090: Starting implicit crosscheck copy at 02-JUN-2012 20:45:13
RMAN-12016: using channel ORA_DISK_1
RMAN-12016: using channel ORA_DISK_2
RMAN-03091: Finished implicit crosscheck copy at 02-JUN-2012 20:45:14

RMAN-07501: searching for all files in the recovery area
RMAN-07507: cataloging files...
RMAN-07512: no files cataloged

RMAN-08031: released channel: ORA_DISK_1
RMAN-08031: released channel: ORA_DISK_2
RMAN-08030: allocated channel: CH1
RMAN-08500: channel CH1: SID=456 device type=DISK

RMAN-08030: allocated channel: CH2
RMAN-08500: channel CH2: SID=469 device type=DISK

RMAN-08030: allocated channel: CH3
RMAN-08500: channel CH3: SID=482 device type=DISK

RMAN-08030: allocated channel: CH4
RMAN-08500: channel CH4: SID=495 device type=DISK

RMAN-08030: allocated channel: CH5
RMAN-08500: channel CH5: SID=508 device type=DISK

RMAN-03090: Starting restore at 02-JUN-2012 20:45:26

RMAN-08016: channel CH1: starting datafile backup set restore

.
.
.
RMAN-08180: channel CH3: restore complete, elapsed time: 00:03:45
RMAN-03091: Finished restore at 03-JUN-2012 20:53:01
RMAN-08031: released channel: CH1
RMAN-08031: released channel: CH2
RMAN-08031: released channel: CH3
RMAN-08031: released channel: CH4
RMAN-08031: released channel: CH5

Recovery Manager complete.

 Ya cuando haya finalizado la restauración de los datafiles, lo que tenemos que hacer es recrear el control file tomando un respaldo hacia un archivo plano. Aquí es una parte muy delicada que yo te recomendaría hacer un listado de tus respaldos en RMAN (list backup) y  guardar un log, ya que al recrear el controlfile, vas a perder esta información si es que estas usando tu controlfile para respaldos.

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ sqlplus

SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 2 21:03:24 2012

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

Enter user-name: /as sysdba

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

TESTDB1 >ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/mount/dba01/oracle/TESTDB/scripts/control_TESTDB.sql' RESETLOGS;

Database altered.

TESTDB1 >shutdown immediate
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.

 Yo lo que hago en lugar de borrar el controlfile actual lo renombro ,si no estas usando ASM, seria con el comando mv, si estas usando ASM seria de la siguiente manera con el usuario grid y entrando a la instancia de ASM

ALTER DISKGROUP GBS_HRMS_DATA RENAME ALIAS '+GBS_HRMS_DATA/DBATEST/CONTROLFILE/control02.ctl'
     TO '+GBS_HRMS_DATA/DBATEST/CONTROLFILE/control02.ctl.old';

 Una vez que moviste los controlfiles , modifica el archivo plano del conrolfile que creamos arriba, y corre el script en sqlplus

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ sqlplus

SQL*Plus: Release 11.2.0.3.0 Production on Sat Jun 2 21:06:39 2012

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

Enter user-name: /as sysdba
Connected to an idle instance.

TESTDB1 >@control_TESTDB.sql
ORACLE instance started.

Total System Global Area 2622255104 bytes
Fixed Size                  2231232 bytes
Variable Size            1409287232 bytes
Database Buffers         1174405120 bytes
Redo Buffers               36331520 bytes

Control file created.

TESTDB1 >exit

Ahora catalogamos el respaldo, ya que como te mencionaba anteriormente, esta información se perdió

oracle@servidor1.oracleenespanol.blogspot.com [TESTDB1] /mount/dba01/oracle/TESTDB/scripts
oracle $ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Sat Jun 2 21:13:10 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: TESTDB (DBID=3889289065, not open)

RMAN> catalog start with '/mount/copy01/TESTDB/oracle/TESTDB' noprompt;

using target database control file instead of recovery catalog
searching for all files that match the pattern /mount/copy01/TESTDB/oracle/TESTDB

List of Files Unknown to the Database
=====================================
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_64_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_65_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_66_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_67_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_68_784500420
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_69_784500421
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_70_784500437
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_71_784500437
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_72_784500494
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_73_784500510
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/TESTDB_05_28_2012_784500375.ctl
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-01
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120510-04
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120510-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120511-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-02
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120531-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_52_784500223
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_53_784500224
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_54_784500224
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_55_784500225
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_56_784500226
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_57_784500226
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_58_784500228
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_59_784500230
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_60_784500231
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_61_784500232
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_64_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_65_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_66_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_67_784500419
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_68_784500420
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_69_784500421
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_70_784500437
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_71_784500437
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_72_784500494
File Name: /mount/copy01/TESTDB/oracle/TESTDB/arch/TESTDB_ARCH_05282012_1_73_784500510
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/TESTDB_05_28_2012_784500375.ctl
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-01
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120510-04
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120510-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120511-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120528-02
File Name: /mount/copy01/TESTDB/oracle/TESTDB/control/c-3889289065-20120531-00
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_52_784500223
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_53_784500224
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_54_784500224
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_55_784500225
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_56_784500226
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_57_784500226
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_58_784500228
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_59_784500230
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_60_784500231
File Name: /mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_05282012_1_61_784500232

 Y por ultimo, lo que tenemos que hacer es recuperar la base de datos al mismo punto en tiempo que restauramos los datafiles y como ves marcado en rojo abajo, pudimos abrir la base de datos y regresamos a un estado de paz y tranquilidad :)
RMAN> RUN
2> {
3> set until time "to_date('28-MAY-2012 20:46:43','dd-MON-yyyy hh24:mi:ss')";
4> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK ;
5> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK ;
6> ALLOCATE CHANNEL CH3 DEVICE TYPE DISK ;
7> ALLOCATE CHANNEL CH4 DEVICE TYPE DISK ;
8> ALLOCATE CHANNEL CH5 DEVICE TYPE DISK ;
9> RECOVER DATABASE;
10> ALTER DATABASE OPEN RESETLOGS;
11> }


 archived log file name=+GBS_HRMS_DATA/TESTDB/archivelog/1_32_782967424.dbf thread=1 sequence=0
 archived log file name=+GBS_HRMS_DATA/TESTDB/archivelog/2_16_782967424.dbf thread=2 sequence=16
 archived log file name=+GBS_HRMS_DATA/TESTDB/archivelog/1_33_782967424.dbf thread=1 sequence=33
 media recovery complete, elapsed time
 Finished recover at 02-JUN-2012 21:18:49

 database opened
 released channel
 released channel
 released channel
 released channel
 released channel

Recovery Manager complete.