This discussion is archived
1 2 Previous Next 25 Replies Latest reply: Aug 16, 2013 8:04 AM by 76423b7a-ff47-4e1f-bd68-5bd592e956d9 Go to original post RSS
  • 15. Re: ORA-16783: cannot resolve gap for database
    Pinela Journeyer
    Currently Being Moderated
    hum....
    2 things:

    1 - are the required archivelogs in the primary server? #43 and onward?
    2 - is the password file the same on both servers? there are posts in the forum about the file needing to be the same on 11g.
    3 - try connecting as suggested before:
    from primary $ sqlplus sys/<pass>@standby as sysdba 
    from standby $ sqlplus sys/<pass>@primary as sysdba
    br,
    jpinela.

    Edited by: Pinela on Dec 27, 2012 7:19 PM
  • 16. Re: ORA-16783: cannot resolve gap for database
    AlexAntonyArokiaraj Newbie
    Currently Being Moderated
    From Primary Database
    emadba@emarn1:~> sqlplus sys/password@emadbdg as sysdba
    
    SQL*Plus: Release 11.2.0.2.0 Production on Mon Dec 31 12:18:13 2012
    
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    
    SQL> 
    From Standby Database
    emadba@emarn2:~> sqlplus sys/password@emadbdg as sysdba
    
    SQL*Plus: Release 11.2.0.2.0 Production on Mon Dec 31 12:15:52 2012
    
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    
    
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Produc
  • 17. Re: ORA-16783: cannot resolve gap for database
    CKPT Guru
    Currently Being Moderated
    Alex Antony Arokiaraj wrote:
    Primary Node
    SQL> archive log list
    Database log mode            Archive Mode
    Automatic archival            Enabled
    Archive destination            /opt/app/oracle/oradata/emadb/archivelog1
    Oldest online log sequence     65
    Next log sequence to archive   67
    Current log sequence            67
    
    SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
    
    THREAD# MAX(SEQUENCE#)
    ---------- --------------
          1           925
    It is misleading the sequence column, Actual sequence number is 65 series but this is beyond. Have you restored any old backup with the same incarnation?
    When you perform incremental backups, did the current_scn in both primary and standby was matched?

    And the sequence number *29* is transferred from primary to standby (or) it was deleted from primary?
    Perform two methods.

    1) SQL> alter system set log_archive_dest_state_2='defer';
    2) perform 3-4 log switches
    3) SQL> alter system set log_archive_dest_state_2='enable';

    and post the information from primary and standby database alert log files.
    And you mentioned host name in listener entries, whether that entry is added in /etc/hosts? if not you can use IP address instead of host name and then reload the listener.

    second method
    1) copy the missing archives from primary of sequence 29
    2) Apply manually and then perform recovery
    or
    3) recover manually


    And update with your findings after all above lists.
    Thanks.
  • 18. Re: ORA-16783: cannot resolve gap for database
    Pinela Journeyer
    Currently Being Moderated
    hello ckpt,

    you mention in method #2, seq# 29.
    but the OP(and the DB) says:
    >
    SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
     
       THREAD# MAX(SEQUENCE#)
    ---------- --------------
          1            42
    so he would just need to worry about 42 onward, right?
    or am I missing something?

    br, happy new year,
    jpinela.
  • 19. Re: ORA-16783: cannot resolve gap for database
    CKPT Guru
    Currently Being Moderated
    Pinela wrote:
    hello ckpt,

    you mention in method #2, seq# 29.
    but the OP(and the DB) says:
    >
    SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
    
    THREAD# MAX(SEQUENCE#)
    ---------- --------------
          1            42
    so he would just need to worry about 42 onward, right?
    or am I missing something?

    br, happy new year,
    jpinela.
    You know? the v$archived_log applied column can be get based on latest, So if the controlfile is restored from the primary in the process of incremental roll forward of course it shows latest information. but at the same time in one of post OP mentioned below comments.

    >
    Also I m getting this message in the alert file for more than a day, since I had performed this RollForward Standby DB

    Fetching gap sequence in thread 1, gap sequence 29-42
    Thu Dec 27 17:01:45 2012
    Fetching gap sequence in thread 1, gap sequence 29-42
    Thu Dec 27 17:01:56 2012
    Fetching gap sequence in thread 1, gap sequence 29-42
    Thu Dec 27 17:02:06 2012
    Fetching gap sequence in thread 1, gap sequence 29-42
    Thu Dec 27 17:02:16 2012
    Fetching gap sequence in thread 1, gap sequence 29-42
    >

    So the sequence from *29* is not yet applied. There is something wrong in the process of incremental roll forward. Either OP has to apply manually or perform incremental in a correct manner. Right now my blog is under migration to new hosting so my URL not working. :(
    You can also refer http://docs.oracle.com/cd/B28359_01/server.111/b28294/rman.htm#CIHIAADC

    Will this helps?

    Thanks for your wishes and wish you the same. :)
  • 20. Re: ORA-16783: cannot resolve gap for database
    AlexAntonyArokiaraj Newbie
    Currently Being Moderated
    Hi CKPT and Pinela,

    Thank you very much for your kind responses. Your tips were very helpful.

    Finally, I have restored the Standby database and the Data Guard shows no errors
    Welcome to DGMGRL, type "help" for information.
    Connected.
    DGMGRL> show configuration verbose
    
    Configuration - DRSolution
    
      Protection Mode: MaxAvailability
      Databases:
        emadb   - Primary database
        emadbdg - (*) Physical standby database
    
      (*) Fast-Start Failover target
    
      Properties:
        FastStartFailoverThreshold      = '30'
        OperationTimeout                = '30'
        FastStartFailoverLagLimit       = '30'
        CommunicationTimeout            = '180'
        FastStartFailoverAutoReinstate  = 'TRUE'
        FastStartFailoverPmyShutdown    = 'FALSE'
        BystandersFollowRoleChange      = 'ALL'
    
    Fast-Start Failover: ENABLED
    
      Threshold:        30 seconds
      Target:           emadbdg
      Observer:         emarn2
      Lag Limit:        30 seconds (not in use)
      Shutdown Primary: FALSE
      Auto-reinstate:   TRUE
    
    Configuration Status:
    SUCCESS
    
    DGMGRL> show database emadb
    
    Database - emadb
    
      Role:            PRIMARY
      Intended State:  TRANSPORT-ON
      Instance(s):
        emadb
    
    Database Status:
    SUCCESS
    
    DGMGRL> show database emadbdg
    
    Database - emadbdg
    
      Role:            PHYSICAL STANDBY
      Intended State:  APPLY-ON
      Transport Lag:   0 seconds
      Apply Lag:       0 seconds
      Real Time Query: OFF
      Instance(s):
        emadbdg
    
    Database Status:
    SUCCESS
    Thank you very much for your support and Wishing you a Happy New Year 2013 as well.
  • 21. Re: ORA-16783: cannot resolve gap for database
    CKPT Guru
    Currently Being Moderated
    Alex Antony Arokiaraj wrote:
    Hi CKPT and Pinela,

    Thank you very much for your kind responses. Your tips were very helpful.

    Finally, I have restored the Standby database and the Data Guard shows no errors
    This is not the solution :( of course your database is small and you restored in minutes/hours.
    Then think of database size in 2-5 TB, Will you restore whole standby whenever issue comes?

    Try to fix at most, If any unresolvable after consulting Oracle support then you can certainly chose that option.
    - Thanks.
  • 22. Re: ORA-16783: cannot resolve gap for database
    Pinela Journeyer
    Currently Being Moderated
    ok.
    so, basically, when using roll forward process, the v$archived_log is not trustworthy.
    interesting to know.

    thank you.

    br,
    jpinela.
  • 23. Re: ORA-16783: cannot resolve gap for database
    Pinela Journeyer
    Currently Being Moderated
    yes, CKPT.
    you managed a workaround, and that will do for now.
    but you should closely monitor the configuration (issue some log switches) and see if they transport and apply.

    br,
    jpinela.
  • 24. Re: ORA-16783: cannot resolve gap for database
    user8665771 Newbie
    Currently Being Moderated
    Hi,


    Plz give the output of the below query(primary).

    1)select DEST_ID,DEST_NAME,STATUS,ERROR FROM V$ARCHIVE_DEST_STATUS;

    2) alter system switch logfile;

    3)select DEST_ID,DEST_NAME,STATUS,ERROR FROM V$ARCHIVE_DEST_STATUS;
  • 25. Re: ORA-16783: cannot resolve gap for database
    76423b7a-ff47-4e1f-bd68-5bd592e956d9 Newbie
    Currently Being Moderated

    Hi CKPT,

     

    I have faced the same issue and I would like to know what do you mean by step 2 

     

    1) SQL> alter system set log_archive_dest_state_2='defer';

    2) perform 3-4 log switches

    3) SQL> alter system set log_archive_dest_state_2='enable';

1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points