Skip Headers
Oracle® Database Backup and Recovery Reference
11g Release 1 (11.1)

B28273-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

DUPLICATE

Purpose

Use the DUPLICATE command to create a copy of a source database. RMAN can create either of the following types of databases:

RMAN can perform the duplication either directly from an open or mounted database or from pre-existing RMAN backups and copies.

See Also:

Additional Topics

Prerequisites

RMAN must be connected as TARGET to the source database, which is the database that is being copied. The source database must be mounted or open. The source database must not be a standby database.

RMAN must be connected as AUXILIARY to the instance of the duplicate database. The instance of the duplicate database is called the auxiliary instance. The auxiliary instance must be started with the NOMOUNT option.

The source and duplicate databases must be on the same platform. In the context of DUPLICATE, 32-bit and 64-bit versions of the same platform are considered the same platform. For example, Linux IA (32-bit) Little is considered the same platform as Linux IA (64-bit) Little. However, after duplicating a database between 32-bit and 64-bit platforms, you must run the utlirp.sql script to convert the PL/SQL code to the new format. This script is located in ORACLE_HOME/rdbms/admin on Linux and UNIX platforms.

The DUPLICATE command requires one or more configured or allocated auxiliary channels. These channels perform the work of the duplication on the auxiliary database instance. RMAN is connected as TARGET to the source database. In the following circumstances, RMAN uses the channel configuration from the source database for auxiliary channels:

If you have configured automatic target channels to use CONNECT strings, then RMAN attempts to use the same channel configuration for the channels on the auxiliary instance. It is recommended that you manually allocate auxiliary channels instead.

The source host is the database on which the source database resides. The destination host is the database on which you intend to create the duplicate database. If you intend to create the duplicate database on the source host, then set the CONTROL_FILES initialization parameter appropriately so that the DUPLICATE command does not generate an error because the source control file is in use. Also, set all *_DEST initialization parameters appropriately so that the source database files are not overwritten by the duplicate database files.

If the COMPATIBLE initialization parameter is set greater than or equal to 11.0.0, then by default RMAN duplicates transportable tablespaces that were not made read/write after being transported. Otherwise, RMAN cannot duplicate transportable tablespaces unless they have been made read/write after being transported.

Tablespace and Column Encryption

The following database encryption features both use the wallet: transparent data encryption, which functions at the column level, and tablespace encryption. Note the following restrictions:

See Also:

Oracle Database Advanced Security Administrator's Guide to learn about transparent data encryption

Prerequisites Specific to Backup-Based Duplication

When you execute DUPLICATE without FROM ACTIVE DATABASE, at least one auxiliary channel is required, but no normal channels are required in the source database.

When you duplicate the database from backups, all backups and archived redo logs used for creating and recovering the duplicate database must be accessible by the server session on the destination host. If the destination host is not the same as the source host, then you must make backups on disk on the source host available to the destination host with the same full path name as in the source database.

Prerequisites Specific to Active Database Duplication

When you connect RMAN to the source database as TARGET, you must specify a password, even if RMAN uses operating system authentication. The source database must be mounted or open. If the source database is open, then archiving must be enabled. If the source database is not open, and if it is not a standby database, then it must have been shut down consistently.

When you connect RMAN to the auxiliary database instance, you must provide a net service name. This requirement applies even if the auxiliary instance is on the local host.

The source database and auxiliary instances must use the same SYSDBA password, which means that both instances must already have password files. You can create the password file with a single password so you can start the auxiliary instance and enable the source database to connect to it.

The DUPLICATE behavior for password files varies depending on whether your duplicate database will act as a standby database. If you create a duplicate database that is not a standby database, then RMAN does not copy the password file by default. You can specify the PASSWORD FILE option to indicate that RMAN should overwrite the existing password file on the auxiliary instance. If you create a standby database, then RMAN copies the password file to the standby host by default, overwriting the existing password file. In this case, the PASSWORD FILE clause is not necessary.

When you execute DUPLICATE with FROM ACTIVE DATABASE, at least one normal target channel and at least one AUXILIARY channel are required. You cannot use the UNTIL clause when performing active database duplication. RMAN chooses a time based on when the online datafiles have been completely copied, so that the datafiles can be recovered to a consistent point in time.

See Also:

Oracle Database Security Guide to learn about password protection

Usage Notes

Active database duplication uses the auxiliary service name to copy the source database over the network to the auxiliary instance on the destination host, whereas backup-based duplication uses pre-existing RMAN backups and copies. Table 2-6 shows which files from the source database are duplicated.

