13 Creating and Updating Duplicate Databases with RMAN

How Recovery Manager Duplicates a Database

To prepare for database duplication, first create an auxiliary instance as described in "Preparing the RMAN DUPLICATE Auxiliary Instance: 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.

RMAN DUPLICATE DATABASE: 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.

RMAN DUPLICATE 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.

Renaming Control Files in RMAN DUPLICATE DATABASE

The rules of precedence for determining the names for the duplicate database control files are the same used by the SQL statement CREATE CONTROLFILE. When choosing names for the duplicate control files, make sure you set the parameters in the initialization parameter file of the auxiliary database correctly; otherwise, you could overwrite the control files of the target database.

Renaming Online Logs in RMAN DUPLICATE DATABASE

RMAN needs new names for the online redo log files of the duplicate database. Either you can specify the names explicitly in the DUPLICATE command, or you can let RMAN generate them according to the rules listed in Table 13-1.

Rules higher in the order of precedence override rules lower in the list. For example, if you specify both the LOGFILE clause and the LOG_FILE_NAME_CONVERT parameter, then RMAN uses the LOGFILE clause.

Renaming Datafiles in RMAN DUPLICATE DATABASE

There are several means of specifying new names to be used for the datafiles of your duplicate database. Listed in order of precedence, they are:

If you do not use any of the preceding options, then the duplicate database reuses the original datafile locations from the target database.

RUN
{
  SET NEWNAME FOR DATAFILE 1 TO /oracle/data/file2.f; # rename df 1 as file2.f
  SET NEWNAME FOR DATAFILE 2 TO /oracle/data/file1.f; # rename df 2 as file1.f
  DUPLICATE TARGET DATABASE TO newdb;
} 

Renaming Tempfiles in RMAN DUPLICATE DATABASE

RMAN re-creates datafiles for temporary tablespaces as part of the process of duplicating a database. There are several means of specifying locations for duplicate database tempfiles. Listed in order of precedence, they are:

Skipping Read-Only Tablespaces When Duplicating a Database

When you specify SKIP READONLY, RMAN does not duplicate the datafiles of read-only tablespaces. After duplication is complete, you can query the views in the duplicate database described in Table 13-2 and Table 13-3 to determine which datafiles were skipped. The STATUS and ENABLED columns describe the current status of the duplicate datafile.

Skipping OFFLINE NORMAL Tablespaces When Duplicating a Database

When tablespaces are taken offline with the OFFLINE NORMAL option before a DUPLICATE operation, RMAN does not duplicate the datafiles of these tablespaces. After duplication, you can manually add or drop these tablespaces. Query the views in the duplicate database described in Table 13-4 and Table 13-5 to determine which datafiles are offline, based on the STATUS and ENABLED columns.

Task 1: Create an Oracle Password File for the Auxiliary Instance

For instructions on how to create and maintain Oracle password files, refer to Oracle Database Administrator's Guide.

Task 2: Establish Oracle Net Connectivity to the Auxiliary Instance

The auxiliary instance must be accessible through Oracle Net. Before proceeding, start SQL*Plus to ensure that you can establish a connection to the auxiliary instance. Note that you must connect to the auxiliary instance with SYSDBA privileges, so a password file must exist.

Task 3: Create an Initialization Parameter File for the Auxiliary Instance

Create a client-side initialization parameter file for the auxiliary instance. The parameters listed in Table 13-6 must be set to the values specified.

The block size for the auxiliary database must match that of the target database. If the target database parameter file contains a value for the DB_BLOCK_SIZE initialization parameter, then you must specify the same value in the auxiliary instance parameter file. If no DB_BLOCK_SIZE is specified in the target database parameter file, then do not specify DB_BLOCK_SIZE in the auxiliary instance parameter file.

You can also set the initialization parameters described in Table 13-7.

If you do not set the conversion parameters shown in Table 13-7, then you can set the DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, or DB_RECOVERY_FILE_DEST initialization parameter. In this case, the DUPLICATE command creates the datafiles, online redo logs, and tempfiles as Oracle Managed Files. If the CONTROL_FILES initialization parameter is not set, then the DUPLICATE command also creates the control file as an Oracle Managed File.

