Choosing a Duplication Technique

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

Consider the following questions:

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

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

   Disadvantages of active database duplication

    a. One disadvantage of this technique is the negative performance effect on the network. 
        b. 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 
    the effect on the network is unacceptable, 
then 
    backup-based duplication may be a better option. 
end

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. 
else
    this is not a requirement
end

3. Is a recovery catalog available?

If     a recovery catalog exists
then 
    perform backup-based duplication without connecting RMAN as TARGET to the source database. 
end

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.

3. 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. 
    Example: 
    if     the source database is 1 terabyte (TB), 
        and 
               (duplicate the database from disk backups without using shared disk or network file system (NFS))
           then 
        at least 2 terabytes (TB) of space available on the destination host. 
    end

     In some environments, manual transfer of backups is necessary because NFS performance is a bottleneck.

4. 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
    end

5. 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
else
    Making backup-based duplication a better choice.
end
 
Also, in active database duplication, the RMAN channels that are required for copying files to the auxiliary host can affect performance.

6. Choosing a Strategy for Naming Duplicate Database Files

When you duplicate a database, RMAN generates names for the database files in the duplicate database. 

This includes the 
    
    1. control files (multiplexed)  
    2. data files
    3. temp files
    4. online redo log files (if multiplexed).

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

    1. Using the Same Names for Database Files in the Source Database and Duplicate Database
    2. Using Different Names for the Database Files in the Source Database and Duplicate Database

If     not specified 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. 
end

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    (SET NEWNAME or CONFIGURE AUXNAME) 
then 
    use caution while specifing the file names for the duplicate database, 
else 
    you may mistakenly overwrite the source database files
end

Using the Same Names for Database Files in the Source Database and Duplicate Database
Certain conditions must be met to use the same names for files in the source and duplicate database.

7. The simplest duplication strategy is to configure the duplicate database to use the same directory structure and file names    as the source database. You can use the same directory structure and names only when duplicating to a remote host.

   Using the same directory structure and file names means that your environment meets the following requirements:

If     the source database uses ASM disk groups
then 
    the duplicate database must use ASM disk groups with the same names.
end

If     the source database files are Oracle Managed Files (OMF), 
then 
    the auxiliary instance must set the DB_CREATE_FILE_DEST parameter to the same directory location as the source     database. Although the directories are the same on the source and destination hosts, Oracle Database chooses the     relative names for the duplicate files.
end

If     the names of the database files in the source database contain a path, 
then 
    this path name must be the same in the duplicate database.
end

For Oracle Real Application Clusters (RAC) environments, use the same value for the ORACLE_SID parameter of the source and destination databases.

When you configure your environment as suggested, no additional configuration is required to name the duplicate files.

8. Using Different Names for the Database Files in the Source Database and Duplicate Database

If     (
    the source host and the destination host use different directory structures 
    or 
    use the same directory structures but you want to name the database files differently
    ) 
then 
    you must specify how RMAN should generate names for the duplicate database files.
end

Note:
    It is recommended that you use different names for the ASM disk groups in the source and duplicate database.

9. Methods of Generating Database File Names for the Duplicate Database

Depending on the method that you choose, RMAN can either automatically generate file names or use specific names for the duplicate database files. The database files include the data files, control files, online redo log files, and temp files.

Use one of the following methods, listed in the order of precedence, to generate file names for the duplicate database:

SET NEWNAME command
===================

Provides specific names for the duplicate database files. Based on your requirement, use the
 
SET NEWNAME FOR DATABASE      
SET NEWNAME FOR DATAFILE
SET NEWNAME FOR TABLESPACE
or 
SET NEWNAME FOR TEMPFILE 

For OMF and ASM database files, you must use the 

SET NEWNAME...TO NEW 

comand and not explicitly provide names for the database files.

CONFIGURE AUXNAME command
=========================

Specifies non-OMF and non-ASM alternative names for duplicate database files.

SPFILE clause of the DUPLICATE command
======================================

Sets all the necessary initialization parameters that are related to duplicate database file names, with the exception of the DB_FILE_NAME_CONVERT parameter.

(Online redo log files only) LOGFILE clause of the DUPLICATE command
====================================================================

Names online redo log files in the duplicate database. You cannot use this method while creating a standby database.

Note:

When duplicating to the local host or to a remote host without the NOFILENAMECHECK clause, ensure that you do not use the name of an online redo log file that is currently in use by the source database.

