Introducing Native Support for Database Disaster Recovery with Oracle Data Guard in NDB

Why Disaster Recovery for Oracle Databases Is So Hard – and Why It Matters

When designing for business continuity, both High Availability (HA) and Disaster Recovery (DR) are essential - but they solve very different problems.

• HA protects against localized failures (e.g., server crashes or VM outages) and keeps your database online through fast failover within the same site.

• DR protects against site-wide or regional disasters (e.g., power outages or natural disasters) and enables your database to be recovered in a different location, even if the primary site is completely down.

HA keeps your database running through minor faults. DR brings it back after major outages.

The Challenges of Implementing & Scaling Native DR

Implementing DR directly within the database engine offers the most precise and transaction-aware protection. But it is not without complexity. 

Oracle Data Guard is a powerful native DR solution, offering transaction-aware protection and robust failover capabilities. But in enterprise environments, its implementation is far from simple.

It demands deep expertise, manual configuration, and careful orchestration - and these challenges multiply as your database fleet grows. Scaling DR across dozens or hundreds of Oracle instances introduces significant operational overhead. Each environment may be managed by different teams, follow different standards, or reside in different silos - making consistency and coordination a real challenge.

Tasks like configuring replication, monitoring lag, and orchestrating switchovers or failovers often require dropping into native tooling or writing custom scripts. This can increase the risk of configuration drift and inconsistent recovery behavior, and also create dependencies on tribal knowledge and custom automation - both of which may be fragile in large organizations.

In short, the complexity of native DR isn’t just technical - it’s organizational. And that’s exactly why simplifying and centralizing DR operations is so critical for enterprise-scale resilience.

By contrast, managing DR from a unified platform - alongside provisioning, patching, and backup - can simplify operations dramatically. It enables teams to:

• Automate DR setup across multiple Oracle instances
• Seamlessly size and connect primary/secondary environments
• Run DR drills uniformly and painlessly
• Accelerate day-2 operations after a DR event

In a nutshell: Native DR is essential - and often mandatory for compliance in regulated environments - but complex. Embedding it directly into a database management system is a true game-changer.

Now You Can Do It All Straight from NDB

The complexity of implementing native DR across your database fleet is real - but now, you don’t have to do it alone.

NDB 2.9 now supports native disaster recovery for Oracle databases, powered by Oracle Data Guard. That means you can now configure, monitor, and operate DR directly from NDB – using the same platform you already use for provisioning, patching, and backup and Time Machine operations.

Whether you prefer API, CLI, or UI, you can now:

• Provision Oracle databases with DR baked in, including support for:
  • Cascaded standby configurations
  • Multiple standby topologies
  • These are supported across Single Instance (SIDB), Single Instance High Availability (SIHA), and Real Application Clusters (RAC) topologies.
  • Selecting the most appropriate protection mode (Maximum Protection, Maximum Performance, Maximum Availability)
• Run DR drills with switchover and switchback to validate your setup without impacting production, for maintenance or testing purposes.
• Trigger failovers in the event of an actual disaster

All of this is now accessible directly within NDB – no need to drop into different database-specific tooling, write custom scripts, or coordinate across multiple teams.

Figure 1: Provisioning a DR Cluster in a Multiple Standby Configuration in the NDB Disaster Recovery UI

Let’s take a closer look at the technical capabilities now available in NDB for Oracle DR.

Flexible DR Topologies

To meet a wide range of business continuity requirements, NDB now supports multiple Oracle DR topologies - giving you the flexibility to design protection strategies that align with your architecture and risk tolerance. Whether you're looking for straightforward coverage or multi-site resilience, you can now configure:

• Single DR Secondary: A standard configuration where the primary database streams redo logs to a single standby instance.
• Multiple DR Secondary: For added protection, the primary can stream redo logs to two standby databases simultaneously, enabling higher availability and failover flexibility.
• Cascaded DR Secondary: Ideal for multi-site strategies, this topology allows a primary to send redo logs to a first standby, which then forwards them to a second, cascaded standby -  reducing load on the primary and extending DR reach.
• These topologies are supported across SIDB, SIHA & RAC configurations, giving you flexibility regardless of your deployment model.