Set other initialization parameters, including the parameters that allow you to connect as SYSDBA through Oracle Net, as needed.

When duplicating to the same host or to a new host with a different file system, pay attention to all initialization parameters specifying path names. Verify that all paths are accessible on the host where the database is being duplicated.

Example 13-1 shows sample initialization parameter settings for the duplicate database.

DB_NAME=newdb
CONTROL_FILES=(/dup/oracle/oradata/trgt/control01.ctl,
               /dup/oracle/oradata/trgt/control02.ctl)
# note that the following two initialization parameters have equivalents
# on the DUPLICATE command itself
DB_FILE_NAME_CONVERT=(/oracle/oradata/trgt/,/dup/oracle/oradata/trgt/)
LOG_FILE_NAME_CONVERT=(/oracle/oradata/trgt/redo,/dup/oracle/oradata/trgt/redo)

After you create the client-side initialization parameter file, you can run the CREATE SPFILE command from SQL*Plus to create a server-side initialization parameter file. You can run this command before or after instance startup. For example, you can create a server-side parameter file in the default location as follows, specifying the filename of the client-side initialization parameter file in the FROM clause:

CREATE SPFILE FROM PFILE='/tmp/initDUPDB.ora';

A server-side parameter file in the default location is an advantage when duplicating a database because you do not need to specify the PFILE parameter on the DUPLICATE command. Because RMAN shuts down and restarts the auxiliary instance as part of the duplication process, you must tell RMAN which client-side file to use if you use a client-side parameter file. It is highly recommended that you create a server-side parameter file for use in database duplication.

Task 4: Start the Auxiliary Instance

Before beginning RMAN duplication, use SQL*Plus to connect to the auxiliary instance and start it in NOMOUNT mode (specifying a client-side parameter file if necessary). In this example, oracle is the password for the user with SYSDBA authority and aux is the net service name for the auxiliary instance:

CONNECT SYS/oracle@aux AS SYSDBA
-- start instance with the server parameter file
STARTUP FORCE NOMOUNT

Because the auxiliary instance does not yet have a control file, you can only start the instance in NOMOUNT mode. Do not create a control file or try to mount or open the auxiliary instance.

RMAN shuts down and restarts the auxiliary instance as part of the duplication. Hence, it is a good idea to create a server-side initialization parameter file for the auxiliary instance in the default location.

If you do not have a server-side initialization parameter file for the auxiliary instance in the default location, then you must specify the client-side initialization parameter file with the PFILE parameter on the DUPLICATE command. The client-side parameter file for the auxiliary instance must reside on the same host as the RMAN client used to perform the duplication.

Task 5: Mount or Open the Target Database

Before beginning RMAN duplication, connect SQL*Plus to the target database and mount or open it if it is not already mounted or open. For example, enter:

-- connect to target database
SQL> CONNECT SYS/oracle@trgt AS SYSDBA;
-- mount or open target database
STARTUP MOUNT;

Task 6: Make Sure You Have the Necessary Backups and Archived Redo Logs

Make sure backups all target datafiles are accessible on the duplicate host. If you do not have backups of everything, then the duplicate operation fails. The database backup does not have to be a whole database backup: you can use a mix of full and incremental backups of individual datafiles.

Archived redo logs required to recover the duplicate database to the desired point in time must be accessible at the same path by the node where the duplicate database is to be created. These can be available either as backups (for instance, on a media manager) or as image copies (or the actual archived redo logs). The backups or copies can be transferred to the local disk of the node that contains the duplicate database or possibly mounted across a network by some means such as NFS.

Task 7: Allocate Auxiliary Channels if Automatic Channels Are Not Configured

Start RMAN with a connection to the target database, the auxiliary instance, and, if applicable, the recovery catalog database. You can start the RMAN client on any host so long as it can connect to all the instances. If the auxiliary instance requires a client-side initialization parameter file, then this file must exist on the same host that runs the RMAN client.

In this example, a connection is established to three instances, all through the use of net service names:

% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb AUXILIARY SYS/oracle@aux

