Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Data Guard Redo Log retry Tips

Oracle Database Tips by Donald BurlesonDecember 9, 2015

Oracle Data GuardChapter 5 - Log Management Services

Retrying Archiving to a Failed Destination


The default value of REOPEN is 300 seconds. These parameters are not related to any specific type of failure.  A heartbeat process on the primary database keeps polling the physical standby database. The frequency of polling is 60 seconds by default.  When the REOPEN attribute is set, the heartbeat polling frequency changes to the REOPEN value. The minimum value of REOPEN can be 0 seconds, but the heartbeat will still poll the physical standby site every 60 seconds even if the REOPEN is set to less than 60 seconds.  Hence, setting it to less than 60 seconds does not have any effect.

WARNING - MAX_FAILURE attribute did not work in release due to Bug 2449124. Check the MOSC site for any bug fixes on this issue if the attribute  is not working in the existing environment.


Archiving to an Alternate archived log Destination






The primary database will not reuse the online redo log file if the log is archived to an alternate location for an archive destination defined as MANDATORY. If a destination is specified as listed below and the appsstdby1 service is not accessible, the archiver will archive the redo file into the destination specified by log_archive_dest_4.  The online redo log file, however, will not be marked as archived; therefore, it will not be re-used by log writer.


Dependence relationship between log archive destinations

In some Data Guard configurations, the DBA may want to keep only one repository of archived redo logs and feed all the standby databases from this repository. In this kind of scenario, the physical archival of log files to one common location needs to be configured.  Upon the successful archival of the log file, inform the dependent standby databases so that the recovery process on the standby databases can continue.

Log Management Services - Dependence relationship between archival destinations

This is more like parent-child relationships between the log archival destinations. Using the DEPENDENCY attribute of the log_archive_dest_n parameter, such a parent-child relationship can be set. The validity of the child destination depends upon the success of archival in the parent archive destination.

Also, the standby_archive_dest parameter needs to be updated on the standby databases to point to the location where the physical archiving will take place. The log_archive_format on the standby databases and the primary database should be the same; otherwise, the MRP process on the standby databases will not be able to identify the logs required for recovery.

In the following example, the redo logs will not be physically archived to the Oracle instance pointed by appsstdby1 service name. Instead, this destination is dependent on log_archive_dest_1. When a log file is archived to the /oracle/appsdb/arch location, the name of archived redo log is registered in the Oracle instance and the recovery process on the Oracle instance reads the log file from the /oracle/appsdb/arch directory:




The above text is an excerpt from the book: Oracle Data Guard Handbook

Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.