About Duplicating a Database to the Local Host

When you duplicate a database to the local host, you must store the duplicate database files by using a directory structure that is different from that of the source database. For example, if the source database files are stored in the /disk1/oracle directory, then the duplicate database files can be stored in the /disk2/oracle directory. The duplicate database file names can be the same as those of the source database or different. The techniques for specifying alternate names for duplicate database files are described in "Methods of Generating Database File Names for the Duplicate Database".

About Duplicating a Database to a Remote Host

• Are you familiar with the prerequisites for each duplication technique?

  Review the Prerequisites section of the DUPLICATE command description in Oracle Database Backup and Recovery Reference for a complete list.

  Some prerequisites are specific and depend on the duplication technique. For example, active duplication requires that the source and auxiliary instances use the same password as the source database, whereas backup-based duplication without connections to the target database and recovery catalog requires only that all backups and database copies reside in a single location.

• Do backups of the source database exist?

  The principal advantage of active database duplication is that it does not require source database backups. Active duplication copies mounted or online database files over a network to the auxiliary instance. One disadvantage of this technique is the negative performance effect on the network. Another disadvantage is that the source database is running processes required to transfer the files to the auxiliary host, thereby affecting the source database and production workload.

  If the source database backups exist, and if the effect on the network is unacceptable, then backup-based duplication may be a better option. You can copy backups to temporary storage and transfer them manually to the destination host. If duplication is made with a connection to the target or the recovery catalog, then the backup files on the destination host must have the same file specification as they had on the source host. Otherwise, this is not a requirement.

• Is a recovery catalog available?

  If a recovery catalog exists, then you can perform backup-based duplication without connecting RMAN as TARGET to the source database. This technique is advantageous where network connections from the auxiliary host to the source database are restricted or prone to intermittent disruptions. When you perform duplication without using a target connection, the source database is unaffected by the duplication.

• How much disk space is available on the destination host?

  When you perform duplication by using disk backups, disk space on the destination host can be an issue. For example, if the source database is 1 terabyte (TB), and if you duplicate the database from disk backups without using shared disk or network file system (NFS), then you must have at least 2 terabytes (TB) of space available on the destination host. In some environments, manual transfer of backups is necessary because NFS performance is a bottleneck.

• Are the source and destination hosts connected by a LAN or a WAN?

  Performance of active database duplication is probably slower on a wide area network (WAN) than on a local area network (LAN). If the performance degradation on a WAN is unacceptable, then backup-based duplication may be the only viable option.

• When do you plan to duplicate the database?

  If you must duplicate the database during a period of high user activity, then the loss of network throughput caused by active duplication may be a problem, making backup-based duplication a better choice. Also, in active database duplication, the RMAN channels that are required for copying files to the auxiliary host can affect performance.

Depending on your duplication scenario, you can name the duplicate database files by using one of the following techniques:

• Using the Same Names for Database Files in the Source Database and Duplicate Database

• Using Different Names for the Database Files in the Source Database and Duplicate Database

If you do not specify a strategy to generate names for duplicate database files, then RMAN uses the same file names and directory structure as the source database for the duplicate database. Only when duplicating to a remote host, use the NOFILENAMECHECK clause to indicate that RMAN must not display an error when the names of the database files are the same in the source and duplicate database.

Some of the methods used to specify alternate names for duplicate database files may generate file names that are the same as the ones used by the source database. This may happen if, for example, you used the SET NEWNAME or the CONFIGURE AUXNAME commands to specify names for the duplicate database files. Use caution when you specify the file names for the duplicate database, else you may mistakenly overwrite the source database files.

Use one of the following techniques to install the software:

• Perform a normal installation with Oracle Universal Installer (OUI).

  Install an Oracle Database whose release number is the same as that of the source database. Do not create a database; install the software only. Apply any required patches.

• Clone the source Oracle home.

  Use OUI to clone the source Oracle home. This ensures that all patches applied to the source database are present in the duplicate database.

When duplicating with a target connection and recovery catalog connection or with just a target connection, RMAN uses metadata in the RMAN repository to locate backups and archived redo log files that are required for duplication. If RMAN is connected to a recovery catalog, then RMAN obtains the backup metadata from the catalog. If RMAN is not connected to a catalog, as may be the case when you perform backup-based duplication with a target connection, then RMAN obtains metadata from the control file.

Unless you are duplicating without a connection to the target and to the recovery catalog, the names of the backups must be available with the same names recorded in the RMAN repository. Ensure that auxiliary channels on the destination host can access all data file backups and archived redo log files. This is required to restore and recover the duplicate database to the desired point in time. If not, duplication fails. The archived redo log files can be available either as image copies or backup sets.