Replication Modes That Fit Your Strategy

NDB gives you control over how your Oracle DR environment balances performance and data protection - by supporting all standard Oracle Data Guard replication modes. You can choose the mode that best aligns with your business continuity goals:

• Maximum Performance: Prioritizes throughput by using asynchronous redo transport. This mode minimizes impact on the primary system, with a minimal trade-off in potential data loss during a failure.
• Maximum Availability: Strikes a balance between performance and protection. It uses synchronous transport during normal operations but can temporarily revert to asynchronous mode to prevent disruption to the primary database’s availability. It is designed to provide zero data loss during normal operations with minimal impact on availability.
• Maximum Protection: Designed to deliver zero data loss by requiring synchronous transport with no tolerance for gaps. If the primary cannot write to at least one standby, it will shut down to maintain  data integrity.

Whether you're optimizing for speed, resilience, or regulatory compliance, NDB gives you the flexibility to choose the right protection model for each workload.

Flexible Standby Creation

NDB supports multiple options for creating standby databases, allowing you to tailor your DR setup to your operational and architectural needs:

• Choice of Creation Method: Standby databases can be created using either Active Duplicate or RMAN (Recovery MANager, Oracle’s built-in tool that helps back up, restore, and recover databases) backups, depending on your preferred approach and infrastructure readiness.
• Control Over Standby State: You can specify whether the standby database is initialized in Mount Mode (where the standby database is started and attached to the control file but remains inaccessible to users - typically used when applying redo logs to keep the standby in sync with the primary) or Read-Only Mode (where the standby database is open for querying and reporting, but changes cannot be made - useful for off-loading read-only workloads ), enabling use cases like reporting or validation.
• Heterogeneous Configurations: NDB supports flexible topologies, such as provisioning an SI standby from a RAC primary - ideal for optimizing cost or simplifying DR environments.
• Automatic TDE Key Management: For databases using Transparent Data Encryption (TDE), NDB automatically manages the secure transfer of encryption keys to the standby, eliminating manual steps and reducing setup risk.

One-Click Switchover and Failover

Just as with provisioning, patching and cloning operations, NDB now is also your single pane of glass for controlling switchover and failover operations for planned and unplanned role transitions, respectively, via simple one-click workflows:

• Switchover: For planned maintenance or testing, you can initiate a controlled role reversal directly from the NDB console. The primary and standby databases switch roles gracefully, with no data loss. Simply select the target standby, and NDB handles the orchestration.
• Failover: In the event of an unplanned outage, you can promote a standby database to become the new primary with a single action. This is a manually-initiated activity and depends on an informed evaluation of the disaster situation - since it may entail data loss - as well as coordination across the stack, including applications. In configurations with multiple standbys, NDB enables you to select which one to promote.

Independent Data Protection with Time Machine

One of the architectural advantages of NDB is its Time Machine feature, which lets NDB users conduct point in time recovery (PITR) of their databases using snapshots and transaction logs defined by their recovery settings. With the Time Machine, operations for primary and standby databases are fully decoupled. This separation enables more flexible workload management and enhances data resilience.

• Operational Flexibility: Backup and cloning operations (Copy Data Management) can be offloaded to the standby database, reducing load on the primary and improving overall system efficiency.
• Resilient Recovery: In the event of a complete site failure, the standby database retains full Point-in-Time Recovery (PITR) capabilities from its own backup history - allowing granular recovery even when the primary is unavailable.

With native database engine disaster recovery now integrated into NDB - now available for Oracle databases and powered by  Oracle Data Guard - teams can define, operate, and validate their DR strategies from the same platform they already use to manage their databases. From flexible topologies and protection modes to simplified switchover, failover, and recovery workflows, NDB brings consistency and control to what has traditionally been a fragmented and complex domain.

This is a major step forward in unifying database lifecycle management - and it’s just the beginning.

To learn more or get started, visit https://www.nutanix.com/ndb , and check out these additional references:

• Get a demo of the feature on https://demo.nutanix.com/
• Check out the feature documentation here.