Incremental backup to recover standby

1. From the standby database, login as a DBA user and query the current scn.

SQL>select current_scn from v$database;

CURRENT_SCN

——————-

1233181

SQL>

(Do not close, leave the window as it is, we need it later.)

2. In the primary database, take the command prompt and connect to RMAN and issue the below command.

RMAN>backup as compressed backupset incremental from scn 1233181 database format ‘d:\backup\incr\incr_%U.bkp’;

Note: Drive letter may vary according to your installation. The folders “backup” and “incr” should be existing in the specified drive prior to starting the backup.
Otherwise the backup will stop with error.
RMAN will start the incremental backup of production/primary database from SCN 1233181. Note this SCN is derived from querying the
standby database which is not synchronized.

3. After completion of the incremental backup, copy the folder “backup” to the standby server.   This time I will use a different drive letter in the standby server. Say E:\.   Hence the folder structure will be E:\backup\incr\ and the incremental backup pieces from the production resides in this folder.

Take RMAN and connect as SYS.

Make RMAN aware of this backup pieces by cataloging the location to the RMAN repository.

RMAN>catalog start with ‘E:\backup\incr\’;

Now RMAN will list the files in the folder as unknown to the database and will ask confirmation for cataloging in the repository.

You type YES as the answer and hit ENTER key.

RMAN will now catalog the files.

4. Now you can tell RMAN to recover the standby database without applying any redo.

RMAN>recover database noredo;

RMAN will now apply the incremental changes from the SCN we specified in the backup command and make your standby nearly synchronized with the primary. I said “nearly synchronized ” since, it takes some small time for the backup and restore process. Perhaps a few archivelogs   will be created in the primary servers during this time.

5. Now start the managed recovery process from the sql*plus prompt which was open earlier. (If it was closed, open a new window)

SQL>alter database recover managed standby database disconnect from session;  

6. When checking you find that the standby database is still trying to apply same old log. Now you will check the scn after the refresh procedure to ensure whether it is updated and you find that it is not updated. But you are sure that you have applied the incremental changes from the scn to the standby database.

SQL>select current_scn from v$database;
CURRENT_SCN
——————-
1233181
SQL>

 To resolve this you have to refresh the standby controlfile.

7. From the production database server, take a backup of controlfile for standby.

RMAN>backup current controlfile for standby format ‘E:\standbycontrol.bkp’;

Copy the backup piece to any drive available in the standby server. (Say D:\)

8. In the standby server, shutdown the standby database if it is already mounted. Start the standby database in nomount state.

SQL>shutdown immediate
SQL>startup nomount

9. Then from RMAN, restore the standby controlfile from the newly created controlfile backup piece.

RMAN>restore standby controlfile from ‘D:\standbycontrol.bkp’;

You can exit the RMAN session.

10. Mount the standby database.

SQL>alter database mount;

11. Now start the managed recovery process from the sql*plus prompt which was open earlier. (If it was closed, open a new window)

SQL>alter database recover managed standby database disconnect from session;

The managed recovery process will start now and will start capturing and applying the latest archives which are created in the primary.