Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
This section contains common duplication scenarios:
Duplicating When the Datafiles Use Inconsistent Paths: Example
Creating Duplicate of the Database at a Past Point in Time: Example
Creating Duplicate of the Database at a Past Point in Time: Example
Creating Duplicate of the Database at a Past Point in Time: 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; }
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';
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
.
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.
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