How to mitigate the performance/protection trade-off in Oracle Data Guard - Part 2 (Axxana)

Introduction

In the previous blog post titled "How to mitigate the performance/protection trade-off in Oracle Data Guard"  I reviewed the common performance vs. protection trade-off between the various data protection modes in Data Guard : Maximum performance (default), maximum availability and maximum protection.

In that blog post I mentioned how far syn can be used in order to achieve both performance (due to the smaller network latency between primary and local far sync instance) while allowing for higher data protection as the far sync instance is always synced with the primary database.

The Challenge
As the far sync instance is located in a near location to the primary database (probably the same data center), what happens if the entire data center is down due to an unexpected site disaster?
In that case there is a good chance that some of the transactions are not protected as there is an asynchronous replication between the far sync instance and the standby instance. In other words, even when using Far sync, it's not possible to guarantee RPO-0 (zero data loss).

Optional Solution
One solution that I came across in several Oracle conferences (such as Oracle OpenWorld and IOUG Collaborate) which you may consider is Axxana
Axxana is like an Oracle Database "black box" which provides a protected storage unit with DR capabilities Installed at the production site, the Black Box is designed to withstand a wide variety of extreme conditions that may occur during a disaster.

According to the official Azxxana website: "Axxana’s Phoenix for Oracle Far Sync, supported by Oracle, is a self-contained, physically indestructible solution that houses, protects, and supports the Oracle Far Sync instance from within the primary (production) data center. Because a nearby data center is not needed, the risk of a nearby synchronous site failing (e.g., due to a power outage or downed communication lines) no longer exists. Zero data loss is guaranteed, increasing the probability of successful failover. In addition, because the instance can reside at the primary site, communication lines are a matter of feet instead of miles and network latency is negligible. Given that it easily and cost-effectively resolves the challenges associated with standalone versions of Far Sync, there is simply no good reason to use the Far Sync software on any other platform—or for that matter, to use three data centers. IT leaders owe it to their company and their customers to take advantage of the risk reduction, cost savings, and other opportunities that Phoenix for Oracle Far Sync offers."