• Create an initialization parameter file manually.

  If the source database does not use a server parameter file, then you must set all the necessary parameters for the auxiliary instance in a text-based initialization parameter file.

• Direct RMAN to use the initialization parameter file of the source database for the auxiliary instance.

  This technique is applicable only if the source database uses a server parameter file. Copying the initialization parameter file from the source database is useful when the duplicate database must use the same parameter settings as the source.

  Note:

  It is recommended to use a server parameter file instead of a text-based initialization parameter file for duplication.

The client-side parameter file for the auxiliary instance must reside on the same host as the RMAN client that performs the duplication.

It is recommended that you create the initialization parameter file in the default location on the auxiliary instance. On Windows, the default initialization parameter file is ORACLE_HOME/dbs/initORACLE_SID.ora and on Linux the file name is ORACLE_HOME\database\intiORACLE_SID.ora.

To connect to a database by using password file authentication, you must create a password file for the database. When duplicating to a remote host, setting up a password file is mandatory. The default location for the password file is $ORACLE_BASE\database on Windows and $ORACLE_BASE/dbs on Linux and UNIX.

Use one of the following options to create a password file for the auxiliary instance on the destination host:

• The RMAN client is run from a host other than the destination host

• The duplication technique chosen is active database duplication

• The destination host is different from the source host

To perform active database duplication, you must connect to the auxiliary instance with SYSDBA or SYSBACKUP privilege and by using a net service name. The source database to which RMAN is connected as TARGET uses this net service name to connect directly to the auxiliary database instance.

To establish Oracle Net connectivity and set up a static listener:

To start the auxiliary instance:

The Oracle software keystore contains the TDE master key used to:

• decrypt encrypted backups when performing backup-based duplication.

• decrypt database or tablespace data when performing active database duplication of TDE-encrypted databases or tablespaces.

The following are the requirements for the keystore at the duplicate database:

• The keystore must be in the default location, or in the location indicated by the sqlnet.ora file.

• Permissions on the Oracle keystore file must be set so that the database can access the file.

• During duplication, the auxiliary instance is restarted thereby causing the Oracle software keystore to become unavailable. To ensure that the auxiliary instance has access to the keystore, set the ENCRYPTION_WALLET_LOCATION parameter in the sqlnet.ora file such that it points to the keystore location.

  The ENCRYPTION_WALLET_LOCATION sqlnet.ora parameter is deprecated in Oracle Database Release 19c. Use the WALLET_ROOT initialization parameter with the TDE_CONFIGURATION initialization parameter to configure the software keystore location.

• With Oracle Real Application Clusters (Oracle RAC), register the auxiliary instance statically with an Oracle Grid Infrastructure listener and use the ENVS parameter in the sqlnet.ora file of the Oracle Grid home to specify environment variables that set the keystore location and the unique name of the database.

  The following example sets the ENVS parameter in sqlnet.ora to specify the keystore location and unique database name:

   (ENVS="ORACLE_UNQNAME=cdbrptl, ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/etc/ORACLE/WALLETS/cdbrpt1)))")

• If the source database uses a password-based software keystore (not an auto-login software keystore), then you must provide the keystore password before you begin the duplication.

  Use the SET command with the DECRYPTION WALLET OPEN IDENTIFIED BY clause to specify the password that must be used to open the keystore.

  The following command specifies the password used to open the keystore (where password is a placeholder for the actual password that you enter):

  SET DECRYPTION WALLET OPEN IDENTIFIED BY password;

To duplicate a database:

1. Ensure that the prerequisites for the selected duplication technique are met.

   See Prerequisites for Duplicating a Database.

2. Complete the required planning tasks before you begin database duplication.

   See Planning to Duplicate a Database.

3. Prepare the auxiliary instance that is used when creating the duplicate database.

   See Preparing the Auxiliary Instance.

4. Start RMAN and connect to required databases. Depending on your duplication technique, you may need to connect to one or more of the following: target database, auxiliary instance, or recovery catalog.

   See Starting RMAN and Connecting to Databases.

5. Place the source database in a proper state (if necessary).

   See Placing the Source Database in a Proper State.

6. (Optional) Configure RMAN channels to improve duplication performance. Channels perform the primary task of duplicating the database. .

   See Configuring RMAN Channels for Use in Duplication.

7. Use the DUPLICATE command to duplicate the source database.

   See Using the DUPLICATE Command to Duplicate Databases.

When you perform active database duplication, you can encrypt or compress the backup sets that are used to transfer files from the source database to the duplicate database. Additionally, you can create backup sets on the source database in parallel by using multisection backups.

To duplicate some tablespaces in a database:

To duplicate a sparse database:

Use one of the following methods to configure channels:

• Automatically allocate channels by using the CONFIGURE command

• Manually allocate channels by using the ALLOCATE command

If no automatic channels are configured, then you can manually allocate at least one channel before you being the duplication. The ALLOCATE command that allocates channels must be in the same RUN block as the DUPLICATE command.

RMAN can use the same channel configurations on the source database for duplication on the destination host even if the source database channels do not specify the AUXILIARY option.

To ensure that the source database is in a proper state:

To start RMAN and connect to the target and auxiliary instances:

1. Start the RMAN client on any host that can connect to the necessary database instances.

   For example, enter the following command at the operating system prompt on the destination host:

   % rman

2. At the RMAN prompt, run CONNECT commands for the database instances that are required for your duplication technique.

   Note:

   When you duplicate a whole CDB or one or more PDBs, connect to the root of both instances.

   • For active database duplication using image copies, you must connect to the source database as TARGET and to the auxiliary instance as AUXILIARY. You must supply the net service name to connect to the AUXILIARY instance. A recovery catalog connection is optional. On both instances, the password for the user performing the duplication must be the same. Any user with a SYSDBA or SYSBACKUP privilege can perform duplication.

   • For active database duplication using backup sets, you must connect to the source database as TARGET by using a net service name. The auxiliary instance uses this net service name to connect to the source database and retrieve the backup sets that are required for the duplication. Connect to the auxiliary instance as AUXILIARY. If you are connecting to the auxiliary instance remotely or intend to use the PASSWORD FILE option of the DUPLICATE command, then connect to the auxiliary instance with a net service name. On both instances, the password for the user performing the duplication must be the same. Any user with a SYSDBA or SYSBACKUP privilege can perform duplication. A recovery catalog connection is optional.

   • For backup-based duplication without a target connection, you must connect to the auxiliary instance as AUXILIARY and the recovery catalog as CATALOG.

   • For backup-based duplication with a target connection, you must connect to the source database as TARGET and the auxiliary instance as AUXILIARY. A recovery catalog is optional.

   • For backup-based duplication without target and recovery catalog connections, you must connect to the auxiliary instance as AUXILIARY.

   Note:

   You cannot connect as TARGET to a standby database.

Example: Connecting to the Required Databases When Performing Active Database Duplication

In this example, a connection is established to the source database and the auxiliary instance using net service names. The Net Service name of the source database is srcdb and that of the auxiliary instance is dupdb.

To connect to required databases from the destination host:

1. Start the RMAN client on the destination host.

   % rman

2. Connect to the source database as TARGET.

   RMAN> CONNECT TARGET sys@srcdb;

   Enter the password for the SYS user on the source database when prompted.

3. Connect to the auxiliary instance as AUXILIARY.

   RMAN> CONNECT AUXILIARY sys@dupdb;

   Enter the password for the SYS user on the auxiliary instance when prompted.

• DUPLICATE DATABASE or DUPLICATE...ACTIVE DATABASE

  Use these for duplicating non-CDBs and CDBs.

• DUPLICATE DATABASE ... FOR STANDBY

  Use this to create a standby database by duplicating the source database.

  Use the DUPLICATE DATABASE ... FOR FARSYNC command to create an Oracle Data Guard far sync instance using duplication.

• DUPLICATE PLUGGABLE DATABASE

  Use this to duplicate one or more PDBs while connected to the root.

To duplicate a CDB:

1. Complete the planning tasks described in "Planning to Duplicate a Database" with the following change:

   In "Making Backups Accessible to the Duplicate Instance" and "Making Disk Backups Accessible Without Shared Disk", note the following adjustment:

   Use the PLUGGABLE DATABASE syntax of the BACKUP command to copy only the backups of a specific PDB.

   The following command transfers the backup files for the entire CDB:

   BACKUP COPY OF DATABASE; 

   The following command transfers only the backup files for the PDB pdb3:

   BACKUP COPY OF PLUGGABLE DATABASE pdb3;

