Exadata Multi-Cloud HA & DR with MAA

On this page

1. 01 · Why HA and DR Need a Fresh Look in Multi-Cloud
2. 02 · MAA Tiers in One Picture
3. 03 · Local HA Inside One Hyperscaler Region
4. 04 · DR Topologies: Second Region, OCI or Another Cloud
5. 05 · Configuring Data Guard for Multi-Cloud
6. 06 · The Failover Sequence, Step by Step
7. 07 · Backups: The Last Line of Defence
8. 08 · Testing and Running the Design
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why HA and DR Need a Fresh Look in Multi-Cloud

Resilience brief · Oracle MAA on Exadata inside the hyperscalers

"The database is in Azure now. Where does the standby go?"

On premises, high availability and disaster recovery were mostly about two data centers and a dark fibre link. With Oracle AI Database@AWS, @Azure and @Google Cloud (formerly Oracle Database@...), the primary Exadata now sits inside a hyperscaler region, managed by OCI, next to applications you do not host. The standby could go to a second region of the same cloud, to an OCI region over an interconnect, or in some designs to another hyperscaler. Each option has different latency, cost and operational consequences.

Oracle Maximum Availability Architecture (MAA) gives you a vocabulary for these choices. It defines four reference tiers, Bronze, Silver, Gold and Platinum, and the Oracle technologies that deliver each one. The tiers apply unchanged to Exadata in a hyperscaler. The work is in mapping each building block to a concrete place: which availability zone, which region, which cloud, which network path.

02 · MAA Tiers in One Picture

Answer: Oracle MAA defines four tiers. Bronze is a single database with backups. Silver adds local clustering with RAC. Gold adds a synchronised Active Data Guard standby for disaster recovery. Platinum adds GoldenGate and zero-downtime techniques so that even failover and upgrades are close to invisible.

Each tier includes everything below it, so the tiers are a stack rather than a menu. The figure shows that stack with what each tier adds and the recovery point objective (RPO) and recovery time objective (RTO) Oracle positions for it. On Exadata in a hyperscaler, a VM cluster with two or more database servers and RAC gives you Silver from day one. Most enterprise production databases should be designed for Gold, and only a small set of revenue-critical systems justify Platinum.

Look at the step from Silver to Gold. It is the only step that protects against losing the whole Exadata site or region, and it is where multi-cloud decisions enter: the standby needs a home outside the primary region. Platinum then removes the remaining downtime for failover and planned upgrades.

03 · Local HA Inside One Hyperscaler Region

Answer: Inside one region, Exadata HA comes from the platform: redundant database servers running RAC, triple-mirrored ASM data across storage servers, and redundant RDMA networking. Oracle maintains the hardware; your team configures services, connection strings and Application Continuity so that sessions survive a node failure.

Exadata was built for local HA. A VM cluster spans at least two database servers, and Oracle Grid Infrastructure runs RAC across them. ASM high redundancy keeps three copies of data across storage servers. When Oracle patches the infrastructure or applies a Grid Infrastructure update, it does so in a rolling fashion, one server at a time, so a correctly configured application sees no outage.

The weak point is almost always the client side. If the application uses a single-instance connect string, ignores Fast Application Notification (FAN) and has no replay capability, a rolling patch still drops sessions. The table lists the failure events and what has to be in place for each.

04 · DR Topologies: Second Region, OCI or Another Cloud

Answer: The standard multi-cloud DR pattern is an Active Data Guard standby on a second Exadata in another region of the same hyperscaler, with the observer in a third location and backups replicated off-site. A standby in an OCI region over an interconnect is a common alternative or addition. Cross-cloud standbys are possible as a design pattern; confirm support for the exact combination.

The topology below shows a Gold-tier design on Oracle AI Database@Azure. The primary RAC database runs in region A next to the application tier. Redo ships asynchronously to an Active Data Guard standby on its own Exadata in region B, where a scaled-down application tier waits. An optional second standby runs in an OCI region, fed over the Oracle Interconnect for Azure. The Fast-Start Failover observer runs outside both hyperscaler regions so that it can tell a dead primary from a broken network link. The same shape works on AWS and Google Cloud.

The purple dashed arrows are Data Guard redo. Cross-region links use ASYNC transport because synchronous commit across hundreds of kilometres would slow every transaction. The grey dashed observer lines are heartbeats, not data. The black arrows show each site writing its own backups to object storage in its own region.

Comparing the standby locations

05 · Configuring Data Guard for Multi-Cloud

Answer: Use the Data Guard broker, choose the protection mode by distance (SYNC with Maximum Availability inside a region or between nearby zones, ASYNC with Maximum Performance across regions), enable Flashback Database on both sides, and enable Fast-Start Failover with an observer in a third location. Size the network for peak redo, not average.

Where the partnership supports it, create the standby from the console or API as a Data Guard association, so that the cloud tooling knows about both roles and can drive switchover and failover. For combinations the console does not cover, such as some cross-cloud designs, build the standby manually with RMAN duplicate or a restore from backup and manage it with DGMGRL. Either way the broker configuration looks the same.

