25 Duplicating Databases

RMAN automates the following steps as part of performing database duplicating operation:

About Duplicating a Database to the Local Host

When you duplicate a database to the local host, you must store the duplicate database files using a directory structure that is different from that of the source database. For example, if the source database files are stored in /disk1/oracle, then the duplicate database files can be stored in /disk2/oracle. 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

Your business requirements and the database environment determine which duplication technique is best for your situation. Consider the following questions:

• 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. In duplication without a TARGET connection, the source database is unaffected by the duplication.

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

  The disk space on the destination host can be an issue when you perform duplication using disk backups. 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 required for copying files to the auxiliary host can affect performance.

When duplicating a database, RMAN generates names for the database files in the duplicate database. This includes the control files, data files, temp files, and online redo log files.

Depending on your duplication scenario, you can name the duplicate database files 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. In this case, you must use the NOFILENAMECHECK clause to indicate that RMAN must not display an error when the names of the files are the same.

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 SET NEWNAME or CONFIGURE AUXNAME to specify names for the duplicate database files. Use caution when specifying the file names for the duplicate database, else you may mistakenly overwrite the source database files.

If the source and destination host are different, then you must install the Oracle Database software on the destination host so that the auxiliary instance can be created. You can install the software in one of the following ways:

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

  Install an Oracle Database that is the same release as 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 you use the RMAN DUPLICATE command, the duplicate database is created and then opened in RESETLOGS mode. You can use the NOOPEN clause in the DUPLICATE command to specify that the duplicate database must not be opened.

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 needed 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 performing 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 (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.

On the destination host, you must create the directories that will be used to store the duplicate database files on the destination host. This includes the directories that store the data files, control files, online redo log files, and temp files.

An initialization parameter file is required to start the auxiliary instance. Use one of the following methods to create the initialization parameter file:

• 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.

  See Steps to Create an Initialization Parameter File for the Auxiliary Instance.

• 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 contains is useful when the duplicate database must use the same parameter settings as the source.

  See Copying the Server Parameter File from the Source Database.

  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 using password file authentication, you must create a password file for the database. Setting up a password file is also mandatory when duplicating to a remote host.

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

The auxiliary instance must be available through Oracle Net Services if any of the following conditions is true:

• 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:

The initialization parameter file created in Creating an Initialization Parameter File for the Auxiliary Instance is used to start the auxiliary instance. RMAN shuts down and restarts the auxiliary instance as part of the duplication. Hence, it is a good idea to create a server-side initialization parameter file for the auxiliary instance in the default location. If you do not have a server-side initialization parameter file in the default location, then you must specify the client-side initialization parameter file with the PFILE parameter on the DUPLICATE command.

To start the auxiliary instance:

If transparent encryption is configured on the source database, then you must ensure that the Oracle software keystore from the source database is available to the auxiliary instance. The Oracle software keystore contains the TDE master key used to decrypt encrypted backups (for backup-based duplication) and database/tablespace data (for active database duplication of TDE-encrypted databases or tablespaces). Manually copy the source database keystore to the destination host.

The following are 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.

• With Oracle Real Application Clusters (Oracle RAC), register the auxiliary instance statically with an Oracle Grid Infrastructure listener and use the ENVS parameter in thesqlnet.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 the 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:

DUPLICATE TARGET DATABASE TO dupdb
FROM ACTIVE DATABASE
SKIP READONLY;

DUPLICATE TARGET DATABASE
 TO dupdb
FROM ACTIVE DATABASE
SKIP TABLESPACE tools;

DUPLICATE TARGET DATABASE
TO dupdb
FROM ACTIVE DATABASE
  TABLESPACE users;

DUPLICATE TARGET DATABASE TO dupdb
 TABLESPACE users
 UNDO TABLESPACE undotbs;

To duplicate a sparse database:

The primary job of database duplication is performed by RMAN channels. Each channel corresponds to an Oracle Database server session that performs the duplication tasks. Depending on the duplication technique, RMAN uses either auxiliary channels or target channels.

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.

If RMAN is connected to the source database as TARGET, then the source database must be in the proper state for the duplication.

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

In this task, you must start the RMAN client and connect to the database instances required by the duplication technique chosen in Choosing a Duplication Technique. The RMAN client can be located on any host so long as it can connect to the necessary databases over the network.

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 required for your duplication technique.

   Note:

   When duplicating 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. 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 using a net service name. The auxiliary instance uses this net service name to connect to the source database and retrieve the backup sets 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.

Depending on your requirement, use one of the following syntaxes of the DUPLICATE command:

• 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.

When you use the SET NEWNAME command to specify alternate names for duplicate database files, ensure that you enclose the DUPLICATE command and the SET NEWNAME commands within a RUN block.

Duplicating a whole multitenant container database (CDB) or one or more pluggable databases (PDBs) requires only minimal adjustments to the procedure for duplicating a non-CDB as described in Duplicating the Whole Database.

To duplicate a CDB:

1. Complete the planning tasks described in Planning to Duplicate a Databasewith 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.

   See 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 copying, perform the following steps:

     • Modify the DB_NAME parameter

     • Modify the various destination/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 proper state (if necessary).

   See Placing the Source Database in the Proper State.

6. Configure RMAN channels (if necessary).

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

   See Configuring RMAN Channels for Use in Duplication.

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

   See Using the DUPLICATE Command to Duplicate Databases.

RMAN enables you to duplicate PDBs with the DUPLICATE command. You can duplicate a single PDB, a set of PDBs, or a set of tablespaces within a PDB. You must be logged in to the root of the CDB as a user who is granted the SYSDBA or SYSBACKUP privilege.

To duplicate PDBs, you must create the auxiliary instance as a CDB. To do so, start the auxiliary instance with the declaration enable_pluggable_database=TRUE in the initialization parameter file. When you duplicate one or more PDBs, RMAN also duplicates the root (CDB$ROOT) and the CDB seed (PDB$SEED). The resulting duplicate database is a fully functional CDB that contains the root, the CDB seed, and the duplicated PDBs. Table 25-3 describes the options that you can use to duplicate PDBs or tablespaces within PDBs.

To duplicate a PDB:

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.

   For example, the following command transfers only the backups files for the PDB pdb3:

   BACKUP COPY OF PLUGGABLE DATABASE pdb3;

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

   See 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 copying, perform the following steps:

     • Modify the DB_NAME parameter

     • Modify the various destination/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 proper state (if necessary).

   See Placing the Source Database in the Proper State.

6. Configure RMAN channels (if necessary).

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

   See Configuring RMAN Channels for Use in Duplication.

7. Duplicate the PDB by using the DUPLICATE … PLUGGABLE DATABASE command.

Examples: Duplicating PDBs

• To duplicate the PDB pdb1 to the CDB cdb1, use the following command:

  DUPLICATE DATABASE TO cdb1 PLUGGABLE DATABASE pdb1;

• To duplicate the PDBs pdb1, pdb3, and pdb4 to the database cdb1, use the following command:

  DUPLICATE DATABASE TO cdb1 PLUGGABLE DATABASE pdb1,pdb3,pdb4;

• To duplicate all the PDBs in the CDB, except the PDB pdb3, use the following command:

  DUPLICATE DATABASE TO cdb1 SKIP PLUGGABLE DATABASE pdb3;

To duplicate tablespaces within a PDB:

1. Ensure that you have completed Steps 1 to 4 in Duplicating PDBs.

2. Run the DUPLICATE command with the TABLESPACE option described in Table 25-3.

   The following are some examples of duplicating tablespaces 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;

This example assumes the following scenario:

• The source host and the destination host are different.

• Both the source database and the duplicate database manage database files 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 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, we perform active database duplication using backup sets.

   • 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.

     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.

     See "Configuring RMAN Channels for Use in Duplication".

2. Ensure that the prerequisites for the chosen duplication technique are met.

   See "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 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 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;
   

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

5. Duplicate the database 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';
   

This example assumes the following scenario:

• 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.

Use the following steps to create a duplicate database for the scenario 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.

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

   • 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 performing active database duplication 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 using image copies.

2. Ensure that the prerequisites for the chosen duplication technique are met.

   See "Prerequisites for Duplicating a Database".

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

   • Create the directories that will 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 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;
   

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

5. Duplicate the database 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 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';
   

This example uses the following scenario:

• 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 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 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.

   See "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. 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
     

     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 /
   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';
   }
   

This example assumes the following scenario:

• 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.

Use the following steps to create a duplicate database for the scenario 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 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.

   See "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;
   

This example uses the following scenario:

• 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 hr and sh.

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

Use the following steps to create a duplicate database for the scenario 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 is suitable for your scenario.

     In this example, backup-based duplication 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 /bkups/oradata/db_files and the backups of the control file and server parameter file in /bkups/oradata/cf on the destination host.

2. Ensure that the prerequisites for the chosen duplication technique are met.

   See "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, 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.

     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.

     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. 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;
   

This example uses the following scenario:

• The source host and destination host are different.

• Both source and destination database use Oracle Managed Files (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 using transparent-mode encryption with the encryption key stored in a password-based software keystore. The keystore password is set up using a command such as the following (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 /oracle2/rman_backups.

• 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 using encrypted backups: