Previous Next JavaScript must be enabled to correctly display this content

## Implement disaster recovery with multi-region standby on Oracle Database@Azure

Ensuring uninterrupted business continuity is critical to success when designing applications. Achieving this requires a robust disaster recovery strategy designed to quickly restore functionality in case of disruptions.

For years, organizations have relied on Oracle Exadata Database Service which is Oracle's premier disaster recovery technologies to support mission-critical applications, whether on-premises or within Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure brings the same industry-leading performance, feature set, and price parity as Exadata on OCI. It leverages Microsoft Azure's availability zones (AZs) and regions to provide low latency to Azure's applications on top of unmatched high availability and disaster recovery capabilities, ensuring seamless operations during maintenance and in the event of disruption.

### Architecture

This architecture shows Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure in a multi-region disaster recovery topology using two remote standby databases.

The following diagram illustrates this reference architecture.

Description of the illustration multi-region-standby-dr-db-azure-arch.png

multi-region-standby-dr-db-azure-arch-oracle.zip

The Oracle Database runs in an Exadata virtual machine (VM) cluster in the Primary region. For data protection and disaster recovery, Oracle Active Data Guard replicates the data to two standby databases running on Exadata VM clusters in two different Standby regions. A remote standby database setup ensures data protection against regional failures and can also be used to offload read-only query processing. Replicate the application across regions to avoid higher latency after switching over to a Standby database.

You can route Active Data Guard traffic through the Azure network. However, this architecture focuses on Active Data Guard network traffic through the OCI network to optimize network throughput and latency.

The Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure network is connected to the Exadata client subnet using a Dynamic Routing Gateway (DRG) managed by Oracle. A DRG is also required to create a peer connection between Virtual Cloud Networks (VCNs) in different regions. Because only one DRG is allowed per VCN in OCI, a second VCN acting as a Hub VCN with its own DRG is required to connect the primary and standby VCNs in each region. In this architecture:

- The primary Exadata VM cluster is deployed in `Region 1` in `VCN1` with `CIDR 10.10.0.0/16`.
- The hub VCN in the primary `Region 1` is `HubVCN1` with `CIDR 10.11.0.0/16`.
- The first standby Exadata VM cluster is deployed in `Region 2` in `VCN2` with `CIDR 10.20.0.0/16`.
- The hub VCN in the first standby region is `HubVCN2` with `CIDR 10.22.0.0/16`.
- The second standby Exadata VM cluster is deployed in `Region 3` in `VCN3` with `CIDR 10.30.0.0/16`.
- The hub VCN in the second standby region is `HubVCN3` with `CIDR 10.33.0.0/16`.

No subnet is required for the hub VCNs to enable transit routing, therefore these VCNs can use very small IP CIDR ranges. The VCNs on the OCI child site are created after the Oracle Exadata Database Service on Dedicated Infrastructure VM clusters on Oracle Database@Azure are created for the Primary and Standby databases.

Microsoft Azure provides the following components:

- 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.

- Azure availability zone

  Azure availability zones are physically separate locations within an Azure region, designed to ensure high availability and resiliency by providing independent power, cooling, and networking.

- Azure Virtual Network (VNet)

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

- Azure delegated subnet

  A delegated subnet allows you to insert a managed service, specifically a platform-as-a-service (PaaS) service, directly into your virtual network as a resource. You have full integration management of external PaaS services within your virtual networks.

