This discussion is archived
1 2 Previous Next 16 Replies Latest reply: Dec 7, 2012 7:53 AM by garywicke RSS

Data Guard - STANDBY server does not update REDO/STANDBY REDO files

952725 Newbie
Currently Being Moderated
Hi everybody.

First time with Data Guard so be patient :-)

Oracle is Oracle Database 11g Enterprise Edition 11.2.0.3.0 64bit Production running on a couple of CentOS 6.2 Linux boxes (test environment).

I've successfully managed to confugure a primary/standby Data Guard setup in the sense that if I insert some records into the primary __AND__ issue the "alter system switch logfile;", by watching the log files I'm able to see the sync stuff:

[primary]
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Thread 1 advanced to log sequence 295 (LGWR switch)
Current log# 1 seq# 295 mem# 0: /oracle/origlog/redo01.log
Current log# 1 seq# 295 mem# 1: /oracle/mirrlog/redo01.log
Wed Sep 26 14:23:03 2012
Archived Log entry 485 added for thread 1 sequence 294 ID 0xb91f1325 dest 1:

[standby]
Wed Sep 26 14:22:59 2012
RFS[4]: Assigned to RFS process 18244
RFS[4]: Opened log for thread 1 sequence 292 dbid -1189156315 branch 794247464
Archived Log entry 63 added for thread 1 sequence 292 rlc 794247464 ID 0xb91f1325 dest 2:
Wed Sep 26 14:22:59 2012
RFS[5]: Assigned to RFS process 18246
RFS[5]: Opened log for thread 1 sequence 293 dbid -1189156315 branch 794247464
Archived Log entry 64 added for thread 1 sequence 293 rlc 794247464 ID 0xb91f1325 dest 2:
Wed Sep 26 14:22:59 2012
Media Recovery Log /oracle/oraarch/log1_292_794247464.arc
Media Recovery Log /oracle/oraarch/log1_293_794247464.arc
Media Recovery Waiting for thread 1 sequence 294
Wed Sep 26 14:23:02 2012
Primary database is in MAXIMUM PERFORMANCE mode
RFS[6]: Assigned to RFS process 18250
RFS[6]: No standby redo logfiles created for thread 1
RFS[6]: Opened log for thread 1 sequence 295 dbid -1189156315 branch 794247464
Wed Sep 26 14:23:04 2012
RFS[7]: Assigned to RFS process 18257
RFS[7]: Opened log for thread 1 sequence 294 dbid -1189156315 branch 794247464
Archived Log entry 65 added for thread 1 sequence 294 rlc 794247464 ID 0xb91f1325 dest 2:
Media Recovery Log /oracle/oraarch/log1_294_794247464.arc
Media Recovery Waiting for thread 1 sequence 295 (in transit)

Also, if I put the standby in READ-ONLY mode and perform a simple query, data is consistent.

I might be happy but I've still some questions for the group:

1) Why does the "No standby redo logfiles created for thread 1" appear? On the STANDBY server:

SQL> select thread#,group#, status from v$standby_log;

THREAD#     GROUP# STATUS
---------- ---------- ----------
+     0     4 UNASSIGNED+
+     0     5 UNASSIGNED+
+     0     6 UNASSIGNED+
+     0     7 UNASSIGNED+

I added them using the "ALTER DATABASE ADD STANDBY LOGFILE..." command but why are they still "UNASSIGNED"?

2) I checked the PRIMARY's ONLINE REDO LOG FILES and they're updated consistently; if I check (ls -l) both the STANDBY's REDO LOG and STANDBY LOGS, they do not get updated. Is it normal?

3) From what I've gathered from the manuals, replication should occur either when the archive_lag_target (mine is set to 1800) expires, the DB ADMIN issues a "alter system switch logfile;" command or when the system does archive an old REDO LOG. Is there a way to have (near) REAL TIME REPLICATION as to have every single rows transferred and applied to the STANDBY as long as it gets interted into the PRIMARY?

4) Again, from what I've learned, the PRIMARY transmits the REDO log to the STANDBY; it should go first into the "STANDBY REDO LOGs" then, once the STANDBY decides to ARCHIVE it, it should be applied to the datafiles. Assuming you're running in "REAL TIME APPLY SERVICE", is it normal for the STANDBY to completely bypass the ONLINE REDO/STANDBY REDO files and write directly to the LOG_ARCHIVE_DEST_1?

