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

 
 Home
 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
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

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

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

   
 

Data Guard Log Transport Tips

Oracle Database Tips by Donald BurlesonDecember 3, 2015

Data Guard log transport Architecture

Process Architecture

Also see these important notes on LNS log transport waits.

The Log Transport Service and Log Apply Service form the backbone of the Data Guard environment. The log transport service starts on the primary database and completes on the standby database.

The Redo Log file is an essential structure for any Oracle database. There must be at least two redo log groups with at least one log member per group for Data Guard. A redo log member is a physical file that contains all the committed and uncommitted transactions. Any changes made to the database are registered to the redo log buffer inside the System Global Area (SGA) memory structure.

When the redo log buffer fills (as defined by the log_buffer parameter), the LGWR process writes the buffer information to the online redo log file. The redo log file contains both old and new values and can be used for media recovery. In addition, each transaction is given a unique System Change Number (SCN) that is used for media recovery.

Online Redo Log File

Redo log groups are reused in a circular method in that when the current redo log file fills, the LGWR starts writing to the next redo log file group. When all of the redo log groups are filled, the LGWR starts reusing the redo log members.

Archived Redo Log File

An archived redo log file is a replica of an online redo log file. When an online redo log file group fills, the archiver process copies the online redo log file to archival destinations.

Once the archiver process completes the replication of the online redo log file to archival destinations, the online redo log file is marked for reuse. The redo thread number and log sequence number uniquely identify an archived redo log file. In case of media recovery, archived redo log files can be used to update the database files.

In a Data Guard environment, a Oracle instance should be an archival destination. Remote archival to the standby database is achieved by a combination of the archiver process on the primary database and the remote file server process of the standby database. The archived redo log file on the Oracle instance is exactly the same as the archived redo file written to a local archival destination.

Role of the Transport Network Substrate (TNS) for Data Guard

Oracle Net can be configured to connect sites over a LAN or a WAN.  Good network bandwidth should be provided in order to achieve better performance of the log transfer service. In addition to connecting the primary site to all of its standby sites through Oracle Net, it is a good practice to connect the standby sites with each other. This will minimize the downtime during switchover or failover operations.

The Oracle Name services on the primary site should be configured such that the archiver process can resolve the service name for archiving to a remote standby destination. Moreover, the listener on standby sites should be configured properly to respond to the request sent by the archiver process of the primary site. The details about the configuration of Oracle Net services in context of Data Guard configuration are provided in the next chapter.

 

Data Guard Process Architecture

  • Remote File Server (RFS) Process - The RFS process runs on the primary instance and is responsible for communication between the primary and the standby database. For the log transport service, the RFS on the Oracle instance receives the redo records from the archiver or the log writer process of the primary database over Oracle Net and writes to filesystem on the standby site.
     

  • Fetch Archive Log (FAL) - The FAL process has two components: FAL Client and FAL Server. Both processes are used for archive gap resolution. If the Managed Recovery Process (MRP) on the Oracle instance site detects an archive gap sequence, it initiates a fetch request to the FAL client on the standby site. This action, in turn, requests the FAL server process on the primary database to re-transmit the archived log files to resolve the gap sequence. Archive gap sequences will be discussed later in this chapter.

The following processes facilitate the log transport service on the primary and the standby site:

  • Archiver Process - The archiver process (ARCn or ARCH) is responsible for archiving online redo logs to the flat files in the archived redo log filesystem. The archival destination could be a local destination or a remote standby database site. In the case of a Data Guard configuration, one of the archival destinations must be a standby database.  The archiver process of the primary database writes the redo log file.

For a better data protection mode, the standby redo log files can be configured on the standby database. In this case, the archiver process on the standby site will be used to archive the standby redo log files.

  • Log Writer (LGWR) - The log writer process on the primary database writes entries from the redo log buffer to the online redo log file. When the current online redo log file is full, it triggers the archiver process to start the archiving activity. In some cases, the log writer process writes redo entries to the online redo log file of the primary database and the standby redo log file of the standby database. Usually, in this kind of arrangement the LGWR works as the log transport agent that is setup to achieve high data protection modes.

  • Logical Standby Process (LSP) - The LSP transports and applies the redo records from archived redo logs to the logical standby database. The Oracle database log miner engine is used by the logical standby process for the SQL apply operations. Using the log miner engine, the LSP process recreates the SQL statements from redo logs that have been executed on the primary database. These statements are then applied to the Oracle instance to keep it current with the primary database.

  • Figure 2.2 shows the database processes involved in Data Guard. In most cases, only a subset of these processes is used, based on the type of Oracle instance and mode of data protection.

    Figure 2.2 - Processes and files involved in the Data Guard environment.

    Once the log transport service completes the transmission of redo records to the standby site, the log apply service starts applying the changes to the standby database. The log apply service operates solely on the standby database. The following processes on the standby site facilitate the log apply operations:

  • Managed Recovery Process (MRP) - The MRP  applies the redo entries from the archived redo logs onto the physical standby database.

  •  


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.