How does redo transport work?
In the world of Oracle Data Guard, Redo Transport is the logistics system. If the Primary database is a factory creating "goods" (data changes), Redo Transport is the fleet of trucks that delivers those goods to the Standby database (the warehouse) across the network.
Understanding how these "trucks" move is the key to balancing performance and data safety.
Redo transport relies on two specialized background processes that talk to each other across the network:
LNS (Log Network Server): On the Primary database, the LNS process reads redo data from the redo log buffer (in memory) or the online redo logs (on disk) and ships it over the network.
RFS (Remote File Server): On the Standby database, the RFS process receives the redo and writes it into Standby Redo Logs (SRLs).
This is the most critical decision a DBA makes. It defines how the Primary database waits for the Standby.
When a user types COMMIT, the Primary database will not tell the user "Success" until it gets a confirmation from the Standby that the redo has safely arrived.
Pros: Zero Data Loss. If the primary explodes, the standby has everything.
Cons: If the network is slow or the standby is sluggish, the primary database slows down. The user feels the "lag."
The Primary database ships the redo but doesn't wait for an answer. It confirms the COMMIT to the user as soon as the local disk is written.
Pros: Maximum Performance. The primary doesn't care about network speed or standby health.
Cons: Risk of "Data Loss." If the primary crashes before the "truck" reaches the standby, those last few seconds of data are gone.
A common mistake is forgetting to create Standby Redo Logs. Without them, the standby has to wait for a "Log Switch" on the primary before it can see any data.
With SRLs, you get "Real-Time Redo Transport." As the primary writes to its log, the data is streamed instantly into the SRL on the standby. It’s like a live TV broadcast versus waiting for the DVD to be mailed to you.
| Protection Mode | Transport Type | Description |
| Maximum Protection | SYNC | The primary shuts down if it can't reach the standby. Data safety is everything. |
| Maximum Availability | SYNC | It acts like Max Protection, but if the network fails, it temporarily drops to "Async" so the business keeps running. |
| Maximum Performance | ASYNC | The standard default. Speed is the priority; a few seconds of data loss is acceptable in a disaster. |
What happens if the network goes down for an hour?
The Primary keeps working and archiving logs locally.
The Data Guard Broker notices the gap.
Once the network returns, the ARCH (Archiver) process on the primary automatically fetches the missing files and "pumps" them to the standby to catch up. This is called Gap Resolution.
In modern systems, you use the Data Guard Broker to set this up easily:
-- To switch to Synchronous transport
DGMGRL> EDIT DATABASE 'standby_db' SET PROPERTY LogXptMode='SYNC';
-- To switch to Asynchronous transport
DGMGRL> EDIT DATABASE 'standby_db' SET PROPERTY LogXptMode='ASYNC';
If you are using SYNC transport, always set the NetTimeout property. This tells the Primary: "Wait for the standby, but if you don't hear back in 30 seconds, give up and keep the business running." It prevents a "hung" standby from killing your production site.