Falla en el archivado de un online redolog por corrupción del online redo file

Comparto un problema con el cual me encontré días atrás y como resolverlo:

• fact: Oracle Server - Enterprise Edition
• fact: Instance is running
• symptom: Errors when archiving online redolog
• symptom: ORA-16038: log %s sequence# %s cannot be archived
• symptom: ORA-00354: corrupt redo log block header
• symptom: ORA-00312: "online log %s thread %s: '%s'"
• cause: Failure to archive online redolog due to a corruption in the online redo file

fix:

You can keep the database running when solving and working around this problem. 
The following steps have to be taken:

1) alter database clear unarchived logfile '<logfilename>';          

2) make a new complete (online) backup of your database

The first command clears the online logfile (fills it with all null).  This 
makes the corruption disappear which causes the contents of the cleared online  
redo file to be missing in the archived redo stream. This requires a new 
complete (online) backup to allow for complete recovery in the future (step 2).

MOS: Errors in Archiving Online Redolog (Doc ID 145769.1)

Script para recolectar iostats de discos ASM

The OS command iostat is normally used to monitoring system input/output device load. This script will provide similar information like iostat  but specific for the ASM disks.
For details about iostat (ie cumulative or not, and so on) please refer to the man of iostat.

Script:

#!/bin/ksh
#
# NAME
#   asmiostat.sh
# 
# DESCRIPTION
#   iostat-like output for ASM
#   $ asmiostat.sh [-s ASM ORACLE_SID] [-h ASM ORACLE_HOME] [-g Diskgroup]
#                  [-f disk path filter] [<interval>] [<count>]
#
# NOTES
#   Creates persistent SQL*Plus connection to the +ASM instance implemented
#   as a ksh co-process
#
# AUTHOR
#   Doug Utzig
#
# MODIFIED
#   dutzig    08/18/05 - original version
#

Basics of the Cost Based Optimizer

Comparto una serie de articulos sobre el optimizador de Oracle (CBO) de Jonathan Lewis publicada entre junio y noviembre de este año en http://allthingsoracle.com

This series on Oracle’s Cost Based Optimizer is aimed at the less experienced DBAs and developers to help them understand what the optimizer is trying to achieve, how it arrives at an execution plan, why it makes mistakes, and (perhaps most importantly) how to recognize the source of those mistakes and so address the resulting problems in an appropriate fashion.

I will try to avoid going into extreme technical detail though I will outline a few of the slightly more technical issues and mention a few URLs that go into greater depth on particular topics.

To get the best out of this series you will need to have some experience with reading execution plans, especially when we look at the “trouble-shooting” side of optimization.

Basics of the Cost Based Optimizer – Part 1

Basics of the Cost Based Optimizer – Part 2

Basics of the Cost Based Optimizer – Part 3

Basics of the Cost Based Optimizer – Part 4

Basics of the Cost Based Optimizer – Part 5

Basics of the Cost Based Optimizer – part 6

Incompatibilidad entre AMM y HughPages

The 11g AMM feature is enabled by the MEMORY_TARGET / MEMORY_MAX_TARGET instance initialization parameters . That is also the case with a default database instance created using Database Configuration Assistant (DBCA).

With AMM all SGA memory is allocated by creating files under /dev/shm. When Oracle DB does SGA allocations that way HugePages are not reserved/used.

The use of AMM is absolutely incompatible with HugePages. (Please see references at the end of the document for further information on HugePages)

On systems with HugePages in use, attempting to set the MEMORY_TARGET / MEMORY_MAX_TARGET instance initialization parameters may result in the following error message:

ORA-00845: MEMORY_TARGET not supported on this system

Como iniciar OSWatcher Black Box (OSWBB) en cada System Boot

The osw-service RPM package provides a script to run the OSWatcher at system boot, and to stop it down gracefully at system shutdown.  It provides an "osw" service that can be controlled using the standard Linux init(1) script controls:

