Beyond a doubt, data is an asset and gives serious concerns to Organization. Every organization takes precautionary and careful measures to protect the data from various data loss situations. Because, data and its continuous availability plays a pivotal role in building organization reputation, and any prolonged interruption to the data availability could have a negative impact on business growth and over reputation. In the context, Oracle offers wide range of solutions to protect Oracle database from various data loss situations. For example, Recovery Manager (RMAN) can be used to back up the database, Real Application Clusters (RAC) offers high availability solutions and Data Guard provides ability to recover from any sort of disasters. In this article, before I start explaining what is Far Sync instance and it’s benefits, I will go through a very brief introduction about explaining what is Oracle data guard and its transition (major changes) in each new release of Oracle since its invention.

Standby Database Overview:

Oracle standby database witnessed several major enhancements since its invention in Oracle v8i (though it was possible to configure physical standby dataset since 7.3) through to the current Oracle 12c release. Although it was initially started off as read-only physical standby database option to provide disaster solution to the business critical databases, the capabilities have been strengthened to further level with every new release as explained below:

  • Logical standby database: provides option to have additional indexes, materialized views etc.
  • Automatic switch-over/fail-over: automatic switchover and failover capabilities
  • Auto gap resolution : potential to resolve archive gap by fetching the logs automatically
  • Heterogeneous platform support
  • Active Standby Database: Users can run SQL queries while recovery being taking place
  • Supports Disaster sites configured hundred/thousands of kilometers away.
  • Snapshot option: provides the ability to convert a standby database to a fully read write database and reverts back to standby mode

Far Sync instance overview

Oracle database 12c Active Data guard far sync instance is a light-weight/remote standby database instance whose role is to receive redo synchronously from the primary database and forward the redo asynchronously to the other remote standby databases configure thousands of miles away over WAN. Far sync instance acts as a middleman/proxy/redo log repository to remote standby databases. Unlike a conventional standby database, a far sync standby instance is a special/light-weight/remote instance with no physical data files of its own, manages only a sever parameter file (spfile), a standby control file and set of standby redo logs (SRLs). Since there is no physical structure, it is not possible to open the instance for general access, redo apply or convert its role to primary. It consumes very minimal server resources, such as, CPU, memory, I/O, disk etc.

The purpose of Far Sync instance discovery is primarily to offload the primary database performance obligations/complexity and overcome network latency issues involved while shipping the redo synchronously to its all remote standby databases configured far away, at the same time guarantee zero data loss failover capabilities. A typical recommendation is that you create a far sync instance close to the primary database, potentially 30-150 miles away, to overcome/avoid network latency bottlenecks and gain performance benefits while transmitting redo.  

Far Sync instance architecture

The diagrams underneath illustrate far sync active data guard instance setup:

  

The diagram represents the following scenarios:

  • A primary database send redo synchronously to the active far sync instance
  • In case the far sync instance is not active for any reasons, it will automatically transmit the redo to the alternate far sync instance, if configured
  • Although the primary database doesn’t send the redo directly to its remote standby database instances, it will maintain a direct network connection with the remote standby database members to perform health checks and switch over processing tasks
  • The active far sync instance then forwards the redo asynchronously to the other remote standby database members configure thousands of miles away

Deploying Far Sync instance                                                                                                                             

Deploying and configuring a far sync instance is no different from creating/configuring any conventional standby database, except that a far sync will have no physical data files, hence, you don’t need to restore data files for this instance. The following describes the general procedure to deploy/configure a far sync instance:

