Synchronous vs Asynchronous Transport, Far Sync Concepts, Lag, and Network Design

Learning outcomes

ServiceHub's primary is in one city and its standby is 80 ms away. The team chooses synchronous transport because “SYNC means zero data loss” and later discovers every commit became slower. Another team chooses ASYNC without measuring peak redo rate and accumulates transport lag during batch windows. Transport is a queueing/network design: redo generation, network throughput/round-trip time (RTT), standby receive I/O and apply capacity determine currency and commit impact.

1. SYNC puts a remote acknowledgment in the protection path

With synchronous redo transport, primary transaction protection requires the remote destination to acknowledge the redo according to the configured durability mode. In Maximum Protection, SYNC to a synchronized standby is required. Maximum Availability also uses synchronized transport but preserves primary availability according to its rules when the destination becomes unavailable.

Commit latency can therefore include network RTT, standby/far-sync receive processing, and—when AFFIRM durability is used—standby redo-log I/O before acknowledgment.

2. ASYNC decouples primary commit from remote acknowledgment

With ASYNC, the primary can commit after local redo durability while transport workers send redo independently. This reduces direct WAN latency impact on commits but creates potential data-loss exposure for redo generated but not received by the target when the primary/site is lost.

Protection mode plus transport attribute—not the word “synchronous” alone—defines the real durability contract.

3. Transport lag and apply lag must be sampled repeatedly

SELECT  name,  value,  time_computed,  datum_timeFROM v$dataguard_statsWHERE name IN ('transport lag','apply lag','apply finish time')ORDER BY name;

If DATUM_TIME stops changing, the displayed lag value is stale because fresh primary data is not arriving. Oracle notes that potential data loss during that disconnection must be considered from the last datum time toward the present, not from the frozen formatted lag alone.

4. Free design lab: measure source redo rate and commits/second

SELECT  SYSTIMESTAMP AS captured_at,  MAX(CASE WHEN name='redo size' THEN value END) AS redo_bytes,  MAX(CASE WHEN name='user commits' THEN value END) AS commitsFROM v$sysstatWHERE name IN ('redo size','user commits');

Compute:

• redo bytes/sec = delta redo bytes ÷ elapsed seconds
• commits/sec = delta user commits ÷ elapsed seconds

Design network capacity from peak/percentile workload windows rather than one average. Include protocol/encryption/compression overhead, other traffic and failure/catch-up headroom based on measured testing—not a universal percentage.

5. Measure the path rather than infer it from geography

ping -c 20 standby-host.example.com

ping -n 20 standby-host.example.com

Ping gives an ICMP RTT sample, not Oracle Net throughput, packet-loss behavior under sustained load, or standby redo-write latency. Production qualification should measure Oracle Net transfer/redo behavior during normal and stressed network/storage conditions. Firewalls, MTU, TLS/native encryption, routing and competing traffic matter.

6. Entitled destination status shows transport state

SELECT  dest_id,  db_unique_name,  status,  type,  synchronization_status,  synchronized,  recovery_mode,  archived_seq#,  applied_seq#,  errorFROM v$archive_dest_statusWHERE type IN ('PHYSICAL','FAR SYNC')ORDER BY dest_id;

Sequence counters and synchronization status complement lag metrics. Do not interpret APPLIED_SEQ# alone for real-time apply without understanding whether the current SRL contains newer, not-yet-archived redo.

7. Far Sync moves the synchronous acknowledgment closer to the primary

An Oracle Data Guard far sync instance is a lightweight instance with a control file, SPFILE, password file and standby redo logs—but no user datafiles and no online redo logs. It cannot be opened for application access, run Redo Apply, become primary, or serve as a normal standby.

A common design sends redo synchronously from primary to a nearby far-sync instance and forwards it asynchronously over the WAN to a remote physical standby. This can extend zero-data-loss protection to a distant failover target under the documented failure model without putting the full WAN RTT directly into every primary commit.

8. Deliberately wrong: “RTT is 3 ms, therefore zero data loss is guaranteed”

RTT says nothing about standby redo-log durability, transport mode, protection mode, missing SRLs, observer/failover rules, redo corruption, bandwidth saturation, storage stalls or simultaneous failures. A zero-data-loss design requires a synchronized target and a tested failover path whose durability state is verified at failure time.

9. Network/redo capacity worksheet

10. Production judgment

Choose SYNC when the business requires the lower data-loss exposure and the network/standby durability path fits commit-latency objectives. Choose ASYNC when commit isolation is more important and the explicit RPO permits transport lag. Monitor lag/freshness and test outage/catch-up conditions, not just healthy steady state.

Far Sync is topology-heavy and Active Data Guard licensed; do not present it as a free WAN accelerator. Lesson 4 now separates basic mounted standby protection from the separately licensed ability to keep apply running while application PDBs are open for reads.

Authoritative references

• Redo Transport Services — SYNC/ASYNC/AFFIRM transport mechanics
• Managing Data Protection Modes — mode/transport requirements
• Redo Transport Troubleshooting and Tuning — transport/apply lag interpretation
• Using Far Sync Instances — far sync architecture
• Licensing Information — Far Sync/Advanced Compression/ADG boundaries