2. Ensure that the prerequisites for the selected duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance", with the following changes:

   • You must create the auxiliary instance as a CDB. To do so, start the instance with the following declaration in the initialization parameter file:

     enable_pluggable_database=TRUE

   • When instructed to create an initialization parameter file for the auxiliary instance, you must copy the file from the source database. This ensures that the auxiliary instance is also a CDB. After you copy the file, perform the following steps:

     • Modify the DB_NAME parameter

     • Modify the various destination or location parameters

   • When instructed to connect to the necessary instances, connect to the root as a user with SYSDBA or SYSBACKUP privilege. On both instances, the password for the user performing the duplication must be the same.

4. Start RMAN and connect to the root as a user with the SYSDBA or SYSBACKUP privilege.

   On both the auxiliary instance and the target database, the password for the user performing the duplication must be the same.

5. Place source database in a proper state, if necessary, as described in "Placing the Source Database in a Proper State".

6. Configure RMAN channels, if necessary, as described in "Configuring RMAN Channels for Use in Duplication".

   The primary task of duplication is performed by RMAN channels. Configuring additional channels improves the duplication performance.

7. Use the DUPLICATE command to duplicate the source CDB.

   See "Using the DUPLICATE Command to Duplicate Databases".

To duplicate tablespaces within a PDB:

1. Ensure that you have completed Steps 1 to 4 in Duplicating a PDB to a New CDB.

2. Run the DUPLICATE command with the TABLESPACE option described in About Duplicating PDBs.

   The following are some examples of duplicating tablespaces that are contained in PDBs:

   To duplicate the users tablespace that is part of PDB pdb1, use the following command:

   DUPLICATE DATABASE TO cdb1 TABLESPACE pdb1:users;

   To duplicate the PDB pdb1 and the users tablespace in PDB pdb2, use the following command:

   DUPLICATE DATABASE TO cdb1 PLUGGABLE DATABASE pdb1 TABLESPACE pdb2:users;

• The source host and the destination host are different.

• Both the source database and the duplicate database manage database files by using ASM.

• The duplicate database files use a different directory structure than the source database.

• Network bandwidth on the source host is limited.

• The duplicate database must be opened after the duplication process completes.

Use the following steps to create a duplicate database for the scenario that is described in this example:

1. Plan the duplication, as described in "Planning to Duplicate a Database".

   This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements.

     Because network bandwidth on the source host is limited, active database duplication by using backup sets is performed.

   • Choose a strategy to name duplicate database files.

     In this example, the DB_CREATE_FILE_DEST initialization parameter is used to specify the location of the duplicate database files.

   • Configure six auxiliary channels on the auxiliary instance, as described in "Configuring RMAN Channels for Use in Duplication".

     In this example, there are two target channels configured on the source database. For RMAN to use backup sets to perform active database duplication, the number of auxiliary channels must be equal to or greater than the number of target channels.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the disk groups that will store the database files on the destination host.

     If it does not already exist, create the +DGROUP2 disk group to store the duplicate database files.

   • Copy the password file from the source database to the destination database, as described in "Creating a Password File for the Auxiliary Instance".

   • Set up Oracle net services connectivity between the source database and the auxiliary instance by using a static listener.

   • Copy the source database software keystore to the destination host. Specify the password that must be used to open the password-based software keystore by using the SET command.

     See "Making the Oracle Keystore Available to the Destination Host".

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance".

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY.

   %rman
   RMAN> CONNECT TARGET sys@srcdb as SYSDBA;
   RMAN> CONNECT AUXILIARY sys@dupdb AS SYSBACKUP;

   See Also:

   For active database duplication, connection to the auxiliary instance must also use password file authentication.

5. Duplicate the database by using the DUPLICATE command.

   The SPFILE clause directs RMAN to copy the server parameter file from the source database to the auxiliary instance. Use the DB_CREATE_FILE_DEST parameter to specify the disk group that is used to store the duplicate database files in the duplicate database.

   DUPLICATE DATABASE to dupdb
   FROM ACTIVE DATABASE
   PASSWORD FILE
   SPFILE
   SET DB_CREATE_FILE_DEST='+DGROUP2';

• The source host and the destination host are different.

• The duplicate database files use a directory structure that is different from that of the source database.

• The source database and the duplicate database use Oracle Managed Files (OMF) to create database files.

• The source database must be available during the duplication process.

• The duplicate database must be opened after the duplication process completes.

