Forum Stats

  • 3,838,038 Users
  • 2,262,323 Discussions
  • 7,900,481 Comments

Discussions

why LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

989969
989969 Member Posts: 21
edited May 14, 2014 5:47AM in Data Guard

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

Tagged:

Answers

  • mseberg
    mseberg Member Posts: 7,004 Silver Crown
    edited May 13, 2014 5:14PM

    Hello;

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

    In any event its just an information message.

    Best Regards

    mseberg

    mseberg
  • 989969
    989969 Member Posts: 21

    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 ?

  • Anand...
    Anand... Member Posts: 3,590
    edited May 14, 2014 1:54AM

    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...

  • 989969
    989969 Member Posts: 21
    edited May 14, 2014 5:51AM

    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

This discussion has been closed.