# /sbin/chkconfig oswbb on
# /sbin/service oswbb start

The osw-service RPM package is available as an attachment to this note.  Download and install it as any other RPM package.  A source RPM is provided for completeness.

Validating The RPM Packages
You can validate the RPM packages by comparing their checksums with these:

$ md5sum oswbb-service*.rpm
dc4f892aa58889e78c1f50e41d694c20 oswbb-service-7.2.0-1.noarch.rpm
4cedf4f97bf9366e8c6ba313973fa9b8 oswbb-service-7.2.0-1.src.rpm

Before starting the service, first change the settings in the /etc/oswbb.conf configuration file to fit your situation:

Catalogando archivelogs con RMAN

En el caso que ciertos archivelogs no se estén backupeando porque RMAN simplemente no los tiene inventariados, la solución es realizar una catalogación manual de los archivos.
Para ello, nos conectamos a RMAN y corremos el comando "catalog archivelog".
Aqui tenemos un ejemplo:


[oracle@server01]$ rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Mon Nov 11 14:28:11 2015
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

connected to target database: PROMAE (DBID=1782667589)

RMAN> catalog archivelog '/u04/ORCL/arch/1_132_788444647.arc';

Descargar OSWatcher

OSWatcher Quick Overview

OSWatcher (oswbb) is a downloadable and free utility to capture performance metrics from the operating system. OSWatcher does not require any special license. When you install and run oswbb as part of a performance diagnostic data collection best practice, you can aid in a quicker resolution of your SR with support and development. oswbb is comprised of two separate components:

1. oswbb: a unix shell script data collector which collects and stores the data

2. oswbba: a java utility which will analyze the data automatically and provide advice and produce graphs and an html document

Both components are contained in a single downloadable tar file.

This utility is not to be confused with the Exadata version of OSWatcher.

Buscando SID y SERIAL de un datapump job

