4 Replies Latest reply: May 14, 2014 4:51 AM by 989969 RSS

    why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

    989969

      Hello @,

       

      i am receiving following notification in my primary db alert

       

      ******************************************************************

      LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

      ******************************************************************

      LNS: Standby redo logfile selected for thread 1 sequence 19008 for destination LOG_ARCHIVE_DEST_2

      Tue May 13 21:27:37 2014

      Thread 1 advanced to log sequence 19009 (LGWR switch)

        Current log# 1 seq# 19009 mem# 0: M:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO01.RDO

        Current log# 1 seq# 19009 mem# 1: N:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO01_1.RDO

      Tue May 13 21:27:37 2014

      ******************************************************************

      LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

      ******************************************************************

      LNS: Standby redo logfile selected for thread 1 sequence 19009 for destination LOG_ARCHIVE_DEST_2

      Tue May 13 21:27:37 2014

      Archived Log entry 36429 added for thread 1 sequence 19008 ID 0x36b84d24 dest 1:

      Tue May 13 21:54:14 2014

      Thread 1 advanced to log sequence 19010 (LGWR switch)

        Current log# 2 seq# 19010 mem# 0: M:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO02.RDO

        Current log# 2 seq# 19010 mem# 1: N:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO02_1.RDO

      Tue May 13 21:54:15 2014

      ******************************************************************

      LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

      ******************************************************************

      LNS: Standby redo logfile selected for thread 1 sequence 19010 for destination LOG_ARCHIVE_DEST_2

      Tue May 13 21:54:15 2014

      Archived Log entry 36431 added for thread 1 sequence 19009 ID 0x36b84d24 dest 1:

       

      =======

       

       

      both standby and primary db are in maximum performance mode and delay of 180 mins.

      db version : 11.2.0.1

       

      i started redo apply in standby using

      " alter database recover managed standby database disconnect from session;"

       

      i tried " alter system archive log current"  and "alter system switch logfile;" in primary db.

      it doesent changes the status of standby redo logfile in standby database;

       

      i tried  SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG; ------ in standby db and output is

       

          GROUP#    THREAD#  SEQUENCE# ARC STATUS

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

               7          1      19010 YES ACTIVE

               8          0          0 YES UNASSIGNED

               9          0          0 YES UNASSIGNED

      .. it remains same for multiple thread# (19006 ..... to 19010)

       

      why i am getting this ..

      ******************************************************************

      LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

      ******************************************************************

      thanks in advance

       

      Regards

      Gold

        • 1. Re: why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
          mseberg

          Hello;

           

          I believe you must be using "Real-time apply"

           

          In any event its just an information message.

           

           

           

           

           

          Best Regards

           

          mseberg

          • 2. Re: why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
            989969

            thankyou ......

             

            but i know the for sure that i started the redo apply by " alter database recover managed standby database disconnect from session"

            and more over why the stb. refo log files are in unassaigned state even after many log switch manually  and by oracle itself

             

            can you tell this why ?

            • 3. Re: why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
              Anand...

              Hi,

               

              We are using real time apply and I have observed that on standby only 2 groups gets used when switch happens. If you perform switch on primary , the status of only 2 standby logfile groups gets changed between active and unassigned. You can even check the standby logfile member name in the alert log and it would belong to 2 groups in v$standby_log.

               

              Its just my observation on my databases, even i didn't check more on that.

               

               

              Anand

               

              Added "We are using real time apply " Message was edited by: Anand...

              • 4. Re: why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
                989969

                thanks anand....

                 

                i have started redo log apply in my standby and the delay is working fine in standby database. i can see that in standby alert

                 

                standby alert:

                ===========

                 

                RFS[877]: Assigned to RFS process 2128

                RFS[877]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:51:27 2014

                RFS[878]: Assigned to RFS process 2340

                RFS[878]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:51:33 2014

                Media Recovery Log L:\ORACLE\PRODUCT\11.2.0\FLASH_RECOVERY_AREA\WDEGSTB\ARCHIVELOG\2014_05_14\O1_MF_1_19033_9Q6133GX_.ARC

                Media Recovery Delayed for 180 minute(s) (thread 1 sequence 19034)

                Wed May 14 10:52:19 2014

                Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST

                Archived Log entry 507 added for thread 1 sequence 19048 ID 0x36b84d24 dest 1:

                ARC5: Archive log thread 1 sequence 19048 available in 179 minute(s)

                Wed May 14 10:52:19 2014

                RFS[879]: Assigned to RFS process 3336

                RFS[879]: Identified database type as 'physical standby': Client is LGWR ASYNC pid 2180

                Primary database is in MAXIMUM PERFORMANCE mode

                RFS[879]: Selected log 7 for thread 1 sequence 19049 dbid 918047780 branch 814944743

                Wed May 14 10:52:28 2014

                RFS[880]: Assigned to RFS process 1340

                RFS[880]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:53:28 2014

                RFS[881]: Assigned to RFS process 348

                RFS[881]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:54:28 2014

                RFS[882]: Assigned to RFS process 3168

                RFS[882]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:55:28 2014

                RFS[883]: Assigned to RFS process 2316

                RFS[883]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:56:28 2014

                RFS[884]: Assigned to RFS process 3856

                RFS[884]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:57:28 2014

                RFS[885]: Assigned to RFS process 3548

                RFS[885]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:58:28 2014

                RFS[886]: Assigned to RFS process 3432

                RFS[886]: Identified database type as 'physical standby': Client is ARCH pid 2152

                Wed May 14 10:59:28 2014

                RFS[887]: Assigned to RFS process 316

                RFS[887]: Identified database type as 'physical standby': Client is ARCH pid 2152

                 

                ==========

                every thing works fine in both primary and standby database... log shipping is fine...... but still my primary instance showing the same information

                 

                primary alert:

                ==========

                *****************************************

                LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

                ******************************************************************

                LNS: Standby redo logfile selected for thread 1 sequence 19050 for destination LOG_ARCHIVE_DEST_2

                Wed May 14 11:00:17 2014

                Archived Log entry 36511 added for thread 1 sequence 19049 ID 0x36b84d24 dest 1:

                Wed May 14 11:10:52 2014

                Thread 1 advanced to log sequence 19051 (LGWR switch)

                  Current log# 1 seq# 19051 mem# 0: M:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO01.RDO

                  Current log# 1 seq# 19051 mem# 1: N:\ORACLE\PRODUCT\11.2.0\ORADATA\WDEGPRO\REDO01_1.RDO

                Wed May 14 11:10:52 2014

                ******************************************************************

                LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

                ******************************************************************

                LNS: Standby redo logfile selected for thread 1 sequence 19051 for destination LOG_ARCHIVE_DEST_2

                Wed May 14 11:10:52 2014

                Archived Log entry 36513 added for thread 1 sequence 19050 ID 0x36b84d24 dest 1:

                 

                how active archival and redo apply can happen at same time ? nad more over only one standby redo log file is being used out of three files and the other two remains still unassaigned

                i have recreated this standby yesterday