Recover a physical standby database by using an incremental backup

Introduction

A standby database is a consistent copy of the production database, which helps in production disasters, data loss, or corruption.

The following reasons might account for a lag between a primary and a standby site:

1. Network bandwidth issues between primary and standby databases.
2. Unavailability of the standby database.
3. Accidental deletion of archive redo data on the primary database.

You can sync primary and standby environments by copying and applying archive logs from the primary site, but this process is very time-consuming.

Another option is to recover the standby site using incremental RMAN backup of the primary site. You can also use this method when you have missing archived logs on the primary that the system never applied to the standby database.

Steps to recover a physical standby database by using an incremental RMAN backup

To set up this scenario, I manually removed some of the archive logs from the primary site to simulate corrupt logs or missing logs. 

Step 1: Check the sync status of the primary and standby site

You need to take a quick look at the sync status between the primary (prod) and standby (stby).

Primary site:

Standby site:

Step 2: Simulate a gap between the primary and standby 
You need to log on to the primary database and alter LOG_ARCHIVE_DEST_STATE_2 to DEFER. Then do the same manual log switches to generate some archive logs, thus creating a gap between primary and standby:

Now, if you take a look at the CURRENT_SCN between primary and standby, the standby isn't catching up because you have manually disabled the sync. 

Primary site:

Standby site:

 

If you now re-enable LOG_ARCHIVE_DEST_STATE_2, the standby automatically catches up. But you should not go for that option right away. To create a gap simulation, you need to delete the archive logs manually from the primary site.

Ensure that in both sites, you do not have archive logs later than 232 and 218 for threads 1 and 2, respectively.

Now, you need to re-enable LOG_ARCHIVE_DEST_STATE_2 (set to ENABLE):

As expected, the standby cannot continue applying the logs because some of the logs are missing from the primary site.

Finally, cancel the recovery and shut down the standby instance:

Step 3: Incremental backup 

Log on to the primary and take an incremental backup from the last SCN applied at the standby:

 

Step 4: Back up the standby control file 

Now, back up the control file on the standby site:

 Step 5: Ship the backups across to the standby site

Transfer the incremental backup that you just took to the standby site:

Step 6: Restore the standby control file

Restore the control file on the standby site:

Note: Ensure that you manually remove the old control files before executing the preceding commands to confirm that you are using the control files. 

Log on as a grid user and remove the old control files:

 

Step 7: Catalog the backup pieces 

Now, catalog the backup process:

 

 

 Step 8: Catalog existing data files

Also, catalog your existing data files:

Step 9: Switch the existing data files 

Switch all existing data files to their image copies

Step 10: Recover the database 

Now, recover your database:

 This step concludes the standby refresh. Just a few more steps to go!

Step 11: Check the sync status

Take a quick look at the sequences across both sites. Notice that the standby  caught up with the primary:

Primary site:

 Standby site:

Step-12: Start Media Recovery 

Start media recovery on the standby site:

Conclusion 

With the help of the preceding steps, you can recover the standby site. Using an incremental backup of your production environment saves a considerable amount of time.