martes, 31 de diciembre de 2013

Particiones, datos y optimización

Tenemos una tabla particionada y una consulta que anda lento porque la condición de where no incluye la columna de partición y usa columnas que no están indexadas.

¿Podemos hacer algo más que dar la recomendación obvia de crear un nuevo índice global?

Seguro!, por lo menos hacer estas dos revisiones rápidas.

Lo primero es ver si se usa la columna de particionamento en la condición del where.
Si se usa, la consulta solo leerá datos de esa partición (el optimizador aplica partition pruning), por lo tanto un nuevo índice podría ser útil siempre que las particiones tengan un volumen de datos que lo justifique (muchas particiones con pocos registros no se van a beneficiar de un nuevo índice).

Si no se usa la columna de particionamento en el where, todavía queda algo más a analizar: ¿el criterio de búsqueda tiene alguna correlación con el criterio de particionamiento? Esto es una relación funcional sobre los datos y que no podemos inferir a partir del texto de la consulta.

Podemos analizar los datos buscando este vínculo, y si se llega a confirmar podríamos hacer que la consulta sea más eficiente (recorra menos registros) modificandola, agregando una simple condición columna_partición=valor.

¿Cómo podemos hacer este análisis? Con la ayuda de la función DBMS_MVIEW.PMARKER, que dado un registro (rowid) retorna el nombre de la partición donde está almacenado.

Todo esto se puede ver mejor con un ejemplo. Usé Oracle 11.2.0.2 Enterprise Edition


Tenemos la tabla bigtbl_part particionada por rangos de la columna tipo, y un índice global:

12:40:43 PRU@ent11g> create table bigtbl_part (id, estado, tipo, clase, dato)
partition by range(tipo) (
     partition p0 values less than (1),
     partition p1 values less than (2),
     partition p2 values less than (3),
     partition p3 values less than (4),
     partition p4 values less than (5)
) as
select  rownum               id,
        floor(dbms_random.value(1,20)) estado,
        mod(rownum,5)        tipo,
        mod(rownum,10)       clase,
        'relleno'            dato
from  all_objects, all_objects

Table created.

Elapsed: 00:00:53.14

12:41:37 PRU@ent11g> create index idx1 on bigtbl_part(id) local;

Index created.

Elapsed: 00:00:15.90

12:42:20 PRU@ent11g> execute dbms_stats.gather_table_stats(user,'bigtbl_part')

PL/SQL procedure successfully completed.

Elapsed: 00:00:02.99



Vemos cómo quedaron generados los datos. Nos vamos a enfocar en las clases y tipos:

12:42:40 PRU@ent11g>select count(*), clase from bigtbl_part group by clase order by clase;

  COUNT(*)      CLASE
---------- ----------
    100000          0
    100000          1
    100000          2
    100000          3
    100000          4
    100000          5
    100000          6
    100000          7
    100000          8
    100000          9

10 rows selected.


Los valores distintos de CLASE por cada partición (columna TIPO):

12:46:29 PRU@ent11g> select count(distinct clase), tipo
from bigtbl_part
group by tipo
order by tipo;

COUNT(DISTINCTCLASE)       TIPO
-------------------- ----------
                   2          0
                   2          1
                   2          2
                   2          3
                   2          4


Y cómo quedaron distribuidos los datos en cada partición:

12:47:40 PRU@ent11g> col partition_name for a10
12:47:41 PRU@ent11g> select partition_name, num_rows, high_value
from user_TAB_PARTITIONS
where table_name='BIGTBL_PART';

PARTITION_   NUM_ROWS HIGH_VALUE
---------- ---------- --------------------------------------------------------------------------------
P0             200000 1
P1             200000 2
P2             200000 3
P3             200000 4
P4             200000 5


Esta es la consulta que nos interesa mejorar:

  SELECT count(*)
  FROM bigtbl_part
  WHERE clase = :clase and estado = :estado;


Para fijar ideas usamos una combinación de valores cualquiera: buscamos registros de clase 3 y estado 15:

12:49:52 PRU@ent11g> var clase number;
12:49:52 PRU@ent11g> var estado number;

12:49:52 PRU@ent11g> exec :clase := 3;

PL/SQL procedure successfully completed.

12:49:52 PRU@ent11g> exec :estado := 15;

PL/SQL procedure successfully completed.

12:49:53 PRU@ent11g> set autotrace on explain

SELECT count(*)
FROM bigtbl_part
WHERE clase = :clase and estado = :estado;

  COUNT(*)
----------
      5265

Execution Plan
----------------------------------------------------------
Plan hash value: 1165574620

