Previous Next JavaScript must be enabled to correctly display this content

## Implement Cross-Region Disaster Recovery for Oracle Exadata Database Service on Oracle AI Database@Azure

When designing applications, it is essential to ensure business continuity by establishing a robust disaster recovery mechanism for restoring operations in the event of an outage.

For many years, customers have trusted Oracle Exadata Database Service using Oracle Maximum Availability Architecture (MAA) to power mission-critical applications both on premises and on Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Oracle AI Database@Azure offers feature and price parity with Exadata on OCI and can be deployed across multiple Microsoft Azure availability zones (AZs) and regions to ensure high availability and disaster recovery.

### Architecture

This architecture shows a high-availability, containerized Azure Kubernetes Service (AKS) application with Oracle Exadata Database Service on Oracle AI Database@Azure in a cross-region, disaster recovery topology.

A high-availability, containerized Azure Kubernetes Service (AKS) application is deployed in two Azure regions: a primary region and a standby region. The container images are stored in the Azure container registry and are replicated between primary and standby regions. Users access the application externally through a public load balancer.

For data protection, the Oracle Database is running in an Exadata virtual machine (VM) cluster in the primary region, with Oracle Data Guard or Oracle Active Data Guard replicating the data to the standby database running on an Exadata VM cluster in the standby region.

The database transparent data encryption (TDE) keys are stored in Oracle Cloud Infrastructure Vault and replicated between the Azure and OCI regions. The automatic backups are in OCI for both the primary and standby regions. Customers can use Oracle Cloud Infrastructure Object Storage or Oracle Database Autonomous Recovery Service as the preferred storage solution.

The Oracle Exadata Database Service on Oracle AI Database@Azure network is connected to the Exadata client subnet by using a dynamic routing gateway (DRG) managed by Oracle. A DRG is also required to create a peer connection between VCNs in different regions. Because only one DRG is allowed per VCN in OCI, a second VCN with its own DRG is required to connect the primary and standby VCNs in each region. In this example:

- The primary Exadata VM cluster is deployed in the `VCN Primary` VCN client subnet (10.5.0.0/24).
- The `Hub VCN Primary` VCN for the transit network is 10.15.0.0/29.
- The standby Exadata VM cluster is deployed in the `VCN Standby` VCN client subnet (10.6.0.0/24).
- The `Hub VCN Standby` VCN for the transit network is 10.16.0.0/29.

No subnet is required for the Hub VCNs to enable transit routing, therefore these VCNs can use a very small network. The VCNs on the OCI child site are created after the Oracle Exadata Database Service VM clusters on Oracle AI Database@Azure have been created for the primary and standby databases.

The following diagram illustrates the architecture:

Description of the illustration exadb-dr-db-azure.png

exadb-dr-db-azure-oracle.zip

Microsoft Azure provides the following components:

- Microsoft Azure region

  An Azure region is a geographical area in which one or more physical Azure data centers, called availability zones, reside. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  Azure and OCI regions are localized geographic areas. For Oracle Database@Azure, an Azure region is connected to an OCI region, with availability zones (AZs) in Azure connected to availability domains (ADs) in OCI. Azure and OCI region pairs are selected to minimize distance and latency.

- Microsoft Azure availability zone

  An availability zone is a physically-separate data center within a region that is designed to be highly available and fault tolerant. Availability zones are close enough to have low-latency connections to other availability zones.

- Microsoft Azure Virtual Netwok

  Microsoft Azure Virtual Network (VNet) is the fundamental building block for a private network in Azure. VNet enables many types of Azure resources, such as Azure virtual machines (VM), to securely communicate with each other, the internet, and with on-premises networks.

- Microsoft Azure Delegated Subnet

  Subnet delegation alows you to inject a managed service, specifically a platform-as-a-service (PaaS) service, directly into your virtual network. A delegated subnet can be a home for an externally managed service inside of your virtual network so that the external service acts as a virtual network resource, even though it is an external PaaS service.

- Microsoft Azure VNIC

  The services in Azure data centers have physical network interface cards (NICs). Virtual machine instances communicate using virtual NICs (VNICs) associated with the physical NICs. Each instance has a primary VNIC that's automatically created and attached during launch and is available during the instance's lifetime.

- Microsoft Azure Route table

  Virtual route tables contain rules to route traffic from subnets to destinations outside a VNet, typically through gateways. Route tables are associated with subnets in a VNet.

- Azure Virtual Network Gateway

  Azure Virtual Network Gateway service establishes secure, cross-premises connectivity between an Azure virtual network and an on-premises network. It allows you to create a hybrid network that spans your data center and Azure.