-- On the primary, once the standby is registered with the broker
DGMGRL> EDIT DATABASE 'prod_a' SET PROPERTY LogXptMode='ASYNC';
DGMGRL> EDIT DATABASE 'prod_b' SET PROPERTY LogXptMode='ASYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit=30;
DGMGRL> ENABLE FAST_START FAILOVER;
-- On the observer host in the third location
DGMGRL> START OBSERVER obs1 IN BACKGROUND FILE IS '/u01/dg/fsfo.dat' LOGFILE IS '/u01/dg/obs1.log';

Then make the services role-aware so applications always land on the current primary or on the readable standby:

srvctl add service -db prod_a -service oltp_rw -preferred prod1,prod2 -role PRIMARY \
  -failovertype TRANSACTION -commit_outcome TRUE -notification TRUE -drain_timeout 300
srvctl add service -db prod_a -service report_ro -preferred prod1,prod2 -role PHYSICAL_STANDBY

Where to run the observer

The observer decides when to fail over, so its location matters more than its size. If it runs in the primary region it may fail with the primary; if it runs in the standby region it cannot distinguish a dead primary from a partitioned network. Run it in a third location: a small VM in a third region, in OCI or on premises, with network paths to both databases that do not share a single point of failure. Configure more than one observer so that losing one does not disable automatic failover.

06 · The Failover Sequence, Step by Step

Answer: A failover has five phases: detect the outage, decide that failover is safe, perform the role change, redirect applications to the new primary, and reinstate the old primary as a standby. Planned switchovers follow the same phases with no data loss and no reinstatement.

Teams often rehearse only the role change and are surprised by the other four phases. The timeline below runs both scenarios in parallel lanes: an unplanned failover driven by Fast-Start Failover and a planned switchover for maintenance or a DR drill. Each column names the parameter or command that controls the phase, so you can see where your runbook needs a decision, a script or a test.

In the failover lane most of the RTO is spent in detection and application redirection, not in the role change itself. That is why FastStartFailoverThreshold, FAN and Application Continuity matter as much as Data Guard. In the switchover lane, reinstatement disappears because the old primary becomes a standby cleanly.

1. Detect. The observer and the standby both lose contact with the primary for longer than FastStartFailoverThreshold (30 seconds by default).
2. Decide. The observer checks that the standby is within FastStartFailoverLagLimit. If not, it does not fail over and alerts instead.
3. Fail over. The broker converts the standby to primary. Role-based services start automatically on the new primary.
4. Redirect applications. FAN events tell connection pools to reconnect. Connect strings that list both sites, plus Application Continuity, replay in-flight work.
5. Reinstate. When the old primary returns, the broker uses Flashback Database to reinstate it as a standby. Without Flashback you rebuild it from a backup or by RMAN duplicate.

07 · Backups: The Last Line of Defence

Answer: Keep automatic backups on both the primary and the standby, write them to object storage in the same region as each database, and copy or replicate at least one backup set outside the primary cloud region. Backups protect against corruption and human error, which Data Guard faithfully replicates.

A standby is not a backup. If someone drops a table or a bad batch corrupts data, Data Guard ships the change to the standby within seconds. You need point-in-time recovery from backups, Flashback Database or a delayed-apply standby to undo it.

Each partnership lets you send automatic backups to native object storage (Amazon S3, Azure Blob Storage, Google Cloud Storage) or to OCI Object Storage or Autonomous Recovery Service in the parent region. Autonomous Recovery Service adds real-time redo protection and validated recovery, which closes the gap between the last backup and the failure. Decide per database, then test a restore every quarter into a separate VM cluster or an Exascale clone.

08 · Testing and Running the Design

An HA and DR design is only as good as its last test. These practices keep a multi-cloud MAA design honest:

1. Switch over twice a year. Run production from the DR region for a full business cycle. It proves the standby, the network and the application redirect all at once.
2. Patch the standby first. Apply release updates to the standby, switch over, then patch the old primary. Use Standby-First patching where the update allows it.
3. Watch apply lag, not just transport. Alert on both transport and apply lag in the native monitoring service and in Oracle tooling.
4. Fail over for real in a test environment. Kill the primary VM cluster's network in a non-production copy and time each of the five phases.
5. Write down the cross-cloud contacts. A regional event may need both the hyperscaler and Oracle support. Keep both escalation paths in the runbook.

Data Guard moves the data in seconds. Whether the business is back in seconds depends on the observer, the services and the connect strings.

09 · Key Takeaways

1. MAA tiers apply unchanged. Bronze, Silver, Gold and Platinum mean the same on Exadata inside AWS, Azure and Google Cloud as they do on premises or in OCI.
2. Exadata gives you Silver out of the box. RAC, ASM high redundancy and rolling patching handle local failures inside one site.
3. Gold needs a second home. Put an Active Data Guard standby in another region, in OCI or in a confirmed cross-cloud location, and use ASYNC across distance.
4. Place the observer and backups outside the failure domain. A third-location observer and off-region backups keep DR working when the primary site is gone.
5. Rehearse all five phases. Detect, decide, fail over, redirect and reinstate; most RTO hides in detection and application redirect.

10 · Frequently Asked Questions