
Introduction
Oracle Data Guard enables you to transport the redo to the standby database synchronously to ensure zero data loss. However, when the standby database is geographically too far, the latency becomes higher, impacting the commit response time and the transaction throughput at the primary database. Oracle Active Data Guard Far Sync can ensure zero data loss at any distance without impacting the primary database performance. The Far Sync instance (a lightweight Oracle instance) provides the ability to perform a zero data loss failover to a remote standby database without creating and managing a second standby database.
Data Guard Environment
In the following example, the Data Guard configuration consists of a primary database running in the OCI Ashburn region (Ashburn_ad1) and a standby database running in the OCI London region (London_ad1). Maximum Performance Mode with asynchronous replication is being used to not impact the application performance by the high network latency between Ashburn and London.

The Data Guard broker’s RedoRoutes property looks like follows for this configuration:
[oracle@hostiad ~]$ dgmgrl SYS as sysdba
DGMGRL> EDIT DATABASE 'Ashburn_ad1' SET PROPERTY RedoRoutes = '( LOCAL : London_ad1 ASYNC)';
Property "redoroutes" updated
DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated
Check the configuration:
[oracle@hostiad ~]$ dgmgrl SYS as sysdba
DGMGRL> show configuration
Configuration - Ashburn_ad1_London_ad1
Protection Mode: MaxPerformance
Members:
Ashburn_ad1 - Primary database
London_ad1 - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 57 seconds ago)
Adding a Far Sync Instance
To use synchronous replication in Maximum Availability mode and ensure zero data loss without impacting application performance, a Far Sync instance (FS1) is added to the configuration. The primary database sends redo to the geographically close Far Sync instance with low network latency, while the Far Sync instance forwards the redo asynchronously to the standby.

The Data Guard broker’s RedoRoutes property looks like follows for this configuration:
[oracle@hostiad ~]$ dgmgrl SYS as sysdba
DGMGRL> EDIT DATABASE 'Ashburn_ad1' SET PROPERTY RedoRoutes = '( LOCAL : ( FS1 FASTSYNC PRIORITY=1, London_ad1 ASYNC PRIORITY=2 ))';
Property "redoroutes" updated
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY RedoRoutes = '( Ashburn_ad1 : London_ad1 ASYNC )';
Property "redoroutes" updated
DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated
Check the configuration:
DGMGRL> show configuration
Configuration - Ashburn_ad1_London_ad1
Protection Mode: MaxAvailability
Members:
Ashburn_ad1 - Primary database
fs1 - Far sync instance
London_ad1 - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 57 seconds ago)
Far Sync Instance in the Remote Region
After a role switch with the previous configuration, the new primary in London will send redo to Ashburn asynchronously:

To ensure zero data loss after a role switch, you need to add a Far Sync instance (FS2) in the London region too. The new primary in London sends redo synchronously to the geographically close Far Sync instance, which forwards the redo asynchronously to Ashburn:

This is achieved by modifying the RedoRoutes as follows:
DGMGRL> EDIT DATABASE 'London_ad1' SET PROPERTY RedoRoutes = '( LOCAL : ( FS2 FASTSYNC PRIORITY=1, Ashburn_ad1 ASYNC PRIORITY=2 ))';
Property "redoroutes" updated
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY RedoRoutes = '( London_ad1 : Ashburn_ad1 ASYNC )';
Property "redoroutes" updated
Far Sync Instance Location
The Far Sync instance should be separated from the primary database to ensure they can’t be affected by the same failure or disaster, but still close enough to the primary to ensure low latency and high application performance.
The primary, standby, and Far Sync instances can be deployed anywhere: on-premises, Oracle Cloud, Non-Oracle Clouds, Hybrid Cloud, or Multicloud environments.
In a Cloud scenario in regions with multiple data centers (Availability Domains/Zones) for example, the Far Sync instance could be deployed in a different data center than the primary.

Considerations
- Far Sync is a very lightweight instance. However, disk performance is critical as the Far Sync instance writes the received redo to disk before acknowledging back to the primary, which impacts the application performance.
- Create two Far Sync instances per region for Far Sync instance High Availability.
- The Far Sync feature requires the Active Data Guard option license.
Conclusion
Far Sync receives redo from the primary database synchronously and forwards it to the standby database asynchronously, ensuring zero data loss even if the standby database is at a far distance from the primary without affecting application performance. Create an additional Far Sync instance in the remote region to ensure a symmetric configuration after a role switch.