RE: dataguard related msgs

Actually, this looks like he's using standby logs, but *not* real time
apply.  For a standby actively using real time apply, one would expect
to see some output similar to the following in the alert log:

Thu Jan 15 11:00:02 2009
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1237]: Successfully opened standby log 8:
'/u04/oradata/MYDB/stdby_rdo02MYDB.dbf'
Thu Jan 15 11:00:03 2009
Media Recovery Waiting for thread 1 sequence 275017 (in transit)
Thu Jan 15 11:00:03 2009
Recovery of Online Redo Log: Thread 1 Group 8 Seq 275017 Reading mem 0
  Mem# 0 errs 0: /u04/oradata/MYDB/stdby_rdo02MYDB.dbf
SCAN_LOG DATE-TIME STAMP: 090115.111501
Thu Jan 15 11:15:02 2009



-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Fuad Arshad
Sent: Thursday, January 15, 2009 10:51 AM
To: stellr@xxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: dataguard related msgs

This means the real time apply is now being used  with LGWR as the
source rather than ARCH.



----- Original Message ----
From: Ray Stell <stellr@xxxxxxxxxx>
To: oracle-l@xxxxxxxxxxxxx
Sent: Thursday, January 15, 2009 9:03:27 AM
Subject: dataguard related msgs

I have a physical standby that I had to do a restart of the primary
for some power maintenance.  The alertlog msgs on both the primary and
standby changed after the restart of the primary.  Perhaps it was a
mistake to not take down the standby, also, but I didn't.  After the
primary restart operations seem to be normal, but the msgs changed.
I'm curious if I can find out something about the nature of the change.

Here are the sample alertlog entries and some status queries:

primary before restart:
-----------------------
Sun Jan 11 05:07:40 2009
Thread 1 advanced to log sequence 1815 (LGWR switch)
  Current log# 3 seq# 1815 mem# 0: /db/db01/oradata/cola/redo03.log
Sun Jan 11 05:07:43 2009
LNS: Standby redo logfile selected for thread 1 sequence 1815 for
destination LOG_ARCHIVE_DEST_2


primary after restart:
----------------------
Sun Jan 11 19:12:08 2009
Thread 1 advanced to log sequence 1838 (LGWR switch)
  Current log# 2 seq# 1838 mem# 0: /db/db01/oradata/cola/redo02.log
Sun Jan 11 19:12:09 2009
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
LNS: Standby redo logfile selected for thread 1 sequence 1838 for
destination LOG_ARCHIVE_DEST_2


standby before restart:
-----------------------
Sun Jan 11 05:08:46 2009
Primary database is in MAXIMUM PERFORMANCE mode
kcrrvslf: active RFS archival for log 5 thread 1 sequence 1815
RFS[5]: Successfully opened standby log 4:
'/db/db01/oradata/cola/sredo01.log'
Sun Jan 11 05:08:50 2009
Media Recovery Log
/db/flash_recovery_area/COLA_STBY/archivelog/2009_01_11/o1_mf_1_1815_4pm
k9g68_.arc
Media Recovery Waiting for thread 1 sequence 1816 (in transit)


standby after restart:
----------------------
Sun Jan 11 19:40:48 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[51]: Assigned to RFS process 29980
RFS[51]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Re-archiving standby log 4 thread 1 sequence 1838
Primary database is in MAXIMUM PERFORMANCE mode
RFS[51]: Successfully opened standby log 5:
'/db/db01/oradata/cola/sredo02.log'
Sun Jan 11 19:40:50 2009
Media Recovery Log
/db/flash_recovery_area/COLA_STBY/archivelog/2009_01_11/o1_mf_1_1838_4po
4dhrh_.arc
Media Recovery Waiting for thread 1 sequence 1839 (in transit)


primary status:
---------------
SQL> select process,status,sequence# from v$managed_standby; 

PROCESS   STATUS        SEQUENCE#
--------- ------------ ----------
ARCH      CLOSING            1932
ARCH      CONNECTED             0
ARCH      CLOSING            1931
ARCH      CLOSING            1930
RFS       IDLE                  0
MRP0      WAIT_FOR_LOG       1933
RFS       IDLE               1933
RFS       IDLE                  0


standby status:
---------------
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ; 

RECOVERY_MODE
-----------------------
IDLE

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM V$MANAGED_STANDBY;   2  

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CLOSING               1       1932      90113        729
ARCH      CONNECTED             0          0          0          0
ARCH      CLOSING               1       1931      94209        994
ARCH      CLOSING               1       1930      90113        729
RFS       IDLE                  0          0          0          0
MRP0      WAIT_FOR_LOG          1       1933          0          0
RFS       IDLE                  1       1933      71961          1
RFS       IDLE                  0          0          0          0

select thread#, sequence#, applied from v$archived_log;

   THREAD#  SEQUENCE# APPLIED
---------- ---------- ---------
         1       1928 YES
         1       1929 YES
         1       1930 YES
         1       1931 YES
         1       1932 YES

Comments?  Thanks.
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Other related posts: