High Availability and Disaster Recovery in Oracle Exadata Cloud@Customer Explained

Somewhere in your organisation, someone is asking: "What happens if something fails?" Maybe it's the CFO before signing off on the ExaCC purchase. Maybe it's you, staring at an architecture diagram at 11 PM, trying to remember whether RAC covers a full-site outage. (It doesn't.)

Oracle Exadata Cloud@Customer (ExaCC) doesn't pretend failures won't happen. It layers protection so that most failures never reach the user — and the catastrophic ones have a rehearsed escape route. Oracle Real Application Clusters (RAC) handles compute. Oracle Automatic Storage Management (ASM) handles disks and storage cells. Oracle Data Guard handles the whole site going dark. Each layer picks up where the last one stops.

If you want the rack-and-control-plane picture first, start with our ExaCC Architecture Overview. This article assumes you know the hardware exists — and focuses on what keeps it alive.

Here's the mistake I see most often: a team buys RAC, feels "highly available," and never budgets for a DR site. Or they build a beautiful standby database and leave the application pointing at hard-coded IP addresses that die on failover. HA and DR solve different problems. You usually need both — but they are not interchangeable.

Figure 1 · HA keeps the lights on locally. DR keeps the business alive when the whole site doesn't.

High Availability — the "something broke in the rack" problem

Think of HA as your day-to-day safety net. A compute node dies during month-end close. A flash drive throws errors. You're patching Grid Infrastructure on a rolling basis. The cluster detects it, moves work elsewhere, and life continues. If you've done the application-side work (Application Continuity, connection pools, service names), most users never know anything happened.

Disaster Recovery — the "we've lost the data center" problem

DR is what you reach for when HA has nothing left to protect. The UPS dies. The building floods. A ransomware event takes every node offline at once. Now you're not relocating a service inside a cluster — you're promoting a standby database in another city and praying your lag was acceptable.

RTO and RPO — the numbers your business actually cares about

Before you pick a protection mode or redundancy level, get these two numbers from the business — not from the DBA team guessing in a vacuum.

On ExaCC, RAC is what stops a single dead server from becoming a production outage. Multiple compute nodes share the same datafiles and work as one database — not one active and one passive, but genuinely active-active. When one node goes away, the others keep going.

If you live in RAC day-to-day, our Advanced Oracle RAC Administration course goes deeper on cache fusion tuning, service relocation, and connection pool setup. This section is the "what actually happens when things break" version.

Cache Fusion — why RAC feels like one database

When Node A needs a data block that Node B already has in memory, RAC doesn't send both nodes to disk. Cache Fusion moves the block directly between SGAs over ExaCC's internal Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) fabric. That's why RAC on Exadata feels fast — and why node-to-node coordination stays in the millisecond range instead of the I/O-wait range.

When a compute node dies — the eight-second story

Picture this: Node 2 in a three-node cluster stops responding. You didn't reboot it. Clusterware did its job before you opened a ticket. Here's the sequence, roughly:

Figure 2 · What happens in the first eight seconds after an ExaCC compute node failure

RAC protects your compute. ASM protects your data on disk. On ExaCC, every database file lives inside ASM disk groups that stripe across Exadata Storage Cells and mirror through Failure Groups — so losing one cell doesn't mean losing your data.

Failure Group design is where a lot of "we thought we had HA" stories go wrong. Our ASM Failure Groups deep dive walks through the mapping in detail. The short version: one Failure Group per storage cell, always.

Striping spreads the load. Mirroring absorbs the hit.

ASM splits your datafiles into extents and spreads them across every storage cell in the rack — so no single disk becomes a bottleneck. Then it mirrors each extent across separate Failure Groups. If Cell 2 dies on a Friday night, the database keeps running from copies on Cell 1 and Cell 3. You fix the hardware Monday. The database never went offline.

Figure 3 · How ASM places mirrored copies across independent Exadata Storage Cells

Automatic rebalancing — the part that saves your weekend

When a drive or an entire cell fails, ASM doesn't wait for you to open a change ticket. It starts rebuilding missing mirror copies onto surviving cells — while the database stays open and serving traffic. You replace the hardware when Oracle's field engineer arrives. The data layer already healed itself.

RAC and ASM are brilliant inside the building. They mean nothing when the building loses power.

That's the moment you stop talking about service relocation and start talking about failover — promoting a standby database somewhere else to become the new primary. It's stressful, it's irreversible (unlike a switchover), and it's exactly why you rehearse it twice a year instead of reading about it for the first time during an actual outage.

Figure 4 · Switchover is a scheduled handoff. Failover is an emergency promotion.

The nightmare scenario isn't failover itself — it's discovering your standby was 45 minutes behind on redo apply when the primary died. That's the RTO-versus-RPO trade-off in real life: how fast can you come back online, and how much committed data are you willing to leave behind?

Data Guard is your insurance policy for the whole site. It keeps a live copy of your production database at a second location — another data center, another city, sometimes an OCI region — by continuously shipping redo from primary to standby.

Configuration details matter here. Our Active Data Guard setup guide for Exadata covers the step-by-step. This section is about choosing the right protection mode and knowing what you're trading away.

Three protection modes — pick your poison carefully

Every protection mode is a trade-off between "how sure are we no data was lost" and "how much latency does every commit pay." There's no free lunch. Here's the honest comparison:

Table 1 · Data Guard protection modes — replication, RPO, and performance trade-offs

Active Data Guard — your standby shouldn't sit idle

With Active Data Guard, the standby stays open for read-only queries while redo apply runs in the background. That means your month-end reporting, heavy analytics, and even RMAN backups can run against the standby instead of hammering production. It's one of the few DR investments that pays dividends before disaster strikes.

Fast-Start Failover (FSFO) adds automation. A Data Guard Observer — a small witness process in a third network zone — watches both sites. If the primary vanishes, the Observer and standby coordinate a failover without waiting for someone to find the runbook at 2 AM.

Figure 5 · Data Guard architecture — redo transport, Active DG workloads, and FSFO Observer

Think of ExaCC resilience like a building with three fire doors. Each one closes a different kind of breach. You don't pick one — you stack them.

Figure 6 · Each layer handles failures the layer below it cannot — together they cover node, cell, and site outages

There's no single "correct" HA/DR design. A hospital can't tolerate the same latency trade-offs as a factory floor ERP. Here are four patterns we see repeatedly — and why each one makes sense for that industry.

Banking and financial services — zero data loss, no excuses

What keeps the CIO awake: A lost transaction isn't a bug report — it's a regulatory incident.

Typical ExaCC design: ASM High Redundancy on the primary rack. Synchronous Data Guard to a second ExaCC rack nearby (under 5 ms round-trip) in Maximum Availability mode. A third asynchronous standby in a distant OCI region for true geographic DR. Application Continuity on every connection pool. FSFO with an Observer in a third network zone.

Healthcare — clinical systems can't stutter

What keeps the CIO awake: A nurse entering vitals at bedside can't get an ORA-03113 because a node rebooted.

Typical ExaCC design: Dual- or quad-node RAC with Application Continuity fully wired into EHR connection pools. Data Guard in Maximum Performance to a secondary site — clinical writes can't wait on synchronous round-trips. Active Data Guard on the standby handles analytics and audit reporting so production stays fast.

Global manufacturing — the line stops, money burns

What keeps the CIO awake: ERP downtime stops assembly lines. Every minute has a dollar figure attached.

Typical ExaCC design: Multi-node RAC with separate ASM disk groups for production data vs backup archives. Maximum Availability Data Guard to a secondary facility — production runs at full speed, and the supply chain engine survives a regional network blip without manual intervention.

Government and defense — sovereignty plus distance