If you do not have automatic channels configured, then before issuing the DUPLICATE command, manually allocate at least one auxiliary channel within the same RUN command. The channel type (DISK or sbt) must match the media where the backups of the target database are located. If the backups reside on disk, then the more channels you allocate, the faster the duplication will be. For tape backups, limit the number of channels to the number of devices available.

RUN 
{
  # to manually allocate a channel of type sbt issue:
  ALLOCATE AUXILIARY CHANNEL ch1 DEVICE TYPE sbt;

  # to manually allocate three auxiliary channels for disk issue (specifying 
  # whatever channel id that you want):
  ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL aux3 DEVICE TYPE DISK;
  .
  .
  .
  DUPLICATE TARGET DATABASE TO dupdb;
}

Duplicating a Database on a Remote Host with the Same Directory Structure

The simplest case is to duplicate the database to a different host and to use the same directory structure. In this case, you do not need to change the initialization parameter file or set new filenames for the duplicate datafiles.

1. Follow the steps in "Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps".

   Run the DUPLICATE command, making sure to do the following:

   • If automatic channels are not configured, then allocate at least one auxiliary channel.

2. Specify the NOFILENAMECHECK parameter on the DUPLICATE command.

3. Specify the PFILE parameter if starting the auxiliary instance with a client-side parameter file. The client-side parameter file must exist on the same host as the RMAN client used to perform the duplication.

   The following example assumes that the RMAN client is running on the duplicate host. It duplicates the database with an automatic channel, specifies a client-side initialization parameter file, and specifies the NOFILENAMECHECK option:

   DUPLICATE TARGET DATABASE TO dupdb
     # specify client-side parameter file (on same host as RMAN client) for
     # auxiliary instance if necessary
     PFILE = /dup/oracle/dbs/initDUPDB.ora
     NOFILENAMECHECK;
   

RMAN automatically allocates the configured channels, then uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs.

Duplicating a Database on a Remote Host with a Different Directory Structure

If you create the duplicate database on a host with a different directory structure, then you must change several initialization parameters in order to generate new filenames for the duplicate database datafiles on the new directory structure. The different techniques available are described in "Renaming Datafiles in RMAN DUPLICATE DATABASE".

DUPLICATE
  TARGET DATABASE TO dupdb
  DEVICE TYPE sbt # restores from tape backups;
# DUPLICATE DEVICE TYPE sbt works only if the sbt device is configured
# by CONFIGURE CHANNEL, CONFIGURE DEVICE TYPE, or CONFIGURE DEFAULT DEVICE.

DUPLICATE TARGET DATABASE TO dupdb
  # specify client-side parameter file for auxiliary instance 
  PFILE = /dup/oracle/dbs/initDUPDB.ora
  DB_FILE_NAME_CONVERT=(/oracle/oradata/trgt/,/dup/oracle/oradata/trgt/)
  LOGFILE
    '/dup/oracle/oradata/trgt/redo01.log' SIZE 200K,
    '/dup/oracle/oradata/trgt/redo02.log' SIZE 200K,
    '/dup/oracle/oradata/trgt/redo03.log' SIZE 200K;

# configure the new desired filenames
 CONFIGURE AUXNAME FOR DATAFILE 1 
        TO '/dup/oracle/oradata/trgt/system01.dbf'; 
 CONFIGURE AUXNAME FOR DATAFILE 2 
        TO '/dup/oracle/oradata/trgt/undotbs01.dbf'; 
# ... add more CONFIGURE AUXNAME commands as needed 

# run the DUPLICATE command
DUPLICATE TARGET DATABASE TO dupdb
# specify client-side parameter file for auxiliary instance if necessary
PFILE = /dup/oracle/dbs/initDUPDB.ora
.
.
.
# create at least two online redo log groups
 LOGFILE
    GROUP1
    (
      '/dup/oracle/oradata/trgt/redo01a.log',
      '/dup/oracle/oradata/trgt/redo01b.log',
      '/dup/oracle/oradata/trgt/redo01c.log';
    ) SIZE 200K,
    GROUP2
    (
      '/dup/oracle/oradata/trgt/redo02a.log',
      '/dup/oracle/oradata/trgt/redo02b.log',
      '/dup/oracle/oradata/trgt/redo02c.log';
    ) SIZE 200K,
    GROUP3
    (
      '/dup/oracle/oradata/trgt/redo03a.log',
      '/dup/oracle/oradata/trgt/redo03b.log',
      '/dup/oracle/oradata/trgt/redo03c.log';
    ) SIZE 200K;

