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.
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:
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.
The diagrams underneath illustrate far sync active data guard instance setup:
The diagram represents the following scenarios:
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)
Do the following parameter changes on the primary database:
On the far sync server:
You can check database role of far sync control file as below
DB_UNIQUE_NAME DATABASE_ROLE ------------------------------ ---------------- PRIMFS FAR SYNC
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.
Optionally you can also configure alternative log shipping destination (any remote standby instance) to overcome far sync instance failure situations. Use the following example:
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:
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:
Remote standby databases
In a nut shell: