Home
 | 
Articles
 | 
High Availability
 | 
Resolving Gaps in Data Guard Redo-Apply
 | 
Resolving gaps in Data Guard
 Redo-Apply using RMAN incremental
Overview
Recent Article
All Archives
Topics
Comments 
Last modified: August 2014
»
We know that the standby database is expected to be lagging behind the primary database (assuming this is an asynchronous non-real time apply). But what if the gap is significantly wide in terms of hours or days.
So, the first thing to do is check how much gap the standby is lagging. Let us take a look at the current SCNs between the primary and secondary to get some idea.
Taking stock of the Redo-Apply gap
On Primary:
CODE: SQL>
select current_scn from v$database;

    CURRENT_SCN
---------------
     3464085565
On standby:
CODE: SQL>
select current_scn from v$database;

    CURRENT_SCN
---------------
     3463940034
To know the real gap in terms of hours (on the primary first)
CODE: SQL>
select scn_to_timestamp(3464085565) from dual;

SCN_TO_TIMESTAMP(3464085565)
-------------------------------
11-AUG-12 10.40.18.000000000 AM
Running the same query on standby revealed the real gap. Pretty bad as it looks. More than 72 hours.
CODE: SQL>
select scn_to_timestamp(3464085565) from dual;

SCN_TO_TIMESTAMP(3463940034)
-------------------------------
08-AUG-12 08.20.25.000000000 AM
For some reason, the standby lost contact with the primary and the redo apply got stuck at some point that we saw little earlier. We aren't going to look the real cause. We are rather more interested in the solution to bring the standby forward close enough. So, for now we can assume that the connection issue is now resolved. But we have another problem. We seem to have lost a bunch of archive logs on the primary which we need them badly to move the standby forward. So, how do we resolve this gap?
One solution is to recreate the standby which we are not going to do given the enormous time that it may require us to recreate the standby. The easiest and effective solution here is to use RMAN incremental backup. So, we need to take an RMAN incremental backup from a specific SCN number that we need to apply on standby.
RMAN incremental backup
The first thing to do is to stop the managed standby apply process on the standby.
CODE: SQL>
alter database recover managed standby database cancel ;
shut immediate ;
By logging on to the primary, let's take an incremental backup from the SCN number where the standby had got stuck.
CODE: $
$ORACLE_HOME/bin/rman target /
CODE: RMAN>
run {
2> allocate channel c1 type disk format '/u01/orabackup/shannura/%U.rmb';
3> backup incremental from scn 3463940034 database;
4> }
On the primary, we need to create a new standby controlfile:
CODE: SQL>
alter database create standby controlfile as '/u01/orabackup/shannura/unicorn_standby.ctl' ;
Let's move these backup files and standby control controlfile across to the standby host.
CODE: $
scp -p /u01/orabackup/shannura/*.rmb *.ctl 192.168.1.11:/u01/orabackup/unicorn
We can startup the standby in nomount mode:
CODE: SQL>
startup nomount ;
I'm going to move/copy the new standby control file (that we just created in the previous step from primary) so as to overwrite the control file on standby.
CODE: SQL><>  
show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------------------------------------------------------
control_files                        string      /u03/control/phoenix/control01.ctl, /u04/control/phoenix/control02.ctl
CODE: $
cp -p /u01/orabackup/unicorn/unicorn_standby.ctl /u03/control/phoenix/control01.ctl
cp -p /u01/orabackup/unicorn/unicorn_standby.ctl /u04/control/phoenix/control02.ctl
Recovery on standby
We can mount the standby database:
CODE: SQL>
alter database mount standby database ;
Before we can start the recovery, we must tell RMAN the location of the new backup piece (incremental backup piece)
CODE: $
$ORACLE_HOME/bin/rman target /
CODE: RMAN>
catalog start with '/u01/orabackup/unicorn' ; 
By now, we can perform the recovery:
CODE: RMAN>
recover database ;
After sometime, the RMAN recovery may fail with the message that the next sequence is required. This is obvious because we have come to the last of the archived logs.
We can come out of RMAN and start the managed recovery process.
CODE: SQL>
alter database recover managed standby database disconnect from session ;
We can take a look at the SCNs on primary and standby once again and see if the standby is catching up with the primary after the recovery using incremental backup.
CODE: SQL>
select current_scn from v$database;

    CURRENT_SCN
---------------
     3464097910     
On standby:
CODE: SQL>
select current_scn from v$database;

    CURRENT_SCN
---------------
     3464097905
We can see that the standby is almost there catching up with the primary.
Please write your comment if this article was useful.

ShanNura

/
You might want to read this:
Refresh the Physical Standby using RECOVER…FROM SERVICE (12c)