Exadata on AWS, Azure & Google Cloud: A DBA's Guide to Architecture, Operations & Migration

On this page

1. 01 · The DBA Role Did Not Disappear. It Moved.
2. 02 · The Database@ Model in One Picture
3. 03 · Who Owns What: The Responsibility Stack
4. 04 · Choosing the Cloud and the Deployment Type
5. 05 · The Migration Playbook
6. 06 · Day-Two Operations Checklist
7. 07 · Your First 90 Days
8. 08 · How the Series Fits Together
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · The DBA Role Did Not Disappear. It Moved.

DBA field guide · Exadata inside AWS, Azure and Google Cloud

"If Oracle runs the Exadata, what do I do all day?"

Every DBA asks it when the first Oracle AI Database@ project lands on their desk. The honest answer is: less hardware, more judgement. You no longer replace failed disks, flash firmware or plan rack expansions. Oracle does that inside the hyperscaler data center. You still own everything that makes a database useful and safe: performance, schema design, security, backups, recovery, patch timing and migrations. You also gain a new job: working fluently across two control planes, the hyperscaler's and OCI's.

Across this series we looked at each piece in depth: where Exascale is available, how each partnership attaches to its cloud's network, how migrations work on AWS, Azure and Google Cloud, how Exascale differs from dedicated Exadata, and how to design networking, operations and disaster recovery. This finale ties those pieces into one map you can work from.

02 · The Database@ Model in One Picture

Answer: In every Database@ partnership, Exadata hardware sits in the hyperscaler's data center as an OCI child site, linked to an OCI parent region for the control plane. You buy and provision through the hyperscaler console and marketplace; OCI builds, patches and scales the infrastructure; and you work inside the databases with the usual Oracle tools.

The services carry the newer names Oracle AI Database@AWS, @Azure and @Google Cloud, adopted in October 2025 with Oracle AI Database 26ai; older documents say Oracle Database@. Azure was first (GA December 2023), Google Cloud followed (September 2024) and AWS joined in July 2025. Early posts in this series covered each partnership's architecture separately. The figure below puts all three side by side and marks the five places a DBA actually touches the system.

The orange arrows are your provisioning requests travelling from the hyperscaler console to OCI. The red dashed arrows are the OCI control plane building and patching each Exadata site. Both deployment types, dedicated ExaDB-D and Exascale ExaDB-XS, appear in each site, because both are offered across the partnerships, region by region.

What is the same everywhere

Oracle Database versions, RAC, Data Guard, Smart Scan, storage indexes, AWR, RMAN and the Exadata cloud tooling (including dbaascli on the VM cluster) behave identically. A tuning technique or a runbook written for one cloud works on the others.

What differs by cloud

03 · Who Owns What: The Responsibility Stack

Answer: The hyperscaler owns the data center, power, network edge, identity platform and billing. Oracle owns the Exadata servers, storage, firmware and the OCI control plane. The customer DBA owns databases, data, users, backup and DR policy, and decides when database and guest OS updates are applied.

The posts on mission-critical operations and disaster recovery showed how incidents and failovers depend on this split. Here it is as a single stack, layer by layer, with each bar under the party that owns it.

The purple bars in the middle are where DBAs most often get caught out. Oracle supplies database updates and guest OS images, but nothing is applied to your databases until you schedule it. If nobody owns that schedule, the database drifts behind on security fixes while everyone assumes "the cloud" is handling it.

04 · Choosing the Cloud and the Deployment Type

Answer: Put the database in the same cloud and region as its application tier, then choose ExaDB-D for large, consolidated or strictly isolated estates and Exascale (ExaDB-XS) for small to medium databases that benefit from a low entry cost and elastic ECPU and storage billing.

The comparison posts earlier in the series reached the same conclusion from different directions: the application decides the cloud. Splitting the application and database across clouds throws away the same-data-center latency that the Database@ model exists to provide, and adds egress charges.

The deployment type is the second decision. Exascale reached general availability on OCI in July 2024, on Oracle Database@Azure in March 2025 and on Oracle AI Database@AWS on 13 August 2026, and it is available on Oracle AI Database@Google Cloud. Oracle positions it at up to 95 percent lower minimum infrastructure cost than ExaDB-D, billed by ECPU and storage with no separate IOPS charge, while keeping Smart Scan, storage indexes and RDMA.

05 · The Migration Playbook