Oracle Cloud Infrastructure provides the following components:

- OCI region

  An OCI region is a localized geographic area that contains one or more data centers, hosting availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

- Availability domain

  Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain shouldn't affect the other availability domains in the region.

- Virtual cloud network (VCN) and subnets

  A virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (CIDR) blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

- Route table

  Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

- Security list

  For each subnet, you can create security rules that specify the source, destination, and type of traffic that is allowed in and out of the subnet.

- Dynamic routing gateway (DRG)

  The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

- Service gateway

  A service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

- Local peering

  Local peering allows two VCNs within the same OCI region to communicate directly using private IP addresses. This communication does not traverse the internet or your on-premises network. Local peering is enabled by a Local Peering Gateway (LPG), which serves as the connection point between VCNs. Configure an LPG in each VCN and establish a peering relationship to allow instances, load balancers, and other resources in one VCN to securely access resources in another VCN within the same region.

- Network security group (NSG)

  NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of OCI you control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of virtual network interface cards (VNICs) in a single VCN.

- OCI Object Storage

  OCI Object Storage provides access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store data directly from applications or from within the cloud platform. You can scale storage without experiencing any degradation in performance or service reliability.

  Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.

- Oracle Data Guard

  Oracle Data Guard and Active Data Guard provide a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases and that enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database by using in-memory replication. If the production database becomes unavailable due to a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Oracle Active Data Guard provides the additional ability to offload read-mostly workloads to standby databases and also provides advanced data protection features.

- Oracle Database Autonomous Recovery Service

  Oracle Database Autonomous Recovery Service is a fully managed service designed to protect Oracle Databases from data loss and cyber threats. It offers faster backups with reduced database overhead, reliable recovery with validated backups, and real-time protection enabling recovery to within less than a second of an outage or ransomware attack. This service provides a centralized data protection dashboard and is recommended for backing up Oracle Databases with high resiliency.

- Exadata Database Service

  Oracle Exadata is an enterprise database platform that runs Oracle Database workloads of any scale and criticality with high performance, availability, and security. Exadata’s scale-out design employs unique optimizations that let transaction processing, analytics, machine learning, and mixed workloads run faster and more efficiently. Consolidating diverse Oracle Database workloads on Exadata platforms in enterprise data centers, on OCI, and in multicloud environments helps organizations increase operational efficiency, reduce IT administration, and lower costs.

  enables you to leverage the power of Exadata in the cloud. Oracle Exadata Database Service delivers proven Oracle Database capabilities on purpose-built, optimized Oracle Exadata infrastructure in the public cloud. Built-in cloud automation, elastic resource scaling, security, and fast performance for all Oracle Database workloads helps you simplify management and reduce costs.

- Oracle AI Database@Azure

  Oracle AI Database@Azure is the Oracle Database service (Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Autonomous AI Database Serverless) running on OCI, deployed in Microsoft Azure data centers. The service offers features and price parity with OCI. Purchase the service on Azure Marketplace.

  Oracle AI Database@Azure integrates Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC), and Oracle Data Guard technologies into the Azure platform. Users manage the service on the Azure console and with Azure automation tools. The service is deployed in Azure Virtual Network (VNet) and integrated with the Azure identity and access management system. The OCI and Oracle Database generic metrics and audit logs are natively available in Azure. The service requires users to have an Azure subscription and an OCI tenancy.

  Autonomous AI Database is built on Oracle Exadata infrastructure, is self-managing, self-securing, and self-repairing, helping eliminate manual database management and human errors. Autonomous AI Database enables development of scalable AI-powered apps with any data using built-in AI capabilities using your choice of large language model (LLM) and deployment location.

  Both Oracle Exadata Database Service and Oracle Autonomous AI Database Serverless are easily provisioned through the native Azure Portal, enabling access to the broader Azure ecosystem.

### Recommendations

Use the following recommendations as a starting point when performing cross-region disaster recovery for Oracle Exadata Database Service on Oracle AI Database@Azure. Your requirements might differ from the architecture described here.

- Deploy the required Exadata infrastructure in both primary and standby regions. For each Exadata instance, deploy an Exadata VM cluster in the delegated subnet of a Microsoft Azure virtual network (VNet). The Oracle Real Application Clusters (RAC) database can then be instantiated on the cluster. In the same VNet, deploy Azure Kubernetes Service (AKS) in a separate subnet. Configure Oracle Data Guard to replicate data from one Oracle Database to the other, across regions.
- When Exadata VM clusters are created in the Oracle AI Database@Azure child site, each is created within its own Oracle Cloud Infrastructure virtual cloud network (VCN). Oracle Data Guard requires that the databases communicate with each other to ship redo data. The VCNs must be peered to enable this communication.

### Considerations

When performing cross-region disaster recovery for Oracle Exadata Database Service on Oracle AI Database@Azure, consider the following.

- Preparation for a disaster scenario requires a comprehensive approach that considers different business requirements and availability architectures and that encompasses those considerations in an actionable, high-availability (HA), disaster-recovery (DR) plan. The scenario described here provides guidelines to help select the approach that best fits your application deployment by using a simple but effective failover for the disaster recovery configuration in your Oracle Cloud Infrastructure (OCI) and Microsoft Azure environments.
- Use Oracle Data Guard across regions for the databases provisioned in the Exadata VM Cluster on Oracle AI Database@Azure by using an OCI-managed network.
- Oracle Cloud Infrastructure is the preferred network for achieving better performance, measured by latency and throughput, and for achieving reduced cost, as the first 10 TB/Month is free.

### Deploy

To configure the network communication between regions shown in the above architecture diagram, complete the following high-level steps.

Primary Region

1. Create a virtual cloud network (VCN), `HUB VCN Primary`, in the Oracle Cloud Infrastructure (OCI) primary region.
2. Deploy two local peering gateways (LPGs), `Primary-LPG` and `Hub-Primary-LPG`, in `VCN Primary` and `HUB VCN Primary` respectively.
3. Establish a peer LPG connection between the LPGs for `HUB VCN Primary` and `VCN Primary`.
4. Create a dynamic routing gateway (DRG), `Primary-DRG` in the `Hub VCN Primary` VCN.
5. In the `HUB VCN Primary` VCN, create the route table, `primary_hub_transit_drg`, and assign the destination of the `VCN Primary` client subnet, a target type of `LPG`, and the target `Hub-Primary-LPG`. For example:

       10.5.0.0/24 target type: LPG, Target: Hub-Primary-LPG

6. In the `HUB VCN Primary` VCN, create a second route table, `primary_hub_transit_lpg`, and assign the destination of the `VCN Standby` client subnet, a target type `DRG`, and a target `Primary-DRG`. For example:

       10.6.0.0/24 target type: DRG, Target: Primary-DRG

7. From the `Hub VCN Primary` VCN, attach `Hub VCN Primary` to the DRG. Edit the DRG VCN attachments, and under advanced options, edit the tab VCN route table to associate it with the `primary_hub_transit_drg` route table. This configuration permits transit routing.​
8. From the `Hub VCN Primary` VCN, associate the `primary_hub_transit_lpg` route table with the `Hub-Primary-LPG` gateway.
9. In the `Hub VCN Primary` default route table, add a route rule for the `VCN Primary` client subnet IP Address range to use the LPG. Add another route rule for the `VCN Standby` client subnet IP Address range to use the DRG. For example:

       10.5.0.0/24 LPG Hub-Primary-LPG
       10.6.0.0/24 DRG Primary-DRG

10. From `Primary-DRG`, select the DRG route table, `Autogenerated DRG Route Table for RPC, VC, and IPSec attachments`. Add a static route to the `VCN Primary` subnet client IP Address range that uses the `Hub VCN Primary` VCN with a next hop attachment type of `VCN` and the next hop attachment name `Primary Hub attachment`. For example:

        10.5.0.0/24 VCN Primary Hub attachment

11. Use the `Primary-DRG` remote peering connection attachments menu to create a remote peering connection, `RPC`.
12. In the `VCN Primary` client subnet, update the network security group (NSG) to create a security rule to allow ingress for TCP port 1521. Optionally, you can add SSH port 22 for direct SSH access to the database servers.

    Note:

    For a more precise configuration, disable the import route distribution of the `Autogenerated DRG Route Table for RPC, VC, and IPSec attachments` route table. For `Autogenerated DRG Route Table for VCN attachments`, create and assign a new import route distribution including only the required RPC attachment.

Standby Region

1. Create the VCN, `HUB VCN Standby`, in the OCI standby region.
2. Deploy two LPGs, `Standby-LPG` and `Hub-Standby-LPG`, in the `VCN Standby` and the `HUB VCN Standby` VCNs respectively.
3. Establish a peer LPG connection between LPGs for `VCN Standby` and `HUB VCN Standby`.
4. Create a DRG, `Standby-DRG` in the `Hub VCN Standby` VCN.
5. In the `HUB VCN Standby` VCN, create a route table, `standby_hub_transit_drg`, and assign the destination of the `VCN Standby` client subnet, a target type of `LPG`, and a target `Hub-Standby-LPG`. For example:

       10.6.0.0/24 target type: LPG, Target: Hub-Standby-LPG

