2 Replies Latest reply: Dec 12, 2012 9:49 AM by CKPT RSS

    Diagnosing gaps at the Physical Standby Side

    spiral
      Version: 11.2.0.3
      Platform : RHEL 5.4

      Are the below queries your step1 in determining a gap at a physical standby side?
      -- on primary
      select max(sequence#) from v$archived_log;
      
      -- on Standby
      select max(sequence#) from v$archived_log where applied='YES';
      If you do find a difference in the sequence from the above query , what should be the next thing one should be looking for (for further diagnosis ) ?
        • 1. Re: Diagnosing gaps at the Physical Standby Side
          mseberg
          Hello;

          It works better from the primary side.

          try this :

          http://www.visi.com/~mseberg/monitor_data_guard_transport.html

          If you have a gap larger than 5 or 6 I would check the alert log on the standby first. Generally you will see a message with the sequence number "Waiting for log..."

          If you have an issue you may see an error message, if nothing check the primary alert log next.

          Best Regards

          mseberg
          • 2. Re: Diagnosing gaps at the Physical Standby Side
            CKPT
            spiral wrote:
            Version: 11.2.0.3
            Platform : RHEL 5.4

            Are the below queries your step1 in determining a gap at a physical standby side?
            -- on primary
            select max(sequence#) from v$archived_log;
            
            -- on Standby
            select max(sequence#) from v$archived_log where applied='YES';
            If you do find a difference in the sequence from the above query , what should be the next thing one should be looking for (for further diagnosis ) ?
            As MSeberg said, first visit alert log files
            second dynamic views
            Ex:- SQL> select severity,error_code,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status where dest_id=<>;
            Mention remote destination number above, also you can check view for the current log what is writing and applying from v$managed_standby