Here's the PFILE for the PRIMARY SERVER:

RZSID.__db_cache_size=117440512
RZSID.__java_pool_size=4194304
RZSID.__large_pool_size=4194304
RZSID.__oracle_base='/rnd/apps/servers/oracle'#ORACLE_BASE set from environment
RZSID.__pga_aggregate_target=192937984
RZSID.__sga_target=343932928
RZSID.__shared_io_pool_size=0
RZSID.__shared_pool_size=205520896
RZSID.__streams_pool_size=4194304
*.archive_lag_target=1800
*.audit_file_dest='/rnd/apps/servers/oracle/admin/RZPRIMARY/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/rnd/apps/servers/oracle/oradata/RZPRIMARY/control01.ctl','/rnd/apps/servers/oracle/bkp_control/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_recovery_file_dest='/rnd/apps/servers/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=9663676416
*.diagnostic_dest='/rnd/apps/servers/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=RZSIDXDB)'
*.memory_target=536870912
*.open_cursors=300
*.processes=150
*.undo_tablespace='UNDOTBS1'
DB_NAME='RZPRIMAR'
DB_UNIQUE_NAME='RZPRIMARY'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(RZPRIMARY,RZBACKUP)'
LOG_ARCHIVE_DEST_1=
     'LOCATION=/oracle/oraarch/
     VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
     DB_UNIQUE_NAME=RZPRIMARY'
LOG_ARCHIVE_DEST_2=
     'SERVICE=RZBACKUP ASYNC
     VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
     DB_UNIQUE_NAME=RZBACKUP'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
remote_login_passwordfile='EXCLUSIVE'
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30
FAL_SERVER=RZBACKUP
STANDBY_FILE_MANAGEMENT=AUTO
DB_FILE_NAME_CONVERT='RZPRIMARY','RZBACKUP'

Here's the STANDBY one:

RZSID.__db_cache_size=92274688
RZSID.__java_pool_size=4194304
RZSID.__large_pool_size=4194304
RZSID.__oracle_base='/rnd/apps/servers/oracle'#ORACLE_BASE set from environment
RZSID.__pga_aggregate_target=209715200
RZSID.__sga_target=327155712
RZSID.__shared_io_pool_size=0
RZSID.__shared_pool_size=213909504
RZSID.__streams_pool_size=4194304
*.archive_lag_target=1800
*.audit_file_dest='/rnd/apps/servers/oracle/admin/RZBACKUP/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.CONTROL_FILES='/rnd/apps/servers/oracle/oradata/RZBACKUP/control01.ctl','/rnd/apps/servers/oracle/bkp_control/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.DB_FILE_NAME_CONVERT='RZPRIMARY','RZBACKUP'
*.DB_NAME='RZPRIMAR'
*.db_recovery_file_dest='/rnd/apps/servers/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=9663676416
*.DB_UNIQUE_NAME='RZBACKUP'
*.diagnostic_dest='/rnd/apps/servers/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=RZSIDXDB)'
*.FAL_SERVER='RZPRIMARY'
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(RZPRIMARY,RZBACKUP)'
*.LOG_ARCHIVE_DEST_1='LOCATION=/oracle/oraarch/
     VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
     DB_UNIQUE_NAME=RZBACKUP'
*.LOG_ARCHIVE_DEST_2='SERVICE=RZPRIMARY ASYNC
     VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
     DB_UNIQUE_NAME=RZPRIMARY'
*.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.LOG_ARCHIVE_FORMAT='log%t_%s_%r.arc'
*.memory_target=536870912
*.open_cursors=300
*.processes=150
*.REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.undo_tablespace='UNDOTBS1'

If you need more info, feel free to ask.

