A standby database is basically the 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:
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.
To set up this scenario, I manually removed some of the archive logs from the primary site to simulate corrupt logs or missing logs.
You need to take a quick look at the sync status between the primary (prod) and standby (stby).
You need to log on to the primary database and alter LOG_ARCHIVE_DEST_STATE_2
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.
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
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:
Log on to the primary and take an incremental backup from the last SCN applied at the standby:
Now, back up the control file on the standby site:
Transfer the incremental backup that you just took to the standby site:
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:
Now, catalog the backup process:
Also, catalog your existing data files:
Switch all existing data files to their image copies:
Now, recover your database:
This step concludes the standby refresh. Just a few more steps to go!
Take a quick look at the sequences across both sites. Notice that the standby caught up with the primary:
Start media recovery on the standby site:
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.
Use the Feedback tab to make any comments or ask questions. You can also start a conversation with us.