From 12c onwards, Data Guard maximum availability supports the use of the noaffirm redo transport parameter. It enables Maximum Availability protection mode at larger distances with less performance impact then before. In “LogXptMode=FASTSYNC” mode, standby database returns receipt acknowledgment to its primary database as soon as redo is received in memory. The standby database does not wait for the Remote File Server (RFS) to write to a standby redo log file.

This is how FastSync set up:


Oracle 12c introduced Far Sync Data Guard configuration which 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. Far Sync instance is a log transport “proxy” and it has to be located close to the primary database. The far sync instance just has a control file , standby redo logs and it archives the standby redo log files to local archive redo logs. This type of instance does not have any user data files so it means it cannot be opened for read access.

Data Guard Broker configuration is already there ( as described Here) and adding new Far Sync instance is quite easy task.

Primary Database DGTST_PRIMY
Remote standby databases DGTST_STBY
 Far sync DGTST_FS

Create directories:  Create the following directories where you want to create the FarSync database instance.

Create Controlfile and pfile: Create a standby control file and pfile file from the primary database using the following syntax, and copy the control file, pfile and  password file to the server were far sync will be configured.

Update parameters: Now update the parameter file with for FarSync instance. Only Data Guard related parameter need to be changed.

Now copy control file and parameter file to true location.

Tnsnames.ora : entry “DGTST_FS”  has to be added on primary and standby server as well along with FarSync server.

Now Far Sync instance can be started and new standby logs could be created. Make sure that Data Guard Broker has been started as well.

Update following parameter at Primary and standby database.

Broker will be used to do all configuration work. You should connect to Broker from primary database.

Note: Don’t set any log_arch_dest_n. DGBroker will take care that.

Above configuration is sending redo data from primary database to far sync instance using SYNC mode and redo data from far sync instance to standby database using ASYNC mode. As primary and far sync instance are close one to each other you can have no data loss mode without additional network synchronization overhead.

I hope this is help for you.


Leave a Reply