Redo Transport Services in Oracle Data Guard
The mechanism that keeps your standby database in sync with the primary — in real time or near real time.
What Are Redo Transport Services?
Redo Transport Services are responsible for sending redo data (changes made in the primary database) to the standby database.
This ensures that every transaction on the primary can be replayed on the standby, keeping it nearly or completely up-to-date.
Real-Life Analogy
Think of it like a secure delivery service between two offices:
- The main office (Primary DB) writes down all activity (redo data),
- A courier (Redo Transport) sends these notes continuously to the backup office (Standby DB),
- The standby updates its records using those notes.
If the main office fails, the backup office has everything it needs to take over.
How Redo Transport Works
- Redo is generated on the primary after every transaction.
- Redo Transport sends this data over the network to standby.
- The Log Apply Services on standby apply the changes.
Key Configurable Elements
| Element | Description |
|---|---|
| SYNC / ASYNC | Sends redo synchronously (waits for response) or asynchronously (doesn’t wait). |
| AFFIRM / NOAFFIRM | Standby confirms after writing redo (AFFIRM) or just after receiving it (NOAFFIRM). |
| Compression | Redo data can be compressed to save bandwidth. |
| Encryption | Redo can be encrypted for secure transport. |
Transport Modes
| Mode | Behavior | Use Case |
|---|---|---|
| SYNC | Primary waits for standby to confirm before committing a transaction | Zero data loss needed |
| ASYNC | Primary sends redo and moves on without waiting | Performance-focused systems |
| AFFIRM | Standby confirms after writing redo to disk | Highest safety |
| NOAFFIRM | Standby confirms after receiving redo (not yet written) | Slightly better performance |