Creating a Duplicate Database: Overview

You can use the RMAN DUPLICATE command to create a duplicate database from backups of the target database (primary database) while retaining the original target database. The duplicate database can be identical to the target database or contain only a subset of the tablespaces in the target database. The target site and the duplicate site can be on separate hosts or on the same host.

A duplicate database is a copy of a target database that you can run independently for a variety of purposes. For example, you can use it to:

Test backup and recovery procedures
Export data such as a table that was inadvertently dropped from the production database, and then import it back into the production database

For example, you can duplicate the production database on host1 to host2, and then use the duplicate database on host2 to practice restore and recovery scenarios while the production database on host1 continues as usual.

A duplicate database is distinct from a standby database, although both types of databases are created with the DUPLICATE command. A standby database is a copy of the primary database that you can update continually or periodically with archived logs from the primary database. If the primary database is damaged or destroyed, then you can perform failover to the standby database and transform it into the new primary database. A duplicate database, on the other hand, cannot be used in this way: it is not intended for failover scenarios and does not support the various standby recovery and failover options.

How Recovery Manager Duplicates a Database

To prepare for database duplication, first create an auxiliary instance as described in "Preparing the Auxiliary Instance for Duplication: Basic Steps". For the duplication to work, you must connect RMAN to both the target (primary) database and an auxiliary instance started in NOMOUNT mode.

Allocate at least one auxiliary channel on the auxiliary instance. The principal work of the duplication is performed by the auxiliary channel, which starts a server session on the duplicate host. This channel then restores the necessary backups of the primary database, uses them to create the duplicate database, and initiates recovery.

So long as RMAN is able to connect to the primary and auxiliary instances, the RMAN client can run on any host. All backups and archived redo logs used for creating and recovering the duplicate database, however, must be accessible by the server session on the duplicate host. If the duplicate host is not the same as the target host, then you must make backups on disk on the target host available to the duplicate host with the same full path name as in the primary database.

When using disk backups, you can accomplish this goal in any of the following ways:

Manually transfer the backups from the primary host to the remote host to an identical path. For example, if the backups are in /dsk1/bkp on the target host, then transfer them to /dsk1/bkp on the duplicate host.
Manually transfer the backups from the primary host to the duplicate host at a new location. For example, if the backups are in /dsk1/bkp on the target host, then you might transfer them to /dsk2/dup on the duplicate host. The new path—in this example, /dsk2/dup—must be accessible from both the target and duplicate hosts. Run the CATALOG command to add these copies to the RMAN repository at the duplicate host.
Use NFS or shared disks and make sure that the same path is accessible in the remote host. For example, the NFS mount point for both hosts could be /home/file_server.

When using tape backups, you must make the tapes containing the backups accessible to the remote node. You can achieve this goal by physically moving the tape to a drive attached to the remote host or by means of a network-accessible tape server.

As part of the duplicating operation, RMAN automates the following steps:

Creates a control file for the duplicate database
Restores the target datafiles to the duplicate database and performs incomplete recovery by using all available incremental backups and archived redo logs
Shuts down and starts the auxiliary instance (refer to "Task 4: Start the Auxiliary Instance" for issues relating to client-side versus server-side initialization parameter files)
Opens the duplicate database with the RESETLOGS option after incomplete recovery to create the online redo logs (except when running DUPLICATE ... FOR STANDBY, in which case RMAN does not open the database)
Generates a new, unique DBID for the duplicate database (except when you create a standby database with DUPLICATE ... FOR STANDBY, in which case RMAN does not create a unique DBID)

During duplication, RMAN must perform incomplete recovery because the online redo logs in the target are not backed up and cannot be applied to the duplicate database. The farthest that RMAN can go in recovery of the duplicate database is the most recent redo log archived by the target database.

Database Duplication Options

When duplicating a database, you have the following options:

You can run the DUPLICATE command with or without a recovery catalog.
You can skip read-only tablespaces with the SKIP READONLY clause. Read-only tablespaces are included by default. If you omit them, then you can add them later.
You can exclude tablespaces from the duplicate database with the SKIP TABLESPACE clause. You can exclude any tablespace except the SYSTEM tablespace or tablespaces containing rollback or undo segments.
You can create the duplicate database in a new host. If the directory structure is the same on the new host, then you can specify the NOFILENAMECHECK option and reuse the target datafile filenames for the duplicate datafiles.
You can duplicate a target database stored on a traditional file system to an ASM or Oracle Managed Files location.
By default, the DUPLICATE command creates the duplicate database from the most recent backups of the target database and then performs recovery to the most recent consistent point contained in the archived redo logs. You can duplicate a database as it stood at a past point in time in the current incarnation, by using a RUN block with a SET UNTIL command, or by including an UNTIL clause with the DUPLICATE command to cause RMAN to recover the duplicate database to a past point in time within the current incarnation. (You cannot, however, use DUPLICATE with a point in time in an earlier incarnation.)

You can register the duplicate database in the same recovery catalog as the target database. This option is possible because RMAN gives the duplicate database a new, unique DBID during duplication.

Note:

If you copy the target database by means of operating system utilities, then the DBID of the copied database remains the same as the original database. To register the copy database in the same recovery catalog with the original, you must change the DBID with the DBNEWID utility (refer to Oracle Database Utilities).

In some cases, you can set the duplicate database DB_NAME differently from the target database DB_NAME. More specifically, if the duplicate database exists in the same Oracle home as the target, then the DB_NAME initialization parameter must be different. If the duplicate database is in a different Oracle home from the target database, then the DB_NAME setting for the duplicate database must be unique among databases in its Oracle home. This is true whether or not the duplicate database is on the same host as the target.

Duplicating a Database: Prerequisites and Restrictions

Duplicating a database with RMAN involves a number of prerequisites and restrictions. Review the restrictions section of the DUPLICATE command in the Oracle Database Backup and Recovery Reference for a complete list.