Table 2-6 Duplicated Files

Source Database Files Active Database Backup-Based

Control files

Copied from source database when FOR STANDBY specified; otherwise re-created

Restored from backups when FOR STANDBY specified; otherwise re-created

Datafiles

Copied from source database (unless excluded with a SKIP option)

Restored from backups (unless excluded with a SKIP option)

Tempfiles

Re-created (see "Tempfile Re-Creation")

Re-created (see "Tempfile Re-Creation")

Online redo log files

Re-created

Re-created

Standby redo log files

Re-created when FOR STANDBY specified and defined on primary database

Re-created when FOR STANDBY specified and defined on primary database

Archived redo log files

Copied from source database, but only if needed for the duplication

Obtained from backups or cataloged copies, but only if needed for the duplication

Server parameter file

Copied from source database (see SPFILE clause in dupOptionList)

Restored from backup if SPFILE clause is specified (see dupOptionList)

Flashback log files

Not re-created

Not re-created

Block change tracking file

Not re-created

Not re-created

Password file

Copied by default for standby databases; for nonstandby databases, copied only if PASSWORD FILE option is specified

Not re-created

Backups and other files in flash recovery area

Not copied

Not copied


All datafiles are included in the duplicate database unless they are offline or excluded. You can exclude tablespaces by means of the SKIP clause, or by including only a subset of tablespaces with DUPLICATE ... TABLESPACE.

Note:

The recovery catalog only knows about current read-only tablespaces. If a tablespace is currently read/write, but you use UNTIL to duplicate the database to a past SCN at which a tablespace was read-only, then this tablespace is not included in the duplicate database. Tablespaces that were read-only in the past are considered offline tablespaces and so are not included in the duplication.

The flash recovery area is defined on the duplicate or standby database if you explicitly define it. Also, if a flash recovery was defined on the source database, and if the auxiliary instance uses a server parameter file that was copied or restored with the DUPLICATE command, then a flash recovery is defined on the duplicate or standby database.

If you use active database duplication, then see the FROM ACTIVE DATABASE description in dupsbyOptionList or dupOptionList for usage notes.

Backup-Based Duplication

In backup-based duplication of databases in NOARCHIVELOG mode, media recovery uses the NOREDO option. Thus, if incremental backups exist, RMAN applies only these incremental backups to the restored files during recovery. For backup-based duplication of databases in ARCHIVELOG mode, RMAN recovers by default up to the last archived redo log generated at the time the command was executed, or until a time specified with a SET UNTIL clause.

If you are using backup-based duplication, and if the source database and auxiliary instances reside on different hosts, then you must decide how to make the backups of the source database available to the auxiliary instance.

If the target database does not use a recovery area in ASM storage, then perform one of the following tasks before executing the DUPLICATE command:

If the source database uses a recovery area in ASM storage, then perform one of the following tasks before executing the DUPLICATE command:

Duplication with Oracle Managed Files

If the source database files are in the Oracle Managed Files (OMF) format, then you cannot use the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT initialization parameters or the fileNameConversionSpec clause to generate new OMF filenames for the duplicate database. OMF filenames are unique and generated by Oracle Database.

The only exception to this rule is when changing only an ASM disk group name. Assume that source datafiles and online redo log files are stored in ASM disk group +SOURCEDSK. You want to store the duplicate database files in ASM disk group +DUPDSK. In this case, you can set the initialization parameters as follows:

DB_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK")
LOG_FILE_NAME_CONVERT = ("+SOURCEDSK","+DUPDSK")

RMAN uses DB_FILE_NAME_CONVERT or LOG_FILE_NAME_CONVERT to convert the disk group name, and then generates a new, valid filename based on the converted disk group name.

You have the following other supported options for naming datafiles when the source files are in the Oracle Managed Files format:

Supported options for naming online redo logs duplicated from Oracle-managed files are DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST, or DB_CREATE_ONLINE_LOG_DEST_n.

Tempfile Re-Creation

When using DUPLICATE with Oracle-managed files, RMAN re-creates tempfiles in the current DB_CREATE_FILE_DEST, either when the database is opened to become a primary or when it is opened read-only. When not using Oracle-managed files, RMAN uses DB_FILE_NAME_CONVERT to convert the tempfile names for the new database. When the standby or duplicate database is opened in read-only or read/write mode, Oracle automatically creates temporary files as needed, with the converted names based upon DB_FILE_NAME_CONVERT. To specify different filenames for the tempfiles, see the discussion of SWITCH TEMPFILE .