# clear specified auxiliary names for the datafiles
CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; 
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; 
.
.
.

Creating a Duplicate Database on the Local Host

When creating a duplicate database on the same host as the target database, follow the same procedure as for duplicating to a remote host with a different directory structure as described in "Duplicating a Database on a Remote Host with a Different Directory Structure".

You can duplicate the database to the same Oracle home as the target database, but you must use a different database name from the target database, and convert the filenames by means of the same methods used for conversion on a separate host.

Using RMAN DUPLICATE with OMF and ASM

The following sections discuss requirements when creating some or all files of the duplicate database in OMF or ASM storage:

• Initialization Parameters for RMAN DUPLICATE to OMF Storage

• Duplicating a Database to ASM Storage

• Using SET NEWNAME with RMAN DUPLICATE to OMF

*.DB_CREATE_FILE_DEST = '+disk1'

RUN {
   SET NEWNAME FOR DATAFILE 1 TO "+dgroup1";
   SET NEWNAME FOR DATAFILE 2 TO "+dgroup2";
...
   DUPLICATE TARGET DATABASE FOR STANDBY;
}

Duplicating When the Datafiles Use Inconsistent Paths: Example

This example assumes the following:

• You are using recovery catalog database catdb.

• The target database trgt is on host1 and contains eight datafiles, which are spread out over multiple directories.

• You want to exclude tablespace tools from the duplicate database, but keep all of the other tablespaces.

• You want to duplicate the target to database dupdb on remote host host2.

• host1 and host2 cannot mount each other's file systems by any means such as NFS.

• You want to store the datafiles in host2 in the /oradata1, /oradata2 ... through /oradata7 subdirectories.

• You have used an operating system utility to copy the initialization parameter file from host1 to an appropriate location in host2.

• You have reset all initialization parameters that end in _DEST and specify a path name.

• You want two online redo logs groups, each with two members of size 200 KB, which on the duplicate system will be stored in the directory "/duplogs".

• You have disk copies or backup sets stored on disk for all the datafiles and archived redo logs in the target database, and you have manually moved them to host2 by means of an operating system utility.

• The auxiliary instance uses a server-side initialization parameter file in the default location (so the PFILE parameter is not necessary on the DUPLICATE command).

Example 13-3 illustrates a script that creates the duplicate database.

CONNECT TARGET /;
CONNECT CATALOG rman/cat@catdb;
CONNECT AUXILIARY SYS/oracle@dupdb;

# note that a RUN command is necessary because you can only execute SET NEWNAME
# within a RUN command
RUN
{
  # The DUPLICATE command uses an automatic sbt channel.
  # Because the target datafiles are spread across multiple directories, 
  # run SET NEWNAME rather than DB_FILE_NAME_CONVERT
  SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf'; 
  SET NEWNAME FOR DATAFILE 2 TO '/oradata2/undotbs01.dbf'; 
  SET NEWNAME FOR DATAFILE 3 TO '/oradata3/cwmlite01.dbf'; 
  SET NEWNAME FOR DATAFILE 4 TO '/oradata4/drsys01'; 
  SET NEWNAME FOR DATAFILE 5 TO '/oradata5/example01.dbf'; 
  SET NEWNAME FOR DATAFILE 6 TO '/oradata6/indx01.dbf';
  # Do not set a newname for datafile 7, because it is in the tools tablespace,
  # and you are excluding tools from the duplicate database.
  SET NEWNAME FOR DATAFILE 8 TO '/oradata7/users01.dbf'; 
  DUPLICATE TARGET DATABASE TO dupdb
    SKIP TABLESPACE tools
    LOGFILE
      GROUP 1 ('/duplogs/redo01a.log', 
               '/duplogs/redo01b.log') SIZE 200K REUSE, 
      GROUP 2 ('/duplogs/redo02a.log', 
               '/duplogs/redo02b.log') SIZE 200K REUSE;
}