6. In the `HUB VCN Standby` VCN, create a second route table, `standby_hub_transit_lpg` and assign the destination of the `VCN Primary` client subnet, a target type DRG, and a target `Standby-DRG`. For example:

       10.5.0.0/24 target type: DRG, Target: Standby-DRG

7. From the `HUB VCN Standby` VCN, attach the `Hub VCN Standby` VCN to the DRG. Edit The DRG VCN attachments and under advanced options, edit the VCN route table to associate it with the `standby_hub_transit_drg` route table. This configuration permits transit routing.
8. From the `HUB VCN Standby` VCN, in the `Hub VCN Standby` default route table, add route rules for the `VCN Standby` client subnet IP Address range to use the LPG and for the `VCN Primary` client subnet IP Address range to use the DRG. For example:

       10.6.0.0/24 LPG Hub-Standby-LPG
       10.5.0.0/24 DRG Standby-DRG

9. Associate the route table, `standby_hub_transit_lpg` with the `Hub-Standby-LPG` gateway.
10. From `Standby-DRG`, select the DRG route table `Autogenerated Drg Route Table for RPC, VC, and IPSec attachments`. Add a static route to the `VCN Standby` subnet client IP Address range that use the `Hub VCN Standby` VCN with a next hop attachment type of VCN and the next hop attachment name `Standby Hub attachment`. For example:

        10.6.0.0/24 VCN Standby Hub attachment

11. Use the `Standby-DRG` remote peering connection attachments menu to create a remote peering connection, `RPC`.
12. Select the remote peering connection, select Establish Connection, and provide the `Primary-DRG` OCID. The peering status becomes peered. Both regions are connected.
13. In the `VCN Standby` client subnet, update the NSG to create a security rule to allow ingress for TCP port 1521. Optionally, you can add SSH port 22 for direct SSH access to the database servers.

Data Guard Association

1. To enable Oracle Data Guard or Oracle Active Data Guard for the Oracle Database, on the Oracle Database details page, click Data Guard Associations, then click Enable Data Guard.
2. On the Enable Data Guard page:
   1. Select the standby region.
   2. Select the standby availability domain mapped to Azure AZ.
   3. Select the standby Exadata infrastructure.
   4. Select the desired standby VM cluster.
   5. Choose Oracle Data Guard or Oracle Active Data Guard. MAA recommends Oracle Active Data Guard for auto block repair of data corruptions and the ability to offload reporting.
   6. For cross-region Oracle Data Guard associations, only the maximum performance protection mode is supported.
   7. Select an existing database home or create one. It's recommended to use the same database software image of the primary database for the standby database home, so that both have the same patches available.
   8. Enter the password for the SYS user and enable Oracle Data Guard.

   After Oracle Data Guard is enabled, the standby database will be listed in the Data Guard Associations section.

3. (Optional) Enable automatic failover (Fast-Start Failover) to reduce the recovery time in case of failures by installing Data Guard Observer on a separate VM, preferably in a separate location or in the application network.

Deploy

Follow these steps to download the code from GitHub, customize the code, and deploy it:

1. Go to GitHub.
2. Clone or download the repository.
3. Follow the instructions in the README document.

### Explore More

Learn more about the features of this architecture and about related architectures.

- Oracle AI Database@Azure

- Well-architected framework for Oracle Cloud Infrastructure

- High Availability Overview and Best Practices

- Oracle Maximum Availability Architecture for Oracle AI Database@Azure

- Learn about Oracle Maximum Availability Architecture for Oracle AI Database@Azure

- Oracle Data Guard

- Fast-Start Failover

- First Principles: Powering mission-critical applications with Oracle AI Database@Azure (blog)

- Oracle Cloud Infrastructure Documentation

- Oracle Cloud Cost Estimator

### Acknowledgments

- Authors: Ricardo Anda, Srikanth Bolisetty, Julien Silverston, Andy Steinorth, Lingaraj Nayak
- Contributors: Tammy Bednar, Wei Han, Glen Hawkins, Gavin Parish, Sinan Petrus Toma, Lawrence To, Thomas Van Buggenhout, Robert Lies

### Change Log

This log lists significant changes:

March 10, 2026 | Added a Deploy section with a link to the repository that includes the associated Terraform code.

Title and Copyright Information

Implement cross-region disaster recovery for Exadata Database on Oracle AI Database@Azure

G10653-06

April 2026

Copyright ©2024,2026,
Oracle and/or its affiliates.