Syntax

duplicate::=

Description of duplicate.gif follows
Description of the illustration duplicate.gif

(dupsbyOptionList::=, dupOptionList::=)

dupsbyOptionList::=

Description of dupsbyoptionlist.gif follows
Description of the illustration dupsbyoptionlist.gif

(fileNameConversionSpec::=, setParameter::=)

dupOptionList::=

Description of dupoptionlist.gif follows
Description of the illustration dupoptionlist.gif

(deviceSpecifier::=, fileNameConversionSpec::=, logSpec::=, setParameter::=, untilClause::=)

setParameter::=

Description of setparameter.gif follows
Description of the illustration setparameter.gif

logSpec::=

Description of logspec.gif follows
Description of the illustration logspec.gif

sizeSpec::=

Description of sizespec.gif follows
Description of the illustration sizespec.gif

Semantics

duplicate

This clause enables you to duplicate a database or tablespace. Refer to the duplicate::= diagram for the syntax.

Syntax Element Description
FOR STANDBY Specifies that database being duplicated is to be used as a standby database (see Example 2-75).

To create a standby database with the DUPLICATE command you must specify the FOR STANDBY option. The DUPLICATE ... FOR STANDBY command creates the standby database by restoring a standby control file and mounting the standby control file. If you specify FROM ACTIVE DATABASE, then RMAN copies the datafiles from the primary to standby database. Otherwise, RMAN restores backups of the source database datafiles to the standby database. RMAN restores the most recent files, unless SET UNTIL is specified.

If DORECOVER is specified, then RMAN also recovers the database. The standby database is left mounted after duplication is complete.

You cannot use SET NEWNAME or CONFIGURE AUXNAME to transform the filenames for the online redo logs on the standby database.

You cannot CONNECT RMAN to the standby database and then use DUPLICATE ... FOR STANDBY to create an additional standby database. To create additional standby databases, connect RMAN to the original primary database and run DUPLICATE ... FOR STANDBY.

Note: Although you can use the DUPLICATE command to create a standby database, you cannot use this command to activate a standby database.

When you connect RMAN to the standby database and the recovery catalog in which the primary database is already registered, RMAN recognizes the standby database and implicitly registers it. Do not attempt to use the REGISTER command for the standby database.

   dupsbyOptionList Specifies options that only apply when creating a standby database. See dupsbyOptionList.
TO database_name Specifies the name of the duplicate database. This duplicate database will not be a standby database.

If you do not specify the SPFILE clause, then the specified database name should match the name in the initialization parameter file of the duplicate database instance, which is the instance to which RMAN is connected as AUXILIARY. Otherwise, the database signals an error.

You cannot use the same database name for the source database and duplicate database when the duplicate database resides in the same Oracle home as the source database. However, if the duplicate database resides in a different Oracle home from the source database, then its database name just has to differ from other database names in its Oracle home. To simplify administration of duplicate database, Oracle recommends that you use different names for the source and duplicate databases.

   dupOptionList Specifies options that only apply when creating a duplicate database that is not a standby database. See dupOptionList.

dupsbyOptionList

This subclause specifies options that only apply when creating a standby database. Refer to the dupsbyOptionList::= diagram for the syntax.

Syntax Element Description
DORECOVER Specifies that RMAN should recover the standby database after creating it. If you specify an untilClause, then RMAN recovers to the specified SCN or time and leaves the database mounted.

RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode. After RMAN creates the standby database, you must resolve any gap sequence before placing it in manual or managed recovery mode, or opening it in read-only mode.

The checkpoint SCN of the control file must be included in an archived redo log that is either available at the standby site or included in an RMAN backup. For example, assume that you create the standby control file and then immediately afterward archive the current log, which has a sequence of 100. In this case, you must recover the standby database up to at least log sequence 100, or the database signals an ORA-1152 error message because the standby control file backup was taken after the point in time.

fileNameConversionSpec Specifies how to convert original datafile names to new datafile names in the standby database.

See Also: fileNameConversionSpec

FROM ACTIVE DATABASE Specifies that the files for the standby database should be provided directly from the source database and not from a backup of the source database (see Example 2-71).

See Also: "Prerequisites Specific to Active Database Duplication" for command prerequisites

NOFILENAMECHECK Prevents RMAN from checking whether datafiles of the source database share the same names as the standby database files that are in use.