----------------------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |     1 |     6 |  1047   (2)| 00:00:13 |       |       |
|   1 |  SORT AGGREGATE      |             |     1 |     6 |            |          |       |       |
|   2 |   PARTITION RANGE ALL|             |  5263 | 31578 |  1047   (2)| 00:00:13 |     1 |     5 |
|*  3 |    TABLE ACCESS FULL | BIGTBL_PART |  5263 | 31578 |  1047   (2)| 00:00:13 |     1 |     5 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("ESTADO"=TO_NUMBER(:ESTADO) AND "CLASE"=TO_NUMBER(:CLASE))


Vemos que para resolverla el optimizador tuvo que recorrer todas las particiones de la tabla, y cada una sin usar índice.

Podemos tener facilmente una idea de la cantidad máxima de registros que se necesitan analizar para responder esta consulta (peor caso):

12:53:04 PRU@ent11g>
select count(*), min(count(*)), max(count(*))
from BIGTBL_part
group by clase, estado;

  COUNT(*) MIN(COUNT(*)) MAX(COUNT(*))
---------- ------------- -------------
       190          5071          5500


Pero si queremos además saber en qué particiones están estos datos, no alcanza con ver la cantidad de registros que tiene cada partición (columna num_rows de DBA_TAB_PARTITIONS), ya que no estamos buscando dentro de una sola partición.
Tenemos que agregar a la consulta original el uso de la función dbms_mview.pmarker, y así ver si hay afinidad de los datos buscados (de la condición de agrupación) con las particiones.

Esta es una primera versión simple de la consulta, donde podemos ver los distintos valores de CLASES almacenados en cada partición:

12:54:12 PRU@ent11g>
select count(*)                      registros
      ,dbms_mview.pmarker(rowid)     data_object_id
      ,count(distinct clase)         clase_x_tipo
FROM bigtbl_part
group by dbms_mview.pmarker(rowid);

 REGISTROS DATA_OBJECT_ID CLASE_X_TIPO
---------- -------------- ------------
    200000          75537            2
    200000          75539            2
    200000          75540            2
    200000          75538            2
    200000          75536            2

Elapsed: 00:00:05.93
 


Agregando la condición original, podemos ver en qué particiones están los datos obtenidos:

12:56:51 PRU@ent11g>
select count(*)                      registros
      ,dbms_mview.pmarker(rowid)     data_object_id
FROM bigtbl_part
WHERE clase = :clase and estado = :estado
12:56:51   5  group by dbms_mview.pmarker(rowid);

 REGISTROS DATA_OBJECT_ID
---------- --------------
      5265          75539


Los 5265 registros que retorna la consulta se obtienen de la partición 75539.
Podemos ver el nombre de la partición consultando USER_OBJECTS:

12:58:17 PRU@ent11g>
select subobject_name
from user_objects
WHERE data_object_id=75539;

SUBOBJECT_NAME
------------------------------------------------------------------------------------------
P3


En resumen, aunque los datos se obtienen todos de la misma partición, la consulta recorre todas las particiones porque no conoce la relación entre los datos (clase y tipo).

En este ejemplo los datos se generaron de esta forma para ilustrar el caso donde se puede mejorar la consulta con la ayuda de los programadores de la aplicación, quienes pueden agregar una condición más al where sobre la columna TIPO con el valor correspondiente (ya que la relación entre los valores de estas columnas pueden ser conocidos), y así mejorar la peformance de la misma.
La consulta modificada quedaría así:

12:59:28 PRU@ent11g>
SELECT count(*)
FROM bigtbl_part
WHERE clase = :clase and estado = :estado and tipo = :tipo;

Plan hash value: 4104149755

-------------------------------------------------------------------------------------------------------
| Id  | Operation               | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |             |     1 |     9 |   211   (2)| 00:00:03 |       |       |
|   1 |  SORT AGGREGATE         |             |     1 |     9 |            |          |       |       |
|   2 |   PARTITION RANGE SINGLE|             |  1053 |  9477 |   211   (2)| 00:00:03 |   KEY |   KEY |
|*  3 |    TABLE ACCESS FULL    | BIGTBL_PART |  1053 |  9477 |   211   (2)| 00:00:03 |   KEY |   KEY |
-------------------------------------------------------------------------------------------------------

Si bien se mantiene el acceso sin índice, ahora es sobre la partición y no sobre todas las particiones.
Esto todavía puede mejorarse incluyendo un índice local por clase y estado si el volumen de las particiones lo amerita.
Si no se hubiera podido modificar la consulta, la recomendación clásica habría sido un índice global por clase y estado.

Otro tema relacionado a mejorar la performance de consultas sobre tablas particionadas, es la utilidad de tener índices que incluyan la columna de partición (conocidos como prefixed local index). Una buena discusión sobre el tema se puede encontrar en este thread de los foros de OTN

Espero les sea útil.

Un saludo y feliz comienzo de año!

miércoles, 13 de noviembre de 2013

Alta disponibilidad en bases de datos

Sobre este tema se habla mucho, hay mucha bibliografía, y se dedica mucho esfuerzo ($$) para lograrlo.

