Resolving Gaps in Data Guard Apply Using Incremental RMAN BAckup

for simplicity, Gap is a range of archived redo logs that were created at a time when the standby database was not available to receive them.

in many practices it happen because the network problems.

We have 3 method to resolving this problem. i'll dispatch it to two main methods,

1. Manually resolving
2. Automatic resolving : Using log switched and FAL configuration

1. start with detecting gaps in the redo logs by querying the v$archive_gap

SQL> select * from v$archive_gap;

thread# low_sequence# high_sequence#

-------- ---------------- ------------------

     1          30           34 

  the output indicates our standby database is currently missing log files from sequence 30 to

  34.

2. issue following statement on primary database to locate the archived redo log files. assuming 

  the local archive destination on primary is LOG_ARCHIVE_DEST_1

SQL> select name from v$archived_log where thread#=1 and dest_id=1 and sequence# between 30 and 34; 

name

----------------------------------

/u02/oraarchive/DB01/arch_t1_s30.dbf  

/u02/oraarchive/DB01/arch_t1_s31.dbf  

/u02/oraarchive/DB01/arch_t1_s32.dbf  

/u02/oraarchive/DB01/arch_t1_s33.dbf  

/u02/oraarchive/DB01/arch_t1_s34.dbf 

3. stop the automatic recovery (MRP) of the data guard

SQL> alter database recover managed standby database cancel;

4. transfer manually the archived log files shown on the step 2 to standby database

5. register that archived log files on standby database

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s30.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s31.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s32.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s33.dbf'; 

SQL> alter database register logfile '/u02/oraarchive/DB01/arch_t1_s34.dbf'; 

6. put the standby database into automatic recovery managed mode

 SQL> alter database recover managed standby database disconnect from session;

7. verify that the gap gets resolved on standby database

SQL> select sequence#, applied from v$archived_log order by sequence#; 

now you figure it out, that your archived log files (ARCLs) has been synchronize with your primary database. as a DBA you must take a notice at log using this SQL statement

SQL> select message from v$dataguard_status where severity like 'Warning';

also on your alert.log

hope it will make your day easier.