set lines 150 pages 100 numwidth 7
col program for a38
col username for a10
col spid for a7
select to_char (sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid,
       s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from   v$session s, v$process p, dba_datapump_sessions d
where  p.addr=s.paddr and s.saddr=d.saddr;

Oracle Critical Patch Update Advisory - October 2015

Oracle corrige 154 vulnerabilidades en su actualización de seguridad de octubre

Siguiendo su ritmo de publicación trimestral de actualizaciones, Oracle publica su boletín de seguridad de octubre. Contiene parches para 154 vulnerabilidades diferentes en múltiples productos pertenecientes a diferentes familias, que van desde el popular gestor de base de datos Oracle Database hasta Solaris, Java o MySQL.
Los fallos se dan en varios componentes de los productos:

• Oracle Database Server, versiones 11.2.0.4, 12.1.0.1 y 12.1.0.2
• Mobile Server, versiones 10.3.0.3, 11.3.0.2 y 12.1.0.0
• Oracle Access Manager, versiones 11.1.2.2 y 11.1.2.3
• Oracle Business Intelligence Enterprise Edition, versiones 11.1.1.7 y 11.1.1.9
• Oracle Endeca Server, versiones 7.3.0.0, 7.4.0.0, 7.5.1.1 y 7.6.1.0.0
• Oracle Enterprise Data Quality, versiones 8.1, 9.0, 11.1.1.7.4 y 12.1.3.0.0
• Oracle Exalogic Infrastructure, versión EECS 2.0.6.2.3
• Oracle Fusion Middleware, versiones 10.1.3.5, 11.1.1.7, 11.1.1.8, 11.1.1.9, 11.1.2.1, 11.1.2.2, 11.1.2.3, 12.1.2.0 y 12.1.3.0
• Oracle GlassFish Server, versiones 3.0.1 y 3.1.2

Como recuperar un UNDO tablespace sin backup

Ayer me topé con la necesidad de tener que recuperar un tablespace de UNDO sin disponer de un backup. 
Comparto un post de Fahd Mirza que me resultó de gran ayuda con esta tarea:

http://www.fahdmirza.com/2015/05/recover-oracle-undo-tablespace-without.html

Como cambiar el Timezone en Grid Infrastructure

Si el timezone del sistema operativo es modificado luego de la instalación de Oracle GI y DB, debemos tener la precaución de cambiarlo también a nivel de "Grid Infraestructure", sino podríamos llegar a encontrar incosistencias por ejemplo al consultar el "sysdate" de la base de datos.

A partir de la versión 11.2.0.2, para realizar este cambio debemos modificar la variable TZ en el archivo:

$GRID_HOME/crs/install/s_crsconfig_<nodename>_env.txt configurando el timezone correcto.

El TZ indicado debe ser uno de los soportados por el sistema operativo.

Veamos un ejemplo:

En un Linux, para ver la configuración actual:

[grid@server01]$ cat /etc/sysconfig/clock
ZONE="Etc/GMT+5"

Webcasts and Videos sobre Database Performance

Aqui un listado de webcasts y videos relacionados con Performance de bases de datos.
Pueden ser encontrados en Oracle Database Advisor Webcast Archive or Oracle Database Learning Stream.
Espero les resulte útil.

Ref: Archive of Database Performance Related Webcasts and Videos (Doc ID 1597373.1)

Tips on SQL Plan Management and Oracle Database In-Memory – Part 3

In Part 1 of this series of tips on SQL Plan Management (SPM) and Oracle Database In-Memory I covered an example where a full table scan query made use of the In-Memory column store immediately without changing the SQL execution plan. In Part 2 I presented an example where the In-Memory column store made an alternative SQL execution plan viable, and where there was a corresponding SQL plan baseline already in place so that this plan could be used immediately. 

In this post I will consider a slightly different scenario:

• SQL plan management is used to stabilize the SQL execution plans for our critical application (that until now has not been using the In-Memory column store).
• The In-Memory column store is subsequently enabled and populated with application tables. 
• The Optimizer identifies new SQL execution plans.
• Most of the new execution plans have never been chosen by the Optimizer before.

Continuar aqui

Achieving Sarbanes-Oxley Compliance with Oracle Identity Management

Buscando alguna otra información dí con este viejo whitepaper, que pese a ser bastante antiguo creo que todavía vigente sobre Oracle y SOX. Una guía de como utilizar Oracle Identity Management para estar "compliance" con SOX (Sarbanes-Oxley). Creo que se prodría darle unas vueltas de tuerca más a este doc. 

INTRODUCTION 

The Sarbanes-Oxley Act of 2002 requires corporate executives to provide and ensure an increased level of financial and operational discipline. To comply with this law, most large corporations are now implementing a variety of new measures that cross financial reporting and processes, as well as internal business operations. This short paper describes how Oracle Identity Management can help ensure compliance with Sarbanes-Oxley (as well as other regulations) while increasing ability to monitor and audit compliance on an ongoing basis. 

Achieving Sarbanes-Oxley Compliancewith Oracle Identity Management 

Tips on SQL Plan Management and Oracle Database In-Memory - Part 2

In Part 1 of this series of tips on SQL Plan Management (SPM) and Oracle Database In-Memory, I covered what would happen if we have a SQL plan baseline for a full table scan query when the table was populating the In-Memory column store. 

In this part I’m going to cover a scenario where a query has more than one SQL plan baseline: 

• There is a query (called Q2, for short).
• Q2 queries a table called MYSALES, which is not yet populating the In-Memory column store.
• Q2 filters rows in MYSALES using a predicate on the SALE_TYPE column.
• Data in SALE_TYPE is skewed, so there’s an index and a histogram on this column.
• Because there is data skew, Q2 has two accepted SQL plan baselines; one with a full table scan and one with an index range scan.

You’ve probably come across this situation many times: the Oracle Optimizer must choose between a full table scan or an index range scan depending on predicate selectivity. The ability to change the execution plan based on the value of bind variables is called adaptive cursor sharing. If you’ve not come across that, then you’ll find it useful to check out the section on this topic in the Database SQL Tuning Guide.

What’s great about SPM is that it allows you to have multiple SQL plan baselines for individual queries, so you're not forced to pick one plan in preference to another. This capability is most relevant in environments where SQL statements use bind variables and there is a good deal of data skew. Queries like this are likely to have their plans affected by Oracle In-Memory Database because in-memory full table scans will have a lower cost than storage-resident table scans. Clearly, the In-Memory column store will affect the point of inflection where a full table scan will become more efficient than an index range scan. How is this going to work with SPM? 

Continuar aqui

Tips on SQL Plan Management and Oracle Database In-Memory Part 1

If you follow Oracle’s In-Memory blog then you probably came across a post mentioning how you should use SQL Plan Management when you’re upgrading to Oracle Database In-Memory. Whether you have read that post or not, you might be wondering what will happen if you have some SQL plan baselines and you begin to populate the In-Memory column store with a bunch of tables as used by those baselines. That’s what this post is about. Well, in fact, I’m going to break the topic up into a few posts because (as ever!) there is a little bit of subtlety to cover. Luckily, this will make your life easier rather than more difficult because you can get immediate benefit from In-Memory even if you don’t evolve SQL plan baselines on day one.  

When I started to think about this post I thought that I would start with the first scenario that probably comes to mind if you’re familiar with SQL Plan Management (SPM): 

• The Optimizer comes up with a new execution plan for a SQL statement because something has changed, and Oracle Database In-Memory would be a very good example of that! 
• If there’s a SQL plan baseline for the statement, the database will use the baseline execution plan and capture the new plan.
• Where appropriate, the new plan will be validated and accepted using SQL plan evolution. 

I will get to that, but first it’s better to start with a couple of more subtle points. With this information in our back pocket it will be easier to understand (and explain) the more traditional aspects of SQL plan evolution in the context of Oracle Database In-Memory.

Continuar aqui

Optimizando Oracle BI Analytics con la opción Oracle 12c: In-Memory Database (Parte II)

Como plataforma de “Business Intelligence” y “Analytics”, Oracle OBIEE Server se conecta a una base de datos física la cual puede ser una “Oracle Database” a través  de ODBC/JDBC , presentando un esquema de vista lógica independiente de la base de datos física. Cuando un usuario ejecuta los reportes, el OBIEE server traduce o mapea los SQL lógicos desde la capa de presentación del reporte a consultas físicas SQL, enviando estos SQL a la base de datos, de esta manera Oracle database ejecuta las consultas SQL físicas, obteniendo los datos correspondientes y retornándolos al OBIEE server para armar el reporte. La herramienta de administración de Oracle BI muestra estas tres capas: Presentación(Presentation), Modelo de negocio y mapeo ( Business Model and Mapping), y  Física  (Physical).

Figura 3: Herramienta de Administración de Oracle BI

TSPITR Using ACFS Snapshots

En este artículo, Anju Garg muestra que los snapshots de ACFS tomadas mientras la base de datos está en modo backup pueden integrarse con RMAN y emplearse para realizar Tablespace Point In Time Recovery (TSPITR).

http://allthingsoracle.com/tspitr-using-acfs-snapshots/

Optimizando Oracle BI Analytics con la opción Oracle 12c: In-Memory Database (Parte I)

Introducción:

Mediante la incorporación de la funcionalidad “In-Memory columnar store”, la recientemente lanzada opción de “In-Memory database”, todo ello apunta a mejorar significativamente el rendimiento de consultas en aplicaciones OLAP. Este artículo explorará cómo aprovechar esta funcionalidad de “In-Memory” en un ambiente de Oracle OBIEE “Analytics”. Utilizaremos como caso de estudio, un proyecto de análisis financiero para poder profundizar sobre las mejores prácticas, lecciones aprendidas, estudios de rendimiento de la aplicación con “In-Memory database” en aplicaciones analíticas de negocio.

Oracle 12c “In-Memory Option”

“Oracle 12c Database” introduce la opción de “In-Memory database”. Esta opción apunta a acelerar las operaciones de “analytics” y también darle velocidad al procesamiento de carga de trabajo mixta OLAP/OLTP. Esta característica tiene también la particularidad de ser transparente para las aplicaciones.

La opción “In-Memory” de “Oracle Database 12c” introduce un nuevo formato dual de arquitectura que consiste en:

"Push-Based Active Database Duplication" de una CDB

Duplicando CDB -"Push-Based Active Database Duplication" de una CDB

En los casos de “Active Database duplication”  mediante el método “Pull-Based”   (Parte II, III, IV), el número de “target channels” es siempre menor que el número de “auxiliary channels”. En el caso que quiera utilizar  “Push-Based Active Database duplication” en Oracle Database 12c Release 1 (12.1.0.1), deberá asignar un número de “target channels”  de RMAN más grande que el número de “auxiliary channels” asignados.

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en la tercer parte de esta serie de artículos. En este caso usamos el comando DUPLICATE de RMAN con las siguientes opciones:

Opción de duplicación	CDB
Tipo de duplicación	Active Database Duplication
Método de duplicación	Push-Based
Tipo de backup utilizado	Image Copies
Número de “Target Channels”	2
Número de “Auxiliary Channels”	1

Creando Backup Sets en paralelo durante una "Active Database Duplication"

Duplicando CDB - Creando Backup Sets en paralelo durante una "Active Database Duplication"

Los “backups multisection” de RMAN brindan la posibilidad de llevar a cabo resguardos de manera más rápida  realizando  backup de datafiles muy grandes en modo paralelo. Múltiples piezas de backup (“backup pieces”) son creadas escribiendo cada una de ellas por un canal separado. A partir de Oracle Database 12c Release 1 (12.1), también se puede utilizar “multisection backup sets” para transferir los archivos de origen requeridos para la duplicación activa de base de datos  (“active database duplication”).
Se utiliza la clausula SECTION SIZE en el comando DUPLICATE para crear  los backupset en “multisection” que pueden ser utilizados para la  “active database duplication”. El siguiente comando crea backup sets en multisección, con un tamaño de 400MB por pieza (“backup piece”).
En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb”como ocurre en la tercera parte de esta serie de  artículos. En este caso usamos el comando DUPLICATE de RMAN con las siguientes opciones:

Opción de duplicación	CDB
Tipo de duplicación	Active Database Duplication
Método de duplicación	Pull Based
Tipo de backup utilizado	Backupsets
Paralelismo	SECTION SIZE 400M
Número de “Target Channels”	1
Número de “Auxiliary Channels”	2

Duplicación de una CDB omitiendo tablespaces de una PDB

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en otra parte de esta serie de artículo. A continuación podemos ver nuestra base de datos CDB origen:  prmcdb.

[oracle@oel62-ora12c-prm ~]$ export ORACLE_SID=prmcdb
[oracle@oel62-ora12c-prm ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Apr 14 09:51:44 2014

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

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> alter pluggable database all open;

Pluggable database altered.

Duplicación al mismo tiempo de una PDB y un tablespaces en otra PDB

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en otras partes de esta serie de artículos.  A continuación podemos ver nuestra base de datos CDB origen  prmcdb.

[oracle@oel62-ora12c-prm ~]$ export ORACLE_SID=prmcdb
[oracle@oel62-ora12c-prm ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Apr 14 09:51:44 2014

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

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> alter pluggable database all open;

Pluggable database altered.

Duplicación de tablespaces de una PDB

RMAN permite duplicar no sólo la CBD sino que también puede hacerlo con una  o múltiples PDBs  utilizando el comando DUPLICATE. También puede duplicar un conjunto de tablespaces dentro de una PDB. Para esto debe estar conectado en el root de la CDB como un usuario que tenga  privilegios de SYSDBA o SYSBACKUP. De aquí en adelante podrá ver ejemplos de duplicación de de Pluggable Databases (PDBs).  La siguiente tabla muestra las opciones para duplicación de PDBs.

Opción de DUPLICATE	Explicación
PLUGGABLE DATABASE pdb_name	Duplica las PDBs especificadas en la CDB. Use una coma como delimitador para duplicar múltiples PDBs.
SKIP PLUGGABLE DATABASE pdb_name	Duplica todos las PDBs en la CDB, exceptuando las PDBs especificadas por pdb_name. Use una coma como delimitador para especificar múltiples PDBs que deben ser excluidas.
TABLESPACE pdb_name:tablespace_name	Duplica los tablespace especificados dentro de una PDB. El nombre del tablespace debe ser especificado con el nombre de la PDB que lo contiene como prefijo. Si usted omite el nombre de la PDB, el root es tomado como default.
SKIP TABLESPACE pdb_name:tablespace_name	Duplica todos los tablespaces en la CDB exceptuando aquellos especificados  en la PDB indicada.

Duplicación de dos "Pluggable Databases" omitiendo una PDB

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en otras partes de esta serie de artículos.  Antes de la duplicación, vamos a sumar una nueva PDB prmpdb03 a la CDB prmcdb clonando la PDB prmpdb02. Si usted aún no agregó una tercera PDB al ambiente de pruebas, necesitará agregar los scripts del Caso 6 en la parte VII de esta serie de artículos. Nuestra CDB origen (prmcdb) se muestra a continuación:

[oracle@oel62-ora12c-prm ~]$ export ORACLE_SID=prmcdb

[oracle@oel62-ora12c-prm ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Apr 14 09:51:44 2014

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

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> alter pluggable database all open;

Pluggable database altered.

“Pull-Based active Database Duplication” de dos “Pluggable Databases”

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre también en otras partes de esta serie de artículos. Antes de la duplicación, vamos a sumar una nueva PDB: prmpdb03 a la CDB prmcdb clonando la PDB prmpdb02.

[oracle@oel62-ora12c-prm ~]$ export ORACLE_SID=prmcdb

[oracle@oel62-ora12c-prm ~]$ sqlplus / as  sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Apr 14 09:51:44 2014

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

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> alter pluggable database prmpdb02 close immediate;

Pluggable database altered.

SQL> alter pluggable database prmpdb02 open read only;

Pluggable database altered.

“Pull-Based Active Database Duplication” de una sola "Pluggable Database"

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en otras partes de esta serie de artículos. En este caso usamos el comando DUPLICATE de RMAN con las siguientes opciones:

Opción de duplicación	Pluggable Database – prmpdb01
Tipo de duplicación	Active Database Duplication
Método de duplicación	Pull-Based
Tipo de backup utilizado	BACKUPSETS   (default)
Número de “Target Channels”	1   (default)
Número de “Auxiliary Channels”	1  (default)

Usando Backup Sets comprimidos para ejecutar una "Active Database Duplication"

Duplicando CDB - Usando Backup Sets comprimidos para ejecutar una "Active Database Duplication"

En el siguiente ejemplo estamos trabajando inicialmente como base de datos origen con la CDB llamada “prmcdb”  que será duplicada en la CDB llamada “dupcdb” como ocurre en la segunda parte de esta serie de artículos. Se pueden ver los detalles cuando se establece la conexión de “prmcbd” como “target” y la conexión con la base de datos "dupcdb" como "auxiliar". En este caso usamos el comando DUPLICATE de RMAN con las siguientes opciones:

Opción de duplicación	CDB
Tipo de duplicación	Active Database Duplication
Método de duplicación	Pull Based
Tipo de backup utilizado	Compressed Backupsets
Número de “Target Channels”	1
Número de “Auxiliary Channels”	2