Cada instalación tiene sus particularidades y cada bases de datos ofrece distintas funcionalidades, por lo que implementar y automatizar la respuesta y recuperación ante fallas es una tarea no tan trivial.

Para esta automatización Oracle provee Clusterware, que nació como parte de la solución de cluster para base de datos Oracle RAC. Soporta además configurar cualquier recurso gestionable con scripts, lo que por ejemplo permite configurar una base MySQL como un recurso de Oracle Clusterware.
En la versión 11.2 (año 2009) se ofreció como producto independiente con la licencia de Oracle Enterprise Linux, y desde este año con la versión 12.1 se ofrece de forma gratuita, con soporte oficial teniendo cualquier otro producto de Oracle.

Este mismo concepto está desde hace mucho tiempo en la comunidad open source, siendo la solución más antigua y popular Heartbeat. A evolucionado desde su origen en 1999, y a partir del 2003 se generó el proyecto Pacemaker que tomó la implementación de una solución completa de gestión de recursos en cluster, además de monitoreo. Pacemaker es muy popular por estar disponible en muchas plataformas, además de ser gratuito y robusto.

Yo lo vengo usando desde el 2007 con Postgres y MySQL, y sigue siendo una buena alternativa para instalaciones que no tienen disponible licencias de Oracle. El pasado 15 y 16 de Octubre se realizó en Buenos Aires la conferencia "MySQL / NoSQL & Cloud", y fui aceptado para  presentar sobre cómo implementar alta disponibilidad en bases de datos con Pacemaker. Está dirigida a gente que no lo ha usado, y cuento todos los detalles con ejemplos usando máquinas virtuales. Dejo acá la presentación y los scripts usados.

miércoles, 23 de octubre de 2013

Parches a instalar en una nueva instalación de Oracle 11.2

¿Vas a instalar Oracle 11.2?
Entonces revisá la nota 1392633.1 "Things to Consider Before Upgrading to 11.2.0.3 to Avoid Poor Performance or Wrong Results". Indica todos los parches necesarios según la versión exacta a instalar (hasta el cuarto dígito, 11.2.0.8 por ejemplo). También está la referencia para 11.2.0.2.
Si ya instalaste y no la revisaste, vas a encontrar varios parches para aplicar ya, porque estos son bugs que impactan en la performance.

A pesar que el proceso de instalación es algo bien conocido y rutinario, esta es una de esas novedades que obliga a actualizar la vieja receta. Instalar estos parches junto con la instalación inicial ahorra tiempo y evita problemas en producción.

Otra novedad que ya tiene varios meses es el paquete oracle-rdbms-server-11gR2-preinstall.prm. Parte de Oracle Enterprise Linux, ajusta parámetros del kernel y del sistema operativo, e instala paquetes faltantes. Está también disponible para 12c, y se pueden ver los detalles de cómo usarlo en este artículo de OTN.

De todas formas, la nota de cabecera para instalaciones es la 169706.1 "Oracle Database (RDBMS) on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2)", aunque al día de hoy todavía no tiene una referencia a la nota anterior, 1392633.1.