The NOFILENAMECHECK option is required when the standby and primary datafiles and online redo logs have identical filenames (see Example 2-74). Thus, if you want the duplicate database filenames to be the same as the source database filenames, and if the databases are in different hosts, then you must specify NOFILENAMECHECK.

See Also: The description of NOFILENAMECHECK in dupOptionList

SPFILE Copies the server parameter file from the source database to the operating system-specific default location for this file on the standby database.

RMAN uses the server parameter file to start the auxiliary instance for standby database creation. Any remaining options of the DUPLICATE command are processed after the database instance is started with the server parameter file.

If you execute DUPLICATE with the SPFILE clause, then the auxiliary instance must already be started with a text-based initialization parameter file. In this case, the only required parameter in the temporary initialization parameter file is DB_NAME, which can be set to any arbitrary value. RMAN copies the binary server parameter file, modifies the parameters based on the settings in the SPFILE clause, and then restarts the standby instance with the server parameter file. When you specify SPFILE, RMAN never uses the temporary text-based initialization parameter file to start the instance.

If FROM ACTIVE DATABASE is specified on DUPLICATE, then a server parameter file must be in use by the source database instance. If FROM ACTIVE DATABASE is not specified on DUPLICATE, then RMAN restores a backup of the server parameter file to the standby database.

See Also: Example 2-70 and Example 2-71 for examples of SPFILE usage

   setParameter Sets the specified initialization parameters to the specified values. Refer to setParameter.

   PARAMETER_VALUE_CONVERT
   string_pattern
   [setParameter]
Replaces the first string with the second string in all matching initialization parameter values. Note that DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT are exceptions to this rule and are not affected.

You can use PARAMETER_VALUE_CONVERT to set a collection of initialization parameter values and avoid explicitly setting them all. For example, if the source database uses disk group +ALPHA while the standby database will use +BETA, then you could modify all parameters that refer to these disk groups by specifying SPFILE PARAMETER_VALUE_CONVERT ('+ALHPA','+BETA').

Note: Parameter values are case-sensitive in PARAMETER_VALUE_CONVERT even though the same values may not be case-sensitive when setting them directly in an initialization parameter file or server parameter file.


dupOptionList

This subclause includes options that control aspects of the duplication such as naming the files and determining an end point for the duplication. Refer to the dupOptionList::= diagram for the syntax.

Note:

Several options in this clause are identical to options in the dupsbyOptionList. Descriptions of these options are not repeated here.

Specify new filenames or convert source database filenames for the datafiles and online redo logs when the filenames of the duplicate database must be different from the filenames of the source database (as when the destination host and source host are the same). If you do not specify filenames for the online redo logs and datafiles of the duplicate database, then RMAN uses the datafile names from the source database.

Syntax Element Description
DEVICE TYPE deviceSpecifier Allocates automatic channels for the specified device only (for example, DISK or sbt).

This option is valid only if you have configured automatic channels and have not manually allocated channels. For example, if you CONFIGURE automatic disk and tape channels, and if you run DUPLICATE...DEVICE TYPE DISK, then RMAN allocates only disk channels.

See Also: deviceSpecifier

fileNameConversionSpec Specifies one or more patterns to map source database filenames to duplicate database filenames (see Example 2-72).

DB_FILE_NAME_CONVERT set on the DUPLICATE command overrides the initialization parameter DB_FILE_NAME_CONVERT (if set). For example, if the initialization parameter file setting is DB_FILE_NAME_CONVERT=('disk1','disk2'), but you execute DUPLICATE ... DB_FILE_NAME_CONVERT ('disk1','disk3'), then RMAN does not convert the disk1 substring to disk2. Instead, RMAN converts the disk1 substring to disk3.

If a file in the specification list is not affected by the conversion parameter in DUPLICATE, then you must rename it by other means, such as SET NEWNAME.

Note: If you specify the SPFILE clause, then DUPLICATE ... DB_FILE_NAME_CONVERT overrides any conversion parameter specified in the SPFILE syntax. For example, if you specify DB_FILE_NAME_CONVERT twice in the DUPLICATE command, both in the SPFILE clause and outside of the SPFILE clause, then the setting outside of the SPFILE clause takes precedence.

See Also: fileNameConversionSpec

FROM ACTIVE DATABASE Specifies that the files for the duplicate database should be provided directly from the source database and not from a backup of the source database (see Example 2-70). If you do not specify an UNTIL time, then RMAN chooses an end time for the duplication based on when the online datafiles are copied.

