A standby database is basically the consistent copy of the production database, which helps in production disasters, data loss, or corruption.
Introduction
The following reasons might account for a lag between a primary and a standby site:
- Network bandwidth issues between primary and standby databases.
- Unavailability of the standby database.
- 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 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, obviously, 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 the 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.
Learn more about our Database services.
Use the Feedback tab to make any comments or ask questions. You can also start a conversation with us.