Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 1 (10.1) Part Number B10734-01 |
|
|
View PDF |
This chapter describes how to use the DUPLICATE
command to create a duplicate database for testing purposes. This chapter contains these topics:
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with the |
You can use the RMAN DUPLICATE
command to create a duplicate database from target database backups while still retaining the original target database. The duplicate database can be identical to the original database or contain only a subset of the original tablespaces.
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:
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 effectively 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.
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with the |
To prepare for database duplication, you must 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.
You must have at least one auxiliary channel allocated 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 machine. However, all backups and archived logs used for creating and recovering the duplicate database must be accessible by the server session on the duplicate host. If the duplicate host is not the same as the primary host, then you must make backups on disk on the primary 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:
CATALOG
command to add these copies to the RMAN repository.When using tape backups, you must make the tapes containing the backups accessible to the remote node, either by physically moving the tape to the remote host or by means of a network tape server.
As part of the duplicating operation, RMAN automates the following steps:
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)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.
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with RMAN |
When duplicating a database, you have the following options:
DUPLICATE
command with or without a recovery catalogSKIP
READONLY
clause. Read-only tablespaces are included by default. If you omit them, then you can add them later.SKIP
TABLESPACE
clause. You can exclude any tablespace except the SYSTEM
tablespace or tablespaces containing rollback or undo segments.NOFILENAMECHECK
option and reuse the target datafile filenames for the duplicate datafiles.SET
UNTIL
command or DUPLICATE
...
UNTIL
command. By default, the DUPLICATE
command creates the duplicate database by using the most recent backups of the target database and then performs recovery to the most recent consistent point contained in the incremental backups and archived logs.
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). |
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 duplication involves a number of prerequisites, restrictions, and caveats. Review the restrictions section of the DUPLICATE
command in the Oracle Database Recovery Manager Reference for a complete list.
When duplicating a database, RMAN creates the required database files. This section describes these stages of file creation:
The DUPLICATE
command creates the control files by using the names listed in the initialization parameter file of the auxiliary instance. When choosing names for the duplicate database control files, make sure that you set the initialization parameter settings correctly so that you do not overwrite the production files at the target database.
Table 11-1 lists the options for creating the names of the duplicate online redo logs. The options appear in the order of precedence.
The order of precedence determines how RMAN renames the online redo logs. For example, if you specify both the LOGFILE
clause and the LOG_FILE_NAME_CONVERT
parameter, then RMAN uses the LOGFILE
clause. If you specify neither of the first two options, then RMAN uses the original target redo log filenames for the duplicate database files.
There are several methods of specifying new names to be used for the datafiles of your duplicate database. Listed in order of precedence, they are:
SET NEWNAME
command, within a RUN block enclosing both the SET NEWNAME
commands and the DUPLICATE
command.CONFIGURE AUXNAME
command to specify new names for existing datafiles, before using the DUPLICATE
command.DB_FILE_NAME_CONVERT
parameter to the DUPLICATE
command, to specify a rule for converting filenames for any datafiles not renamed using SET NEWNAME
or CONFIGURE AUXNAME
. Note that you can specify multiple conversion pairs, and use ASM disk groups.DB_FILE_NAME_CONVERT
initialization parameter, subject to the same semantics and limitations as the DB_FILE_NAME_CONVERT
parameter to the DUPLICATE
command.If yo do not use any of these options, then the duplicate database will reuse the original datafile filenames from the target database.
It is possible for CONFIGURE
AUXNAME
, SET
NEWNAME
, or DB_FILE_NAME_CONVERT
to generate a name that is already in use in the target database. In this case, specify NOFILENAMECHECK
to avoid an error message. For example, assume that the host A database has two files: datafile 1
is named /oracle/data/file1.f
and datafile 2
is named /oracle/data/file2.f
. When duplicating to host B, you use a configured channel to duplicate as follows:
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; }
Even though you issued SET
NEWNAME
commands for all the datafiles, the DUPLICATE
command fails because the duplicate filenames are still in use in the target database. Although datafile 1
in the target is not using /oracle/data/file2.f
, and datafile 2
in the target is not using /oracle/data/file1.f
, the target filename is used by one of the duplicate datafiles and so you must specify NOFILENAMECHECK
to avoid an error.
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 11-2 and Table 11-3 to determine which datafiles were skipped. The STATUS
and ENABLED
columns are the key to determining the current status of the duplicate datafile.
In the column ... | The value is ... |
---|---|
|
|
|
|
|
|
View | In the column ... | The value is ... |
---|---|---|
|
|
|
|
|
|
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 11-4 and Table 11-5 to determine which datafiles are offline, based on the STATUS
and ENABLED
columns.
In the column ... | The value is ... |
---|---|
|
|
|
|
|
|
View | In the column ... | The value is ... |
---|---|---|
|
|
|
|
|
|
When you take a tablespace offline with the IMMEDIATE
option, RMAN duplicates rather than skips the tablespace because this tablespace requires recovery. As with online tablespaces, RMAN requires a valid backup for duplication.
Perform these tasks before performing RMAN duplication:
For instructions on how to create and maintain Oracle password files, refer to Oracle Database Administrator's Guide.
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.
Create a client-side initialization parameter file for the auxiliary instance, and set at least the parameters described in the following table.
Parameter | You must specify: |
---|---|
|
The same name used in the |
|
Refer to "Creating the Duplicate Control Files". |
You can also set the initialization parameters described in the following table.
Initialization Parameter | You must specify: |
---|---|
|
Refer to "Renaming Datafiles When Duplicating a Database". You can also specify this parameter on the |
|
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.
Following are examples of the 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.
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.
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 CONNECT SYS/oracle@trgt -- mount or open target database STARTUP
If necessary, you can use a client-side initialization file to start up the target instance.
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 by the node where the duplicate database is to be created, either as backups (for instance, on a media manager) or as image copies (or the actual archived redo logs), either copied to the local disk of the node that contains the duplicate database, or possibly mounted across a network by some means such as NFS.
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 ... }
The proceture to create a duplicate database depends on your configuration.
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.
DUPLICATE
command, making sure to do the following:
NOFILENAMECHECK
parameter on the DUPLICATE
command.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.
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 methods available for doing so are described in "Renaming Datafiles When Duplicating a Database".
This procedure assumes that you use only initialization parameters to rename the duplicate datafiles and log files.
_DEST
or _PATH
and specify a path name.DB_FILE_NAME_CONVERT
so that it captures all the target datafiles and converts them appropriately, for example, from /oracle/oradata/
to /dup/oracle/oradata/
.LOG_FILE_NAME_CONVERT
so that it captures all the online redo logs and converts them appropriately, for example, /oracle/oradata/redo
to /dup/oracle/oradata/redo
.
PFILE
parameter.The following example assumes that the duplicate host can access the same media manager as the primary database host. The example duplicates the database with an automatic sbt
channel and uses a server-side parameter file located on the duplicate host to restart the auxiliary instance:
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.
RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery. RMAN then shuts down, starts, and opens the database with the RESETLOGS
option to create the online redo logs.
This procedure assumes that you use the DB_FILE_NAME_CONVERT
parameter of the DUPLICATE
command to rename the duplicate datafiles, and the LOGFILE
clause to specify names and sizes for the online redo logs.
Perform the following operations when running the duplication:
LOGFILE
clause.DB_FILE_NAME_CONVERT
parameter.PFILE
parameter.The following example duplicates the database with an automatic channel and specifies an initialization parameter file:
DUPLICATE TARGET DATABASE TO dupdb # specify client-side parameter file for auxiliary instance if necessary 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;
This procedure assumes that you use the SET
NEWNAME
command to rename the duplicate datafiles.
_DEST
or _PATH
and specify a path name.PFILE
parameter.The following example uses automatic channels and a default server-side initialization parameter file for the database duplication, and uses the LOGFILE
clause to specify names and sizes for the online redo logs:
RUN { # set new filenames for the datafiles SET NEWNAME FOR DATAFILE 1 TO '/dup/oracle/oradata/trgt/system01.dbf'; SET NEWNAME FOR DATAFILE 2 TO '/dup/oracle/oradata/trgt/undotbs01.dbf'; . . . # issue the duplicate command DUPLICATE TARGET DATABASE TO dupdb # 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;
RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery. RMAN shuts down, starts up, and then opens the database with the RESETLOGS
option to create the online logs.
This procedure assumes that you use the CONFIGURE
AUXNAME
command to rename the duplicate datafiles.
_DEST
or _PATH
and specify a path name.CONFIGURE AUXNAME
commands for all datafiles, to be executed before database duplication.LOGFILE
clause to specify redo log groups and members for the duplicate database. (You do not have to use the same number of redo log groups or redo log group members in the duplicate database as you did in the target database.)PFILE
parameter. The client-side parameter file must reside on the same host as the RMAN client used to perform the duplication.The following example uses CONFIGURE AUXNAME
to set new datafile names, uses automatic channels and a client-side initialization parameter file for the database duplication, and uses the LOGFILE
clause to specify names and sizes for the online redo logs.
# 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;
RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery and then opens the database with the RESETLOGS
option to create the online redo logs.
After the duplication is complete, clear the configured auxiliary names for the datafiles in the duplicate database, so that they are not overwritten by mistake. For example, enter the following:
# un-specify auxiliary names for the datafiles CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; . . .
and so on.
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.
The process for creating a duplicate database to an Automatic Storage Management or Oracle Managed Files location is similar to the procedure described in "Duplicating a Database on a Remote Host with a Different Directory Structure". However, you must edit the initialization parameter file in the auxiliary instance to set the DB_CREATE_FILE_DEST
parameter to refer to an ASM disk group, and eliminate parameters such as DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT
which are used to control the naming of any files in the duplicate database which will be created in ASM during the duplication process.
For example, edit the file as follows to create the database files in the disk group named disk1
:
*.DB_CREATE_FILE_DEST = '+disk1'
Here are some common variations on the process of duplicating a database.
This example assumes the following:
catdb
.trgt
is on host1
and contains eight datafiles, which are spread out over multiple directories.dupdb
on remote host host2
.host1
and host2
use different file systems.host2
in the /oradata1
, /oradata2
... through /oradata7
subdirectories.tools
from the duplicate database, but keep all of the other tablespaces.host1
to an appropriate location in host2
._DEST
or _PATH
and specify a path name./duplogs
".host2
by means of an operating system utility.sbt
. The media management device is accessible by host2
.PFILE
parameter is not necessary on the DUPLICATE
command).
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 example makes the same assumptions as in "Duplicating When the Datafiles Use Inconsistent Paths: Example".
In this case, the assumption is that you want to update the duplicate database daily so that it stays current with the target database. Therefore the CONFIGURE command is used to set persistent new names for the datafiles, to use in the daily duplication process.
This script performs the onetime setup of the names for the data files, and should be run once.
# start RMAN and then connect to the 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 you are excluding tools from the duplicate database. CONFIGURE AUXNAME FOR DATAFILE 8 TO '/oradata7/users01.dbf';
This script is run daily to peform the duplication:
# start RMAN and then connect to the databases CONNECT TARGET /; CONNECT CATALOG rman/cat@catdb; CONNECT AUXILIARY SYS/oracle@dupdb; # Create the duplicate database. Issue the same command daily # 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;
This duplication example assumes the following:
trgt
and duplicate database dupdb
are on different hosts but have exactly the same directory structure.prod1
as it appeared at that time.
CONNECT TARGET SYS/oracle@trgt CONNECT AUXILIARY SYS/oracle@dupdb DUPLICATE TARGET DATABASE TO dupdb NOFILENAMECHECK UNTIL TIME 'SYSDATE-7';
If you use a client-side initialization parameter file to start the auxiliary instance, then it must reside on the same host as the RMAN client used to perform the duplication. Assume the following scenario:
host_tar
and the duplicate host is host_dup
host_dup
is named /orahome/dbs/initTEST.ora
.host_dup
and host_tar
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_tar
or host_dup
.
If you run the executable on host_dup
, you can duplicate the database as follows:
DUPLICATE TARGET DATABASE TO dupdb DEVICE TYPE sbt PFILE='/orahome/dbs/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 local filename of the parameter file.
In this scenario, you run RMAN on the same host as the target database rather than on the host with the duplicate database. Hence, the client-side initialization parameter file needed by the DUPLICATE
command is not located on the same node as the RMAN client. You must transfer the parameter file from host_dup
to host_tar
, or remotely mount the directory containing the parameter file by some means such as NFS, so that it can be accessed from the target host.
In this scenario, you manually copy the file from one host to another. In Unix systems you could use the cp command:
% cp /net/host_dup/orahome/dbs/initTEST.ora /net/host_tar/tmp
Then, you can start RMAN on host_tar
and perform the duplication with the following command:
% rman TARGET SYS/oracle@trgt AUXILIARY SYS/oracle@dupdb RMAN> DUPLICATE TARGET DATABASE TO dupdb DEVICE TYPE sbt PFILE='/net/host_tar/tmp/initTEST.ora'; RMAN> EXIT
In this scenario, you mount the host_dup
file system on the host_tar
file system by using /net/host_dup
as the mount point. The /net/host_dup/initTEST.ora
filename on host_tar
points to the /orahome/dbs/initTEST.ora
file residing on host_dup
. Then, you can run the duplication as follows:
DUPLICATE TARGET DATABASE TO dupdb DEVICE TYPE sbt PFILE='/net/host_dup/initTEST.ora';