RMAN Choosing A Duplication Technique
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,
the effect on the network is unacceptable,
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.
this is not a requirement
3. Is a recovery catalog available?
If a recovery catalog exists
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.
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.
if the source database is 1 terabyte (TB),
(duplicate the database from disk backups without using shared disk or network file system (NFS))
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.
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
backup-based duplication may be the only viable option
5. When do you plan to duplicate the database?
If you must duplicate the database during a period of high user activity
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.
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,
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 (SET NEWNAME or CONFIGURE AUXNAME)
use caution while specifing the file names for the duplicate database,
you may mistakenly overwrite the source database files
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
the duplicate database must use ASM disk groups with the same names.
If the source database files are Oracle Managed Files (OMF),
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.
If the names of the database files in the source database contain a path,
this path name must be the same in the duplicate database.
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
the source host and the destination host use different directory structures
use the same directory structures but you want to name the database files differently
you must specify how RMAN should generate names for the duplicate database files.
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
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.
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.
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.
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
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.
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:
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.
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.
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.
If performing active database duplication,
this step is not necessary.
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
perform backup-based duplication with a target connection
RMAN obtains metadata from the control file.
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.
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)
you must designate a backup location for the duplication by using the BACKUP LOCATION clause
using a backup location the backups and copies can reside in a shared location
can be moved to the location on the destination host
(do not need to preserve the name or the original path of the backup or copy).
The location specified in the BACKUP LOCATION option must contain sufficient
that location must contain
i. backup sets,
ii. image copies, and
iii. archived logs to restore all of the files that are being duplicated,
recover them to the desired point in time.
the database is to be open with RESETLOGS option only.
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.
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,
the DATABASE clause must specify the name of the database that is to be duplicated.
If the backup location contains backup files from multiple databases having the same name,
the DATABASE clause must specify both the name and DBID of the database that is to be duplicated.
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.
Assume that the backups of the source database are stored in the
a. Manually transfer backups from the source host to an identical path in the destination host.
if the backups are in the
use FTP to transfer them to the
Use NFS or shared disks and ensure that the same path is accessible in the destination host.
Assume that the source host can access the
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.
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
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.
create backup directory
Mount the directory created in the previous step on the other host, ensuring that the directory and the mount point names are the same.
use NFS to mount this directory as
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.
use the BACKUP COPY OF DATABASE command to copy the backups in the
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.
Use an operating system utility to transfer the backups to the new location.
Use FTP to transfer the backups from the
Use the cp command to copy the backups from the
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