RMAN DUPLICATE DATABASE From File System to ASM: Example

This duplication example assumes the following:

• You are using recovery catalog database catdb.

• The target database trgt is on host1 and the database files are stored in a non-ASM file system.

• You want to duplicate the target to database dupdb on remote host host2.

• host2 has diskgroup +DISK1.

• You want to store the datafiles for dupdb to +DISK1.

• You want to store two controlfiles in +DISK1.

• The backups and archivelogs created by host1 are accessible by host2.

Create an initialization parameter for auxiliary instance by copying the target database initialization parameter file. Change the parameters as follows:

• Set DB_NAME to the new database name dupdb

• Set CONTROL_FILES to store two copies of the control file in +DISK1

• Make sure DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT are not set

• Set any other initialization parameters that end in _DEST, such as DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_DEST_n, to reference +DISK1

For example:

DB_NAME=dupdb
CONTROL_FILES=+DISK1,+DISK1

Create an SPFILE from the parameter file, and start the auxiliary instance:

SQL> CONNECT AUXILIARY SYS/oracle@dupdb;
SQL> CREATE SPFILE FROM PFILE=auxiliary instance pfile;
SQL> STARTUP NOMOUNT;

Then run the following RMAN commands to duplicate the database:

RMAN> CONNECT TARGET /;
RMAN> CONNECT CATALOG rman/cat@catdb;
RMAN> CONNECT AUXILIARY SYS/oracle@dupdb;
RMAN> DUPLICATE TARGET DATABASE TO dupdb
      LOGFILE GROUP 1 ('+DISK1','+DISK1') SIZE 200K,
              GROUP 2 ('+DISK1','+DISK1') SIZE 200K;

When the DUPLICATE command completes, the duplicate database is created, with datafiles, online logs and control files in ASM disk group +DISK1.

RMAN DUPLICATE DATABASE From ASM to ASM: Example

This duplication example assumes the following:

• You are using recovery catalog database catdb

• The target database trgt is on host1 and contains ASM datafiles and online logs in diskgroup +DISK1

• You want to duplicate the target to database dupdb on remote host host2.

• host2 has diskgroup +DISK2

• You want to store the datafiles for dupdb to +DISK2

• You want to store two controlfiles in +DISK2

• The backups and archivelogs created by host1 are accessible by host2

Create an initialization parameter for auxiliary instance by copying the target database initialization parameter file. Change the parameters as follows:

• Set DB_NAME to the new database name dupdb

• Set CONTROL_FILES to store two copies of the control file in +DISK2

• Set DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT to convert the datafile and online log file names from +DISK1 to +DISK2

• Set any other initialization parameters that end in _DEST, such as DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_DEST_n, to reference +DISK2

For example:

DB_NAME=dupdb
CONTROL_FILES=+DISK2,+DISK2
DB_FILE_NAME_CONVERT=+DISK1,+DISK2
LOG_FILE_NAME_CONVERT=+DISK1,DISK2

Create an SPFILE from the parameter file, and start the auxiliary instance:

SQL> CONNECT AUXILIARY SYS/oracle@dupdb;
SQL> CREATE SPFILE FROM PFILE=auxiliary instance pfile;
SQL> STARTUP NOMOUNT;

Then run the following RMAN commands to duplicate the database:

RMAN> CONNECT TARGET /;
RMAN> CONNECT CATALOG rman/cat@catdb;
RMAN> CONNECT AUXILIARY SYS/oracle@dupdb;
RMAN> DUPLICATE TARGET DATABASE TO dupdb;

When the DUPLICATE command completes, the duplicate database is created, with datafiles, online logs and control files in ASM disk group +DISK2.

RMAN DUPLICATE DATABASE at a Past Point in Time: Example

This duplication example assumes the following:

• The target database trgt and duplicate database dupdb are on different hosts but have exactly the same directory structure.

• You want to name the duplicate database files the same as the target files.

• You are not using a recovery catalog.

• You are using automatic channels for disk and sbt, which are already configured.

