Oracle® Data Guard helps protect Oracle databases (e.g., Oracle 11g or 12c) in the event of a disaster by replicating data from the primary database environment to a secondary (standby) disaster recovery site. Oracle Data Guard supports both synchronous replication and asynchronous replication; however, without a solution like Axxana’s Phoenix System for Oracle, both configurations have inherent qualities that make them vulnerable to data loss.
Oracle Data Guard – The Data Lag and Consistency Challenge
When using asynchronous replication in Oracle environments (e.g., Data Guard in Maximum Performance mode), there is an inherent lag between the primary site and the disaster recovery site. This lag creates a “delta” between the real-time, committed transaction data at the primary site and the data at the remote disaster recovery site. If this lag is not protected, all recent transaction data that comprises the lag—the data that has not yet been replicated to the disaster recovery site—is lost.
When multiple databases of different applications are replicated asynchronously using Data Guard, each of the replicas at the remote site will be consistent to a different point in time. This means that when data loss occurs, there will be no consistency between the various databases and applications. This inconsistency impedes recovery efforts and slows down the failover of the business to the remote site. In a best-case scenario, an extensive and lengthy manual process will be required to resume operation at some consistent point in time, across all databases and applications. In a worst-case scenario, the recovery will not succeed, and it will be necessary to recover from tapes.
Even synchronous replication (e.g., Data Guard in Maximum Availability or Maximum Protection mode) is not immune to data loss and the resulting application inconsistency. Synchronous replication—whether through a secondary disaster recovery site or an Oracle instance—requires replication sites to be in close geographic proximity. For this reason, a regional disaster or rolling event can bring down both the primary site and the secondary site or Far Sync instance, resulting in loss of the data lag. Synchronous replication also requires costly communication lines and causes latency issues that can degrade performance.
Please link to the whitepaper: Oracle Active Data Guard for Far Sync with Axxana Phoenix for Oracle. I have not found the paper on the Axxana site.
Zero Data Loss Regardless of Data Guard Replication Topology
Axxana’s Phoenix System for Oracle prevents transaction loss at any distance and maximizes application availability during a disaster by providing continuous lag protection and full, rapid recovery of application-level consistency in the Oracle environment. Whether Data Guard is configured for synchronous or asynchronous replication, the Phoenix System for Oracle ensures zero transaction loss and near-zero recovery time. It allows organizations to leverage any type of storage (including flash arrays and Exadata) and any type of server connectivity (e.g., SAN, InfiniBand, or IP-based). In addition, organizations do not need to upgrade their asynchronous communication lines in order to implement the Phoenix System for Oracle, which saves time and money.
At the heart of the Phoenix System for Oracle are the Phoenix Black Box and PhoenixOS™. Similar to an aviation black box (i.e., flight data recorder), the Black Box is designed to withstand a wide variety of extreme conditions. Installed at the primary site, the Phoenix System for Oracle protects the Oracle Redo log, Archive log, and control files. Built-in detection mechanisms enable it to automatically identify a disaster as soon as it begins. Once a disaster is identified, the Black Box transfers (via a wide area network [WAN] or 4G LTE connection) the delta data (i.e., the lag) to the secondary data center. This data can then be used to recover the Oracle database to the exact same state it was in at the moment the disaster hit the primary data center. All databases and applications are recovered to that same point in time, ensuring a complete, lossless, and consistent state of the business across all databases and applications.