This chapter describes how to use the DUPLICATE
command to create a duplicate database for testing purposes. This chapter contains these topics:
Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps
Using DUPLICATE DATABASE to Resynchronize a Duplicate Database: Example
Using RMAN Incremental Backups to Refresh a Standby Database
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with theDUPLICATE
commandYou 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.
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with theDUPLICATE
commandTo 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.
See Also:
Oracle Data Guard Concepts and Administration to learn how to create a standby database with RMANWhen 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 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.
When duplicating a database, RMAN generates names for the required database files. This section describes the different stages of file creation:
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.
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.
Table 13-1 Order of Precedence for Online Redo Log Filename Generation
Order | Method | Result |
---|---|---|
1 |
Specify the |
Creates online redo logs as specified. |
2 |
Set |
Transforms target filenames, for example, from For details on the use of RMAN uses the |
3 |
Set one of the Oracle Managed Files initialization parameters |
Transforms target filenames based on the parameters set. The rules of precedence among these parameters are the same used by the SQL statement |
4 |
Do none of the preceding steps. |
Makes the duplicate filenames the same as the filenames from the target. You must specify the |
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.
Caution:
If the target and duplicate databases are in the same host, then do not use the name of an online redo log currently in use by the target database.
Do not use the name of an online log currently in use by the target database if the duplicate database is in a different host and NOFILENAMECHECK
is not used.
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:
Use the RMAN command SET NEWNAME FOR DATAFILE
within a RUN
block that encloses both the SET NEWNAME
commands and the DUPLICATE
command.
Use the RMAN command CONFIGURE AUXNAME
to specify new names for existing datafiles. Run the CONFIGURE AUXNAME
command before the DUPLICATE
command.
Specify the DB_FILE_NAME_CONVERT
parameter on the DUPLICATE
command to specify a rule for converting filenames for any datafiles not renamed with SET NEWNAME
or CONFIGURE AUXNAME
.
Note:
TheDB_FILE_NAME_CONVERT
clause of the DUPLICATE
command cannot be used to control generation of new names for files at the duplicate instance which are Oracle Managed Files (OMF) at the target instance. See Oracle Database Backup and Recovery Reference for details on this restriction.Set the DB_FILE_NAME_CONVERT
initialization parameter.
Note:
TheDB_FILE_NAME_CONVERT
initialization parameter cannot be used to control generation of new names for files at the duplicate instance which are Oracle Managed Files (OMF) at the target instance. It is subject to the same semantics and limitations as the DB_FILE_NAME_CONVERT
parameter to the DUPLICATE
command. It See Oracle Database Backup and Recovery Reference for details.Set the DB_CREATE_FILE_DEST
initialization parameter to create Oracle Managed Files datafiles at the specified location.
If you do not use any of the preceding options, then the duplicate database reuses the original datafile locations 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
on the DUPLICATE
command 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. Thus, you must specify DUPLICATE ... NOFILENAMECHECK
to avoid an error.
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:
Use the SET NEWNAME FOR TEMPFILE
command within a RUN
block that encloses both the SET NEWNAME
commands and the DUPLICATE
command.
Specify the DB_FILE_NAME_CONVERT
clause to the DUPLICATE
command to specify a rule for converting tempfiles not renamed with SET NEWNAME
or CONFIGURE AUXNAME
.
Note:
TheDB_FILE_NAME_CONVERT
clause cannot be used to control generation of new names for files at the duplicate instance which are Oracle Managed Files (OMF) at the target instance. See Oracle Database Backup and Recovery Reference for details on this restriction.Set the DB_FILE_NAME_CONVERT
initialization parameter.
Note:
TheDB_FILE_NAME_CONVERT
initialization parameter is subject to the same semantics and limitations as the DB_FILE_NAME_CONVERT
parameter to the DUPLICATE
command.See Oracle Database Backup and Recovery Reference for details.Set the DB_CREATE_FILE_DEST
initialization parameter to create Oracle Managed Files tempfiles.
It is not always necessary to duplicate all tablespaces of a database. For example, you may plan to generate reports at the duplicate that require only a subset of tablespaces from your target database. RMAN DUPLICATE
DATABASE
can skip read-only tablespaces or tablespaces that are currently OFFLINE NORMAL. This section describes how to skip such tablespaces during DUPLICATE
. It contains the following topics:
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.
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.
Table 13-4 Offline Tablespaces in V$ Views on Duplicate Database
In the column ... | The value is ... |
---|---|
|
|
|
|
|
|
Table 13-5 Offline Tablespaces in Data Dictionary Views on Duplicate Database
View | In the column ... | The value is ... |
---|---|---|
|
|
|
|
|
|
Note:
RMAN duplicates tablespaces that are taken offline with theIMMEDIATE
option, because such a tablespace requires recovery. As with online tablespaces, RMAN requires a valid backup for duplication.To prepare the auxiliary instance used in RMAN DUPLICATE DATABASE, carry out the following tasks:
Task 1: Create an Oracle Password File for the Auxiliary Instance
Task 2: Establish Oracle Net Connectivity to the Auxiliary Instance
Task 3: Create an Initialization Parameter File for the Auxiliary Instance
Task 6: Make Sure You Have the Necessary Backups and Archived Redo Logs
Task 7: Allocate Auxiliary Channels if Automatic Channels Are Not Configured
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. The parameters listed in Table 13-6 must be set to the values specified.
Table 13-6 Database Name and Control File Name Initialization Parameters
Parameter | Required Value |
---|---|
|
The same name used in the |
|
Refer to "Renaming Control Files in RMAN DUPLICATE DATABASE". |
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.
Table 13-7 Filename Conversion Initialization Parameters
Initialization Parameter | You must specify: |
---|---|
|
Refer to "Renaming Datafiles in RMAN DUPLICATE DATABASE". You can also specify |
|
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.
Example 13-1 Sample Initialization Parameters for 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 SQL> CONNECT SYS/oracle@trgt AS SYSDBA; -- mount or open target database STARTUP MOUNT;
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.
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; }
Note:
If you configure automatic channels, then RMAN can use configured channels for duplication even if they do not specify theAUXILIARY
option. Nevertheless, if the auxiliary channels need some special parameters (for example, to point to a different media management subsystem), then you can configure an automatic channel with the AUXILIARY
option.The procedure to create a duplicate database depends on your configuration. This section contains the following topics:
Duplicating a Database on a Remote Host with the Same Directory Structure
Duplicating a Database on a Remote Host with a Different 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.
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.
Specify the NOFILENAMECHECK
parameter on the DUPLICATE
command.
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.
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".
This procedure assumes that you use only initialization parameters to rename the duplicate datafiles and log files.
Follow the steps in "Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps". You can either create a client-side parameter file, or copy the parameter file from its location in the target host directory structure to the same location in the duplicate host directory structure using operating system utilities.
Perform the following tasks:
Review all initialization parameters that end in _DEST
and specify a path name. Some may need to be changed.
Set 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/
.
Set 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
.
You can set multiple conversion pairs in DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT
. For example, you can specify that DB_FILE_NAME_CONVERT
changes /disk1/dbs
to /dup1/dbs
and /disk2/dbs
to /dub2/dbs
.
You can also use the CONFIGURE AUXNAME
or SET NEWNAME
commands to rename individual datafiles if you cannot easily generate all of your desired filenames using DB_FILE_NAME_CONVERT
patterns. As described in "Using RMAN DUPLICATE with OMF and ASM", you can also duplicate your database to an Oracle Managed Files location and let the database generate names for your files.
Perform the following operations when running the duplication:
If automatic channels are not configured, then allocate at least one auxiliary channel.
If using a client-side parameter file to start the auxiliary instance, specify the 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:
If automatic auxiliary channels are not configured, then allocate at least one auxiliary channel.
Specify the names and sizes for the duplicate database redo logs in the LOGFILE
clause.
Specify new filenames for the duplicate database datafiles with the DB_FILE_NAME_CONVERT
parameter.
If using a client-side parameter file to start the auxiliary instance, specify the PFILE
parameter.
The following example duplicates the database using configured channels and specifies an initialization parameter file:
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;
This procedure assumes that you use the SET
NEWNAME
command to rename the duplicate datafiles.
Follow the steps in "Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps", making sure to use an operating system utility to copy the parameter file from its location in the target host directory structure to the same location in the duplicate host. Set all initialization parameters that end in _DEST
and specify a path name.
Perform the following operations when running the duplication:
If channels are not configured for the auxiliary database, then allocate at least one auxiliary channel.
If desired, specify the same number of redo log members and groups that are used in the target database.
Specify new filenames for the duplicate database datafiles.
If you use a client-side parameter file to start the auxiliary instance, then specify the PFILE
parameter.
The following example uses configured 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.
Follow the steps in "Preparing the RMAN DUPLICATE Auxiliary Instance: Basic Steps", making sure to use an operating system utility to copy the parameter file from its location in the target host directory structure to the same location in the duplicate host directory structure. Set all initialization parameters that end in _DEST
and specify a path name.
Add the following features when creating the RMAN commands to perform the duplication:
Prepare CONFIGURE AUXNAME
commands for all datafiles, to be executed before database duplication.
If automatic auxiliary channels are not allocated, then allocate at least one auxiliary channel.
Use a 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.)
If you start the auxiliary instance with a client-side parameter file, then specify the PFILE
parameter. The client-side parameter file must reside on the same host as the RMAN client used to perform the duplication.
Example 13-2 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.
Example 13-2 Using CONFIGURE AUXNAME to Generate Database Filenames
# 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 future operations. For example, enter the following:
# clear specified auxiliary names for the datafiles CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR; CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; . . .
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.
Caution:
Do not use theNOFILENAMECHECK
option when duplicating to the same Oracle home as the primary database. If you do, then the DUPLICATE
command may overwrite the datafiles of the target database.The following sections discuss requirements when creating some or all files of the duplicate database in OMF or ASM storage:
When duplicating a database and storing the duplicate in OMF storage, you must make the following changes on the initialization parameter file for the duplicate database:
Set the DB_CREATE_FILE_DEST
initialization parameter to the desired OMF storage location. Any database files for which no other location is specified are created in DB_CREATE_FILE_DEST
during DUPLICATE
.
For a duplicate database that is not a standby database, change the value of the DB_NAME
initialization parameter. For a standby database, keep DB_NAME
the same, but change the DB_UNIQUE_NAME
initialization parameter.
If duplicating for standby, set the STANDBY_FILE_MANAGEMENT
initialization parameter to AUTO
.
Do not set the CONTROL_FILES
initialization parameter if you want to create the new control files as Oracle Managed Files. Oracle recommends that you use an SPFILE at the duplicate database when using OMF for the control file.
Do not set the DB_FILE_NAME_CONVERT
initialization parameter. This will allow the database to generate valid OMF filenames for the duplicate datafiles.
The default location for OMF files is DB_CREATE_FILE_DEST
. You can override the default for individual files using SET NEWNAME, as described in "Using SET NEWNAME with RMAN DUPLICATE to OMF".
Do not set the LOG_FILE_NAME_CONVERT
initialization parameter. This will allow the database to generate valid OMF redo log filenames.
To direct duplicate database online redo log files to OMF storage, you can use the DB_CREATE_FILE_DEST
, DB_RECOVERY_FILE_DEST
or DB_CREATE_ONLINE_LOG_DEST_
n
initialization parameters to identify an OMF location for the online logs. Table 13-8, "Oracle Managed Files Initialization Parameter Settings" explains how to choose among these options.
You must also decide:
How many copies of the control file are needed
How many online redo logs members are needed
Whether the online redo log and control file locations should be different from the datafile locations
These decisions determine whether you use the Oracle Managed Files initialization parameters DB_RECOVERY_FILE_DEST
, DB_CREATE_FILE_DEST
, or DB_CREATE_ONLINE_DEST_
n
.
Table 13-8 explains the required initialization parameter values, depending upon your requirements.
Table 13-8 Oracle Managed Files Initialization Parameter Settings
Copies of control files and online redo logs | Control file, online log, and datafile locations | Required Initialization parameters |
---|---|---|
n, where n is 3 or more |
Same or different |
|
n, where n is 1 or more |
Different |
|
2 |
Same |
|
1 |
Same |
|
The procedure for creating a duplicate database to an Automatic Storage Management (ASM) location is similar to the procedure described in "Initialization Parameters for RMAN DUPLICATE to OMF Storage". The difference is that you must edit the initialization parameter file in the auxiliary instance to set all parameters that control the location where files are created at the duplicate, such as DB_CREATE_FILE_DEST
, DB_CREATE_ONLINE_DEST_
n
, and CONTROL_FILES
, to the ASM disk group.
For example, edit the auxiliary instance parameter file as follows to create the database files in the disk group disk1
:
*.DB_CREATE_FILE_DEST = '+disk1'
If you want to store specific datafiles or tempfiles in an OMF destination, independent of the locations of the rest of the database files, then you can use the following steps:
Set the DB_CREATE_FILE_DEST
initialization parameter at the auxiliary instance to the desired location
Enclose the DUPLICATE
command in a RUN block
Use SET NEWNAME FOR DATAFILE ... TO NEW
and SET NEWNAME FOR TEMPFILE ... TO NEW
commands in the RUN block with the DUPLICATE
command
The specified files are created with OMF names in the location specified by DB_CREATE_FILE_DEST
.
This technique is similar to the scenario described in "Using RMAN DUPLICATE With SET NEWNAME: Example"
You can also use SET
NEWNAME
to direct individual datafiles or tempfiles to a specific ASM disk group. For example:
RUN { SET NEWNAME FOR DATAFILE 1 TO "+dgroup1"; SET NEWNAME FOR DATAFILE 2 TO "+dgroup2"; ... DUPLICATE TARGET DATABASE FOR STANDBY; }
This section presents several representative examples for using RMAN DUPLICATE
DATABASE
.
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:
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.
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.
Note:
DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT
convert the disk group name portion of the datafile and online log filenames. The new filenames in +DISK2 are generated by ASM and do not match the original filenames in disk group +DISK1.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';
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
You may want to synchronize a duplicate database with the original database that was duplicated. The solution is to run the DUPLICATE
DATABASE
command again, essentially re-creating the duplicate database.This technique requires making complete copies of the datafiles of the duplicate database.
In this example, RMAN connects to the database on host_src
as its target database and the duplicate database on host_dup
as an auxiliary database. The example uses the DUPLICATE
DATABASE
command to transfer complete copies of all updated datafiles from the source database to the duplicate site.
This example makes the same assumptions about file names, locations, and the datafiles to be duplicated in "Duplicating When the Datafiles Use Inconsistent Paths: Example".
As an initial setup step, the CONFIGURE
command is used to set persistent new names for the datafiles. These new names are recorded in the control file and used every time you perform the duplication in the future.
The script shown in Example 13-4 performs the one-time setup of the names for the datafiles.
Example 13-4 Configuring Auxiliary Names for 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';
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.
Example 13-5 Reduplicating the Database
# 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;
You can create an incremental backup of the target database containing changes to the database since the creation of the duplicate or the previous syncrhonization. You can apply the incremental backup to the standby database.
Note:
This technique cannot be used to update a duplicate database.RMAN enables you to synchronize a standby database with a primary database by creating an incremental backup at the source database that contains all changed blocks since the duplicate was created or last refreshed. You then apply the incremental backup to the standby database, which updates it with all changes.
This capability facilitates the temporary conversion of a physical standby database into a reporting database, as described in Oracle Data Guard Concepts and Administration. In particular, this capability makes it possible to reverse the effects of converting the standby into a reporting database. After the standby database has been used for reporting or testing, Flashback Database can reverse any changes resulting from that work, returning the database to its contents when it was still a standby. An incremental backup created with BACKUP
INCREMENTAL
... FROM
SCN
can be used to refresh the standby with changes at the primary since the conversion and then managed recovery can resume. The effect is to return the reporting database to its role as standby.
For more details on this scenario, see Oracle Data Guard Concepts and Administration.
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.
Note:
RECOVER
DATABASE
operation at the source database.The backup sets produced by this command are written to ?/dbs
by default, even if the flash recovery area or some other backup destination is defined as the default for disk backups.
You must create this incremental backup on disk for it to be useful. When you move the incremental backup to the standby, you must catalog it at the standby as described in "Step 3: Catalog the Incremental Backup Files at the Standby Database". Backups on tape cannot be cataloged.
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.
Create the needed incremental backup at the source database, using BACKUP
with the INCREMENTAL FROM SCN
clause.
Assume that the incremental backup to be used in updating the duplicate database is to be created on disk, with the filenames for backup pieces determined by the format /tmp/incr_for_standby/bkup_%U
.
RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE FORMAT '/tmp/incr_for_standby/bkup_%U';
Make the backup pieces containing the incremental backup available in some directory accessible on the system containing the standby database. For this example, assume that the destination directory is called /standbydisk1/incrback/
and ensure that it contains nothing besides the incremental backups from Step 1.
Use the RMAN CATALOG
command to register the backup sets in the RMAN repository at the duplicate. With an RMAN client connected to the standby database and the recovery catalog (if you use one at the standby), mount the standby and run the following command:
RMAN> CATALOG START WITH '/standbydisk1/incrback/';
The backups are now available for use in recovery of the standby.
Use the RMAN RECOVER
command with the NOREDO
option to apply the incremental backup to the standby database. All changed blocks captured in the incremental backup are updated at the standby database, bringing it up to date with the primary database. With an RMAN client connected to the standby database, run the following command:
RMAN> RECOVER DATABASE NOREDO;
You can now resume managed recovery at the standby. Any redo logs required at the standby with changes since those contained in the incremental are automatically requested from the primary and applied.