Running Mission-Critical Oracle Databases on Exadata Across Multiple Clouds

On this page

1. 01 · What Mission-Critical Means in a Multi-Cloud Estate
2. 02 · Start With the Availability Tier
3. 03 · The Reference Architecture of a Governed Estate
4. 04 · The Operating Model: Who Owns Which Layer
5. 05 · Observability That Works Across Clouds
6. 06 · Security, Keys and Compliance
7. 07 · Patching and Change Without Downtime
8. 08 · Incident Response Across Three Parties
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · What Mission-Critical Means in a Multi-Cloud Estate

Operations brief · Tier-1 Oracle workloads on Database@ Exadata

"Who do we call at 3 a.m.?"

That is usually the first question a risk committee asks when a tier-1 Oracle database moves onto Oracle AI Database@Azure, @AWS or @Google Cloud. On premises the answer was simple: your DBA team, your data center team and Oracle Support. In the Database@ model there are three parties. Oracle operates the Exadata infrastructure as an OCI child site inside the hyperscaler data center. The hyperscaler runs the building, the network edge, identity and billing. Your team still owns the databases, the data and the applications.

Nothing about that is a problem, provided the boundaries are written down and tested. The organisations that struggle are the ones that treat the database as "just another managed service" and discover during the first incident that nobody knows whether a stuck failover is an Oracle case, a hyperscaler case or their own runbook gap. This post describes the operating model that avoids that.

02 · Start With the Availability Tier

Answer: Classify every database against Oracle Maximum Availability Architecture tiers: Bronze, Silver, Gold or Platinum. Mission-critical systems are normally Gold (RAC plus Active Data Guard in a second region) or Platinum (adding GoldenGate for near-zero downtime). The tier then drives architecture, monitoring depth and runbooks.

Teams often argue about tools before they agree on targets. Turn that around. Agree the recovery time objective (RTO) and recovery point objective (RPO) with the business, map them to an MAA tier, and only then decide which clouds and regions are involved. The table summarises how the tiers are typically built on Exadata in a Database@ estate.

Exadata itself contributes a lot to the lower tiers: redundant database and storage servers, mirrored storage, and fast detection of failed nodes. What Exadata cannot do on its own is protect you from losing a whole region. That is where the multi-cloud design choices in this series come in.

03 · The Reference Architecture of a Governed Estate

Answer: A governed mission-critical estate has a primary Exadata cluster and a Data Guard standby in a second region or cloud, both connected to a single set of central services: identity, key management, monitoring, audit and backup. The central services are shared so that policy and visibility do not depend on which cloud a database runs in.

The figure below shows the pattern for a Gold-tier database. The primary runs as a two-node RAC cluster on Exadata Database Service on Dedicated Infrastructure (ExaDB-D) in one region; an Active Data Guard standby runs in a second region. In the middle sits the governance plane your organisation owns: federated identity, OCI Vault for Transparent Data Encryption (TDE) keys, central monitoring, audit collection and backups to Autonomous Recovery Service or object storage.

The grey dashed lines are telemetry and audit events: every database, primary or standby, reports into the same monitoring and audit tools. The orange line is key traffic, which matters because a standby that cannot reach its TDE keys cannot open. The purple line is redo transport, and it is the only path that must work for the standby to stay current.

Primary and standby placement

Most teams start with both sites in the same hyperscaler, because the network is simpler and the operating model is identical. A standby in OCI or in a second hyperscaler adds concentration-risk protection, at the cost of interconnect design and a second set of cloud skills. Whichever you choose, confirm with Oracle that your specific region pair and service combination is supported for Data Guard before you design around it.

04 · The Operating Model: Who Owns Which Layer

Answer: Oracle operates the Exadata infrastructure and the OCI control plane, the hyperscaler operates the data center, network edge, identity platform and billing, and the customer owns databases, data, security policy, monitoring and the incident process. Write this split down as a RACI before the first production database goes live.

It helps to think of operations as a stack. Policy flows down from governance; signals flow up from the platform. Each layer has an owner, and the most common failures happen where two owners meet: a patch window that Oracle schedules but your change board never saw, or an identity change in the hyperscaler that breaks a DBA's access during an incident.

Read the owner line in each band as the accountable party, not the only party. The platform band is Oracle and the hyperscaler, but your team still decides when database patches go in. The security band is shared because the cloud provides the controls while you define who may use them and where the keys live.

05 · Observability That Works Across Clouds

Answer: Combine database-level monitoring (Oracle Enterprise Manager or OCI Database Management, AWR and ASH) with the hyperscaler's native monitoring (Azure Monitor, Amazon CloudWatch or Google Cloud Monitoring). Route both into one alerting path so the on-call engineer sees a single view of each database regardless of cloud.