Thanks,
Rob
  • 1. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    mseberg Guru
    Currently Being Moderated
    Hello;

    I found something right away

    Primary

    DB_NAME='RZPRIMAR'
    DB_UNIQUE_NAME='RZPRIMARY'


    These need to be the same value.

    This appears to be backwards on the primary side. Not a big deal now, but might cause an issue down the line.

    DB_FILE_NAME_CONVERT='RZPRIMARY','RZBACKUP'





    Standby

    Same mismatch

    DB_NAME='RZPRIMAR'


    Not a big deal but would set this to DEFER


    LOG_ARCHIVE_DEST_STATE_2='ENABLE'



    Still reviewing

    Best Regards

    mseberg
  • 2. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    MahirM.Quluzade Guru
    Currently Being Moderated
    Hi,

    Can you paste here ?
     on primary 
     select max(sequence#) from v$archived_log; 
    
     
     on standby 
     select max(sequence#) from v$archived_log; 
     select max(sequence#) from v$archived_log where applied='YES';
    
     select *  from v$archive_gap;
     
    Regards
    Mahir M. Quluzade
  • 3. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    CKPT Guru
    Currently Being Moderated
    1) Why does the "No standby redo logfiles created for thread 1" appear? On the STANDBY server:

    SQL> select thread#,group#, status from v$standby_log;

    THREAD#     GROUP# STATUS
    ---------- ---------- ----------
    +     0     4 UNASSIGNED+
    +     0     5 UNASSIGNED+
    +     0     6 UNASSIGNED+
    +     0     7 UNASSIGNED+

    I added them using the "ALTER DATABASE ADD STANDBY LOGFILE..." command but why are they still "UNASSIGNED"?
    How many Online redo log files are in Primary database?
    &
    How many standby log files created on standby database?
    What is the size of Online and Standby Redo log files.
    2) I checked the PRIMARY's ONLINE REDO LOG FILES and they're updated consistently; if I check (ls -l) both the STANDBY's REDO LOG and STANDBY LOGS, they do not get updated. Is it normal?
    Just a question, Primary is RAC database? If not please give me answers of first question response.
    3) From what I've gathered from the manuals, replication should occur either when the archive_lag_target (mine is set to 1800) expires, the DB ADMIN issues a "alter system switch logfile;" command or when the system does archive an old REDO LOG. Is there a way to have (near) REAL TIME REPLICATION as to have every single rows transferred and applied to the STANDBY as long as it gets interted into the PRIMARY?
    You can achieve by using Real-Time apply, But its not applicable for Every single row, Then probably you have to change your protection mode from Maximum Performance to Maximum Protection.
    4) Again, from what I've learned, the PRIMARY transmits the REDO log to the STANDBY; it should go first into the "STANDBY REDO LOGs" then, once the STANDBY decides to ARCHIVE it, it should be applied to the datafiles. Assuming you're running in "REAL TIME APPLY SERVICE", is it normal for the STANDBY to completely bypass the ONLINE REDO/STANDBY REDO files and write directly to the LOG_ARCHIVE_DEST_1?
    Again it depends on what redo transport mode you are using ? Is it Synchronous or Asynchronous?
    If you are in maximum performance mode, default is Asynchronous, Here there will be no network or apply or transport acknowledgments will be received. Of course by choosing Maximum protection availability you may achieve it. But i suggest you to go through with each protection modes and their impact of each mode.

    http://docs.oracle.com/cd/B28359_01/server.111/b28294/protection.htm#CHDDAHJD
    LOG_ARCHIVE_DEST_2=
         'SERVICE=RZBACKUP ASYNC
         VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
         DB_UNIQUE_NAME=RZBACKUP'
    You can change above parameter as below to enable Real-TIme apply
    LOG_ARCHIVE_DEST_2='SERVICE=RZBACKUP LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=RZBACKUP'
  • 4. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    952725 Newbie
    Currently Being Moderated
    Well, funny how things change in a few minutes :-)

    On the STANDBY database I used the alter database drop standby logfile 'srlX.f'; to remove STBY LOG FILES (where X is a number ranging from 1 to 4); as you might notice, the pathname is a relative and not an absolute one.

    Then, I create the */oracle/standby* folder on the STANDBY server and issued the alter database add standby logfile '/oracle/standby/srlX.f' size 52428800 (again, X ranges from 1-4) and restarted the STANDBY DB and everything started working as expected.

    By "as expected" I mean:

    . replication occurred in real time
    . I was able to see the last access time of the STANDBY LOGS updated
    . the newly created STBY LOGS are now ACTIVE and assigned to a given thread
    . archiving on the STBY server works as expected

    So it seems the issue might be related either to the creation of the STANDBY LOGS (which I could have done in a wrong way) or to the ABSOLUTE pathname given.

    Anytime, in the next few hours I'll reconstruct the STBY DB from scratch and update this thread.

    Cheers,
    Rob
  • 5. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    CKPT Guru
    Currently Being Moderated
    By "as expected" I mean:

    . replication occurred in real time
    . I was able to see the last access time of the STANDBY LOGS updated
    . the newly created STBY LOGS are now ACTIVE and assigned to a given thread
    . archiving on the STBY server works as expected

    So it seems the issue might be related either to the creation of the STANDBY LOGS (which I could have done in a wrong way) or to the ABSOLUTE pathname given.
    Yes, that is correct. standby redo log files will be used only in case of Real-Time apply, That i already mentioned in my previous post how to enable it. Then standby redo logs will be assigned to write redo by RFS.
    Anytime, in the next few hours I'll reconstruct the STBY DB from scratch and update this thread.
    Just playing with it? If so then Ok.
  • 6. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    952725 Newbie
    Currently Being Moderated
    Hi!

    Thanks for your post.

    As I wrote, I completed wiped out the STBY dbase and restarted from scratch; after copying the DATA + CONTROL FILE (from primary) + REDO LOGS, I had to start the STBY in "startup mount" mode as to add the required "ALTER DATABASE ADD STANDBY LOGFILE..." commands.

    While in "mount" mode, the PRIMARY (which was active) tried to synch with the STBY but the latter emitted the following messages into the ALTER file:

    ARC0: STARTING ARCH PROCESSES COMPLETE
    Errors in file /rnd/apps/servers/oracle/diag/rdbms/rzbackup/RZSID/trace/RZSID_lgwr_23169.trc:
    ORA-00313: open failed for members of log group 4 of thread 0
    ORA-00312: online log 4 thread 0: '/rnd/apps/servers/oracle/EE/112_64/dbs/srl1.f'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    Errors in file /rnd/apps/servers/oracle/diag/rdbms/rzbackup/RZSID/trace/RZSID_lgwr_23169.trc:

    Please notice that I did not create (yet) any STANDBY LOG on the STBY server but the engine supposed there were some under /rnd/apps/servers/oracle/EE/112_64/dbs (which is the default dir if you give only a filename to the "ALTER DATABASE ADD STANDBY LOGFILE" command).

    So, I added MY STANBY LOG files which I wanted to go in a given folder (eg, "ALTER DATABASE ADD STANDBY LOGFILE '/oracle/standby/slrX.f"..) and then removed the "missing ones" (alter database drop standby logfile 'srlX.f'; - again, X ranging from 1 to 4); once completed, everything worked as expected.

    One thing I could think of is the following; on the PRIMARY DB I added 4 STANDBY LOGFILES without giving the absolute pathname. Then I created the STBY CONTROL FILE which might include a "reference" to the PRIAMRY's STBY LOGFILES (just created, never used); perhaps these files might be added AFTER the creation of the STBY CONTROL FILE as to have a clean situation.

    Nevertheless, a few minutes ago I tried a switchover between the PRIMARY and the STBY and the STBY LOG files on the (former) PRIMARY got accessed without problems.

    Thanks for your time,
    Roberto
  • 7. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    mseberg Guru
    Currently Being Moderated
    Hello;

    You do not have any online redo logs on your standby database.

    You should have both Redo and Standby Redo logs. While SRL's are not required it makes no sense to run Data Guard without them.

    Use

    select * from v$standby_log;

    and

    select group#, member from v$logfile;

    Make sure your SRL match the exact size of the Redo you create.

    Best Regards

    mseberg
  • 8. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    CKPT Guru
    Currently Being Moderated
    As I wrote, I completed wiped out the STBY dbase and restarted from scratch; after copying the DATA + CONTROL FILE (from primary) + REDO LOGS, I had to start the STBY in "startup mount" mode as to add the required "ALTER DATABASE ADD STANDBY LOGFILE..." commands.
    While in "mount" mode, the PRIMARY (which was active) tried to synch with the STBY but the latter emitted the following messages into the ALTER file:
    ARC0: STARTING ARCH PROCESSES COMPLETE
    Errors in file /rnd/apps/servers/oracle/diag/rdbms/rzbackup/RZSID/trace/RZSID_lgwr_23169.trc:
    ORA-00313: open failed for members of log group 4 of thread 0
    ORA-00312: online log 4 thread 0: '/rnd/apps/servers/oracle/EE/112_64/dbs/srl1.f'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    Errors in file /rnd/apps/servers/oracle/diag/rdbms/rzbackup/RZSID/trace/RZSID_lgwr_23169.trc:
    These are expected, because these information related to Primary when you start MRP it try to crosscheck so ignore these errors.
    Please notice that I did not create (yet) any STANDBY LOG on the STBY server but the engine supposed there were some under /rnd/apps/servers/oracle/EE/112_64/dbs (which is the default dir if you give only a filename to the "ALTER DATABASE ADD STANDBY LOGFILE" command).
    What is the location of those files in primary?
    So, I added MY STANBY LOG files which I wanted to go in a given folder (eg, "ALTER DATABASE ADD STANDBY LOGFILE '/oracle/standby/slrX.f"..) and then removed the "missing ones" (alter database drop standby logfile 'srlX.f'; - again, X ranging from 1 to 4); once completed, everything worked as expected.
    One thing I could think of is the following; on the PRIMARY DB I added 4 STANDBY LOGFILES without giving the absolute pathname. Then I created the STBY CONTROL FILE which might include a "reference" to the PRIAMRY's STBY LOGFILES (just created, never used); perhaps these files might be added AFTER the creation of the STBY CONTROL FILE as to have a clean situation.
    When you created standby these standby redo log files will not be created automatically, you have to create thema.
    Nevertheless, a few minutes ago I tried a switchover between the PRIMARY and the STBY and the STBY LOG files on the (former) PRIMARY got accessed without problems.
    If you create Standby redo log files on primary and both standby then if you perform switchover you can save the time to create SRL's and real-time will applicable whenever primary switched to standby.

    These are generic issues, If you are really having any issue please post. Thank you.
  • 9. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    952725 Newbie
    Currently Being Moderated
    Hi.

    Thanks again for your time.

    The location of the SRLs on the primary is under '/rnd/apps/servers/oracle/EE/112_64/dbs/srlX.f' since I created 'em without giving an absolute pathname.

    Yesterday I was able to complete a controller switchover between the primary and the standby and everything worked fine; SRLs on the primary got used without errors/issues.

    Since I'm monitoring their usage, I've noticed that only 2 SRLs out of 4 are actually used; as an example, on the former PRIMARY (now STBY) the log files are as follows:

    /oracle/origlog/redo03.log
    /oracle/origlog/redo02.log
    /oracle/origlog/redo01.log
    /oracle/mirrlog/redo01.log
    /oracle/mirrlog/redo02.log
    /oracle/mirrlog/redo03.log
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl1.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl2.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl3.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl4.f

    The last 4 are the SRL ones. From SQLPLUS:

    SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

    GROUP# THREAD# SEQUENCE# ARC STATUS
    ---------- ---------- ---------- --- ----------
         4     1     344 YES ACTIVE
         5     1     0 NO UNASSIGNED
         6     0     0 YES UNASSIGNED
         7     0     0 YES UNASSIGNED

    From "ls -l /rnd/apps/servers/oracle/EE/112_64/dbs/srl*":

    -rw-r----- 1 oracle oinstall 52429312 Sep 25 08:44/oracle/EE/112_64/dbs/srl1.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 27 08:14 /oracle/EE/112_64/dbs/srl2.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 25 16:40 /oracle/EE/112_64/dbs/srl3.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 25 16:40 /oracle/EE/112_64/dbs/srl4.f

    As you can see, only SRL1 and SRL2 are actually being updated.

    Again, not a real issue, just me trying to get better acquainted with Data Guard.

    Thanks,
    Rob
  • 10. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    CKPT Guru
    Currently Being Moderated
    The location of the SRLs on the primary is under '/rnd/apps/servers/oracle/EE/112_64/dbs/srlX.f' since I created 'em without giving an absolute pathname.
    Yes, Guess was correct. Because you created with the same name in primary and when you start MRP first time in standby database, These errors are very much expected.
    Yesterday I was able to complete a controller switchover between the primary and the standby and everything worked fine; SRLs on the primary got used without errors/issues.
    Yes even you dont have SRL's, there would be no issues but real time wont be applicable. So to ensure Realtime apply you must have created Standby redo log files even on current primary database.
    Since I'm monitoring their usage, I've noticed that only 2 SRLs out of 4 are actually used; as an example, on the former PRIMARY (now STBY) the log files are as follows:

    /oracle/origlog/redo03.log
    /oracle/origlog/redo02.log
    /oracle/origlog/redo01.log
    /oracle/mirrlog/redo01.log
    /oracle/mirrlog/redo02.log
    /oracle/mirrlog/redo03.log
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl1.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl2.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl3.f
    /rnd/apps/servers/oracle/EE/112_64/dbs/srl4.f

    The last 4 are the SRL ones. From SQLPLUS:

    SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

    GROUP# THREAD# SEQUENCE# ARC STATUS
    ---------- ---------- ---------- --- ----------
         4     1     344 YES ACTIVE
         5     1     0 NO UNASSIGNED
         6     0     0 YES UNASSIGNED
         7     0     0 YES UNASSIGNED

    From "ls -l /rnd/apps/servers/oracle/EE/112_64/dbs/srl*":

    -rw-r----- 1 oracle oinstall 52429312 Sep 25 08:44/oracle/EE/112_64/dbs/srl1.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 27 08:14 /oracle/EE/112_64/dbs/srl2.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 25 16:40 /oracle/EE/112_64/dbs/srl3.f
    -rw-r----- 1 oracle oinstall 52429312 Sep 25 16:40 /oracle/EE/112_64/dbs/srl4.f

    As you can see, only SRL1 and SRL2 are actually being updated.
    If it is using SRL, then they also updated.
    Again, not a real issue, just me trying to get better acquainted with Data Guard.
    All the best.


    If answered your question please close the threads as answered,
    Thanks.
  • 11. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    952725 Newbie
    Currently Being Moderated
    Thanks.

    Thread closed.

    Cheers,
    Rob
  • 12. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    garywicke Newbie
    Currently Being Moderated
    Michael, CKPT

    I realize this is an old post but I didn't think it worthwhile to create a whole new thread for this question.

    Michael, I've seen you state several times that the LOG_ARCHIVE_DEST_STATE_n on the Standby database should all be set to 'DEFER' rather than 'ENABLE' and I was wondering why?

    I haven't seen anything in the docs about that.

    Wouldn't I want them set to 'ENABLE' in the case I needed to do a switchover? They would all then be ready to assume the role of the new Primary.

    What am I missing?

    Thanks very much!!

    -gary
  • 13. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    mseberg Guru
    Currently Being Moderated
    Gary;

    Hello again.

    I'm not sure I have a "Here's what will happen if you set it wrong example".

    That said for the past two years, once a year they shutdown the Primary server room here.

    In advance I do a switchover to the Standby and shutdown the Primary.

    By having it set to DEFER I'm not shipping logs back by default, and that's a good thing.

    If you think about a failover, a true failover you would not want logs shipping by default either. So DEFER.

    I probably got this idea from Larry Carpenter's excellent book :

    http://www.amazon.com/Oracle-Data-Guard-Handbook-Press/dp/0071621113

    I hope this helps and makes sense. For the record both Oracle 10 and 11 of "Data Guard Concepts and Administration" show the Standby INIT setting for this as :

    LOG_ARCHIVE_DEST_STATE_2=ENABLE

    But I think it should be DEFER. I think it comes down to asking why. Why is this parameter set this way? Should it be? Should I think about it?

    Later

    Check out another opinion here ( look for sentence that starts with "While functioning as a STANDBY"

    http://gavinsoorma.com/2009/06/few-checks-before-manual-dataguard-switchover/


    Best Regards

    mseberg

    Edited by: mseberg on Dec 6, 2012 2:10 PM

    Edited by: mseberg on Dec 6, 2012 2:20 PM
  • 14. Re: Data Guard - STANDBY server does not update REDO/STANDBY REDO files
    garywicke Newbie
    Currently Being Moderated
    Michael

    Well that makes a lot of sense.

    I guess I was assuming a switchover would include an immediate establishment of the old primary as the new standby, but now that you mention it a switchover would usually be needed by a failure of 'something' and until that was repaired the new primary would be acting alone.

    I'm also guessing I set mine to ENABLE based on the Oracle docs.

    I think I'll change them.

    I actually do have Larry Carpenter's book but haven't read that chapter yet. I got it after I had my standby already set up and running so I've been using it as a reference.

    Thanks again for sharing your experiences. Sometimes the documentation doesn't explain real life. That's why we need people like you.

    Happy holidays!!

    -gary
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points