Oracle Data Guard Redo Transport Services

I recommend reading article “Oracle Data Guard Architecture” to understand What is Data Guard before reading this article. Redo transport services are responsible for transporting redo data from the primary database to the standby database. Oracle database supports two redo transport methods;

Redo Transport Methods

1. Synchronous Redo Transport
2. AsynchronousRedo Transport

Note: I will explain redo transport methods details below.

While “redo transport services” transporting redo data, LGWR Background Process in PRIMARY Database continues to write to Online Redo Log files simultaneous. In other words, the two processes marked below continue simultaneous.

Redo Transport Steps

1. LNS (Log Network Server) sends REDO data read from REDO LOG BUFFER in Process SGA to ONS (Oracle Net Service) service.
2. REDO data sent is received by the RFS (Remote File Server) Process on the Standby Database side.
3. The received REDO data is processed into the Standby Redo Log files with the RFS Process.

Synchronous Redo Transport

Synchronous redo transport is also known as “Zero Data Loss”. This is because the LNW background process does not return the COMMIT completion information to the end user before the LGWR process verifies that the redo data sent from the primary is written to disk on the Standby database side.
With this approach, every data that is commited is guaranteed by the standby database.

The working logic is as follows:

1. The user starts a process.
2. This process is written to the Redo Log Buffer Cache in the SGA.
3. When the user commits the process, the LGWR background process writes the data read from the “Redo Log Buffer” field to the “Online Redo Log” file and waits for the LNS background process to verify that the redo data is written to the Standby Database.
4. LNS reads the same redo data from the “Redo Log Buffer” and reports it to the RFS process.
5. RFS receives the sent data and writes it to the “Standby Redo Logs” file.
6. If Physical Standby is used, it is applied to “Standby Database” by MRP (LSP if logical) process.
7. RFS notifies the LNS process that the process has been successfully applied.
8. LNS transfers this information to the LGWR background process.
9. Finally, the Commit completed information returns to the user.

Synchronous Redo Transport Disadvantages

This method, which provides zero data loss, has some disadvantages in terms of performance. Because LGWR always expects verification information from LNS. Therefore, the validation time varies according to the following values;

• I / O
• Network bandwidth
• Depending on the network status

Asynchronous Redo Transport

• Unlike Synchronous Redo Transport, LGWR background process does not expect validation from LNS background process.
• There is no “Zero Data Loss” approach in this redo transport method!
• There is an approach to recovering our database with minimal data loss in case of a problem.
• Its performance is better than Synchronous Redo Transport.

The working logic is as follows:

1. The user starts a process.
2. This process is written to the Redo Log Buffer Cache in the SGA.
3. When the user commits the process, the LGWR background process writes the data read from the “Redo Log Buffer” to the “Online Redo Log” file.
4. LNS reads the same redo data from the “Redo Log Buffer” and reports it to the RFS process.
5. RFS receives the sent data and writes it to the “Standby Redo Logs” file.
6. If Physical Standby is used, it is applied to “Standby Database” by MRP (LSP if logical) process.
7. Finally, the Commit completed information returns to the user.

If the Redo Buffer is recycle in some way or the LNS cannot reach the required redo data, it automatically reads the “Online Redo Log” file and sends the redo data from Online Redo Log.

When the gap is solved, it automatically starts reading from “Redo Log Buffer”.