DB_FILE_NAME_CONVERT and 
LOG_FILE_NAME_CONVERT 

initialization parameters

Specifies a rule for converting file names in the source database to names in the duplicate database. You can specify multiple conversion pairs.

When you use the DB_FILE_NAME_CONVERT parameter for ASM file names, only disk group name changes must be performed.

Note:If the source database uses Oracle Managed Files, then you cannot use this method to specify alternative names for duplicate database files.

DB_CREATE_FILE_DEST and 
DB_CREATE_ONLINE_LOG_DEST_n 

parameters

Creates Oracle Managed Files at the location specified by these parameters. This is the recommended method to specify alternative names for OMF and ASM.

If more than one method is used to specify alternate names for duplicate database files, then the order of precedence decides which technique is used to name files. Any files that are not renamed by a particular method are renamed by the method that follows it. For example, if two data files are not included in the SET NEWNAME command, then these data files are renamed by using the 

DB_FILE_NAME_CONVERT parameter.

Specifying Alternative Names for Duplicate Database Files
=========================================================

The DUPLICATE command in Oracle Database Backup and Recovery Reference for the LOGFILE and SPFILE clauses

Preventing File Name Checking During Database Duplication

It is possible for the CONFIGURE AUXNAME command, the SET NEWNAME command, or the DB_FILE_NAME_CONVERT parameter to generate a name that is already in use in the target database. In this case, RMAN displays an error during duplication. When duplicating to a remote host, use the NOFILENAMECHECK option to avoid this error message.

Note:

Using NOFILENAMECHECK when duplicating to the local host overwrites the target database files.

10. Generating Names for Control Files in the Duplicate Database

    By default, RMAN creates the control file in the default location in the duplicate database. You can specify alternate     files names and directory names to store the duplicate database control files. While choosing names for the control     files, ensure that you do not mistakenly overwrite the control files of the source database.

    Use one of the following techniques, listed in the order of precedence, to specify the location of the duplicate 
database control files:

Set the CONTROL_FILES initialization parameter in the auxiliary instance's initialization parameter file.

Create an OMF-based control file in a location which is determined by setting one of the following parameters:

DB_CREATE_ONLINE_LOG_DEST_n
DB_CREATE_FILE_DEST
DB_RECOVERY_FILE_DEST

If more than one of these parameters is set, then the order of precedence used is the order in which these parameters are listed.

11. Installing the Oracle Database Software on the Destination Host

    When the source and destination host are different, you must install the Oracle Database software on the destination     host, so that the auxiliary instance can be created.

Note:

Ensure that you install the same release of Oracle Database software, with the same patch level, on both the source and destination host. 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.

Deciding the State of the Duplicate Database

When you use the RMAN DUPLICATE command, the duplicate database is created and opened in RESETLOGS mode. You can use the NOOPEN clause in the DUPLICATE command to specify that the duplicate database must not be opened.

You may not want to open the duplicate database immediately after creation in the following situations:

Opening the duplicate database may cause errors.
You need to modify the initialization parameters of the duplicate database.

Example: 

Need to modify 
    a. flashback database settings 
    b. configure fast incremental backups  or 
    c. modify block change tracking.

12. Creating a new database as part of an upgrade procedure.

    During an upgrade you cannot open the database with the RESETLOGS option. 
    The NOOPEN clause enables you to duplicate the database and then leave it in a state that is ready for opening in     upgrade mode and for subsequent execution of upgrade scripts.

13. Making Backups Accessible to the Duplicate Instance

Names of the backups used during duplication are stored in the RMAN repository or control file.

Note:

If     performing active database duplication, 
then 
    this step is not necessary.
end

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
then    
    perform backup-based duplication with a target connection
else
    RMAN obtains metadata from the control file.
end

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

Note:
The database backup need not have been generated with the BACKUP DATABASE command. You can mix full and incremental backups of individual data files, but a full backup of every data file is required.

Making SBT Backups Accessible to the Auxiliary Instance

The steps to make SBT backups accessible to the auxiliary instance are specific to your media manager configuration.

To make SBT backups accessible to the auxiliary instance:

If necessary, install media management software on the destination host.Make the tapes with the backups accessible to the destination host. Typically, you do one of the following:

Physically move the tapes to a drive attached to the remote host.

