Disaster Recovery

Understanding Redo Transport in Oracle Data Guard

Introduction

If you are working with Oracle Data Guard, you have probably wondered what actually gets transmitted between your primary and standby databases. Is it the redo data, the redo log files, or the entire data blocks themselves?

It is an important distinction, and understanding it can help you troubleshoot performance issues, optimize your network configuration, and gain a deeper understanding of how Data Guard ensures data integrity.

What Data Guard Really Sends

Oracle Data Guard transports redo data, not entire data blocks.

Redo data is a record of what changed in the database, not the actual contents of the changed blocks. Every time a transaction modifies a table or index, for example, through an INSERT, UPDATE, or DELETE, Oracle generates redo entries, also known as change vectors, that describe how to replay that change.

These redo entries are stored in the redo log buffer in the SGA and then written to the online redo log files on disk. Data Guard’s redo transport services send this same redo stream across the network to your standby database.

How Redo Transport Works

The following explains the simplified process, without distinguishing between SYNC and ASYNC mode:

  1. Transaction executes on the primary database.
  2. The database records the change as redo entries in memory (redo log buffer in SGA).
  3. Redo is written to the online redo log file on disk by the Log Writer Process (LGWR).
  4. Log Transport Services (NSS / TT) transmit the redo data from memory to the standby database.
  5. On the standby, the Remote File Server (RFS) writes it to the standby redo logs (SRLs).
  6. The Managed Recovery Process (MRP) applies the redo, reconstructing the actual data block changes on the standby.

Keep in mind, neither the Log Writer Process (LGWR) nor the transport process waits for a commit to happen. They continuously write or send redo as it appears in the log buffer.

So rather than sending entire data blocks, Data Guard sends compact descriptions of the changes. The standby then replays those changes to stay synchronized with the primary.

When Are Archived Redo Logs Sent?

If redo transport is interrupted, for example, because of a network connectivity issue between the primary and standby database, the primary database will continue writing (except in maximum protection mode) into the online redo logs. The archiver processes (ARCn) automatically archive online redo log files into archived redo log files.

Once the standby is available again, Data Guard will fetch the missing redo by sending archived redo log files from the primary. These still contain redo, not entire blocks.

This process is known as Fetch Archived Log (FAL), or, more commonly, gap resolution.

When Are Data Blocks Sent?

Under normal circumstances, Data Guard never ships full data blocks, only redo data.
However, there are a few special cases where actual blocks will be transmitted:

  • Automatic block repair: if a block becomes corrupted on one side, Data Guard can fetch a healthy copy from the other side. So, this works from primary to standby and vice versa. This feature requires the Active Data Guard option license.
  • RMAN operations: when creating or recovering a standby database with RMAN duplicate, incremental restore, or restore from service operations, physical data blocks are transferred. This is outside the scope of redo transport itself.
  • Automatic Recovery of non-logged operations: on Engineered Systems and Oracle Cloud Infrastructure only, changes made by batch workloads can be transferred as blocks to avoid setting up Force Logging in Data Warehouse environments.

Benefits of Sending Redo Instead of Data Blocks

Oracle Data Guard’s strength lies in its efficiency. Instead of constantly moving full data blocks (8 KB or larger) across the network, it ships only redo data (might be as little as a few bytes). This keeps standby databases highly consistent while:

  • Minimizing network bandwidth usage and latency.
  • Improving performance by handling high transaction volumes efficiently.
  • Ensuring the integrity of the standby database via end-to-end validations, avoiding the replication of corrupted blocks, and protecting from ransomware.
  • Strengthens security by limiting the amount of potentially exploitable content crossing the network. In addition, the redo stream can also be encrypted.

Further Reading

Would you like to get notified when the next post is published?