Tuesday, February 11, 2014

Oracle Database 12c - Far Sync Instance



A New Standby destination type is allowed in 12c Active Dataguard environment that ensures zero data loss failover and zero performance impact on Primary Database by a new concept called "Far Sync Instance". 


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).

How to configure?
(Same as configuring Dataguard except backup/restore operations of the Primary Database)
1)Create pfile from spfile of the Primary, and copy to to Far Sync Server, and start the Instance
2)Add the Far Sync Destination, EX: "CDBFS"(Net Service Name/DB_UNIQUE_NAME), to Dataguard configuration (under LOG_ARCHVE_CONFIG=DG_CONFIG)
3)Set a new destination parameter to enable Log Transport Services, EX: LOG_ARCHIVE_DEST_3 & LOG_ARCHIVE_DEST_STATE_3
4)Create the Far Sync Instance Control file, copy it to FSI Server, and mount
SYS@CDB AS SYSDBA 28-OCT-13> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/fra/fsi_control01.ctl';
Database altered.

5)Enable the destination to FSI on Primary

FSI now receives the redo by establishing RFS connections to its primary

Hope it helps, your feedback is appreciated, and thanks for reading..

replica sets, Replication with mongoDB

Before we get into details of mongoDB replica sets, let's understand what is replication and why is it needed? Replication is a config...