Best Practices for Configuring Far Sync in Oracle Data Guard

 

Best Practices for Configuring Far Sync in Oracle Data Guard

Alireza Kamrani    14/07/2025

Active Data Guard Far Sync

SYNC transport over WAN distances or on an underperforming network often has too large an impact on primary database performance to support zero data loss protection.

Oracle Active Data Guard Far Sync provides the ability to perform a zero data loss failover to a remote standby database without requiring a second standby database or complex operation.

Far Sync enables this by deploying a Far Sync instance (a lightweight Oracle instance) at a distance that is within an acceptable range of the primary for SYNC transport.

A Far Sync instance receives redo from the primary using SYNC transport and forwards the redo to up to 29 remote standby databases using ASYNC transport.

 

There are few new configuration best practices necessary in addition to those that would apply to any SYNC redo transport destination.

They are:

• Standby Redo Logs (SRLs) should be placed on storage with sufficient IOPS (writes per second) capacity to support peak primary database redo rates in addition to any I/O activity using the same shared storage. This is an important consideration. For example:
• If the Far Sync instance has lower performing disks than the primary it will not be able to forward redo to remote destinations as fast as it is received, and an archive log gap may form.
• In the case of redo gap resolution scenarios, due to planned maintenance on the standby or network outages, for example, there will be additional I/O requests for gap resolution on top of peak redo coming in.
• Lower performing disks at the Far Sync instance will delay acknowledgement to the primary database, increasing the total round-trip time between primary and standby and impacting application response time. This impact can be eliminated by using Fast Sync between the primary and the Far Sync instance.
• The Far Sync instance should have the same number of redo log groups as the primary plus one for each thread as described in standard MAA Best Practices.
• The SRLs of an alternate Far Sync instance should be manually cleared prior to use in order to achieve the best return to SYNC transport when the alternate Far Sync is acitvated. For example:

ALTER DATABASE CLEAR LOGFILE GROUP 4, GROUP 5, GROUP 6, GROUP 7;

• Performance testing has shown that a small Far Sync instance SGA does not impact performance of the Far Sync instance nor the primary database. The MAA recommendation is to configure the minimum SGA required for Far Sync to function.
• In order to achieve the smallest possible SGA, set CPU_COUNT=1 or 2.
• MAA testing determined that a 300MB SGA (with CPU_COUNT=1) on Linux was sufficient for Far Sync
• When using RMAN, configure the RMAN archive log deletion policy at the Far Sync instance to SHIPPED TO ALL STANDBY or APPLIED ON ALL STANDBY. Backing up the archive logs at the Far Sync instance is not necessary provided there is a proper backup plan at the primary or standby site.
• Configure Far Sync instances for both the primary and standby databases to allow for zero data loss protection to be maintained following role transitions. The second Far Sync instance configured in proximity to the standby database will be idle until the standby becomes primary, enabling SYNC redo transport in the reverse direction.
• Note that in a Data Guard Broker configuration, a switchover (planned role transition) cannot occur while in Maximum Availability mode unless the protection mode can be enforced from the target standby site. If the standby does not have its own Far Sync instance it will have to be configured to ship ASYNC to the original primary after roles are reversed. This will prevent a switchover from occurring unless the protection mode for the primary database is first dropped from Maximum Availability to Maximum Performance.
• Fast Sync improved performance between 5% and 12% depending on the network latency between the primary database and Far Sync instance.
• Multiple Far Sync instances servicing multiple Data Guard configurations can share the same physical server, cluster, or virtual machine.

 

Oracle Far Sync is a lightweight instance introduced in Oracle 12c that allows zero data loss (Maximum Availability protection) over long distances

by synchronously transferring redo to a local Far Sync instance, which then asynchronously forwards it to a remote standby.

1. Use for Maximum Availability Mode Over WAN

• Far Sync is designed for zero data loss across high-latency networks.
• It allows the primary to acknowledge redo locally (to Far Sync), improving commit performance while still protecting remote sites.

2. Deploy Far Sync Close to the Primary

• Place the Far Sync instance in the same data center (or local metro network) as the primary to ensure low-latency synchronous transport.
• Avoid WAN latency between primary and Far Sync.

3. Ensure Network Redundancy

• Use redundant network interfaces and paths to minimize the risk of communication failures between primary and Far Sync.
• Consider enabling Data Guard Fast-Start Failover (FSFO) with observer for better fault tolerance.

4. Configure Far Sync with Redo Transport Compression

• If network bandwidth is a concern, enable redo transport compression to reduce traffic between Far Sync and the remote standby.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_n='SERVICE=far_sync_instance COMPRESSION=ENABLE ...';

 

5. Protect Far Sync with Its Own Data Guard (Optional)