(This is a big deal. If NetBackup is used, the client name is registered and while restoring you are to set the client name as a unix variable and enable NetBackup to recognize to restore files) 

Use a network-accessible tape server.

If necessary, inform the remote media management software about the existence of the tapes.

14. Making Disk Backups Accessible to the Auxiliary Instance

    When you make disk backups accessible to the auxiliary instance, the strategy depends on whether duplicate the         database while connected 
    to the target (source database) or 
    to recovery catalog. 

If     (NOT connected to the target or recovery catalog)     
then     
    you must designate a backup location for the duplication by using the BACKUP LOCATION clause
end

If
    using a backup location the backups and copies can reside in a shared location 
end

If
    can be moved to the location on the destination host
then
    (do not need to preserve the name or the original path of the backup or copy). 
end
if 
    The location specified in the BACKUP LOCATION option must contain sufficient
then 
    that location must contain 
        i. backup sets, 
      ii. image copies, and 
    iii. archived logs to restore all of the files that are being duplicated, 
         and 
         recover them to the desired point in time.
    and 
    the database is to be open with RESETLOGS option only.
end

It is not required that all of the backups be from the same point in time, or that they all be backup sets, or all image copies. Data file backups can be supplied as either image copies or backup sets. Archived logs can be supplied either in their normal format or as backup sets of archived logs.

Important:

When you use backups from different points in time, the backup location must contain archived logs covering the time from the start of the oldest backup until the desired recovery point.

If     the backup location contains backup files from multiple databases, 
then 
    the DATABASE clause must specify the name of the database that is to be duplicated.
end 

If     the backup location contains backup files from multiple databases having the same name, 
then 
    the DATABASE clause must specify both the name and DBID of the database that is to be duplicated.
end

The source database's Fast Recovery Area is particularly well suited for use as a backup location because it almost always contains all the files that are required for the duplication. To use a Fast Recovery Area as a backup location, you can either remotely access it from the destination system, or copy its contents to the destination system.

When you are not using a backup location, your strategy depends on the following mutually exclusive scenarios:

Identical file systems for source and destination hosts

This scenario is the simplest and Oracle recommends it. 

Example
    Assume that the backups of the source database are stored in the directory. In this case, you can     make disk backups accessible to the destination host in either     of these ways:
    
    a. Manually transfer backups from the source host to an identical path in the destination host.

    if     the     backups are in the directory on the source host, 
    then 
        use FTP to transfer them to the directory on the destination host.
    end

    Use NFS or shared disks and ensure that the same path is accessible in the destination host. 
Example
    Assume that the source host can access the directory, use NFS to mount the         directory on the destination host and use as the mount point name.

Different file systems for source and destination hosts

    In this case you cannot use the same directory name on the destination host as you use on the source host. You have the     following options:

    Shared disk to make backups available. 

Note:

You cannot use shared disk to make backups available. 

    Making Disk Backups Accessible Without Shared Disk describes this technique.

    Assume that you have two hosts, srchost and dsthost, and access to NFS or shared disk. The database on srchost is         called srcdb. The backups of srcdb reside in the directory on host srchost. The directory          is in use on the destination host, but the directory is not in use on     either host.
    
    To transfer the backups from the source host to the destination host:

    i. Create a backup storage directory in either the source or destination host.

Example
    create backup directory on the destination host.
    Mount the directory created in the previous step on the other host, ensuring that the directory and the mount point     names are the same.

Example

    if      directory on the destination host
    then 
        use NFS to mount this directory as on the source host.
    end

    Make the backups available in the new location on the destination host. You can use either of the following techniques:

    i. Connect RMAN to the source database as TARGET and use the BACKUP command to back up the backups. 

    Example 
        use the BACKUP COPY OF DATABASE command to copy the backups in the  directory on the         source host to the directory on the destination host. 
        In this case, RMAN automatically catalogs the backups in the new location.

If     duplicating a PDB, 
then     use the PLUGGABLE DATABASE syntax of the BACKUP COPY OF command to copy only the backups of the PDB.
end

Use an operating system utility to transfer the backups to the new location. 

Example
    Use FTP to transfer the backups from the directory on the source host to the          directory on the destination host, 
    or 
    Use the cp command to copy the backups from the directory on the source host to the           directory on the destination host. 

Important:
    Afterward, connect RMAN to the source database as TARGET and use the CATALOG command to update the RMAN repository with     the location of the manually transferred backups