See Also: "Prerequisites Specific to Active Database Duplication" for command prerequisites

LOGFILE Specifies options for creating online redo logs when creating a duplicate database that is not a standby database (see Example 2-72).
   INSTANCE 'inst_name' Creates online redo logs for the specified instance in a Real Applications Cluster (Oracle RAC) database. The instance name is a string of up to 80 characters.

RMAN automatically uses the thread mapped to the specified instance. If no INSTANCE name is specified, then the log files are for the default instance.

This clause is relevant when you use DUPLICATE TARGET DATABASE to duplicate an Oracle RAC database to a single-instance database. Otherwise, you do not need to use INSTANCE. If you use the LOGFILE clause, then use INSTANCE to specify the name of the RAC instance for each thread that was open during the database backup (for backup-based duplication) or during the UNTIL TIME (for active database duplication).

   logSpec Specifies the filenames and groups for the online redo log files.

See Also: logSpec for the valid options

NOFILENAMECHECK Prevents RMAN from checking whether the datafiles and online redo logs files of the source database are in use when the source database files share the same names as the duplicate database files (see Example 2-73). You are responsible for determining that the duplicate operation will not overwrite useful data.

This option is necessary when you are creating a duplicate database in a different host that has the same disk configuration, directory structure, and filenames as the host of the source database. For example, assume that you have a small database located in the /dbs directory of host1:

/oracle/dbs/system_prod1.dbf
/oracle/dbs/users_prod1.dbf
/oracle/dbs/rbs_prod1.dbf