• You want to recover the duplicate database to one week ago in order to view the data in prod1 as it appeared at that time (and you have the required backups and logs to recover the duplicate to that point tin time).

CONNECT TARGET SYS/oracle@trgt
CONNECT AUXILIARY SYS/oracle@dupdb

DUPLICATE TARGET DATABASE TO dupdb 
    NOFILENAMECHECK UNTIL TIME 'SYSDATE-7';

Duplicating with a Client-Side Parameter File: Example

You can run the DUPLICATE command using a client-side parameter file for the auxiliary instance. Assume the following scenario:

• The target host is host_src and the duplicate host is host_dup.

• The client-side initialization parameter file on host_dup is named /tmp/initTEST.ora.

• The hosts host_dup and host_src are linked by a network.

In this scenario, you can run the RMAN client (that is, run the DUPLICATE command in an RMAN session) either on host_src or host_dup.

DUPLICATE  
  TARGET DATABASE TO dupdb
  DEVICE TYPE sbt
  PFILE='/tmp/initTEST.ora';

% rman TARGET SYS/oracle@trgt AUXILIARY SYS/oracle@dupdb
RMAN> DUPLICATE TARGET DATABASE TO dupdb
        DEVICE TYPE sbt PFILE='/net/host_src/tmp/initTEST.ora';
RMAN> EXIT

Using CONFIGURE AUXNAME to Name Datafiles at the Duplicate

The script shown in Example 13-4 performs the one-time setup of the names for the datafiles.

# start RMAN and then connect to the target and auxiliary databases     
CONNECT TARGET /;
CONNECT CATALOG rman/cat@catdb;
CONNECT AUXILIARY SYS/oracle@dupdb;

# configure auxiliary names for the datafiles only once     
CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oradata2/undotbs01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 3 TO '/oradata3/cwmlite01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 4 TO '/oradata4/drsys01'; 
CONFIGURE AUXNAME FOR DATAFILE 5 TO '/oradata5/example01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 6 TO '/oradata6/indx01.dbf';
# Do not set a newname for datafile 7, because it is in the tools tablespace,
# and in this example you are excluding tools from the duplicate database.
CONFIGURE AUXNAME FOR DATAFILE 8 TO '/oradata7/users01.dbf'; 

Syncrhonizing the Duplicate With the Target Using Auxnames

Run the script in Example 13-5 whenever you want to synchronize the duplicate with the source database. For example, you might run the script daily or weekly.

# start RMAN and then connect to the target and auxiliary databases     
CONNECT TARGET /;
CONNECT CATALOG rman/cat@catdb;
CONNECT AUXILIARY SYS/oracle@dupdb;

# Create the duplicate database. Run the same command periodically
# to re-create the database, thereby keeping the duplicate 
# in sync with the target.
DUPLICATE TARGET DATABASE TO dupdb
SKIP TABLESPACE tools
  LOGFILE
    GROUP 1 ('/duplogs/redo01a.log', 
             '/duplogs/redo01b.log') SIZE 200K REUSE, 
    GROUP 2 ('/duplogs/redo02a.log', 
             '/duplogs/redo02b.log') SIZE 200K REUSE;

Using BACKUP INCREMENTAL... FROM SCN

The incremental backup is created at the source database by means of the BACKUP INCREMENTAL FROM SCN=n form of the BACKUP command. For example:

BACKUP DEVICE TYPE SBT INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
     FORMAT '/tmp/incr_standby_%U';

RMAN uses the selected SCN as the basis for this incremental backup. For all files being backed up, RMAN includes all data blocks that were changed at SCNs greater than or equal to the FROM SCN in the incremental backup.

Refreshing a Standby Database With INCREMENTAL FROM SCN Backups: Example

This example shows the steps required to update a standby database using incremental backups. The assumption is that you have already activated the standby, performed your tests or other operations at the standby, and then used Flashback Database to undo the effects of those changes. The task here is to refresh the standby with the latest changes to the primary, so that it can resume its role as a standby database.

RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
     FORMAT '/tmp/incr_for_standby/bkup_%U';

RMAN> CATALOG START WITH '/standbydisk1/incrback/';

RMAN> RECOVER DATABASE NOREDO;