RE-SYNCHRONIZING DATA GUARD.

When we use Standby Databases, an error that can happen (but shouldn't) is that at some point you may have so-called "GAPs" in the REDO log threads and then our Data Guard stops working and in the alert.log you may see a message like this.

Fetching gap sequence in thread 1, gap sequence 13809-13820

To explain further, this is because Data Guard works from the REDO log threads that are sent from the principal database to the standby database whenever a log switch occurs.

If for some reason the communication between the servers is interrupted, during this downtime the main database will work and generate the archive logs normally and when communication is re-established, these archive logs will be used to synchronize the databases.

Now imagine if for some reason you go 24 hours or more without communication between the servers, to do this synchronization the two servers will be overloaded due to the high volume of information that needs to be sent back and forth, in addition, imagine if when communication is re-established, a backup has already been performed on the primary server with the "" option or something like that? BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT

Now you no longer have the archive logs on your server and in the alert.log of the Standby server you will receive the message:

Fetching gap sequence in thread 1, gap sequence 13809-13820

To solve this kind of situation, we can use an incremental backup to re-synchronize the databases, but here comes the question:

Question: An incremental backup from where?

Answer: From the last SCN (System Change Number) of the Standby database, because it will be exactly from the last information that was recorded on the Standby server and to do this perform the step by step below:

1 – If the Redo Apply (MRP media recovery process) process is active, stop it:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2 – Check the Standby server for the last SCN with the select below:

SQL> SELECT CURRENT_SCN FROM V$DATABASE; CURRENT_SCN ----------- 8885952

3 – Now that you have the value of the last SCN of the Standby database, on the principal database make an incremental backup from it: RMAN> run { allocate channel d1 type disk; allocate channel d2 type disk; backup incremental from scn 8885952 database format '/tmp/dba/bkups/GAPDB_%U'; release channel d1; release channel d2; }

4 – Once the backup is finished, create a standby control file on the primary server: SQL> ALTER DATABASE CREATE STANDBY CONTROL FILE AS ‘/tmp/dba/bkups/STD_CONTROL.ctl’

5 – Copy the backup files along with the new standby control file to the standby server, in the same directories where they were created on the primary server.

6 – Re-start the standby server in mount mode and then access RMAN and run the commands "CATALOG START WITH" and "RECOVER DATABASE NOREDO".

sqlplus / as sysdba SQL*Plus: Release 11.2.0.2.0 Production on Mon Jul 16 11:39:22 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. Connected to an idle instance SQL> startup mount; ORACLE instance started. Total System Global Area 2137886720 bytes Fixed Size 2228200 bytes Variable Size 503316504 bytes Database Buffers 1627389952 bytes Redo Buffers 4952064 bytes Database mounted. SQL> exit

rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Mon Jul 16 11:39:48 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: BPMPRD01 (DBID=572426427, not open)

RMAN> CATALOG START WITH '/tmp/dba/bkups/'; RMAN> RECOVER DATABASE NOREDO;

7 – If there was no error at all in this process, the servers are already re-synchronized, now just re-activate the Redo Apply process (MRP media recovery process) so that everything can return to normal.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;