Answer: Choose the migration method by downtime tolerance and platform. Zero Downtime Migration automates physical online moves using Data Guard and logical moves using GoldenGate and Data Pump. RMAN and Data Pump cover offline moves, XTTS handles cross-endian sources, and OCI Database Migration provides a managed logical path.

The three migration posts in this series walked through AWS, Azure and Google Cloud in detail. The method is the same on all three; only the network path to the target and the staging storage change.

# Evaluate a ZDM physical online migration before running it
zdmcli migrate database -sourcedb SALES -sourcenode srcdb01 \
  -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdm/.ssh/id_rsa \
  -srcarg3 sudo_location:/usr/bin/sudo \
  -rsp /home/zdm/sales_physical.rsp -eval

Always run the evaluation first. It checks connectivity, versions, space and the response file before any data moves. Then baseline performance on the source with AWR so you can compare after cutover.

06 · Day-Two Operations Checklist

Answer: After go-live, a DBA's routine is patch scheduling, backup and restore checks, performance baselines with AWR, monitoring in both OEM and the cloud's native tools, capacity and cost reviews, and regular DR drills.

The operations and DR posts covered the theory. This is the weekly and monthly rhythm that turns it into habit.

• Weekly: review backup success and age, Data Guard lag, top SQL by database time and any alerts that fired.
• Monthly: apply database release updates to test, then standby first, then production; review ECPU usage and scale where sustained.
• Quarterly: run a restore test from object storage and a switchover drill; review users, roles and audit findings.
• Every maintenance notice: check Oracle's infrastructure maintenance window against your change calendar.

One quick check confirms that Exadata offload is actually working after a migration, which is the first thing to look at if a reporting query is slower than on the old platform:

SELECT name, ROUND(value/1024/1024/1024, 1) AS gb
FROM   v$sysstat
WHERE  name IN ('cell physical IO bytes eligible for predicate offload',
                'cell physical IO interconnect bytes returned by smart scan');

07 · Your First 90 Days

Answer: Spend days 1 to 30 assessing the estate and confirming the cloud and region, days 31 to 60 choosing the deployment type and migrating with the right method, and days 61 to 90 hardening operations: monitoring, backups, patch cycle, a first DR drill and a cost review.

New Database@ programs move fast, and DBAs are often pulled in after the cloud has already been chosen. The flow below gives you a structure to work in, and three questions to answer in order.

The blue question boxes are the decisions you own or strongly influence. Answer them in order: the application tier fixes the cloud, the workload profile picks ExaDB-D or Exascale, and the downtime budget picks the migration method. The bottom row is what turns a successful migration into a well-run service.

1. Inventory and assess. List every database with size, version, character set, RPO, RTO and dependencies. Capture AWR baselines at peak.
2. Confirm placement. Identify each application's cloud and region and verify Database@ and Exascale availability there and in the DR region.
3. Pick the deployment type. ExaDB-D for large or isolated estates, Exascale for small to medium and elastic workloads.
4. Migrate with rehearsal. Run the ZDM evaluation, do a full rehearsal on a copy, then cut over with a rollback plan.
5. Harden operations. Wire monitoring, confirm backups, set the patch rhythm and run the first switchover drill.

08 · How the Series Fits Together

If you have read the series from the start, you have seen each of these decisions in depth. Availability posts explained why region coverage must be checked rather than assumed. The AWS, Azure and Google Cloud posts showed how each partnership plugs into its own network, identity and monitoring. The Exascale posts explained the shared-pool architecture, the pricing model and when dedicated infrastructure is still the better fit. The migration posts gave per-cloud playbooks. The networking, mission-critical and DR posts showed how to connect, govern and protect the result.

The hardware moved into someone else's data center. The responsibility for the data did not. A good Exadata DBA in a multi-cloud world is the person who knows exactly where that line sits.

09 · Key Takeaways

1. Same database, different platform. Oracle Database and Exadata behave the same on AWS, Azure and Google Cloud; console, identity, network and monitoring differ.
2. Know the responsibility line. Oracle runs the Exadata infrastructure, the hyperscaler runs the platform, and you own the databases and their schedules.
3. Let the application choose the cloud. Then pick ExaDB-D or Exascale by workload size, isolation and cost.
4. Match the migration tool to downtime. ZDM physical or logical online for minutes, RMAN or Data Pump for offline moves, XTTS for cross-endian sources.
5. Spend day 61 onward on operations. Monitoring, backups, patch rhythm, DR drills and cost reviews make the platform trustworthy.

10 · Frequently Asked Questions