What keeps the CIO awake: Data cannot leave sovereign boundaries, but it also cannot exist in only one physical location.

Typical ExaCC design: ExaCC in on-premises sovereign data centers. Data Guard over dedicated encrypted dark fiber. FSFO Observers in three separate administrative zones to prevent split-brain when networks get unreliable — which they will, under stress.

These come up in almost every architecture review. They're understandable — and they're wrong in ways that hurt.

1. Wire up Application Continuity before you need it.I've seen perfect RAC failovers produce angry users because the JDBC URL pointed at a SID, not a service. Set FAILOVER_TYPE=TRANSACTION and test it — don't assume.
2. Give redo transport its own network path.Nothing kills a standby faster than sharing the redo NIC with bulk ETL or backup traffic. Isolate it. Monitor lag daily, not quarterly.
3. Size the standby like you mean to run on it.A standby with half the OCPUs of primary will embarrass you during the one failover that actually matters.
4. Drill failover without breaking replication.Snapshot Standby lets you test read-write against a clone of your DR database. Use it. A runbook nobody has executed is fiction.
5. Alert on lag before lag becomes a crisis.Fifteen minutes of transport lag is a warning. Four hours is a board-level conversation. Configure OEM or Cloud Guard alerts and act on them.

Print this. Walk your ExaCC deployment with a colleague. Be honest about the unchecked boxes — those are your real gaps.

• Is Oracle RAC configured across multiple nodes? (Verifies compute-tier high availability.)
• Are ASM Failure Groups explicitly mapped across distinct storage cell units? (Protects against storage server chassis failure.)
• Is Oracle Data Guard configured with an explicit protection mode matching business RPO? (Verifies site-level DR readiness.)
• Have you enabled and tested Application Continuity on application servers? (Ensures end-user transaction replay during node failures.)
• Is a third-party Data Guard Fast-Start Failover (FSFO) Observer deployed in a separate network zone? (Enables hands-free automated failover.)
• Are RMAN database backups stored on a separate platform like OCI Object Storage or Zero Data Loss Recovery Appliance? (Protects against localized rack destruction.)
• Has a full role-reversal (planned switchover) drill been performed within the last 6 months? (Validates operational readiness.)
• Are application connection strings configured to automatically search for the active primary database service across both data centers? (Ensures application traffic follows the active instance.)

1. HA and DR are distinct operational pillars.HA handles local failures within one data center; DR handles entire site losses across regions.
2. Oracle RAC handles compute node crashes.Active-active multi-node setups keep connections running via Cache Fusion and Application Continuity.
3. Oracle ASM prevents data loss from drive failures.Intelligent mirroring and automatic rebalancing protect storage blocks without operational disruption.
4. Oracle Data Guard is your site protection layer.It continuously ships transactional redo logs across geographical boundaries to a standby destination.
5. ExaCC combines these layers into one architecture.RAC, ASM, and Data Guard form a cohesive cloud-managed resilience stack.
6. RTO and RPO determine your budget and setup.Establish clear recovery metrics before choosing Maximum Availability or Maximum Performance.
7. Software settings matter as much as hardware.HA fails if application connection strings aren't tuned for seamless node transitions.
8. Resilience requires regular testing.A DR plan is only as good as your last successful failover test.

No single technology saves you on ExaCC. RAC, ASM, and Data Guard each handle a different kind of failure — and none of them work if the application layer isn't configured to follow the database when it moves.

The architects who sleep well aren't the ones who bought the most redundancy. They're the ones who tested failover last quarter, know their redo lag right now, and can tell you their RTO in plain English without opening a slide deck.

The question that separates a working ExaCC deployment from one that survives a real outage is still the same one DBAs have always asked: how does this fail — and how do we recover?

Our Exadata Expert course covers ExaCC HA/DR design hands-on — RAC failover labs, ASM Failure Group mapping, Active Data Guard setup, and the failover drills most teams never get around to doing on their own.