(Please note that this article will not explain the procedure to configure standby database process)

  • Create/generate a standby control file from the primary database using the following syntax, and copy the file fsinst01.ctl to the server were far sync will be configured:
    • SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFIE AS '/tmp/primfs.ctl';
  • Prepare a server parameter file (SPFILE) and password file for a far sync instance, ensure you modify the below parameters on far sync instance:
    • DB_UNIQUE_NAME=PRIMFS
    • CONTROL_FILES= '+DG_PRIMDB'
    • FAL_SERVER=PRIMDB
    • LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(PRIMDB,PRIMFS,PRIMSDB1,PRIMSDB2,PRIMSDB3)
    • LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=( ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRIMFS
    • LOG_ARCHIVE_DEST_2= 'SERVICE=PRIMSDB1 ASYNC VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME='PRIMSDB1'
    • LOG_ARCHIVE_DEST_3= 'SERVICE=PRIMSDB2 ASYNC VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME='PRIMSDB2'
    • LOG_ARCHIVE_DEST_4= 'SERVICE=PRIMSDB3 ASYNC VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) DB_UNIQUE_NAME='PRIMSDB3'
  • Using Network Configuration Assistant (NETCA) create a listener on far sync server, and add a static service of far sync instance
  • Add TNS entry for all remote standby databases (PRIMSDB1, PRIMSDB2, PRIMSDB3), as mentioned in the LOG_ARCHIVE_DEST_2 and other parameters
  • Add a TNS entry to connect to the primary database, as mentioned in the fal_server parameter

Do the following parameter changes on the primary database:

  • LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(PRIMDB,PRIMFS,PRIMSDB1,PRIMSDB2,PRIMSDB3)
  • LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=( ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRIMDB
  • LOG_ARCHIVE_DEST_2= 'SERVICE=PRIMFS SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME='PRIMFS'
  • Add a TNS entry to connect to the far sync instance

On the far sync server:

  • Startup far sync instance in no mount, and restore the standby control file from the file transferred from the production server, and mount the database subsequently:
    • RMAN> RESTORE STANDBY CONTROLFILE FROM ‘/tmp/primfs.ctl’
    • RMAN> ALTER DATABASE MOUNT

You can check database role of far sync control file as below

  • SQL> select db_unique_name,database_role from v$database;

DB_UNIQUE_NAME                 DATABASE_ROLE
------------------------------ ----------------
PRIMFS                         FAR SYNC

  • After far sync instance is mounted, create standby redo logs with same size and same number of redo groups + 1 of production database on the far sync instance. Assuming that the primary database has 3 redo groups with single redo member and sized 100m:
    • SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
    • SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
    • SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;
    • SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;

On the primary database, change the protection mode using the following command, Note that far sync instance is supported in either maximum performance or maximum availability mode. Usually when Data Guard is running under maximum availability and there is chance to switch internally to maximum performance in case of redo data unable to commit on any one standby database, With the same mechanism Oracle can work on both maximum availability and maximum performance, so worth increasing the protection level to Maximum availability.

  • SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMUM AVAILABILITY;

Optionally you can also configure alternative log shipping destination (any remote standby instance) to overcome far sync instance failure situations. Use the following example:

  • LOG_ARCHIVE_DEST_STATE_3='ALTERNATE'
  • LOG_ARCHIVE_DEST_3= 'SERVICE=PRIMSDB1 ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME='PRIMDB'

In the event of far sync failure, the primary database will continue sending the redo to the alternate destination asynchronously. Therefore, when the far sync instance becomes available, the primary database starts sending the redo to the far sync instance synchronously.

Additionally, you can also configure another far sync instance to avail the high availability option to retain/maintain maximum availability with zero data loss capabilities. To configure another far sync instance follow the above example and do the following change on the production database:

  • LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(PRIMDB,PRIMFS1,PRIMFS2,PRIMSDB1,PRIMSDB2,PRIMSDB3)
  • LOG_ARCHIVE_DEST_2= 'SERVICE=PRIMFS1 SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME='PRIMFS'
  • LOG_ARCHIVE_DEST_STATE_3'ALTERNATE'
  • LOG_ARCHIVE_DEST_3= 'SERVICE=PRIMFS2 SYNC AFFIRM ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME='PRIMFS2'

Also ensure that to use FAR sync feature, don’t forget to configure FAL_SERVER parameter to point the Far sync instances (PRIMFS1 or PRIMFS2) from the standby databases (PRIMSDB1, PRIMSDB2, PRIMSDB3). So that in case of any GAP’s standby database(s) can communicate to far sync instances to fetch the archive logs.

There will be confusion for sure, whether we have to start MRP on PRIMFS (or) PRIMSDB?

When MRP started, it reads every datafile headers, updates checkpoint information and also recovery will perform to data files. When there are no datafiles there is no scope of recovery. So MRP will be running only on standby database(s)

In this article, we have used the following primary/far sync/standby instance names for the demonstration purpose:

Primary Database

PRIMDB

Far sync

PRIMFS1, PRIMFS2

Remote standby databases

PRIMSDB1,PRIMSDB2,PRIMSDB3

In a nut shell:

  • Is a light-weight/remote Oracle data guard special instance with no physical data files of its own acts as a middleman/layer between a primary database and all its standby databases configured far away
  • Owns/manages only server parameter file (spfile), a standby control file and set of Standby redo logs (SRLs)
  • The purpose of Far Sync instance is to receive redo from the primary database synchronously and transport them to respective remote destinations, a maximum of 29 destinations, asynchronously in real time, provides zero data loss fail-over capabilities
  • Supports Maximum availability and maximum performance protection modes
  • Advised to deploy/configure closer to the primary database location, roughly 30-150 miles, to avoid the network latency while shipping redo
  • Best recommended option when standby databases are placed thousands of kilometer away from a primary site
  • The solo purpose is to offloads/minimizes a primary database performance overheads
  • Part of an active data guard option that requires separate license
  • Its role can’t be converted either to primary or any other type of standby database
  • Consumes minimal server resources, CPU, disk, memory etc.