Skip to Main Content

Database Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Dataguard : MRP still in WAIT_FOR_GAP after incremental backup recover

Ray ZinMay 19 2015 — edited May 21 2015

Hello,

I am new to dataguard configuration, and I recently connected on a dataguard configuration for testing purpose.

I have stupidely removed some archive log files from my primary database, thus breaking the update of standby (due to the fact that the database was not started during long time, the gap is now around 130 days ).

To try recover from the situation I have re-synchronized the SCN from the standby using an incremental backup (and creating standby control files from primary).

After recover, both SCN were the same, but restarting the recovery service (MRP), it is still stating WAIT_FOR_GAP, and still waiting for my missing archive logs.

New archive logs are well shipped to the standby though.

Any idea what I have missed or what should I do?

The database version is a 12.1.0.1.

DGMGRL> show configuration

Configuration - g12dggo

  Protection Mode: MaxPerformance

  Databases:

  g12dggop - Primary database

    Error: ORA-16724: cannot resolve gap for one or more standby databases

    g12dggos - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

ERROR

DGMGRL> validate database g12dggop

  Database Role:    Primary database

  Ready for Switchover:  Yes

  Flashback Database Status:

    g12dggop:  Off

DGMGRL> validate database g12dggos

  Database Role:     Physical standby database

  Primary Database:  g12dggop

  Ready for Switchover:  No

  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:

    g12dggop:  Off

    g12dggos:  Off

  Standby Apply-Related Information:

    Apply State:      Running

    Apply Lag:        143 days 14 hours 18 minutes 26 seconds

    Apply Delay:      0 minutes

From standby database:

SQL> select process,sequence#,status from v$managed_standby;

PROCESS    SEQUENCE# STATUS

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

ARCH               0 CONNECTED

ARCH               0 CONNECTED

RFS                0 IDLE

MRP0            1965 WAIT_FOR_GAP

RFS             3526 IDLE

Most little sequence of table v$archived_log is corresponding to the last recover done.

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

SEQUENCE# APPLIED

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

      3441 NO

SQL> select * from v$archived_log where sequence#=3441;select * from v$archived_log where sequence#=3441;

     RECID      STAMP

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

NAME

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

   DEST_ID    THREAD#  SEQUENCE# RESETLOGS_CHANGE# RESETLOGS_TIME      RESETLOGS_ID FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME               BLOCKS BLOCK_SIZE CREATOR

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

REGISTR STA ARC APPLIED   DEL S COMPLETION_TIME     DIC DIC END BACKUP_COUNT ARCHIVAL_THREAD# ACTIVATION# IS_ COM FAL END_OF_RED BAC     CON_ID

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

         1  880046905

/oravar/G12DGGO/archiv/1_3441_865786197.dbf

         2          1       3441                 1 08/12/2014 16:09:57    865786197       7004011 18/05/2015 17:21:17      7005043 18/05/2015 17:29:22        509        512 ARCH

RFS     NO  YES NO        NO  A 18/05/2015 17:28:25 NO  NO  NO             0                1  2523036437 NO  NO  YES            NO           0

Thanks in advance for your help!

This post has been answered by Ray Zin on May 21 2015
Jump to Answer
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Jun 18 2015
Added on May 19 2015
14 comments
17,637 views