DUPLICATE

Purpose

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

• A duplicate database, which is a copy of the source database (or a subset of the source database) with a unique DBID. Because a duplicate database has a unique DBID, it is independent of the source database and can be registered in the same recovery catalog. Typically, duplicate databases are used for testing.

• A standby database, which is a special copy of the source database (called a primary database in a Data Guard environment) that is updated by applying archived redo logs from the primary database. A standby database does not get a new DBID.

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

Additional Topics

• Prerequisites

• Usage Notes

• Syntax

• Semantics

• Examples

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:

• You have not used ALLOCATE CHANNEL to manually allocate auxiliary channels.

• You have not used CONFIGURE to configure 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:

• If you are duplicating an encrypted tablespace, then you must manually copy the wallet to the duplicate database.

• If the duplicate database has an existing wallet, then you cannot copy the wallet from the source database to the duplicate database. Thus, you cannot transport encrypted data to a database that already has a wallet. If you encrypt columns with transparent data encryption, then you can export them into an export file that is password-protected and import the data into the duplicate database.

• You cannot duplicate an encrypted tablespace across platforms with different endianism.

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 execute DUPLICATE with FROM ACTIVE DATABASE, at least one normal target channel and at least one AUXILIARY channel are required.

When connecting to the auxiliary 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.

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.

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.

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.

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.

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 you are using SBT backups, then make the tapes with the backups accessible to the destination host.

• If you are using disk backups, and if you can use the same backup directory names on the destination host as the source host, then do one of the following:

  • Manually transfer the backups and copies from the source host to the destination host to an identical path.

  • Use NFS or shared disks and make sure that the same path is accessible in the destination host.

• If you are using disk backups, and if you cannot use the same backup directory names on the destination host as the source host, then use of the techniques described in Oracle Database Backup and Recovery User's Guide.

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

• Make a database backup to a location outside the flash recovery area. You can make this backup accessible in the following ways:

  • Use NFS to mount the backup on the destination host with the same name.

  • Use NFS to mount the backup on the destination host with a different name, and then CATALOG the backup while RMAN is connected as TARGET to the source database.

• Back up the flash recovery area to tape and use it for duplication.

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:

• Use SET NEWNAME to specify names for individual datafiles.

• Set DB_FILE_CREATE_DEST to make all datafiles of the new database Oracle-managed files, with the exception of the files for which SET NEWNAME is used. You should not set DB_FILE_NAME_CONVERT if you set DB_FILE_CREATE_DEST.

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

(dupsbyOptionList::=, dupOptionList::=)

dupsbyOptionList::=

(fileNameConversionSpec::=, setParameter::=)

dupOptionList::=

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

setParameter::=

logSpec::=

sizeSpec::=

Semantics

duplicate

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

dupsbyOptionList

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

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.

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.

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

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

setParameter

This subclause specifies server parameter file values.

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.

Examples

CONNECT TARGET SYS/password@prod1    # source database
CONNECT AUXILIARY SYS/password@dup1  # duplicate database instance
DUPLICATE TARGET DATABASE TO dup1
  FROM ACTIVE DATABASE
  PASSWORD FILE
  SPFILE;

CONNECT TARGET SYS/password@prod1   # source database
CONNECT AUXILIARY SYS/password@dup1 # duplicate database instance
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;

CONNECT TARGET SYS/password@prod1    # source database
CONNECT AUXILIARY SYS/password@newdb # duplicate database instance
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;
}

CONNECT TARGET                          # source database
CONNECT AUXILIARY SYS/password@newdb    # duplicate databvavse instance
DUPLICATE TARGET DATABASE TO ndbnewh 
  LOGFILE 
    '?/dbs/log_1.f' SIZE 4M,
    '?/dbs/log_2.f' SIZE 4M
  SKIP READONLY
  NOFILENAMECHECK;

CONNECT TARGET SYS/password@prod1
CONNECT CATALOG rman/password@catdb
CONFIGURE DEFAULT DEVICE TYPE sbt FOR DB_UNIQUE_NAME standby1;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2 FOR DB_UNIQUE_NAME standby1;

CONNECT TARGET SYS/password@prod1         # source database
CONNECT CATALOG rman/password@catdb       # recovery catalog database
CONNECT AUXILIARY SYS/password@standby1   # standby database instance
DUPLICATE TARGET DATABASE FOR STANDBY
  NOFILENAMECHECK;

CONNECT TARGET SYS/password@prod1
CONNECT CATALOG rman/password@catdb
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;

CONNECT TARGET SYS/password@prod1
CONNECT CATALOG rman/password@catdb
CONNECT AUXILIARY SYS/password@standby1
DUPLICATE TARGET DATABASE FOR STANDBY TO standby1;