Roll-forwarding a physical standby database is a procedure, technique and method typically used to resolve the huge archive gap between the primary and standby database that is caused by various reasons. It’s a faster and recommended approach to resolve the huge gap and make the standby database in line with the primary database in a quick fashion.
Most of the existing material in this context, explains only one approach, i.e. taking a fresh RMAN incremental back up on the primary database and then applying it on a standby database to fill the archive gap. In this article, I will be sharing an interesting scenario that I have confronted while building a standby database of 2TB sized database and how I resolved the issue taking a slight different approach to the problem.
The following is the typical roll-forward method is used to resolve the gap between the primary and standby databases. For example, when a huge gap, let’s say over 500 archives logs, is found on a physical standby database, you will follow the steps mentioned below to resolve the gap:
Now coming back to my situation, as part of the Disaster Recovery (DR) implementation project at our premises, a physical standby database of 1.5TB sized primary database was being configured. Due to slow network between the primary and disaster recovery (DR) sites, the standby database creation procedure triggered from RMAN (DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK ) took about 2 days of time to complete. When the standby database creation procedure was completed, the standby database was almost 2 days behind from the primary database with a larger number of archive log gap. What made the situation complex was there were couple of new data files added to the primary database during the course of standby database creation.
If I wanted to take the typical roll-forward approach in case, i.e. taking and applying fresh incremental backup, it is going to take a considerable time and there will be a gap again. The amount of archive logs produced per hour for the database is over 200, and imagine when we should be able to complete the synchronization in this context.
The below is a step-by-step procedure that followed to address the issue in my case:
The method and approach demonstrated in this paper can be used in any standby database environment to cover the huge gap between the primary and standby. Additionally, if you come across situation like my case, also, it would be very useful to address the gap or missing data files issues. This approach also explained how to make use of the backups stored in TAPES.
Contributed by Syed Jaffar Hussain