Mostrando las entradas con la etiqueta RMAN. Mostrar todas las entradas
Mostrando las entradas con la etiqueta RMAN. Mostrar todas las entradas

sábado, 15 de febrero de 2014

RMAN 12c : Dile adios a tu respaldo cuando haces un DROP de tu PDB

Estaba trabajando en mis presentaciones para IOUG Collaborate, y me tope con este extraño comportamiento en RMAN 12c (12.1.0.1.0), que para mí, no debería suceder. Parece que cuando haces un DROP PLUGGABLE DATABASE, es el equivalente a DROP DATABASE INCLUDING BACKUPS. Esto significa que si necesitas  restaurar tu PDB más adelante, no tendrás este respaldo registrado - así que ten cuidado cuando tires tu PDB.

Aquí vamos: Tomé un respaldo de mi CDB y todas sus PDBs, ahora mantente atento en este tag TAG20140212T191237 (He quitado un par de líneas para facilitar la lectura del blog).

oracle@oracleenespanol2.localdomain [cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
 
oracle $ rman target sys/oracle@cdb1
 
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 19:12:06 2014
 
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: CDB1 (DBID=808250731)
 
RMAN> backup database plus archivelog ;
 
Starting backup at 12/02/2014 19:12:31
 
current log archived
 
...
 
Starting backup at 12/02/2014 19:12:37
 
using channel ORA_DISK_1
 
channel ORA_DISK_1: starting full datafile backup set
 
channel ORA_DISK_1: specifying datafile(s) in backup set
 
input datafile file number=00003 name=/u01/app/oracle/oradata/CDB1/datafile/o1_mf_sysaux_9c520w6w_.dbf
 
input datafile file number=00004 name=/u01/app/oracle/oradata/CDB1/datafile/o1_mf_undotbs1_9c524cnr_.dbf
 
input datafile file number=00001 name=/u01/app/oracle/oradata/CDB1/datafile/o1_mf_system_9c522mbz_.dbf
 
input datafile file number=00006 name=/u01/app/oracle/oradata/CDB1/datafile/o1_mf_users_9c524bjm_.dbf
 
channel ORA_DISK_1: starting piece 1 at 12/02/2014 19:12:38
 
channel ORA_DISK_1: finished piece 1 at 12/02/2014 19:15:23
 
piece handle=/u01/app/oracle/fast_recovery_area/CDB1/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbjrqd_.bkp tag=TAG20140212T191237 comment=NONE
 
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:45
 
channel ORA_DISK_1: starting full datafile backup set
 
channel ORA_DISK_1: specifying datafile(s) in backup set
 
input datafile file number=00009 name=/u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_sysaux_9c52fqvt_.dbf
 
input datafile file number=00008 name=/u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_system_9c52fqt1_.dbf
 
input datafile file number=00010 name=/u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_users_9c52hof0_.dbf
 
channel ORA_DISK_1: starting piece 1 at 12/02/2014 19:15:23
 
channel ORA_DISK_1: finished piece 1 at 12/02/2014 19:16:08
 
piece handle=/u01/app/oracle/fast_recovery_area/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbovmw_.bkp tag=TAG20140212T191237 comment=NONE
 
..
 
Finished backup at 12/02/2014 19:16:37
 
Starting Control File and SPFILE Autobackup at 12/02/2014 19:16:37
 
piece handle=/u01/app/oracle/fast_recovery_area/CDB1/autobackup/2014_02_12/o1_mf_s_839358997_9hrbr5vr_.bkp comment=NONE
 
Finished Control File and SPFILE Autobackup at 12/02/2014 19:16:38

Así que primero quiero mostarte que si soy capaz de recuperar mi PDB en caso de que perdiera mis archivos con el respaldo que tengo, así que primero voy a eliminarlos manualmente.

oracle@oracleenespanol2.localdomain[cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
 
oracle $ sqlplus / as sysdba
 
Connected to:
 
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
 
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
SQL> set pages 999
 
SQL> COLUMN PDB_ID FORMAT 999
 
COLUMN PDB_NAME FORMAT A8
 
COLUMN FILE_ID FORMAT 9999
 
COLUMN TABLESPACE_NAME FORMAT A10
 
COLUMN FILE_NAME FORMAT A45
 
SELECT p.PDB_ID, p.PDB_NAME, d.FILE_ID, d.TABLESPACE_NAME, d.FILE_NAME
 
FROM DBA_PDBS p, CDB_DATA_FILES d
 
WHERE p.PDB_ID = d.CON_ID
 
ORDER BY p.PDB_ID;
 
PDB_ID PDB_NAME FILE_ID TABLESPACE FILE_NAME
 
------ -------- ------- ---------- ---------------------------------------------
 
2 PDB$SEED       5 SYSTEM   /u01/app/oracle/oradata/CDB1/datafile/o1_mf_system_9c5257ms_.dbf
 
2 PDB$SEED       7 SYSAUX   /u01/app/oracle/oradata/CDB1/datafile/o1_mf_sysaux_9c5257mj_.dbf
 
3 PDB1      9 SYSAUX   /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_sysaux_9c52fqvt_.dbf
 
3 PDB1      8 SYSTEM   /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_system_9c52fqt1_.dbf
 
3 PDB1     10 USERS   /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_users_9c52hof0_.dbf
 
SQL> alter pluggable database pdb1 close;
 
Pluggable database altered.
 
SQL> exit
 
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
 
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 
oracle@oracleenespanol2.localdomain[cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
 
oracle $ rm /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_sysaux_9c52fqvt_.dbf
 
oracle@oracleenespanol2.localdomain[cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
 
oracle $ rm /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_system_9c52fqt1_.dbf
 
oracle@oracleenespanol2.localdomain[cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
 
oracle $ rm /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_users_9c52hof0_.dbf

Ahora que he borrado los datafiles de mi PDB, voy a proceder a restaurar y recuperarla, y no pierdas de vista la etiqueta TAG20140212T191237 que es utilizada para la restauración.

oracle@oracleenespanol2.localdomain [cdb1] /u01/app/oracle/product/12.1.0/db_1/network/admin
oracle $ rman target /
 
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Feb 12 19:19:46 2014
 
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
 
connected to target database: CDB1 (DBID=808250731)
 
RMAN> RESTORE PLUGGABLE DATABASE PDB1;
 
Starting restore at 12/02/2014 19:20:12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=77 device type=DISK
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00008 to /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_system_9c52fqt1_.dbf
channel ORA_DISK_1: restoring datafile 00009 to /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_sysaux_9c52fqvt_.dbf
channel ORA_DISK_1: restoring datafile 00010 to /u01/app/oracle/oradata/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/datafile/o1_mf_users_9c52hof0_.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbovmw_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/CDB1/EDDDC5E35CF7216DE043344EB2C0AB6F/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbovmw_.bkp tag=TAG20140212T191237
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 12/02/2014 19:20:48
 
RMAN> RECOVER PLUGGABLE DATABASE PDB1;
 
Starting recover at 12/02/2014 19:21:06
using channel ORA_DISK_1
 
starting media recovery
media recovery complete, elapsed time: 00:00:00
 
Finished recover at 12/02/2014 19:21:07
 
RMAN> alter pluggable database pdb1 open;
 
Statement processed

Como puedes ver, pude restaurar y recuperar mi PDB sin ningún problema. ¿Pero qué sucede si decido tirar mi PDB, y más tarde me doy cuenta de que la PDB se necesitaba? Así que traté recuperar mis PDB con mi respaldo, ya no esta, y de igual manera no se reporta en la etiqueta de respaldo TAG20140212T191237.

RMAN> alter pluggable database pdb1 close;
 
Statement processed
 
RMAN> drop pluggable database PDB1;
 
Statement processed
 
RMAN> RESTORE PLUGGABLE DATABASE PDB1;
 
Starting restore at 13/02/2014 11:18:26
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=41 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/13/2014 11:18:27
RMAN-06813: could not translate pluggable database PDB1
 
RMAN> list backup tag TAG20140212T191237;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
67 Full 1.88G DISK 00:02:41 12/02/2014 19:15:19
 BP Key: 67 Status: AVAILABLE Compressed: NO Tag: TAG20140212T191237
 Piece Name: /u01/app/oracle/fast_recovery_area/CDB1/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbjrqd_.bkp
 List of Datafiles in backup set 67
 File LV Type Ckp SCN Ckp Time Name
 ---- -- ---- ---------- ------------------- ----
 1 Full 3220602 12/02/2014 19:12:38 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_system_9c522mbz_.dbf
 3 Full 3220602 12/02/2014 19:12:38 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_sysaux_9c520w6w_.dbf
 4 Full 3220602 12/02/2014 19:12:38 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_undotbs1_9c524cnr_.dbf
 6 Full 3220602 12/02/2014 19:12:38 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_users_9c524bjm_.dbf
 
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
69 Full 680.13M DISK 00:00:24 12/02/2014 19:16:32
 BP Key: 69 Status: AVAILABLE Compressed: NO Tag: TAG20140212T191237
 Piece Name: /u01/app/oracle/fast_recovery_area/CDB1/EDDDB886A1191F07E043344EB2C0BE27/backupset/2014_02_12/o1_mf_nnndf_TAG20140212T191237_9hrbq8lm_.bkp
 List of Datafiles in backup set 69
 Container ID: 2, PDB Name: PDB$SEED
 File LV Type Ckp SCN Ckp Time Name
 ---- -- ---- ---------- ------------------- ----
 5 Full 1732663 18/12/2013 22:52:25 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_system_9c5257ms_.dbf
 7 Full 1732663 18/12/2013 22:52:25 /u01/app/oracle/oradata/CDB1/datafile/o1_mf_sysaux_9c5257mj_.dbf

Como puedes ver, el respaldo de mi PDB ya no está registrado. Yo todavía no sé si esto es un comportamiento normal para los respaldos de una PDB o un error - pero por ahora sólo ten cuidado al tirar una PDB ya que el respaldo puede que no será confiable. Si esto no te asusta, la verdad no se que lo hará ¿o no?

lunes, 22 de abril de 2013

El estado no documentado "M" de un respaldo en RMAN

No es raro que Oracle le haga falta detalles a su documentación , y esto es sólo otro caso de esta enfermedad.

Tenemos una base de datos en la que tenemos dos copias del mismo backup set, uno lo tenemos en el FRA, la otra en un disco externo, que de vez en cuando la copia se elimina de este segundo disco. Pero, ¿qué sucede después de hacer un crosscheck y una de las 2 copias  no se encuentra? El del FRA está disponible y el que está en el disco externo ha expirado, como vas a ver esto cuando hagas un LIST en RMAN?

En cuanto a la documentación de 11.2 para el comando LIST, sólo dice que el estado de un respaldo puede estar AVAILABLE, UNAVAILABLE, o EXPIRED, pero como puedes ver a continuación, este no es el caso de nuestra base de datos :)


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
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1986    B  F  A DISK        17-APR-13       1       2       NO         *
1987    B  F  M DISK        17-APR-13       1       2       NO         *
1988    B  F  A DISK        17-APR-13       1       2       NO         *
1989    B  F  A DISK        19-APR-13       1       1       NO         TAG000661
1990    B  A  A DISK        19-APR-13       1       1       YES        BUP_ARCH_FRA

La primera vez que vi esto, se me hizo curioso en cuanto a lo que significa el sentido del status M (y es al día de hoy  que todavía no sé el significado exacto, pero tengo mis suposiciones). Si hago un trace de mi comando LIST BACKUP SUMMARY, puedo ver exactamente lo que yo sabía que estaba ocurriendo:


pythian@oracleenespanol.local /home/pythian/working/antunez
pythian $ rman target / debug trace rman.trc
Recovery Manager: Release 11.2.0.3.0 - Production on Fri Apr 19 16:02:56 2013
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
RMAN-06005: connected to target database: TESTDB (DBID=1834739652)
 
RMAN> list backup summary;

Este es un pequeño resultado del trace que hice :


DBGMISC: 339 BS (datafile) key=1987 recid=1987 stamp=812962808 setstamp=812962807 setcount=2021
DBGMISC: level=1 level_i=-1 piececount=1 keepopts=0, site_key=0 [16:03:27.544]
DBGMISC: site_key=0 [16:03:27.544]
DBGMISC: chid=NIL parm=NIL [16:03:27.544]
DBGMISC: flags= [16:03:27.544]
DBGMISC: valid backup set list is [16:03:27.544]
DBGMISC: 1 VBS copy#=1 tag=BACKUP_CONTROLFILE_FRA deviceType=DISK status=A
DBGMISC: 1 BPIECEX key=3502 recid=3502 stamp=812962808
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=+FRA/test/backupset/2013_04_17/ncnnf0_backup_controlfile_fra_0.297.812962809
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: 2 VBS copy#=2 tag=BACKUP_OF_BACKUPSET deviceType=DISK status=X
DBGMISC: 1 BPIECEX key=3538 recid=3538 stamp=813024283
DBGMISC: bskey=1987 set_stamp=812962807 set_count=2021 site_key=0
DBGMISC: pieceno=1 handle=/backupdisk/TEST_bck/db_bckset_backup_TEST2_04-18-2013_v5o79kvn_1_2.rman
DBGMISC: device=DISK krmkch { count=0 found=FALSE }
DBGMISC: restore target list is [16:03:27.545]
DBGMISC: 1 ACT type=full fromSCN=0 toSCN=307822519 fno=0
DBGMISC: CURCF

Como puedes ver arriba, una copia ha expirado y la otra está disponible, también cuando el resultado del comando LIST tiene un asterisco "*",  se debe a que cada copia tiene un TAG diferente,  para la etiqueta del backupset con clave 1987.

Ambas conductas son perfectamente normales, pero no vas a encontrar esto en cualquier lugar de la documentación de Oracle, por lo que la próxima vez que veas esto en tu comando LIST, conocerás el significado exacto de este estado. ¿Has visto esto antes en tus listados de RMAN?

P.D. Para mí significa Múltiple o Mixta.

jueves, 25 de octubre de 2012

RMAN : Crear un respaldo consistente y un RESTORE POINT todo a la vez

Una característica que tiene RMAN en 11g es que tienes la posibilidad de crear un punto de restauración en el mismo respaldo, este método es muy útil, sobre todo cuando vas a hacer una actualización importante en tu Base de Datos y tienes que crear un respaldo antes, este es el mejor método desde mi punto de vista.

Lo primero , es que verifico que no hay un punto de restauración para mi base de datos

TESTDB> set linesize 121
TESTDB> col name format a15
TESTDB> col time format a32

TESTDB> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

no rows selected

Ahora lo que hago es que corro un respaldo con la opción de KEEP UNTIL y RESTORE POINT

RMAN> RUN
2>  {
3> BACKUP AS COMPRESSED BACKUPSET
4>  INCREMENTAL LEVEL = 0
5>  DATABASE
6>   FORMAT '/mount/copy01/TESTDB/oracle/TESTDB/incr/%d_HOT_%M%D%Y_%p_%s' 
7>   TAG TESTDB
8>   KEEP UNTIL TIME 'SYSDATE + 5'
9>   RESTORE POINT BEFORE_UPGRADE;
10> }
Starting backup at Oct 25 2012 08:41:49
current log archived

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:50
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/mount/u01/oracle/TESTDB/data/system01.dbf
input datafile file number=00003 name=/mount/u01/oracle/TESTDB/data/undotbs1_01.dbf
input datafile file number=00004 name=/mount/u01/oracle/TESTDB/data/users01.dbf
input datafile file number=00002 name=/mount/u01/oracle/TESTDB/data/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:50
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:57
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_24 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:57
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed 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 Oct 25 2012 08:41:57
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:58
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_25 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01


current log archived
using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:58
archived logs required to recover from this backup will be backed up
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=19 RECID=19 STAMP=797589718
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:41:58
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:41:59
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_26 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

using channel ORA_DISK_1
backup will be obsolete on date Oct 30 2012 08:41:59
archived logs required to recover from this backup will be backed up
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at Oct 25 2012 08:42:00
channel ORA_DISK_1: finished piece 1 at Oct 25 2012 08:42:01
piece handle=/mount/copy01/TESTDB/oracle/TESTDB/incr/TESTDB_HOT_10252012_1_27 tag=TESTDB comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at Oct 25 2012 08:42:01

Para verificar que se creo el punto de restauración corro los siguientes comandos en RMAN

RMAN> list restore point all;

SCN              RSP Time             Type       Time                 Name
---------------- -------------------- ---------- -------------------- ----
234073                                           Oct 25 2012 08:41:58 BEFORE_UPGRADE

y en Sqlplus

SQL> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size
  2  FROM gv$restore_point;

NAME         SCN TIME        DATABASE_INCARNATION# GUA STORAGE_SIZE
--------------- ---------- -------------------------------- --------------------- --- ------------
BEFORE_UPGRADE     234073 25-OCT-12 08.41.58.000000000 AM   1 NO   0

Si te fijas, el SCN es el mismo , 234073,  que es lo que andamos buscando. En dado caso de que tengas que hacer un rollback, a este SCN seria al que regresarias.

Este respaldo de igual manera lo podemos utilizar para clonar una base de datos hasta el punto de restauración que creaste con la opción TO RESTORE POINT, no puse toda la salida, pero si te fijas abajo, esta recuperando hasta el punto de restauración que creamos en la Base de Datos TESTDB

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


RMAN> RUN
2> {  
3>   ALLOCATE AUXILIARY CHANNEL newdb DEVICE TYPE disk; 
4>   DUPLICATE TARGET DATABASE TO testcopy
5>     TO RESTORE POINT BEFORE_UPGRADE
6>      DB_FILE_NAME_CONVERT ('/mount/u01/oracle/TESTDB/','/mount/u01/oracle/TESTCOPY/','/mount/u02/oracle/TESTDB/','/mount/u02/oracle/TESTCOPY/')
7> LOGFILE
8>       GROUP 1 ('/mount/u01/oracle/TESTCOPY/log/redo01_1.f',
9>                '/mount/u02/oracle/TESTCOPY/log/redo01_2.f') SIZE 4M,
10>       GROUP 2 ('/mount/u01/oracle/TESTCOPY/log/redo02_1.f',
11>                '/mount/u02/oracle/TESTCOPY/log/redo02_2.f') SIZE 4M,
12>       GROUP 3 ('/mount/u01/oracle/TESTCOPY/log/redo03_1.f',
13>                '/mount/u02/oracle/TESTCOPY/log/redo03_2.f') SIZE 4M REUSE;
14> }
using target database control file instead of recovery catalog
allocated channel: newdb
channel newdb: SID=19 device type=DISK

Starting Duplicate Db at Oct 25 2012 08:50:53

contents of Memory Script:
{
   set to restore point  'BEFORE_UPGRADE';
   sql clone "alter system set  db_name = 
 ''TESTDB'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   sql clone "alter system set  db_unique_name = 
 ''TESTCOPY'' comment=
 ''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile;
   alter clone database mount;
}
.
.
.
contents of Memory Script:
{
   Alter clone database open resetlogs;
}
executing Memory Script

database opened
Finished Duplicate Db at Oct 25 2012 08:51:57
released channel: newdb


Espero que este método te sirva en tus próximas actualizaciones.