1. Plan the duplication, as described in "Planning to Duplicate a Database". This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements.

     Since the bandwidth between the source and destination is limited, active database duplication by using image copies is performed.

   • Choose a strategy to name duplicate database files.

     In this example, the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters are used to specify how the source database file names are converted to duplicate database file names.

   • When you perform active database duplication by using image copies, RMAN uses image copies either if no auxiliary channels are configured or if the number of auxiliary channels is lesser than the number of target channels. Therefore, no additional channels need to be configured to perform active database duplication by using image copies.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the directories that store the database files on the destination host.

     In this example, create the /app/db_home2/database directory to store the data files, control file, and server parameter file and the /app/db_home2/logfiles directory to store the online redo log files.

   • On the destination host, create a minimal initialization parameter file for the auxiliary instance. The file is called initdup.ora and is located in the /app/db_home1/database directory. It contains the following entries:

     DB_NAME=dup
     DB_DOMAIN = dup.example.com

     See "Creating an Initialization Parameter File for the Auxiliary Instance".

   • Copy the password file from the source database to destination host, as described in "Creating a Password File for the Auxiliary Instance"

   • Set up Oracle net services connectivity between the source database and the auxiliary instance by using a static listener, as described in "Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance".

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance".

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY.

   % rman
   RMAN> CONNECT TARGET sys@srcdb as SYSDBA;
   RMAN> CONNECT AUXILIARY sys@dupdb AS SYSBACKUP;

   See Also:

   For active database duplication, connection to the auxiliary instance must also use password file authentication.

5. Duplicate the database by using the DUPLICATE command. Include the SPFILE clause with the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters to specify that the server parameter file from the source database must be used for the auxiliary instance.

   The duplicate database files are stored in the duplicate database by using OMF-generated names. The PARAMETER_VALUE_CONVERT option of the SPFILE clause specifies that the path name /app/db_home1 should be converted to /app_db_home2.

   DUPLICATE DATABASE TO dupdb
   FROM ACTIVE DATABASE
   PASSWORD FILE
   SPFILE PARAMETER_VALUE_CONVERT='/app/dbhome1','/app/db_home2'
   SET db_file_name_convert='/app/dbhome1/dbs','/app/db_home2/database/dbs'
   SET log_file_name_convert='/app/dbhome1/log','/app/db_home2/logfiles';

• A complete backup of the source database including the control files, data files, and archived redo log files is available in the /backups/db_files directory on the destination host.

• A connection to the target database or recovery catalog is not available.

• The source host and destination host are different.

• The duplicate database uses a directory structure that is different from that used by the source database to store the duplicate database files. The data files and control file of the duplicate database files are stored in the /oracle2/database directory and the online redo logs files are stored in /oracle2/database/logs directory.

• The DB_NAME of the source database is db12 and that of the duplicate database is dup.

• The duplicate database must be opened after the duplication process completes.

Use the following steps to create a duplicate database for the scenario that is described in this example:

1. Plan the duplication, as described in "Planning to Duplicate a Database". This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements.

     In this example, backup-based duplication without a target connection or recovery catalog connection is performed. Therefore, we use the BACKUP LOCATION clause to specify the location of the source database backups.

   • Because the duplicate database uses a directory structure that is different from the source database, you must choose a strategy to generate duplicate database file names.

     In this example, the SET NEWNAME FOR DATABASE command specifies the location of the data files and control file. The LOGFILE clause of the DUPLICATE command specifies the location of the online redo log files.

   • Copy the required backups to the destination host by using the same directory structure used on the source database.

     In this example, the backups of the data files and archived redo log files must be stored in /backups/db_files and the backups of the control files and server parameter file in /backups/cf on the destination host.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance.

   • Create the directories that will store the duplicate database files on the destination host.

     In this example, you create the /oracle2/database directory to store the data files, control file, and server parameter file. Create the /oracle2/database/logs directory to store the online redo log files.

   • Create a minimal initialization parameter file for the auxiliary instance, as described in "Creating an Initialization Parameter File for the Auxiliary Instance".

     The file is called initdup.ora and is located in the /oracle2/database directory. In addition to any other specific settings, it must contain the following entries:

     DB_NAME = dup
     DB_DOMAIN = dupdb.example.com

   • Create a password file for the auxiliary instance by using the orapwd utility. A password file is required because the duplicate database is being created on a remote host.

     See "Creating a Password File for the Auxiliary Instance".

   • Set up Oracle Net Services connectivity between the source database and the auxiliary instance by using a static listener, as described in "Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance".

     This is required because this example duplicates a database to a remote host.

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance".

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY.

   %rman
   RMAN> CONNECT TARGET /
   RMAN> CONNECT AUXILIARY sys@dup AS SYSBACKUP;

   Enter the passwords when prompted.

