Zero Data Loss for Any Replication Topology
Oracle Database 11g (as well as Oracle 10g, 12c, and other releases) is an object-relational database management system (RDMS) that stores data and runs processes related to monitoring and expediting database operations. Oracle® Data Guard helps protect Oracle 11g and other Oracle databases 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 Oracle 11g and other databases vulnerable to data loss.
Oracle 11g Replication – The Data Lag and Consistency Challenge
When using asynchronous replication for Oracle 11g (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’s Oracle 11g 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 Oracle 11g 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 Oracle 11g 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 manual process will be required to resume operation at some consistent point in time, across all Oracle 11g 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 of Oracle 11g (e.g., Data Guard in Maximum Availability or Maximum Protection mode) is not immune to data loss and the resulting application inconsistency. Synchronous replication 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, resulting in loss of the data lag. Synchronous replication also requires costly communication lines and causes latency issues that can degrade performance.
Zero Data Loss for Oracle 11g – Regardless of 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 11g 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 Oracle 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 (for 11g, 12c, and others) 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 11g 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.