6 Replies Latest reply: Dec 2, 2013 8:15 PM by petra-K RSS

    DG Standby db complicating its report

      Hi All,

       

      11.2.0.1

      Aix .6.1

       

      After the MRP0 was down and activated, my standby status again is not consistent.

       

      At PRIMARY, I run >  select process,status,sequence# from v$managed_standby;

       

      PROCESS   STATUS        SEQUENCE#

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

      ARCH      WRITING            3505

      ARCH      CLOSING            3515

      ARCH      WRITING            3506

      ARCH      WRITING            3507

      LNS       WRITING            3516

       

      Then at STANDBY , I also run > select process,status,sequence# from v$managed_standby;

       

      PROCESS   STATUS        SEQUENCE#

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

      ARCH      CLOSING            3504

      ARCH      CONNECTED             0

      ARCH      CLOSING            3501

      ARCH      CLOSING            3502

      RFS       IDLE               3516

      RFS       IDLE               3506

      RFS       IDLE               3507

      MRP0      WAIT_FOR_LOG       3505

      RFS       IDLE               3505

       

      9 rows selected.


      Why is that my PRIMARY is already at 3516? while my standby is on at 3505?


      Please help,

      Thanks

        • 1. Re: DG Standby db complicating its report
          mseberg

          Hello;

           

          v$managed_standby is not he best source of information on a database in Primary mode. It should be used for status of processes related to physical standby databases in the Data Guard environment.

           

          What issue or concern do you have with your DG setup?

           

          Try this on your primary:

           

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

           

          Best Regards

           

          mseberg

          • 2. Re: DG Standby db complicating its report

            I checked the STANDBY archivelog folder and I saw that log 3507 and 3508 are missing? How do missing logs happened?

            I am now trying to  copy the missing from Primary, I hope this will resolve the issue. So far for a long time, I just encountered it.

            • 3. Re: DG Standby db complicating its report

              Hi Ms,

               

              SQL> SET PAGESIZE 140

              SQL> COL DB_NAME FORMAT A10

              SQL> COL HOSTNAME FORMAT A14

              SQL> COL LOG_ARCHIVED FORMAT 999999

              SQL> COL LOG_APPLIED FORMAT 999999

              SQL> COL LOG_GAP FORMAT 9999

              SQL> COL APPLIED_TIME FORMAT A14

              SQL> SELECT

                2     DB_NAME, HOSTNAME, LOG_ARCHIVED, LOG_APPLIED, APPLIED_TIME, LOG_ARCHIVED-LOG_APPLIED LOG_GAP

                3  FROM

                4  ( SELECT

                5     NAME DB_NAME

                6  FROM

                7     V$DATABASE

                8  ),

                9  (

              10  SELECT

              11     UPPER(SUBSTR(HOST_NAME,1,(DECODE(INSTR(HOST_NAME,'.'),0,LENGTH(HOST_NAME), (INSTR(HOST_NAME,'.')-1))))) HOSTNAME

              12  FROM

              13     V$INSTANCE

              14  ),

              15  (

              16  SELECT

              17     MAX(SEQUENCE#) LOG_ARCHIVED

              18  FROM

              19     V$ARCHIVED_LOG

              20  WHERE

              21     DEST_ID=1

              22  AND

              23     ARCHIVED='YES'

              24  ),

              25  (

              26  SELECT

              27     MAX(SEQUENCE#) LOG_APPLIED

              28  FROM

              29     V$ARCHIVED_LOG

              30  WHERE

              31     DEST_ID=2

              32  AND

              33     APPLIED='YES'

              34  ),

              35  (

              36  SELECT

              37     TO_CHAR(MAX(COMPLETION_TIME),'DD-MON/HH24:MI') APPLIED_TIME

              38  FROM

              39     V$ARCHIVED_LOG

              40  WHERE

              41     DEST_ID=2

              42  AND

              43     APPLIED='YES'

              44  );

               

               

              DB_NAME    HOSTNAME       LOG_ARCHIVED LOG_APPLIED APPLIED_TIME   LOG_GAP

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

              PROD1      SERVER1                3515        3499 02-DEC/21:01        16

              • 4. Re: DG Standby db complicating its report
                mseberg

                Odd;

                 

                I have never had that happen, but I've hear it reported before.

                 

                You may have to use this after the copy:

                 

                ALTER DATABASE REGISTER LOGFILE

                 

                Example:

                 

                ALTER DATABASE REGISTER LOGFILE '/u01/app/oracle/oradata/STANDBY/archive/PRIMARY_1_21_716110538.arc';

                 

                It may throw a warning that it is registered already.

                 

                I have never had much luck with V$ARCHIVE_GAP. I would use the query from the link and see if the gap goes away.

                 

                Best Regards

                 

                mseberg

                • 5. Re: DG Standby db complicating its report

                  Hi all,

                   

                  I finished copying log 3507 and 3508 to the Standby. But why is that it is not automating the transfer anymore? I see new archivelogs 3509 upto 3515  current at PRIMARY

                  which is not transferred to STANDBY. I keep on manually transferring them. How do I resume it automated transfer?

                   

                   

                  Thanks

                  • 6. Re: DG Standby db complicating its report

                    Oops...MY MISTAKE

                     

                    The archive log which I thought are missing were created under a new date folder, and I was looking for the old report which I thought did not apply the logs, then panicked....Its all ok now. Thankssss