5. Duplicate the database by using the DUPLICATE command.

   Include the BACKUP LOCATION clause to specify the location of the source database backups. Enclose the SET NEWNAME FOR DATABASE and DUPLICATE command within a RUN block. The LOGFILE clause specifies the names and location of the online redo log files.

   run
   {
   set newname for database to '/oracle2/database/%b';
   duplicate database 'db12' to 'dup'
   logfile group 1 ('/oracle2/database/logs/r1.f','/ oracle2/database/logs/r2.f') size 4m reuse, 
           group 2 ('/ oracle2/database/logs/r3.f','/oracle2/database/logs/r4.f') size 4m reuse
   backup location '/backups/db_files';
   }

• A complete backup of the source database is available on the source host. The backups of the data files and archived redo log files are stored in /bkups/db_files. The backups of the control files and server parameter file are stored in /bkups/cf.
• A connection to the source database is not available, but a connection to the recovery catalog is available.

• The source host and destination host are different. The destination host used OMF and has the Oracle Database software installed.

• The duplicate database stores database files in a different directory structure than the source database. The database files of the duplicate database must be stored in the /app/oracle2/dbs directory.

• The DB_NAME of the source database is ora and its Net Service name is oradb. The DB_NAME of the duplicate database is dup and its Net Service name is dupdb.

• The read-only tablespaces in the source database must be excluded from the duplicate database.

• The duplicate database must not be opened after the duplication process completes.

1. Plan the duplication. as described in "Planning to Duplicate a Database". This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements.

     In this example, backup-based duplication using a recovery catalog connection is performed.

   • Choose a strategy to generate duplicate database file names.

     Since the duplicate database uses OMF, use the DB_CREATE_FILE_DEST parameter in the auxiliary instance's initialization parameter file to specify the directory in which the duplicate database files are stored.

   • Use the NOOPEN clause of the DUPLICATE command to specify that the duplicate database must not be opened using RESETLOGS after the duplication completes.

   • Copy the required backups to the destination host using the same directory structure used on the source database.

     In this example, the backups of the data files and archived redo log files must be stored in /scratch/db_files and the backups of the control files and server parameter file in /scratch/cf on the destination host.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the directories that will store the duplicate database files on the destination host.

     In this example, you create the /app/oracle2/dbs directory to store the data files, control file, online redo log files, and server parameter file.

   • Create an initialization parameter file for the auxiliary instance. The file is called initdup.ora and is located in the /app/oracle2/dbs directory. In addition to any other specific settings, it must contain the following entries:

     DB_NAME=dup
     DB_DOMAIN = dupdb.example.com
     DB_CREATE_FILE_DEST= /app/oracle2/dbs

     See "Creating an Initialization Parameter File for the Auxiliary Instance".

   • Create a password file for the auxiliary instance by using the orapwd utility. A password file is required because the duplicate database is being created on a remote host.

     See "Creating a Password File for the Auxiliary Instance".

   • Set up Oracle net services connectivity between the source database and the auxiliary instance using a static listener. This is required because this example duplicates a database to a remote host.

     See "Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance".

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance".

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY.

   %rman
   RMAN> CONNECT TARGET sys@oradb;
   RMAN> CONNECT AUXILIARY sys@dupdb;

   Enter the passwords when prompted.

5. Duplicate the database by using the DUPLICATE command.

   Include the SKIP READONLY clause to exclude the read-only tablespaces from the duplicate database. Because there is no connection to a target database, you must specify the name of the target database that is being duplicated.

   DUPLICATE DATABASE db12 TO dup
   SKIP READONLY;

• A complete backup of the source database including the control file, data files, and archived redo log files is available.

• A connection to the source database is available.

• The source host and destination host are different.

• The source database is configured to use transparent encryption with a password-based software keystore.

• The duplicate database uses the same directory structure and file names as the source database to store database files.

  On the source host, the data file, control files and server parameter file are stored in /app/db_home1/database and the online redo log files are stored in /app/db_home1/logfiles.

• The DB_NAME of the source database is src and its Net Service name is srcdb. The DB_NAME of the duplicate database is dup and its Net Service name is dupdb.

• On the source host, backups of the data files and archived redo log files are stored in /bkups/oradata/db_files. The backups of the control files and server parameter file are stored in /bkups/oradata/cf.

• The tablespaces HR and SH must be excluded from the duplicate database.

  The remaining tablespaces in the source database are self-contained and do not have links to the hr and sh tablespaces.

• The duplicate database must be opened after the duplication process completes.