- Azure Virtual Network Interface Card (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.

OCI provides the following components:

- Region

  An Oracle Cloud Infrastructure 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 domains

  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 VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping 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.

- Local peering

  Local peering enables you to peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

- 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 Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

- 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 the internet 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.

- Data Guard

  Oracle Data Guard and Oracle 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 an Oracle Cloud service that protects Oracle databases. Backup automation and enhanced data protection capabilities for OCI databases allow you to offload all backup processing and storage requirements to Oracle Database Autonomous Recovery Service, which reduces backup infrastructure costs and manual administration overhead.

- Exadata Database Service on Dedicated Infrastructure

  Oracle Exadata Database Service on Dedicated Infrastructure 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 Database@Azure

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

  Oracle 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 Database is built on Oracle Exadata infrastructure, is self-managing, self-securing, and self-repairing, helping eliminate manual database management and human errors. Autonomous 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 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 disaster recovery for Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure. Your requirements might differ from the architecture described here.

- Use Active Data Guard for comprehensive data corruption prevention with automatic block repair, online upgrades and migrations, and offload workload to standby with read-mostly scale-out.
- Enable Application Continuity to mask database outages during planned and unplanned events from end-users and ensure uninterrupted applications.
- Set up automatic backup to Oracle Database Autonomous Recovery Service (in Azure or OCI) even though the data is protected by Oracle Data Guard to minimize the backup workload on the database by implementing the incremental forever backup strategy that eliminates weekly full backups. Alternatively, customers can use OCI Object Storage for automatic backups.
- Enable backups from standby to achieve backup replication across regions.
- Use OCI Full Stack DR to orchestrate database switchover and failover operations.
- Use OCI Vault to store the database's Transparent Data Encryption (TDE) keys using customer-managed keys.

### Considerations

When performing multi-regional disaster recovery for Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@Azure, consider the following.

- When Exadata VM clusters are created in the Oracle Database@Azure child site, each VM cluster is created within its own OCI VCN. Oracle Data Guard requires that the databases communicate with each other to ship `redo` data. Peer the VCNs to enable this communication. Hence, the Exadata VM cluster VCNs must not share overlapping IP CIDR ranges.
- 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, and disaster recovery 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 OCI and Microsoft Azure environments.
- OCI is the preferred network for achieving better performance, measured by latency and throughput, and for achieving reduced cost, including the first 10 TB/month egress for free.
- You can create up to six standby databases for a primary database via Cloud Tooling.
- Creating a standby database associated with another standby database (cascading standby) is not supported using Cloud Tooling.

### Deploy

Follow these steps to configure the network communication between regions shown in the architecture diagram:

Follow these steps to configure the Primary region:

1. Add the following ingress rules to the Security List of the client subnet of `VCN1` to allow incoming traffic from `VCN2` and `VCN3`.

   Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description
   --- | --- | --- | --- | --- | --- | ---
   No | `10.20.0.0/16` | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from `VCN2`
   No | `10.30.0.0/16` | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from `VCN3`

2. Create Virtual Cloud Network `HubVCN1` with `CIDR 10.11.0.0/16`.
3. Create Local Peering Gateway `HubLPG1` in Virtual Cloud Network `HubVCN1`.
4. Create Local Peering Gateway `LPG1R` in Virtual Cloud Network `VCN1`.
5. Establish the local peering connection between `LPG1R` and `HubLPG1`.
6. Add route rules to the route table of the client subnet of `VCN1` to forward traffic targeted for `VCN2` and `VCN3` to `LPG1R`.

   Destination | Target Type | Target | Route Type | Description
   --- | --- | --- | --- | ---
   `10.20.0.0/16` | Local Peering Gateway | `LPG1R` | Static | Traffic to `VCN2`
   `10.30.0.0/16` | Local Peering Gateway | `LPG1R` | Static | Traffic to `VCN3`

7. Create Route Table `HubLPG1rt` in `HubVCN1`.
8. Associate Route Table `HubLPG1rt` to Local Peering Gateway `HubLPG1`.
9. Create Dynamic Routing Gateway `DRG1`.
10. Create Route Table `DRG1rt` in `HubVCN1`.
11. Add a route rule to Route Table `DRG1rt` to forward traffic targeted for `VCN1` to `HubLPG1`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.10.0.0/16` | Local Peering Gateway | `HubLPG1` | Static | Traffic to `VCN1`

12. To attach `DRG1` to `HubVCN1`:
    1. Select Autogenerated Drg Route Table for VCN attachments.
    2. Select the existing route table `DRG1rt`.
    3. Select VCN CIDR blocks.
13. Create two Remote Peering Connections in `DRG1`, named `RPC1a` and `RPC1b`.
14. Add two route rules to `HubLPG1rt` to forward traffic targeted for `VCN2` and `VCN3` to `DRG1`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.20.0.0/16` | Dynamic Routing Gateway | `DRG1` | Static | Traffic to `VCN2`
    `10.30.0.0/16` | Dynamic Routing Gateway | `DRG1` | Static | Traffic to `VCN3`

Follow these steps to create the first Standby region (Region 2):

1. Add the following ingress rules to the Security List of the client subnet of `VCN2` to allow incoming traffic from `VCN1` and `VCN3`.

   Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description
   --- | --- | --- | --- | --- | --- | ---
   No | `10.10.0.0/16` | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from `VCN1`
   No | `10.30.0.0/16` | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from `VCN3`

2. Create Virtual Cloud Network `HubVCN2` with CIDR `10.22.0.0/16`.
3. Create Local Peering Gateway `HubLPG2` in Virtual Cloud Network `HubVCN2`.
4. Create Local Peering Gateway `LPG2R` in Virtual Cloud Network `VCN2`.
5. Establish the local peering connection between `LPG2R` and `HubLPG2`.
6. Add route rules to the Route Table of the client subnet of `VCN2` to forward traffic targeted for `VCN1` and `VCN3` to `LPG2R`.

   Destination | Target Type | Target | Route Type | Description
   --- | --- | --- | --- | ---
   `10.10.0.0/16` | Local Peering Gateway | `LPG2R` | Static | Traffic to `VCN1`
   `10.30.0.0/16` | Local Peering Gateway | `LPG2R` | Static | Traffic to `VCN3`

7. Create Route Table `HubLPG2rt` in `HubVCN2`.
8. Associate Route Table `HubLPG2rt` to Local Peering Gateway `HubLPG2`.
9. Create Dynamic Routing Gateway `DRG2`.
10. Create Route Table `DRG2rt` in `HubVCN2`.
11. Add a route rule to `DRG2rt` to forward traffic targeted for `VCN2` to `HubLPG2`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.20.0.0/16` | Local Peering Gateway | `HubLPG2` | Static | Traffic to `VCN2`

12. To attach `DRG1` to `HubVCN2`:
    1. Select Autogenerated Drg Route Table for VCN attachments.
    2. Select the existing route table `DRG2rt`.
    3. Select VCN CIDR blocks.
13. Create two Remote Peering Connections in `DRG2`, named `RPC2a` and `RPC2c`.
14. Establish a remote peering connection between `RPC1a` (region 1) and `RPC2a` (region 2).
15. Add two route rules to `HubLPG2rt` to forward traffic targeted for `VCN1` and `VCN3` to `DRG2`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.10.0.0/16` | Dynamic Routing Gateway | `DRG2` | Static | Traffic to `VCN1`
    `10.30.0.0/16` | Dynamic Routing Gateway | `DRG2` | Static | Traffic to `VCN3`

Follow these steps to create the second Standby region (Region 3):

1. Add the following ingress rules to the Security List of the client subnet of `VCN3` to allow incoming traffic from `VCN1` and `VCN2`.

   Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description
   --- | --- | --- | --- | --- | --- | ---
   No | 10.10.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from VCN1
   No | 10.20.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | Allow ingress from VCN2

2. Create Virtual Cloud Network `HubVCN3` with `CIDR 10.33.0.0/16`.
3. Create Local Peering Gateway `HubLPG3` in Virtual Cloud Network `HubVCN3`.
4. Create Local Peering Gateway `LPG3R` in Virtual Cloud Network `VCN3`.
5. Establish the local peering connection between `LPG3R` and `HubLPG3`.
6. Add route rules to the Route Table of the client subnet of `VCN3` to forward traffic targeted for `VCN1` and `VCN2` to `LPG3R`.

   Destination | Target Type | Target | Route Type | Description
   --- | --- | --- | --- | ---
   `10.10.0.0/16` | Local Peering Gateway | `LPG3R` | Static | Traffic to `VCN1`
   `10.20.0.0/16` | Local Peering Gateway | `LPG3R` | Static | Traffic to `VCN2`

7. Create Route Table `HubLPG3rt` in `HubVCN3`.
8. Associate Route Table `HubLPG3rt` to Local Peering Gateway `HubLPG3`.
9. Create Dynamic Routing Gateway `DRG3`.
10. Create Route Table `DRG3rt` in `HubVCN3`.
11. Add a route rule to `DRG3rt` to forward traffic targeted for `VCN3` to `HubLPG3`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.30.0.0/16` | Local Peering Gateway | `HubLPG3` | Static | Traffic to `VCN3`

12. To attach `DRG1` to `HubVCN3`:
    1. Select Autogenerated Drg Route Table for VCN attachments.
    2. Select the existing route table `DRG3rt`.
    3. Select VCN CIDR blocks.
13. Create two Remote Peering Connections in `DRG3`, named `RPC3b` and `RPC3c`.
14. Establish a remote peering connection between `RPC1b` (region 1) and `RPC3b` (region 3).
15. Establish a remote peering connection between `RPC2c` (region 2) and `RPC3c` (region 3).
16. Add two route rules to `HubLPG3rt` to forward traffic targeted for `VCN1` and `VCN2` to `DRG3`.

    Destination | Target Type | Target | Route Type | Description
    --- | --- | --- | --- | ---
    `10.10.0.0/16` | Dynamic Routing Gateway | `DRG3` | Static | Traffic to `VCN1`
    `10.20.0.0/16` | Dynamic Routing Gateway | `DRG3` | Static | Traffic to `VCN2`

### Explore More

Learn more about about Oracle Database@Azure and Oracle Data Guard.

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

- High Availability Overview and Best Practices documentation

- MAA best practices for Oracle Data Guard documentation

- Oracle Database@Azure site

- First Principles: Powering mission critical applications with Oracle Database@Azure site

- Oracle Exadata Database Service on Dedicated Infrastructure

- Oracle Data Guard site

Review these additional resources:

- Oracle Cloud Infrastructure for Microsoft Azure professionals
- Well-architected framework for Oracle Cloud Infrastructure
- Oracle Cloud Infrastructure documentation
- Oracle Cloud Cost Estimator

### Acknowledgments

- Authors: Sinan Petrus Toma, Sebastian Solbach, Julien Silverston
- Contributor: Sreya Dutta

Title and Copyright Information

Implement disaster recovery with multi-region standby on Oracle Database@Azure

G30082-01

April 2025

Copyright ©2025,
Oracle and/or its affiliates.