Oracle Data Guard long distance replication

Oracle data guard had been around for some time already enabling you to have a standby database and keep this in sync with your primary database for failover situations. One of the less know features from Oracle data Guard is the use of a Data Guard Broker. In many setups the use of Oracle Data Guard is somewhat limited due to the distances between your primary datacenter and your secondary datacenter. You are limited by the laws of physics on where your secondary datacenter can be located while keeping performance at an acceptable level. This is because if you are using SYNC synchronisation your primary database will be waiting for a commit of the write from the secondary database. The log writer on the primary database will wait for a acknowledgement from the standby database when operating in a protection or availability mode. After the acknowledgement from the standby database is received it will send the acknowledge from the commit to the client application.

Even though Oracle Data Guard is already available to databases for some time it has been improved a lot in the new Oracle Database 12C release and will be compatible with the container database setup and the pluggable database concept.

Oracle Data Guard broker is a distributed management framework which enables you to have more flexibiity when developing your primary and standby database design with Data Guard. Oracle data guard is proving you standard with 3 options; protection, availability and performance. You can set this by using a SQL command in your database.

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

All 3 options have there own use and should be considerd carefully when implemented and checked against the SLA's you have for this database, the RPO set for recovery and the performance demands for this database. The option you will have tie into the your consideration is the number of transactions per second that will be running against your database. All transactions that are not a read will have to be send to the standby database(s) which will have a load on your entire system.

To be able to take the correct decision you will have to understand what the protection, availability and performance option will do.

Maximum Protection:
Maximum Protection offers the highest level of data protection. Maximum Protection synchronously transmits redo records to the standby database(s) using SYNC redo transport. The Log Writer process on the primary database will not acknowledge the commit to the client application until Data Guard confirms that the transaction data is safely on disk on at least one standby server. Because of the synchronous nature of redo transmission, Maximum Protection can impact primary database response time. Configuring a low latency network with sufficient bandwidth for peak transaction load can minimize this impact. Financial institutions and lottery systems are two examples where this highest level of data protection has been deployed.

It is strongly recommended that Maximum Protection be configured with at least two standby databases so that if one standby destination fails, the surviving destination can still acknowledge the primary, and production can continue uninterrupted. Users who are considering this protection mode must be willing to accept that the primary database will stall (and eventually crash) if at least one standby database is unable to return an acknowledgement that redo has been received and written to disk. This behavior is required by the rules of Maximum Protection to achieve zero data loss under circumstances where there are multiple failures (e.g. the network between the primary and standby fails, and then a second event causes the primary site to fail). If this is not acceptable, and you want zero data loss protection but the primary must remain available even in circumstances where the standby cannot acknowledge data is protected, use the Maximum Availability protection mode described below. 

Maximum Availability:
Maximum Availability provides the next highest level of data protection while maintaining availability of the primary database. As with Maximum Protection, redo data is synchronously transmitted to the standby database using SYNC redo transport services. Log Writer will not acknowledge that transactions have been committed by the primary database until Data Guard has confirmed that the transaction data is available on disk on at least one standby server. However, unlike Maximum Protection, primary database processing will continue if the last participating standby database becomes unavailable (e.g. network connectivity problems or standby failure). The standby database will temporarily fall behind compared to the primary database while it is in a disconnected state. When contact is re-established, Data Guard automatically resynchronizes the standby database with the primary.

Because of synchronous redo transmission, this protection mode can impact response time and throughput. Configuring a low latency network with sufficient bandwidth for peak transaction load can minimize this impact.

Maximum Availability is suitable for businesses that want the assurance of zero data loss protection, but do not want the production database to be impacted by network or standby server failures. These businesses will accept the possibility of data loss should a second failure subsequently affect the production database before the initial network or standby failure is resolved and the configuration resynchronised.

Maximum Performance:
Maximum Performance is the default protection mode. It offers slightly less data protection with the potential for higher primary database performance than Maximum Availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped to the standby database using ASYNC redo transport. Log Writer on the primary database does not wait for standby acknowledgement before it acknowledges the commit to the client application. This eliminates the potential overhead of the network round-trip and standby disk i/o on primary database response time. If any standby destination becomes unavailable, processing continues on the primary database and there is little or no impact on performance.

During normal operation, data loss exposure is limited to that amount of data that is in-flight between the primary and standby – an amount that is a function of the network’s capacity to handle the volume of redo data generated by the primary database. If adequate bandwidth is provided, total data loss exposure is very small or zero.

Maximum Performance should be used when availability and performance on the primary database are more important than the risk of losing a small amount of data. This mode is suitable for Data Guard deployments in cases where the latency inherent in a customer’s network is high enough to limit the suitability of synchronous redo transmission.

When you are using Data Guard Broker as a man in the middle solution you can mix and match the above mentioned solutions. This will enable you to get past some of the physical issues that you are around long distance replication. The below model shows how you could do a long distance data replication using the Oracle Data Guard Broker technology as a true distributed management framework.

In the above image you can see that Data Guard is using a SYNC connection to the Oracle Data Guard broker. The Data Guard broker is to be located at a location which is geographically close to the primary database and should be equipped with networking capabilities that are up to the task. Using the SYNC method will make that the primary database is waiting for a acknowledge from the broker. As soon as the acknowledge is received the primary database can provide a acknowledge to the client.

From this point on Oracle Data Guard broker can be configured to use a ASYNC Connection to ship the changes to the standby database. By using the ASYNC option you can achieve data synchronisation over a much longer distance. Within the setup for Oracle Database 12C specially on this point some improvements are made and will be available in 2013 in the first release 12.1 release of the new database concept.

You can place the Oracle Data Guard broker in the same datacenter as the primary database however it would make good sense if you placed it in a different datacenter. By having a SYNC connection to the Oracle Data Guard broker all your data will be in the datacenter where the Oracle Data Guard broker is and this will forward it to the standby database. So in case of an emergency all data will be transported to the standby database even in the case of a sudden total loss of the primary datacenter.