1. Plan the duplication, as described in "Planning to Duplicate a Database". This includes the following tasks:

   • Choose a duplication technique that is suitable for your scenario.

     In this example, backup-based duplication by using a target connection is performed.

   • Because the duplicate database uses the same directory structure as source database, you need not specify an alternative file naming strategy.

     However, use the NOFILENAMECHECK clause in the DUPLICATE command to prevent RMAN from checking if the data files and online redo logs files of the source database use the same names as that on the duplicate database.

   • Configure three additional auxiliary channels, as described in "Configuring RMAN Channels for Use in Duplication". Using additional auxiliary channels enhances the performance of the duplication process

   • Copy the required backups to the destination host using the same directory structure used on the source database.

     In this example, the backups of the data files and archived redo log files must be stored in the /bkups/oradata/db_files directory and the backups of the control file and server parameter file in the /bkups/oradata/cf directory on the destination host.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the directories that store the duplicate database files on the destination host.

     In this example, the source database and the duplicate database use the same directory structure. Create the /app/database directory to store the data files, control file, and server parameter file and the /app/logfiles directory to store the online redo log files.

   • Create a minimal initialization parameter file for the auxiliary instance. The file is called initdup.ora and is located in the /app/database directory. It contains the following entries:

     DB_NAME=dup
     DB_DOMAIN = dup.example.com

     See "Creating an Initialization Parameter File for the Auxiliary Instance".

   • Create a password file for the auxiliary instance by copying the password file from the source database to the duplicate database, as described in "Creating a Password File for the Auxiliary Instance".

   • Set up Oracle Net Services connectivity between the source database and the auxiliary instance by using a static listener, as described in "Establishing Oracle Net Connectivity Between the Source Database and Auxiliary Instance".

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance"

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY. These connections are established from the destination host and the auxiliary connection uses operating system authentication.

   %rman
   RMAN> CONNECT TARGET sys@dupdb AS SYSBACKUP;
   RMAN> CONNECT AUXILIARY /

5. Duplicate the database by using the DUPLICATE command.

   Include the SKIP TABLEPACE clause to specify the tablespaces that must be omitted during the duplication process. Use the SPFILE clause to specify that the server parameter file from the source database must be restored and copied to the duplicate database.

   DUPLICATE DATABASE TO dup
   SPFILE
   SKIP TABLESPACE HR, SH
   NOFILENAMECHECK;

• The source host and the destination host are the same.

• Both the source database and the duplicate database manage database files by using Oracle Managed Files (OMF).

• The duplicate database files use a different directory structure than the source database.

• The source database is run in ARCHIVELOG mode and is available during the duplication process.

• The service name of the source database dbsrc and that of the duplicate database is dbdup. The source database uses a server parameter file (spfile).

Use the following steps to create a duplicate database for the scenario that is described in this example:

1. Plan the duplication, as described in "Planning to Duplicate a Database".

   This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements

     Because network bandwidth on the source host is limited, active database duplication by using backup sets is performed.

   • Choose a strategy to name duplicate database files

     In this example, the DB_CREATE_FILE_DEST initialization parameter is used to specify the location of the duplicate database files.

     To ensure that the source database files are not overwritten, do not include the NOFILENAMECHECK clause in the DUPLICATE command.

   • Configure auxiliary channels on the auxiliary instance

     In this example, there are three target channels configured on the source database. For RMAN to use backup sets to perform active database duplication, the number of auxiliary channels must be equal to or greater than the number of target channels.

     See "Configuring RMAN Channels for Use in Duplication".

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the directories that store the database files on the destination host

     In this example, create the /app/db_home3/dbs directory to store the data files, control file, and server parameter file and the /app/db_home3/logfiles directory to store the online redo log files.

   • Copy the password file from the source database to the duplicate database, as described in "Creating a Password File for the Auxiliary Instance".

   • Create an initialization parameter file for the auxiliary instance with the following minimum parameters: DB_NAME, CONTROL_FILES, DB_CREATE_FILE_DEST, and LOG_CREATE_FILE_DEST.

   • Set up Oracle net services connectivity between the source database and the auxiliary instance by using a static listener.

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance".

4. Start RMAN and connect to the source database as TARGET and to the auxiliary instance as AUXILIARY. Both connections user net service names.

   %rman
   RMAN> CONNECT TARGET sys@srcdb as SYSDBA;
   RMAN> CONNECT AUXILIARY sys@dupdb AS SYSBACKUP;

   Note: For active database duplication, the connection to the auxiliary instance must also use password file authentication.

