Oracle introduced a new feature for DataGuard called Far Sync. This configuration is design to support synchronous redo transport between primary and standby database which are far apart. In usual configuration synchronous redo transport between data centre in Europe and US is possible but inefficient from the primary database performance perspective. Every commit has to be written locally to redo logs and send to standby with confirmation – a network round trip between Europe and US is a significant delay for every commit operation in synchronous mode. If database has to run in no data loss mode DBA had no choice but run primary in SYNC mode and suffer from every transaction network round-trip or setup both databases in data centres which are relatively close to each other.
To mitigate that problem an Oracle 12c has introduced DataGuard Far Sync instance. Far Sync instance is a log transport “proxy” and it has to be located close to the primary database. As Far Sync is a type of instance only – there is no need to put whole database there. Far Sync instance requires space for a standby and an archive logs.
In that configuration primary is sending transaction to Far Sync instance in synchronous mode so every transaction is written to primary redo logs and Far Sync standby logs – so commit time is limited to time required for both writes and network round trip between primary and Far Sync. In next stage Far Sync instance is sending redo stream in asynchronous mode to standby database located in other data center.
What is Far Sync Instance?
As we knew so far (until 11g), A SYNCHRONOUS redo transport Dataguard configuration impacts the availability and performance of Primary Database in order to protect data loss that happens due to network outages with its Standby Site. To avoid such issues and give benefit of the same zero Data loss to customers at additional cost, Oracle has introduced a new type of Instance called Far Sync Instance. A Far Sync Instance usually is very close in distance to its Primary Database Network receives the redo synchronously from its Primary partner and then pushes it to its remote Standby Partner, plays a dummy physical standby role that actually fakes its Primary Partner to forget network outages as it takes the responsibility of managing redo to actual Standby targets. As a result of it, It minimises the unplanned downtime and performance issues due to Wider Area Network latencies or simply Network latencies.
What does it contain?
This destination contains parameterfile, controlfile, and standby redo logs (SRLs), it receives the redo from Primary Database, and archives it to local destination through Standby Redo Logs. There are no Datafiles here. As a result of it, it consumes very little disk and processing resources, yet provides the ability to failover to a terminal destination with zero data loss, as well as offload the primary database of other types of overhead (for example, redo transport).
In Next article, we configure the Far Sync DataGuard.