Tuesday 24 November 2015

Resolve Archive gap between PRIMARY and STANDBY

To Check the below query to confirm ARCHIVE GAP Primary and Standby  servers.


A Physical Standby database syncs with Primary by continuous apply of archive logs from a Primary Database.
When the logs are missing on standby difference is huge (Suppose  more than 600 logs), you have to rebuild the standby database from scratch.

Please use below query to find out archive gap on Standby STEP 1:
set time on
set lines 200

prompt ++++++++++++++++++++LAST SEQUENCE RECIEVED FROM PRODUCTION and APPLIED ON STANDBY+++++++++++++++++++++++++

SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received", APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"
FROM
(SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
(SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
WHERE
ARCH.THREAD# = APPL.THREAD#
;
OUTPUT ARCHIVE:-
    Thread Last Sequence Received Last Sequence Applied Difference
---------- ---------------------- --------------------- ----------
         2                  31852                 31852          50
         1                  49127                 49127          50
prompt ++++++++++++++++++++CHECK FOR GAP AT STANDBY+++++++++++++++++++++++++

SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
exit
Find the SCN on the PRIMARY STEP 2:
SQL> select current_scn from v$database;
 
CURRENT_SCN
———–  
222271661
Find the SCN on the STANDBY:
 
SQL> select current_scn from v$database;
CURRENT_SCN
———–  
223762173
Clearly you can see there is difference
In Primary Server will take increment level  backup with SCN STEP 3:-
run {
allocate channel c1 type disk format ‘/oradata/ora_backup/rman/QTSMMDB/%U.bkp’;
backup  AS COMPRESSED BACKUPSET  incremental from scn 223762173 database;
}
run
{
allocate channel c1 type disk format
‘/oradata/ora_backup/rman/QTSMMDB/%U.bkp’;
backup current controlfile for standby;
}
Stop and shutdown the managed standby apply process STEP 4:
SQL> alter database recover managed standby database cancel;
Database altered.
Shutdown the standby database
SQL> shut immediate
Step 5:-
Copy the backup dump to  standby instance.
step 6:-
Connect to RMAN on STANDBY, Catalog backup files to RMAN using below commands STEP 7:
$ rman target /
RMAN> startup nomount;
RMAN> catalog start with ‘/oradata/ora_backup/Standby/c-3875280703-20150907-02’;
RMAN> restore standby controlfile from
'/oradata/ora_backup/Standby/c-3875280703-20150907-02';
RMAN> sql 'alter database mount standby database';
RMAN> catalog start with ‘/oradata/ora_backup/Standby/’;
PERFORM RECOVER:
RMAN> recover database;
Start managed recovery process STEP 8:
SQL> alter database recover managed standby database disconnect from session;
Database altered.
Check the SCN’s in primary and standby it should be close to each other.

6 comments:

  1. Hello,

    Can you please help on below:
    In our case, we are using ASM. and location of datafile is different on primary and standby. On primary we have +DATAC2 and on standby we have +DATAC1. So if we create a control file for standby from primary database, it has location as +DATAC2. Now we start the standby database with this control file, will it automatically change the location to +DATAC1? Do we need to manually update that. Is there any other way to work around this. Please help on the same. Thank You!

    ReplyDelete
    Replies
    1. Hi,
      If you've mentioned db_file_name_convert and log_file_name_convert parameters.Locations will get updated automatically based on that...

      Delete
    2. I configure for RAC to 1 STANDBY DG NODE, I get the following error:
      RMAN> recover database;

      Starting recover at 23-AUG-19
      using target database control file instead of recovery catalog
      allocated channel: ORA_DISK_1
      channel ORA_DISK_1: SID=11 device type=DISK
      RMAN-00571: ===========================================================
      RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
      RMAN-00571: ===========================================================
      RMAN-03002: failure of recover command at 08/23/2019 11:05:12
      RMAN-06094: datafile 1 must be restored

      RMAN>

      Delete
    3. Hi Matrix,

      You got this error because a standby controlfile is recreated, by restoring it from the primary site, the datafile names as shown in v$datafile and RMAN's REPORT SCHEMA will actually reflect those of the primary database rather than the standby database.

      You can check this by REPORT SCHEMA command in RMAN.

      Please follow the doc id--RMAN-06094 or RMAN-06571 During Recovery or Switch to Copy at Standby Site (Doc ID 1339439.1)

      Although you must have solved it. You've got this long back.

      Thanks,

      Delete
  2. quick qustion please, with the primary and stby having the same scn, does it mean the lag caught up?

    ReplyDelete