Assume that you want to duplicate this database to host2, which has the same file system /oracle/dbs/*, and you want to use the same filenames in the duplicate database as in the source database. In this case, specify the NOFILENAMECHECK option to avoid an error message. Because RMAN is not aware of the different hosts, RMAN cannot determine automatically that it should not check the filenames.

If duplicating a database on the same host as the source database, then make sure that NOFILENAMECHECK is not set. Otherwise, RMAN may signal the following error:

RMAN-10035: exception raised in RPC: ORA-19504: failed to create 
            file "/oracle/dbs/tbs_01.f" 
ORA-27086: skgfglk: unable to lock file - already in use 
SVR4 Error: 11: Resource temporarily unavailable 
Additional information: 8 
RMAN-10031: ORA-19624 occurred during call to 
DBMS_BACKUP_RESTORE.RESTOREBACKUPPIECE
OPEN RESTRICTED Enables a restricted session in the duplicate database by issuing the following SQL statement: ALTER SYSTEM ENABLE RESTRICTED SESSION. RMAN issues this statement immediately before the duplicate database is opened.
PASSWORD FILE Specifies that RMAN should use the password file on the source database to overwrite the password file currently used by the auxiliary instance (see Example 2-70). This option is only valid when FROM ACTIVE DATABASE is specified; otherwise, RMAN signals an error.

If FOR STANDBY is specified, then RMAN copies the password file by default; if not specified, then RMAN does not copy the password file by default. You can use PASSWORD FILE to request that RMAN overwrite the existing password file with the password file from the source database. If you want the duplicate database to contain all the passwords available on your production database, then use the PASSWORD FILE option.

PFILE filename Specifies a text-based initialization parameter file used by the auxiliary instance (see Example 2-72). RMAN automatically shuts down and restarts the auxiliary instance during duplication. If the auxiliary does not use a server parameter file in the default location, then you must specify the text-based initialization parameter file that RMAN should use when starting the auxiliary instance. The initialization parameter file must reside on the same host as the RMAN client used to perform the duplication.

If the auxiliary instance uses a server parameter file in the default location, then you do not need to specify PFILE.

SKIP READONLY Excludes datafiles in current read-only tablespaces from the duplicate database (see Example 2-73). By default RMAN duplicates current read-only tablespaces.

If a tablespace is currently read/write, but you use untilClause to duplicate the database to an SCN at which the tablespace was read-only, then RMAN does not include the tablespace in the duplicate database. Tablespaces that were read-only in the past are considered offline tablespaces and so are not included in the duplication.

Note: A record for the skipped read-only tablespace still appears in DBA_TABLESPACES. By using this feature, you can activate the read-only tablespace later. For example, you can store the read-only tablespace data on a writable DVD, then mount the DVD later and view the data.

SKIP TABLESPACE tbs_name Excludes the specified tablespace from the duplicate database (see Example 2-72). Note that you cannot exclude the SYSTEM tablespace, SYSAUX tablespace, undo tablespaces, and tablespaces with rollback segments.

If you need to duplicate a database when some backups of the source database do not exist, then SKIP TABLESPACE is required. If you do not specify SKIP TABLESPACE, then RMAN attempts to duplicate the following:

  • All datafiles in online tablespaces, whether or not the datafiles are online.

  • All tablespaces taken offline with an option other than NORMAL. For example, RMAN attempts to duplicate tablespaces taken offline with the IMMEDIATE option. You cannot duplicate OFFLINE NORMAL tablespaces, although you can add these tablespaces manually after duplication.

  • If no valid backups exist of any tablespace or datafile, then the DUPLICATE command fails.

RMAN does not check for completeness. For example, you can duplicate a data tablespace but not the tablespace containing the index for the data, or duplicate a tablespace that contains only one partition of a partitioned table.

SPFILE Copies the server parameter file from the source database to the duplicate database. Refer to the description of SPFILE in dupsbyOptionList.
   setParameter Sets the specified initialization parameters to the specified values. Refer to setParameter.

   PARAMETER_VALUE_CONVERT
   string_pattern
   [setParameter]
Replaces the first string with the second string in all matching initialization parameter values. Refer to the description of PARAMETER_VALUE_CONVERT in dupsbyOptionList.
TABLESPACE tablespace_name Specifies which tablespaces should be included in the specified database. Unlike SKIP TABLESPACE, which specifies which tablespaces should be excluded from the duplicate database, this option specified which tablespaces should be included and then skips the remaining tablespaces.

Note: RMAN automatically includes the SYSTEM, SYSAUX, and undo tablespaces in the duplicate database: these tablespaces cannot be skipped.


TO RESTORE POINT
restore_point_name
Specifies a restore point for backup-based duplication, with the SCN at which the restore point was created as the upper, inclusive limit. Because the limit is inclusive, RMAN selects only files that can be used to duplicate a database up to and including the corresponding SCN.

Note: The same restrictions that apply to untilClause also apply to TO RESTORE POINT.

untilClause Sets the end time, SCN, or log sequence number for point-in-time recovery in backup-based duplication (see Example 2-72). The UNTIL clause is not supported in active database duplication.

You can achieve the same result by running SET UNTIL before the DUPLICATE command. If you specify the UNTIL clause for duplication, then the following restrictions apply:

  • RMAN determines whether to use NOREDO based on the current state of the database. If the database was in an archiving mode at the specified UNTIL time or SCN that is different from the current archiving mode, then RMAN does not use NOREDO.

  • If a tablespace was read-only at the time of the duplication, then RMAN does not include it even if SKIP READONLY was not used.

  • The end point for a DUPLICATE command cannot be before the SCN of the most recent ALTER DATABASE OPEN RESETLOGS. Duplication to previous database incarnations is not supported.

  • You cannot recover the duplicate database to the current point in time, that is, the most recent SCN. RMAN recovers the duplicate database up to or before the most recent available archived log, but cannot recover into the online redo logs.

See Also: untilClause


setParameter

This subclause specifies server parameter file values.

Syntax Element Description
SET identifier string Sets the specified initialization parameters to the specified values (see Example 2-71). You can use SET to adjust for differences in memory, turn off replication options, and set other options for the duplicate database.

This SET functionality is equivalent to pausing the duplication after restoring the server parameter file and issuing ALTER SYSTEM SET statements to change the initialization parameter file.

RMAN processes SET after PARAMETER_VALUE_CONVERT. If PARAMETER_VALUE_CONVERT sets the filename specified by a parameter, and if SET sets the filename specified by the same parameter, then the SET value overrides the PARAMETER_VALUE_CONVERT setting.

Note: If DB_FILE_NAME_CONVERT is specified on the DUPLICATE command, then its filename settings override competing settings specified by SPFILE SET.

   COMMENT 'string' Specifies an optional comment for the parameter setting.

logSpec

This subclause specifies the online redo logs when creating a duplicate database that is not a standby database. Refer to the logSpec::= diagram for the syntax diagram.

If you do not specify LOGFILE, then RMAN uses LOG_FILE_NAME_CONVERT if it is set. If neither LOGFILE nor LOG_FILE_NAME_CONVERT is set, then RMAN uses the original redo log filenames of the source database for redo log files of the duplicate database. You must specify the NOFILENAMECHECK option in this case.

Syntax Element Description
'filename' SIZE sizeSpec Specifies the filename of the online redo log member and the size of the file in kilobytes (K) or megabytes (M). The default is in bytes.
   REUSE Allows the database to reuse an existing file. If the file already exists, then the database verifies that its size matches the value of the SIZE parameter. If the file does not exist, then it is created.

GROUP integer
('filename', ...)
SIZE sizeSpec
Specifies the group containing the online redo log members, the filename of the online redo log member, and the size of the file in kilobytes (K) or megabytes (M). The default is in bytes.
   REUSE Allows the database to reuse an existing log.

Examples

Example 2-70 Duplicating from an Active Database

Assume that you want to create a test database from database prod1 on a new host. The new host has the same directory structure as the source host, so the files in the duplicate database can use the same names as the files in the source database. You want to create the database without using RMAN backups and allow prod1 to remain open during the duplication.

If prod1 uses a server parameter file, then you can create an initialization parameter file on the destination host that contains only the DB_NAME parameter set to an arbitrary value. Before starting the auxiliary instance you should create a password file that has the same SYSDBA password as the source database. Afterward, start the auxiliary instance.

By default, RMAN does not duplicate the password file when creating a duplicate database that is not a standby database. The PASSWORD FILE option specifies that RMAN should copy the password file to the destination host. If you want the duplicate database to contain all the passwords available on your source database, then use the PASSWORD FILE option.

You do not need to configure auxiliary channels because RMAN uses the normal channels configured on the source database to copy the database files. Start the RMAN client, connect to the source and auxiliary database instances, and duplicate the database as follows:

% rman
RMAN> CONNECT TARGET SYS@prod1

target database Password: password
connected to target database: PROD1 (DBID=39525561)

RMAN> CONNECT AUXILIARY SYS@dup1

auxiliary database Password: password
connected to auxiliary database: DUP1 (not mounted)

RMAN> DUPLICATE TARGET DATABASE TO dup1
2> FROM ACTIVE DATABASE
3> PASSWORD FILE
4> SPFILE;

Example 2-71 Copying the Server Parameter File in Active Database Duplication

Assume that you want to create a standby database from database prod1 on a new host. The destination host has a different directory structure from the source host, so the standby database files will be stored in /disk2 rather than /disk1. You want to create the standby database without using RMAN backups and let prod1 remain open during the duplication.

Your first step is to create a minimal initialization parameter file for the standby database and then start the standby instance. This parameter file is minimal because when you use the SPFILE option, RMAN copies the server parameter file to the new host and sets various parameters to the new values provided.

Start the RMAN client, CONNECT to the source database as TARGET, and connect to the auxiliary instance. You do not need to configure auxiliary channels because RMAN uses the normal channels on the source host to copy the database files. You can then enter the following command:

DUPLICATE TARGET DATABASE TO dup1
  FOR STANDBY
  FROM ACTIVE DATABASE
  PASSWORD FILE
  SPFILE 
    PARAMETER_VALUE_CONVERT '/disk1', '/disk2'
    SET DB_FILE_NAME_CONVERT '/disk1','/disk2'
    SET LOG_FILE_NAME_CONVERT '/disk1','/disk2'
    SET SGA_MAX_SIZE 200M
    SET SGA_TARGET 125M;

Example 2-72 Setting New Filenames Manually for Duplication

Assume that you want to duplicate the source database on host1 to newdb on host2.

In this scenario, your source database does not use a server parameter file. You create a text-based initialization parameter file on host2 and start the instance.

When executing DUPLICATE on host2, you must use the PFILE parameter to specify the location of the initialization parameter file. Note that you must use the RMAN client on the same host as the initialization parameter file for the duplicate database.

You do not want the tablespaces example and history to be included in the duplicate database, so you specify DUPLICATE ... SKIP TABLESPACE for these tablespaces. Also, you want the duplicate database to be in the state that the production database was in 24 hours ago, so you use DUPLICATE ... UNTIL TIME.

This example assumes that the datafiles of the source database are on host1 in directory /h1/oracle/dbs/trgt. You want to duplicate the datafiles to the directory /h2/oracle/oradata/newdb, so you specify DUPLICATE ... DB_FILE_NAME_CONVERT generate the names for the duplicate datafiles. You use DUPLICATE ... LOGFILE to specify names for the online redo log files in the duplicate database.

Start the RMAN client on host2, CONNECT to the source database as TARGET, and connect to the auxiliary instance. You can then enter the following RUN command:

RUN
{  
  ALLOCATE AUXILIARY CHANNEL newdb DEVICE TYPE sbt; 
  DUPLICATE TARGET DATABASE TO newdb
    PFILE ?/dbs/initNEWDB.ora
    UNTIL TIME 'SYSDATE-1'  # specifies incomplete recovery
    SKIP TABLESPACE example, history   # skip desired tablespaces
    DB_FILE_NAME_CONVERT ('/h1/oracle/dbs/trgt/','/h2/oracle/oradata/newdb/')
    LOGFILE
      GROUP 1 ('?/oradata/newdb/redo01_1.f',
               '?/oradata/newdb/redo01_2.f') SIZE 4M,
      GROUP 2 ('?/oradata/newdb/redo02_1.f',
               '?/oradata/newdb/redo02_2.f') SIZE 4M,
      GROUP 3 ('?/oradata/newdb/redo03_1.f',
               '?/oradata/newdb/redo03_2.f') SIZE 4M REUSE;
}

Example 2-73 Using the Source Database Filenames for the Duplicate Database

Assume that you want to use RMAN backups to create a duplicate database for testing. The following conditions apply:

  • You are restoring to a destination host that is different from the source host.

  • RMAN is not connected to a recovery catalog.

  • You have configured automatic channels.

  • The source host and destination host have the same file structure.

  • You want to name the duplicate database files exactly like the source database files.

  • You do not want to duplicate read-only tablespaces.

  • You want to prevent RMAN from checking whether files on the source database are in use if these files have the same names as the duplicate database files.

Start the RMAN client, CONNECT to the source database as TARGET, and connect to the auxiliary instance. You can then enter the following command:

DUPLICATE TARGET DATABASE TO ndbnewh 
  LOGFILE 
    '?/dbs/log_1.f' SIZE 4M,
    '?/dbs/log_2.f' SIZE 4M
  SKIP READONLY
  NOFILENAMECHECK;

Example 2-74 Creating a Standby Database with the Same Directory Structure

Assume that you want to use RMAN backups to create a standby database on a remote host with the same directory structure as the source host. The source database is called prod1 and will be the primary database in the Data Guard environment.

First, start the RMAN client, CONNECT to the source database prod1 as TARGET, and connect to the auxiliary instance. You can then CONFIGURE the default device type to sbt for a standby database with the DB_UNIQUE_NAME of standby1:

CONFIGURE DEFAULT DEVICE TYPE sbt FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2 FOR DB_UNIQUE_NAME standby1;

Assume all backups needed to create the standby database are on tape. In the standby database initialization parameter file, you set DB_UNIQUE_NAME to standby1.

The default initialization parameter file location is in use on the standby database. After starting the standby instance NOMOUNT, you start the RMAN client, CONNECT to the source database as TARGET, and connect to the auxiliary instance and recovery catalog. You run the following DUPLICATE command, specifying the NOFILENAMECHECK option because the standby and primary datafiles and online redo log files have the same names:

DUPLICATE TARGET DATABASE FOR STANDBY
  NOFILENAMECHECK;

Example 2-75 Creating a Standby Database in OMF and ASM

Assume that you want to use RMAN backups to create a standby database on a host that uses OMF and ASM. The source database is called prod1 and will be the primary database in the Data Guard environment.

First, start the RMAN client, CONNECT to database prod1 as TARGET, and connect to the recovery catalog. Run the following commands to CONFIGURE the default device type to sbt for a standby database that will have the DB_UNIQUE_NAME of standby1 and the net service name sby1.

CONFIGURE CONNECT IDENTIFIER "sby1" FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEFAULT DEVICE TYPE TO sbt FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2 FOR DB_UNIQUE_NAME standby1;

Assume all backups needed to create the standby database are stored on tape. You set the following parameters in the initialization parameter file for database standby1:

  • Set DB_UNIQUE_NAME to the value standby1.

  • Se DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST to the desired ASM disk groups on the standby host. For example, set DB_CREATE_FILE_DEST to +DATAFILE and DB_RECOVERY_FILE_DEST to +FLASH_REC_AREA.

Ensure that the standby instance is in NOMOUNT mode. Start the RMAN client, CONNECT to database prod1 as TARGET, connect to the standby1 instance as AUXILIARY, and connect to the recovery catalog. Enter the following command to create the standby database:

DUPLICATE TARGET DATABASE FOR STANDBY TO standby1;

RMAN automatically generates new OMF/ASM datafile names for the restored datafiles. The new database name and file names will be automatically resynchronized with the recovery catalog.