También existen guías rápidas de instalación hechas por reconocidos profesionales Oracle, como por ejemplo las de Tim Hall o las viejas de Puschitz, donde se muestra las sentencias a ejecutar en cada sistema operativo. Son muy buenas porque resumen los pasos a seguir para un ambiente en particular, a partir del manual de instalación (por ejemplo, para Oracle 11.2 en Linux x64: http://docs.oracle.com/cd/E11882_01/install.112/e47689/toc.htm) lo que ahorra mucho tiempo.
Pero para instalar un ambiente de producción es necesario revisar todas las notas de soporte (http://support.oracle.com) en busca de nuevos fixes (parches) que corrijan defectos (bugs) detectados después que la versión está disponible, por lo que no se evita el trabajo de revisar las dos notas anteriores.

lunes, 23 de septiembre de 2013

Histogramas de tiempos de ejecución SQL con AWK

Hace unos días tuve que analizar la performance de una aplicación java que usa Oracle y evaluar si el problema de lentitud estaba en las sentencias SQL ejecutadas. El escenario es:
 - el código no se puede modificar
 - la base de datos usada recibe cientos de sentencias por segundo de varias aplicaciones que vienen del mismo servidor.
 - en el mismo servidor de aplicaciones se ejecutan varias aplicaciones java similares a la que tiene problemas.

Como el problema es en producción, no había posibilidad de bajar el resto de las aplicaciones para dejar solo el tráfico de la problemática.

Así que la alternativa disponible fue habilitar un log de ejecución de sentencias en la aplicación.
Esto genera una entrada por cada ejecución en el archivo con este formato:
2013-09-09 14:38:44,066 [org.hibernate.SQL] Sentencia

No sabemos en qué momento se escribe la entrada en el log. Puede ser antes o después de ejecutar la sentencia. Pero lo que sí sabemos es que el tiempo de ejecución es como máximo el tiempo entre dos entradas consecutivas. Así que como una aproximación sirve para tener una idea de por donde puede venir el problema.

Obtener datos útiles de archivos de log con sentencias SQL es una alternativa muy conocida y bien aprovechada en MySQL con utilitarios como pt-query-digest. Sin intentar imitarlo, me alcanza con ver los tiempos de ejecución de las sentencias, cosa que se puede obtener con un simple script AWK tomando el tiempo transcurrido entre dos entradas consecutivas. Por ejemplo, para ver las que demoraron más de un segundo:
oracle@oraculo:~> awk '{split($3,a,":"); sec=60*(60*a[1]+a[2])+a[3]; if(b!=0 && (sec-b)>1){ print $3 " - " sec - b; }; b=sec}' /tmp/pp.txt
    14:38:49,899 - 5,015
    14:38:51,995 - 2,094
    14:43:46,037 - 2,067
    14:43:51,054 - 5,015
    14:43:56,072 - 5,015

Así puedo ir al log y ver cuales fueron esas sentencias para después analizar si realmente tienen buenos planes de ejecución.

Limpié del archivo entradas iniciales antes de empezar la ejecución de sentencias, y algunas entradas finales, mirando con un editor los números de línea (vi y g es lo más simple). Así nos quedamos con las líneas 6821 a 74572:

oracle@oraculo:~> head -n 74572 myjavaapp.2013091112.log | tail -n +6821 > /tmp/pp.txt

Las sentencias SQL incluidas en este log son:
oracle@oraculo:~> grep -ic insert /tmp/pp.txt
    507
oracle@oraculo:~> grep -ic delete /tmp/pp.txt
    0
oracle@oraculo:~> grep -ic update /tmp/pp.txt
    524
oracle@oraculo:~> grep -ic select /tmp/pp.txt
    2254

Para tener una visión más clara del tiempo de ejecución de las sentencias, armo histogramas de tiempos de ejecución, redondeando a 0,1 segundo (tiempos más chicos no me interesa optimizar). El formato de esta salida es: tiempo de ejecución en segundos y cantidad de sentencias.
oracle@oraculo:~> awk 'BEGIN {b=0;} { split($3,a,":"); sec=60*(60*a[1]+a[2])+a[3]; if(b!=0){ n[int((sec-b)*10+.5)/10]++}; b=sec} END {for (i in n) print i,n[i]}' /tmp/pp2.txt | sort -n
   
    0 2268
    0,1 161
    0,2 421
    0,3 207
    0,4 90
    0,5 68
    0,6 50
    0,7 11
    0,8 1
    0,9 2
    2,1 2
    5 3

Se puede ver con claridad que la mayoría de las sentencias se resuelven en menos de 0,4 segundos, lo que indica con claridad que la base de datos no está teniendo problemas, y se debe analizar el código de la aplicación en busca de más pistas de la lentitud observada.


Espero les sea útil.
Un saludo.

lunes, 2 de septiembre de 2013

Automatizar recover UNTIL CANCEL

Relacionado a mi post anterior, otra de las cosas que ocurre frecuentemente al actualizar una base Oracle de test con un respaldo de producción, es la necesidad de realizar recuperación incompleta UNTIL CANCEL. En este caso la sentencia RECOVER nos va a preguntar qué archivelogs se debe aplicar para dejar la base en un estado consistente.
08:41:07 SYS@test>recover database until cancel using backup controlfile;
ORA-00279: change 2691063472 generated at 03/12/2013 01:30:02 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58643_%u_.arc
ORA-00280: change 2691063472 for thread 1 is in sequence #58643


08:41:29 Specify log: {=suggested | filename | AUTO | CANCEL}

Si estamos recuperando al momento en que se tomó el respaldo, éste incluye archivelogs y ya los copiamos desde el respaldo al directorio sugerido (/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13), entonces podemos indicar AUTO para que los aplique sin mayores problemas.
Como referencia, la restauración de archivelogs con RMAN se hace con el comando 'restore archivelog ...'.

Cuando es necesario ir a un momento en el tiempo posterior, usando respaldos adicionales de archivelogs, y sin tener definido con exactitud el tiempo al que queremos llegar, debemos ir aceptando manualmente cada archivelog para luego ver si es hasta ahí donde queremos llegar (por ejemplo si interesa recuperar hasta el momento previo en que se borraron datos en una tabla, y no contamos con la funcionalidad FLASHBACK).

Al presionar enter y aceptar la sugerencia, si el archivo existe en el destino se aplica:
08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
 

ORA-00279: change 2691076177 generated at 03/12/2013 02:02:53 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/TEST/archivelog/2013_03_13/o1_mf_1_58644_%u_.arc
ORA-00280: change 2691076177 for thread 1 is in sequence #58644
ORA-00278: log file '/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58643_8n0rj3kr_.arc' no
longer needed for this recovery

Si todavía no trajimos este archivelog desde el respaldo, o lo dejamos en otro directorio, va a dar este error:
08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
 

ORA-00308: cannot open archived log
'/u01/app/oracle/flash_recovery_area/test/archivelog/2013_03_13/o1_mf_1_58645_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Luego que aplicamos todos los archivelogs que nos parecen necesarios para llegar al tiempo que nos interesa, ingresamos CANCEL. Y aquí es donde puede aparecer el problema: la base todavía no está en un punto consistente.
08:41:04 Specify log: {=suggested | filename | AUTO | CANCEL}
cancel

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u02/oradata/test/system01.dbf'

Esto es un aviso de que nos faltó aplicar archivelogs, o que nos pasamos del punto que nos interesaba (si tenemos varios respaldos de archivelogs y los trajimos todos, podemos estar aplicando ya el siguiente grupo de archivos).

Cuando cancelamos la recuperación y llegamos a un punto consistente, el mensaje es claro:
09:07:53 Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

Ahora sí queda la base lista para ser usada después de abrirla con resetlogs.
09:08:00 SYS@test>alter database open resetlogs;

Database altered.

Si tenemos muchos archivelogs para aplicar, estar pendiente de la pregunta para presionar enter es algo tedioso, y se puede automatizar fácilmente con un script en bash, que continúa la aplicación mientras el resultado de cancelar el recovery no sea exitoso:
#/bin/bash
###############################
# reco.sh
#
# ncalero 5/2010 - recupera aplicando
# archivelogs hasta que CANCEL sea exitoso
#
###############################

RESULT=/tmp/reco.txt
LOG=/tmp/reco-full.txt

# flag que cuenta si aparecen estos errores. Termina cuando sea cero
SIGO=1
while [ $SIGO -gt 0 ]; do
echo "..."
sqlplus / as sysdba <$RESULT 2>&1
recover database until cancel using backup controlfile;
CANCEL
exit;
EOF


# buscamos mensaje "ORA-01194: file 1 needs more recovery to be consistent"
SIGO=`grep -c 01194 $RESULT`
echo "ora-1194 = $SIGO"

if [[ $SIGO -gt 0 ]] ; then
   # se dio el error, hacemos doble validacion con el otro error
   # ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
   SIGO=`grep -c 01547 $RESULT`
   echo "ora-1547 = $SIGO"
fi
cat $RESULT >>$LOG
done

echo " ### Se puede recuperar!!! ### "

Al ejecutar este script, se muestran dos líneas por errores de intentar cancelar, y termina cuando la base queda en un estado consistente:
oracle@oraculo:/local/work/scripts> ./reco.sh
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
...
ora-1194 = 1
ora-1547 = 1
### Se puede recuperar!!! ###

Una última consideración: si cuando ingresamos cancel nos dice que necesita más recovery e intentamos resolver el problema dejando la base en un punto anterior en el tiempo al último archivelog aplicado, vamos a obtener el siguiente error:
RMAN> recover database until scn 2691031554;
Starting recover at 12/MAR/2013 09:14:47
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/12/2013 09:14:48
RMAN-06556: datafile 1 must be restored from backup older than scn 2691031554

Esto se debe a que no podemos deshacer la aplicación de archivelogs que hicimos antes con el comando RECOVER. Tenemos que volver a traer los datafile desde el respaldo con el que empezamos esta maniobra y aplicar los archivelogs hasta ese punto, sin volver a pasarnos.

Espero que les sea útil.
Un saludo.

martes, 27 de agosto de 2013

Automatizar recuperación de respaldos RMAN

Algo que tengo que hacer seguido y es tarea habitual de un DBA, es restaurar un respaldo RMAN en un servidor distinto al que fue tomado. Si estamos en 10g no podemos usar el comando DUPLICATE ... FROM LOCATION que haría todo más fácil (por detalles ver mi post anterior).

Este procedimiento es bien conocido como Database Point in Time Recovery.

Se debe restaurar el respaldo usando la cláusula "UNTIL TIME .." del comando RESTORE (o SCN / LOG). ¿Qué valor debemos usar? Mirando el contenido del respaldo podemos identificar el último archivelog incluido a continuación del respaldo completo.

Ahora, si queremos poner estos pasos en un script, ¿cómo obtenemos este valor?.
Podemos consultar los datos que almacena RMAN en la base destino después de catalogar el respaldo. Vamos a ver cómo hacerlo sin usar una base de catálogo central, obteniendo estos datos directamente del controlfile (vistas V$BACKUP_*). Usando catálogo habría que usar las vistas RC_*.

Hay varios detalles a tener en cuenta. Lo más importante es poder identificar el respaldo completo que vamos a usar. En este ejemplo, lo identificamos porque tenemos catalogado solamente un respaldo completo (ejecutamos crosscheck después de recuperar el controlfile, y catalogamos solo este respaldo), con esta consulta:
select 'set until sequence '||max_seq||';'
from (
 select min(sequence#) min_seq, max(sequence#) max_seq
 from  v$backup_set s, v$BACKUP_ARCHIVELOG_DETAILS r
 where s.set_count = r.id2
   and s.set_stamp = r.id1
   and s.backup_Type='L'
   and r.first_time>=(
       select start_time from v$backup_set s
       where s.CONTROLFILE_INCLUDED='NO' and s.backup_type='D'
        and (set_stamp, set_count) in (
        select set_stamp, set_count
        from v$backup_piece
        where deleted='NO')
   )
);

Por más información sobre el contenido de estas vistas se puede ver el manual de cada una: v$backup_piece, v$backup_set y v$BACKUP_ARCHIVELOG_DETAILS.

¿Esto es lo mismo que se obtiene con comandos RMAN?. Vemos un ejemplo que lo confirma:
oracle@oraculo:> rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Tue Aug 27 10:27:08 2013

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

connected to target database: PROD (DBID=3195287633)

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
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
19056   B  F  A DISK        08/AUG/2013 02:36:18 17      1       YES        TAG20130807T233030                                 
19057   B  F  A DISK        08/AUG/2013 02:36:24 1       1       NO         TAG20130808T023623                 
19058   B  A  A DISK        08/AUG/2013 02:41:36 1       1       YES        TAG20130808T023635                                 
19059   B  F  A DISK        08/AUG/2013 03:01:53 1       1       NO         TAG20130808T030153

Estos datos los podemos ver en SQLPLUS:
11:27:15 SYS@PROD> select *
from v$backup_set
where set_count in (19056,19057,19058,19059);

     RECID      STAMP  SET_STAMP  SET_COUNT BAC CONTROLFI INCREMENTAL_LEVEL     PIECES START_TIME
---------- ---------- ---------- ---------- --- --------- ----------------- ---------- -----------------------------
COMPLETION_TIME               ELAPSED_SECONDS BLOCK_SIZE INPUT_FIL KEEP      KEEP_UNTIL
----------------------------- --------------- ---------- --------- --------- -----------------------------
KEEP_OPTIONS
------------------------------
     19017  822452177  822451892      19056 L   NO                                   1 03/AUG/2013 02:51:32
03/AUG/2013 02:56:17                      285        512 NO        NO


     19018  822452458  822452178      19057 L   NO                                   1 03/AUG/2013 02:56:18
03/AUG/2013 03:00:58                      280        512 NO        NO


     19019  822452470  822452470      19058 D   YES                                  1 03/AUG/2013 03:01:10
03/AUG/2013 03:01:10                        0      16384 NO        NO

     19020  822798680  822798381      19059 L   NO                                   1 07/AUG/2013 03:06:21
07/AUG/2013 03:11:20                      299        512 NO        NO

Para validar que tenemos un respaldo completo, dos del controlfile y uno de archivelogs, vemos sus contenidos:
oracle@oraculo:> rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Tue Aug 27 10:36:00 2013

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

connected to target database: PROD (DBID=3195287633)

RMAN> list backup;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time   
------- ---- -- ---------- ----------- ------------ --------------------
19056   Full    33.87G     DISK        03:05:47     08/AUG/2013 02:36:18
  List of Datafiles in backup set 19056
  File LV Type Ckp SCN    Ckp Time             Name
  ---- -- ---- ---------- -------------------- ----
  1       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/system01.dbf
  2       Full 3048062425 07/AUG/2013 23:30:32 /u03/oradata/PROD/undotbs01.dbf
  3       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/sysaux01.dbf
  4       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/users_01.dbf
  5       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/datos_prod.dbf
  6       Full 3048062425 07/AUG/2013 23:30:32 /u03/oradata/PROD/indices_prod.dbf
  7       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/cwmlite01.dbf
  8       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/drsys01.dbf
  9       Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/example01.dbf
  10      Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/indx01.dbf
  11      Full 3048062425 07/AUG/2013 23:30:32 /u02/oradata/PROD/tools01.dbf

  Backup Set Copy #1 of backup set 19056
  Device Type Elapsed Time Completion Time      Compressed Tag
  ----------- ------------ -------------------- ---------- ---
  DISK        03:05:47     09/AUG/2013 04:55:28 YES        TAG20130807T233030

    List of Backup Pieces for backup set 19056 Copy #1
    BP Key  Pc# Status      Piece Name
    ------- --- ----------- ----------
    31790   1   AVAILABLE   /backup/database_PROD_20130807_p1_s19095_1
    31795   2   AVAILABLE   /backup/database_PROD_20130807_p2_s19095_1
    31766   3   AVAILABLE   /backup/database_PROD_20130807_p3_s19095_1
    31789   4   AVAILABLE   /backup/database_PROD_20130808_p4_s19095_1
    31794   5   AVAILABLE   /backup/database_PROD_20130808_p5_s19095_1
    31765   6   AVAILABLE   /backup/database_PROD_20130808_p6_s19095_1
    31775   7   AVAILABLE   /backup/database_PROD_20130808_p7_s19095_1
    31788   8   AVAILABLE   /backup/database_PROD_20130808_p8_s19095_1
    31793   9   AVAILABLE   /backup/database_PROD_20130808_p9_s19095_1
    31792   10  AVAILABLE   /backup/database_PROD_20130808_p10_s19095_1
    31764   11  AVAILABLE   /backup/database_PROD_20130808_p11_s19095_1
    31768   12  AVAILABLE   /backup/database_PROD_20130808_p12_s19095_1
    31787   13  AVAILABLE   /backup/database_PROD_20130808_p13_s19095_1
    31791   14  AVAILABLE   /backup/database_PROD_20130808_p14_s19095_1
    31763   15  AVAILABLE   /backup/database_PROD_20130808_p15_s19095_1
    31767   16  AVAILABLE   /backup/database_PROD_20130808_p16_s19095_1
    31786   17  AVAILABLE   /backup/database_PROD_20130808_p17_s19095_1

BS Key  Type LV Size       Device Type Elapsed Time Completion Time   
------- ---- -- ---------- ----------- ------------ --------------------
19057   Full    11.58M     DISK        00:00:01     08/AUG/2013 02:36:24
        BP Key: 31753   Status: AVAILABLE  Compressed: NO  Tag: TAG20130808T023623
        Piece Name: /backup/c-3195287633-20130808-00
  Control File Included: Ckp SCN: 3048178773   Ckp time: 08/AUG/2013 02:36:23
  SPFILE Included: Modification time: 15/MAY/2013 11:17:45

BS Key  Size       Device Type Elapsed Time Completion Time   
------- ---------- ----------- ------------ --------------------
19058   742.70M    DISK        00:04:59     08/AUG/2013 02:41:36
        BP Key: 31758   Status: AVAILABLE  Compressed: YES  Tag: TAG20130808T023635
        Piece Name: /backup/archivedlogs_PROD_20130808_p1_s19097_1

  List of Archived Logs in backup set 19058
  Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
  ---- ------- ---------- -------------------- ---------- ---------
  1    70088   3048053610 07/AUG/2013 23:18:01 3048062243 07/AUG/2013 23:30:27
  1    70089   3048062243 07/AUG/2013 23:30:27 3048086304 08/AUG/2013 00:01:51
  1    70090   3048086304 08/AUG/2013 00:01:51 3048117667 08/AUG/2013 00:50:04
  1    70091   3048117667 08/AUG/2013 00:50:04 3048156318 08/AUG/2013 01:24:49
  1    70092   3048156318 08/AUG/2013 01:24:49 3048178827 08/AUG/2013 02:36:32
  1    70093   3048178827 08/AUG/2013 02:36:32 3048178838 08/AUG/2013 02:36:34

BS Key  Type LV Size       Device Type Elapsed Time Completion Time   
------- ---- -- ---------- ----------- ------------ --------------------
19059   Full    11.58M     DISK        00:00:00     08/AUG/2013 03:01:53
        BP Key: 31754   Status: AVAILABLE  Compressed: NO  Tag: TAG20130808T030153
        Piece Name: /backup/c-3195287633-20130808-01
  Control File Included: Ckp SCN: 3048186759   Ckp time: 08/AUG/2013 03:01:53
  SPFILE Included: Modification time: 08/AUG/2013 01:00:58

Y vemos lo mismo en SQLPLUS:

11:13:12 SYS@PROD> col handle for a45
11:13:12 SYS@PROD> col tag for a25
11:13:12 SYS@PROD> set linesize 120

11:13:12 SYS@PROD> select p.tag, piece#, handle
from v$backup_set s, v$backup_piece p
where s.CONTROLFILE_INCLUDED='NO' and s.backup_type='D' and p.deleted='NO'
and s.set_stamp=p.set_stamp and s.set_count=p.set_count
order by piece#;

TAG                           PIECE# HANDLE
------------------------- ---------- ---------------------------------------------
TAG20130807T233030                 1 /backup/database_PROD_20130807_p1_s19095_1
TAG20130807T233030                 2 /backup/database_PROD_20130807_p2_s19095_1
TAG20130807T233030                 3 /backup/database_PROD_20130807_p3_s19095_1
TAG20130807T233030                 4 /backup/database_PROD_20130808_p4_s19095_1
TAG20130807T233030                 5 /backup/database_PROD_20130808_p5_s19095_1
TAG20130807T233030                 6 /backup/database_PROD_20130808_p6_s19095_1
TAG20130807T233030                 7 /backup/database_PROD_20130808_p7_s19095_1
TAG20130807T233030                 8 /backup/database_PROD_20130808_p8_s19095_1
TAG20130807T233030                 9 /backup/database_PROD_20130808_p9_s19095_1
TAG20130807T233030                10 /backup/database_PROD_20130808_p10_s19095_1
TAG20130807T233030                11 /backup/database_PROD_20130808_p11_s19095_1
TAG20130807T233030                12 /backup/database_PROD_20130808_p12_s19095_1
TAG20130807T233030                13 /backup/database_PROD_20130808_p13_s19095_1
TAG20130807T233030                14 /backup/database_PROD_20130808_p14_s19095_1
TAG20130807T233030                15 /backup/database_PROD_20130808_p15_s19095_1
TAG20130807T233030                16 /backup/database_PROD_20130808_p16_s19095_1
TAG20130807T233030                17 /backup/database_PROD_20130808_p17_s19095_1

17 rows selected.

11:14:08 SYS@PROD> select 'set until sequence '||max_seq||';' texto
from (
 select min(sequence#) min_seq, max(sequence#) max_seq
 from  v$backup_set s, v$BACKUP_ARCHIVELOG_DETAILS r
 where s.set_count = r.id2
   and s.set_stamp = r.id1
   and s.backup_Type='L'
   and r.first_time>=(
       select start_time from v$backup_set s
       where s.CONTROLFILE_INCLUDED='NO' and s.backup_type='D'
        and (set_stamp, set_count) in (
        select set_stamp, set_count
        from v$backup_piece
        where deleted='NO')
   )
);

TEXTO
-------------------------
set until sequence 70093;

1 rows selected.

Con estas consultas y un poco de scripting se puede armar un buen script de recuperación.

Un saludo.

miércoles, 21 de agosto de 2013

Clonación RMAN sin conexión a target

Si necesitamos crear una base de datos copiando una existente, en la versión 11.2 de Oracle tenemos muchas opciones. Sin considerar el procedimiento clásico de copia manual de archivos por filesystem mientras la base está baja (sin usar utilitarios), podemos usar el utilitario RMAN que ofrece varias alternativas:
  • Tomar los datos de una instancia activa
  • Usar un respaldo ya existente
La primer opción es nueva en 11g.
Usar un respaldo existente es algo clásico, pero en 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 de RMAN: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm#BRADV010

Me interesa mostrar un ejemplo con los detalles 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.

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 (estos ya existen y se comparten con la base origen, sólo como referencia).
Voy a usar Oracle 11gR2 (11.2.0.2) en Linux x86-64 (OpenSuse 12.3)
Primero vemos en detalle los pasos a seguir, luego un ejemplo de 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.
Lo único que se 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
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 pueden haber muchos respaldos, y el comando DUPLICATE va a tomar el más reciente. Si quisieramos 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. %b deja el nombre original. Más detalles sobre los valores posibles aquí
  • 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!
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. Aquí no lo tenemos así que tomamos uno.
Marco 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.


Ahora sí, duplicamos:
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.


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 * from v$instance;

INSTANCE_NUMBER INSTANCE_NAME
--------------- ------------------------------------------------
HOST_NAME
------------------------------------------------------------------------------------------------------------------------
VERSION                                             STARTUP_TIME                  STATUS
--------------------------------------------------- ----------------------------- ------------------------------------
PARALLEL     THREAD# ARCHIVER              LOG_SWITCH_WAIT                               LOGINS
--------- ---------- --------------------- --------------------------------------------- ------------------------------
SHUTDOWN_ DATABASE_STATUS                                     INSTANCE_ROLE
--------- --------------------------------------------------- ------------------------------------------------------
ACTIVE_STATE                BLOCKED
--------------------------- ---------
              1 TEST
oraculo.site
11.2.0.2.0                                          21/AUG/2013 09:07:24          OPEN
NO                 1 STARTED                                                             ALLOWED
NO        ACTIVE                                              PRIMARY_INSTANCE
NORMAL                      NO


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'

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 al comando DUPLICATE, es posible encontrarse con errores. A continuación listo algunos errores que generé de forma intencional omitiendo alguna de las partes del procedimiento descripto antes, para ver la distintas situaciones que se pueden dar y cómo resolverlas.

Siempre que ocurran errores, recordar borrar el nuevo spfile creado por el DUPLICATE (pudo quedar creado con valores incorrectos) antes de intentar una nueva duplicación, y reiniciar la nueva base en modo nomount, así:
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

Ahora sí, algunos errores que pueden encontrarse y su explicación, aunque varios son obvios:

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 hacen bajo 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 es similar al error 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 compromente los controfile de la base original, que pudieron ser sobreescritos al ejecutar el duplicate. Indica que se omitió incluir 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 cual es el controlfile que no se convirtió en el alert de la nueva base :
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. Y 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 tal como dice, 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 parametros 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.


Espero que les sea útil.
Un saludo.