Each Database@ partnership publishes metrics and events into the hyperscaler's own tools, which is useful for application teams who already live there. DBAs need more depth: wait events, SQL plans, Data Guard lag and Exadata cell metrics. Use both layers, and decide which one pages a human.

The signals that matter most

• Data Guard transport and apply lag. The leading indicator for your RPO. Alert well before it threatens the target.
• Database time and top wait events. AWR and ASH baselines show whether a slowdown is the database or something upstream.
• Cluster and service health. Instance status, service placement and FAN events for connection pools.
• Backup success and age. A backup that failed silently for a week is a hidden outage.
• Key and certificate expiry. TDE wallets, TLS certificates and service credentials.

-- Data Guard lag on the standby (run regularly and alert on thresholds)
SELECT name, value, time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag');

-- Broker view of the whole configuration
DGMGRL> SHOW CONFIGURATION LAG;

06 · Security, Keys and Compliance

Answer: Federate identity from the hyperscaler's directory, keep TDE keys under customer control in OCI Vault or a supported key service, collect database audit records centrally with Oracle Data Safe or your SIEM, and apply the same policies to primary and standby sites.

Mission-critical systems usually carry the strictest compliance scope in the company. Auditors will ask the same questions they asked on premises, plus a new one: how do you keep controls consistent across two providers?

Identity

Use Microsoft Entra ID, AWS IAM or Google Cloud IAM for console and API access on the hyperscaler side, and OCI IAM for the Oracle-side operations it governs. For database logins, use centrally managed users with MFA where supported, and keep a sealed break-glass account per database with its use alerted and reviewed.

Encryption and keys

Every Exadata database in these services is encrypted with TDE. Decide early who holds the master keys. Customer-managed keys in OCI Vault give you rotation control and an audit trail. Whatever you choose, make sure the standby site can reach its keys during a regional failure; a key service that lives only in the failed region defeats the purpose of DR.

Audit and data protection

Enable unified auditing with policies for privileged users and sensitive tables, and send the trail to Oracle Data Safe or your SIEM. Data Safe also helps with user risk assessment and sensitive data discovery, which auditors increasingly expect for regulated databases.

07 · Patching and Change Without Downtime

Answer: Let Oracle patch the infrastructure inside maintenance windows you set, and patch databases yourself using rolling RAC updates and standby-first patching. Test every update on a non-production clone first, and feed both Oracle's and your own schedules into one change calendar.

Exadata infrastructure maintenance is performed by Oracle in a rolling fashion across database and storage servers, within windows you configure. Database software updates are your call. For Gold and Platinum databases, the safe sequence is:

1. Clone and test. Apply the release update to a thin clone or test database and run the regression suite.
2. Patch the standby first. Update the standby database home and let it apply redo while the primary is still on the old version.
3. Switch over. Use the Data Guard broker to switch roles during a quiet period. The application reconnects through its services.
4. Patch the former primary. Update the remaining cluster in a rolling fashion, then switch back if you prefer the original roles.
5. Record and review. Capture timings and any surprises in the runbook so the next cycle is faster.

08 · Incident Response Across Three Parties

Answer: Run incidents in five phases: detect, triage, mitigate, recover and review. Your team owns the incident throughout; Oracle and the hyperscaler join for faults in their layers. Decide in advance who may declare a failover and how joint support cases are opened.

The timeline below shows a regional outage that takes down the primary Exadata site. Detection comes from the monitoring stack; triage decides which layer failed; mitigation is a Data Guard failover; recovery reinstates the old primary as a standby once the region returns; review updates the runbooks. The swimlanes show who is engaged in each phase.

Notice the blue lane runs end to end. Even when the root cause sits in Oracle's or the hyperscaler's layer, your team drives the decision to fail over and the communication to the business. The provider lanes start at triage, which is why a pre-agreed escalation matrix saves so many minutes.

DGMGRL> CONNECT sys@sales_stby
DGMGRL> VALIDATE DATABASE sales_stby;
DGMGRL> FAILOVER TO sales_stby;
-- after the old primary site returns
DGMGRL> REINSTATE DATABASE sales_prim;

A mission-critical database is not defined by the hardware it runs on. It is defined by how quickly a tired engineer at 3 a.m. can tell what broke, who owns it and which command to run next.

09 · Key Takeaways

1. Choose an MAA tier per database. Gold or Platinum for mission-critical systems; the tier drives everything else.
2. Write the ownership split down. Oracle runs the Exadata infrastructure, the hyperscaler runs the platform, you own databases and incidents.
3. Keep one governance plane. Identity, keys, monitoring and audit should be the same for primary and standby, whatever cloud they run in.
4. Patch standby first, rolling always. Use Data Guard switchover and RAC rolling updates to keep planned work invisible to users.
5. Rehearse incidents with all three parties. Agree escalation paths and failover authority before go-live, then drill them.

10 · Frequently Asked Questions