Purpose
This document describes a method of rolling forward a standby database using incremental backups (instead of the typical media recovery process MRP). The process uses an RMAN incremental backup taken on the primary database which is then applied to the standby database.Introduction
In normal cases when a gap occurs on a standby database normal gap detection and resolution processes can accurately and efficiently bring the standby up to date. However, in cases where a physical standby has fallen substantially behind from the primary database it can be beneficial to bring the standby current by using the method described within this article. The procedure described here can be more efficient for the large gap scenario as incremental backups on the primary and roll forward on the standby can be much faster than normal gap resolution. In most cases only a small subset of the primary database is altered so incremental backups (and subsequent roll forward) will only contain one complete block for each change versus a large number of change vectors for the same block if read through archivelogs. This process can be used under either of the following conditions:- When the standby database has fallen significantly behind the primary database and there have not been nologging operations performed on the primary database.
- When nologging operations have been performed on the primary database and the standby database has not yet applied past the point that the nologging operations occurred.
Steps
- Stop managed recovery if it is running and mount the standby database.
SQL> recover managed standby database cancel;
SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount standby database;
- Ensure that the primary database is already registered in the recovery catalog. Note that a recovery catalog must be used since there is no mechanism to manually catalog a backup piece in 9i.
$ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> register database;
- Using RMAN connect to the standby as the target database and catalog the remote standby datafiles as level 0 datafile copies.
$ rman target sys/oracle@stby catalog rman/rman@rcvcat
RMAN> catalog datafilecopy
'/u03/stby/system01.dbf',
'/u03/stby/undotbs01.dbf',
'/u03/stby/indx01.dbf',
'/u03/stby/tools01.dbf',
'/u03/stby/undotbs02.dbf',
'/u03/stby/users01.dbf'
level 0 tag 'STBY';
- Using RMAN connect to the primary database as the target and create the incremental level 1 backup
$ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> backup incremental level 1 tag 'STBY' database format '/private/%u';
- Transfer the incremental backup piece created in the above step to the same path on the standby host. Connect to the standby as the target database and roll forward the standby datafiles using the incremental backup.
$ rcp /private/<incr_backup> stby:/private/
$ rman target sys/oracle@stby catalog rman/rman@rcvcat
Note: If datafile names on standby are different, use SET NEWNAME to ensure all standby datafile names are retained:
RMAN> run {
set newname for datafile 1 to '/u03/stby/system01.dbf';
set newname for datafile 2 to '/u03/stby/undotbs01.dbf';
set newname for datafile 3 to '/u03/stby/indx01.dbf';
set newname for datafile 4 to '/u03/stby/tools01.dbf';
set newname for datafile 5 to '/u03/stby/undotbs02.dbf';
set newname for datafile 6 to '/u03/stby/users01.dbf';
switch datafile all;
recover database noredo;
}
Note: If datafile names are the same, just run the recover command:
RMAN> recover database noredo;
- Using RMAN delete the incremental backup and uncatalog the datafile copies.
$ rman target sys/oracle@prod catalog rman/rman@rcvcat
RMAN> delete backup tag 'STBY';
RMAN> change copy tag 'STBY' uncatalog;
- If the standby database is on the same host as the primary database then you must uncatalog the online redo logs that are registered in v$archived_log on the standby. The RECOVER DATABASE command issued in the above step will put entries in v$archived_log if the defined redo logs in the controlfile are accessible. A local standby will have access to the primary redo logs. If the standby database is not on the same host as the primary database then this step can be skipped.
$ rman target sys/oracle@stby catalog rman/rman@rcvcat
RMAN> change archivelog like '...' uncatalog;
- On the primary database recreate the standby controlfile. Transfer the new standby controlfile over to the standby host and mount the standby on the new controlfile.
SQL> alter database create standby controlfile as '/tmp/stby.ctl';
$ rcp /tmp/stby.ctl stby:/u03/stby
- Restart the standby database and start MRP
SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database disconnect;
Rolling a Standby Forward using an RMAN Incremental Backup in 10g
Purpose
This document describes a method of rolling forward a standby database using incremental backups (instead of the typical media recovery process MRP). The process leverages the RMAN incremental roll forward feature available starting with 10g Release 2.Introduction
In normal cases when a gap occurs on a standby database normal gap detection and resolution processes can accurately and efficiently bring the standby up to date. However, in cases where a physical standby has fallen substantially behind from the primary database it can be beneficial to bring the standby current by using the method described within this article. The procedure described here can be more efficient for the large gap scenario as incremental backups on the primary and roll forward on the standby can be much faster than normal gap resolution. In most cases only a small subset of the primary database is altered so incremental backups (and subsequent roll forward) will only contain one complete block for each change versus a large number of change vectors for the same block if read through archivelogs. This process can be used under either of the following conditions:- When the standby database has fallen significantly behind the primary database and there have not been nologging operations performed on the primary database.
- When nologging operations have been performed on the primary database and the standby database has not yet applied past the point that the nologging operations occurred.
Steps
1. Stop managed recovery on the physical standby database SQL> alter database recover managed standby database cancel;
2. Connect to the recovery catalog and the standby database as the target, and manually catalog the standby datafiles as datafile copies
RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host2/stby
RMAN> catalog datafilecopy
'/oracle/oradata/STBY/datafile/o1_mf_system_0chdb5sb_.dbf',
'/oracle/oradata/STBY/datafile/o1_mf_sys_undo_0chdb61n_.dbf',
'/oracle/oradata/STBY/datafile/o1_mf_sysaux_0chdb5wm_.dbf'
level 0 tag 'STBY';
3. Connect to the recovery catalog and the primary database as the target, and create an incremental level 1 backup using the datafile copies as the parent level 0.
RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host1/prod
RMAN> backup incremental level 1 tag 'STBY' for recover of copy with tag 'STBY' database format '/private/backup/%u';
4. Copy the newly created backup piece to the same location on the standby system
$ rcp /private/backup/<incr_backup> stby:/private/backup/
5. Connect to the recovery catalog and the standby database as the target, and roll the datafile copies forward
RMAN> connect catalog rman/rman@host1/rcvcat
RMAN> connect target sys/manager@host2/stby
RMAN> recover copy of database with tag 'STBY';
6. Delete incremental backup and uncatalog the standby datafiles as datafile copies
RMAN> delete backup tag 'STBY';
RMAN> change copy like '/oracle/oradata/STBY/datafile/%' uncatalog;
Note: The RECOVER COPY OF DATABASE command causes the 'STBY' tag associated with the datafile copies to change to '' (NULL) or back to a previous tag, if one had existed. Use CHANGE COPY LIKE to uncatalog the standby datafiles as copies.
7. Recreate the Standby Controlfile following
Steps to recreate a Physical Standby Controlfile (Doc ID 459411.1)
8. Restart managed recovery
SQL> alter database recover managed standby database disconnect;