Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-01
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
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

Using RMAN DUPLICATE DATABASE: Examples

This section contains common duplication scenarios:

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.

Example 13-3 Duplicating When Datafiles Use Inconsistent Paths

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;
}

Creating Duplicate of the 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 poin 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.

Running RMAN Client on host_dup

If you run the RMAN client on host_dup, you can duplicate the database as follows:

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

Because the initialization parameter file used by the auxiliary instance resides on the same node as the RMAN client, you can reference the parameter file by its path name on the local system.

Running RMAN from host_src

You can run the RMAN client on the same host as the target database rather than on the host with the duplicate database. In such a case, the client-side initialization parameter file needed by the DUPLICATE command is not located on the same node as the RMAN client.

One option is to copy the parameter file from host_dup to host_src. If the source host and duplicate host have access to the same file system by some means such as NFS, then you can also remotely mount the directory containing the parameter file by some means such as NFS, and access it directly from host_src.

The following example starts RMAN on host_src and duplicates the database. In this scenario, assume /net/host_src/tmp is an NFS mount point for /net/host_dup/tmp, so RMAN is able to access the auxiliary parameter file.

% 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