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

mseberg

Hello;

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

In any event its just an information message.

Best Regards

mseberg

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 ?

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

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