• You can configure a standby for the Far Sync instance itself, which allows continuity in case the Far Sync server fails.

6. Monitor Redo Transport Lag

• Use views like V$DATAGUARD_STATS and V$STANDBY_SYNC_STATUS to monitor:
• Apply lag on the standby
• Transport lag from Far Sync
• Sync status and RTO (recovery time objective)

7. Tune Redo Transport Parameters

Adjust key parameters for optimal performance:

• REOPEN – retry interval if transport fails
• NET_TIMEOUT – time to wait before marking the transport connection as failed
• ASYNC/NOASYNC, AFFIRM/NOAFFIRM settings depending on your protection mode

Example:

SQL> LOG_ARCHIVE_DEST_2='SERVICE=FARSYNC SYNC AFFIRM NET_TIMEOUT=15 REOPEN=5 VALID_FOR= (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=farsync_site'

8. Dedicated Host and Resources

• Run Far Sync on a dedicated server or VM with adequate CPU, RAM, and I/O.
• Ensure it has sufficient disk space for standby redo logs (but it does not store full datafiles).

9. Use Static Service Names in TNS

• Far Sync connections must use static service entries in listener.ora (it cannot register dynamically).

Example:

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = farsync_dg)

      (SID_NAME = farsync)

      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)

    )

  )

10. Use Oracle Enterprise Manager or Scripts for Health Checks

• Regularly monitor Far Sync health and redo transport status.
• Automate alerts for lag, connection loss, or log shipping failures.

 

Goal	Best Practice
Low-Latency Sync with Primary	Deploy Far Sync close to Primary (same site)
Redo Transport Efficiency	Enable compression, tune NET_TIMEOUT, REOPEN
High Availability	Redundant network and optional Far Sync standby
Manageability	Use static services, monitoring tools, alerting
Protection Across WAN	Use Far Sync for Maximum Availability mode

 

 Sample Configuration Template (Primary + Far Sync + Remote Standby)

 On the Primary Database:

-- Configure Redo Destination to Far Sync (SYNC, AFFIRM)

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 =   'SERVICE=farsync SYNC AFFIRM NET_TIMEOUT=15 REOPEN=5     VALID_FOR= (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=farsync_site';

 

-- Confirm valid destination

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG = 'DG_CONFIG= (primary_db, farsync_site, remote_standby)';

 

 On the Far Sync Instance:

-- Create Far Sync instance using DBCA or manually

-- Ensure no datafiles exist — only standby redo logs

 

-- TNS Static Listener Entry (listener.ora)

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = farsync_site_DGMGRL)

      (SID_NAME = farsync)

      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)

    )

  )

 

-- Redo destination to remote standby

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 ='SERVICE=remote_standby ASYNC NOAFFIRM COMPRESSION=ENABLE NET_TIMEOUT=30 REOPEN=10  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=remote_standby';

---

Far Sync Architecture Overview

 

• Primary ↔ Far Sync: Synchronous (SYNC AFFIRM) connection, ensuring zero data loss.
• Far Sync ↔ Remote Standby: Asynchronous transport over WAN, improving performance.
• Far Sync does not hold datafiles, only standby redo logs and configuration metadata.

Supported Protection Modes for Far Sync Instances 

There are two types of protection modes available in the Far Sync instance configuration:

1. Maximum Availability Mode: In this mode, the Far Sync instance resides comparatively closer to the primary database to reduce network latency. This mode uses Synchronous transport as a primary service for redo transport.
2. Maximum Performance Mode: In this mode, the Primary database uses the asynchronous redo primary service to the Far Sync instance destination for redo transport. Regardless of the physical distance between Far Sync and the primary instance, the high network latencies do not impact redo tractions if the remote destination uses asynchronous transport. A Far Sync instance can provide more benefits to Oracle Data Guard configurations which have more than one remote destination. Almost zero incremental effect for every remote destination adds to the Data Guard configuration. A Far Sync instance also takes care of a redo transport compression and offloads it from a primary including serving the rest of the standbys in the configuration. To achieve better performance, you need to ensure that the number of destinations is high.

Advantages of Far Sync Instance

• A very lightweight standby instance.
• It only maintains instances i.e. parameter file with control file and SRLs, No Datafiles.
• Due to this, it consumes very low server resources i.e. CPU, Memory, I/O, etc.
• No Network latency issues even synchronous redo shipping.
• Always gives Zero-Data-Loss Guarantee. 
• Should be close to the Primary site, within 40-150 miles, on a higher bandwidth network link.
• No Physical Structure in terms of Database.
• Active-n-alternate Far sync instances can be configured. 
• A maximum of 29 Remote Standby databases can be supported.