5. Duplicate the database by using the DUPLICATE command.

   DUPLICATE DATABASE to dbdup
   FROM ACTIVE DATABASE;

• The source host and the destination host are different.

• Both the source database and the duplicate database manage database files by using OMF.

• Network bandwidth on the source host is limited.

• The duplicate database files use a different directory structure than the source database.

Use the following steps to create a duplicate database for the scenario that is described in this example:

1. Plan the duplication, as described in "Planning to Duplicate a Database". This includes the following tasks:

   • Choose a duplication technique that suits the scenario and requirements.

     Because network bandwidth on the source host is limited, active database duplication by using backup sets is performed.

   • Choose a strategy to name duplicate database files.

     In this example, the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters are used to specify the location of the duplicate database files.

   • Configure four auxiliary channels on the auxiliary instance, as described in "Configuring RMAN Channels for Use in Duplication".

     In this example, two target channels are configured on the source database. For RMAN to use backup sets to perform active database duplication, the number of auxiliary channels must be equal to or greater than the number of target channels.

2. Ensure that the prerequisites for the chosen duplication technique are met, as described in "Prerequisites for Duplicating a Database".

3. Prepare the auxiliary instance, as described in "Preparing the Auxiliary Instance".

   • Create the directories that store the database files on the destination host.

     In this example, create the /app/dbhome3/database directory to store the data files, control file, and server parameter file and the /app/dbhome3/logfiles directory to store the online redo log files.

   • On the destination host, create a minimal initialization parameter file for the auxiliary instance. The file is called initdup.ora and contains the following entries:

     ENABLE_PLUGGABLE_DATABASE=true
     DB_NAME=dup
     DB_DOMAIN = dup.example.com

   • Create the password file on the destination database by using the PASSWORD FILE option in the DUPLICATE command..

   • Set up Oracle net services connectivity between the source database and the auxiliary instance by using a static listener.

   • Start the auxiliary instance in NOMOUNT mode, as described in "Starting the Auxiliary Instance". Connect to the root as a common user with the SYSDBA or SYSBACKUP privilege.

4. Start RMAN and connect to the root of the source database as TARGET and to the auxiliary instance as AUXILIARY.

   %rman
   RMAN> CONNECT TARGET sys@srcdb as SYSDBA;
   RMAN> CONNECT AUXILIARY sys@dupdb AS SYSBACKUP;

   Note: For active database duplication, connection to the auxiliary instance must also use password file authentication.

5. Ensure that the source CDB is open or mounted.

6. Duplicate the database by using the DUPLICATE command.

   The SPFILE option directs RMAN to copy the server parameter file from the source database to the auxiliary instance. Use the DB_CREATE_FILE_DEST parameter to specify the disk group that is used to store the duplicate database files in the duplicate database.

   DUPLICATE DATABASE to dupdb
   FROM ACTIVE PLUGGABLE DATABASE my_pdb
   PASSWORD FILE
   SET DB_FILE_NAME_CONVERT='/app/dbhome/database','/app/dbhome3/database' SET LOG_FILE_NAME_CONVERT='/app/dbhome/logfiles','/app/dbhome3/logfiles';

The example assumes the following scenario:

• The source CDB, cdb_src, and the destination CDB, cdb_dest, are on different hosts.

• Both source and destination CDB use OMF to manage database files.

• The source and destination CDBs have compatible set to 18.0.0 or higher.

• The source CDB and the destination CDB use local undo.

• The PDB being duplicated, my_pdb, is in read-write mode.

• The source CDB and the destination CDB are open in read-write mode.

• The initialization parameter REMOTE_RECOVERY_FILE_DEST which determines the location to which foreign archived redo log files are restored is set for the destination CDB.

This example uses the following scenario:

• The source host and destination host are different.

• Both source and destination database use OMF to manage database file names. However, the duplicate database uses a directory structure that is different from that of the source database.

• Source database backups are encrypted by using transparent-mode encryption with the encryption key stored in a password-based software keystore. The keystore password is set up by using the following command (where password is a placeholder for the actual password that you enter):

  ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password;

• A complete backup of the source database including the control files, data files, and archived redo log files is stored in the /oracle2/rman_backups directory.

• The DB_NAME of source database is db_src and that of the duplicate database is dup_db.

• The EXAMPLE and TOOLS tablespaces must be excluded from the duplicate database.

• The duplicate database must be opened after the duplication process completes.

To perform backup-based database duplication by using encrypted backups: