Oracle Exadata Exascale explained: a practical guide for DBAs
What Exascale really changes, what stays the same, and how to get your team ready, in plain language with real commands.
Why Exascale matters now
Exascale was announced in July 2024, but 2026 is the year it moved into everyday DBA work. In August 2026, Oracle and AWS made Oracle Exadata Database Service on Exascale Infrastructure generally available through Oracle AI Database@AWS, across 22 AWS Regions. On OCI, Exascale VM storage is now an option for Exadata Database Service on Dedicated Infrastructure, and the X11M-XT storage servers support Exascale on-premises.
In short, if you support Exadata, whether on-premises, in OCI, with Cloud@Customer or in a multicloud setup, you will meet Exascale soon. This guide gets you ready.
What Exascale is, in one sentence
Exascale is a new storage architecture for Exadata that replaces per-cluster disk groups with one shared, secured storage pool that every cluster draws from on demand.
It is software, not a new hardware model. It arrived with Exadata System Software release 24.1.0.
The easy analogy: an apartment building's water supply
In traditional Exadata, every apartment (each VM cluster) has its own private water tank (its own ASM disk groups). If one tank runs dry while the neighbour's tank is full, you call a plumber (the DBA) to rearrange tanks.
With Exascale, the building has one big shared water system. Every apartment turns on the tap and gets what it needs. The building manager simply puts a meter and a lock on each apartment.
| Everyday word | Exascale term |
|---|---|
| The shared water system | Storage pool: all storage cells combined |
| Each apartment's meter and lock | Vault: your space, with a quota and access rules |
| The pipes | RDMA network fabric |
| The apartments | VM clusters running your databases |
Architecture: pools, vaults and volumes
Three ideas explain almost everything about Exascale.
1. Storage is decoupled from clusters
Exascale separates database and Grid Infrastructure clusters from the storage servers underneath. A single Exascale deployment manages a large fleet of storage servers over the RDMA fabric. Files in a vault are spread across every cell in the pool, so each database can use the I/O bandwidth of the whole system instead of a small slice of it.
2. The vault replaces the ASM disk group
You don't carve grid disks per cluster anymore. You create vaults, give them quotas and access rules, and change them online. Isolation comes from security rather than physical partitioning: users and databases can only reach data they have privileges for.
3. Database servers stop doing storage management
With Oracle AI Database 26ai, Exascale takes over file and extent management. Native Exascale databases don't need an ASM instance on the compute nodes, so that CPU and memory go back to the database. Older database releases use Exascale Volumes, which are RDMA-enabled block volumes, typically formatted with ACFS. VMs also use Exascale Volumes for their own images instead of local disks on the database servers.
The services behind the scenes
| Service | What it does |
|---|---|
| EGS (Exascale Global Services) | Control plane: cluster membership, pool metadata, coordination |
| ERS (Exascale RESTful Services) | Management endpoint used by escli and cloud tooling |
| EDS (Exascale Data Services) | File and vault metadata services |
| BSM / BSW (Block Store Manager / Worker) | Serve Exascale Volumes to VMs |
| CELLSRV | Still performs the actual I/O, Smart Scan and flash caching |
What stays the same: Smart Scan, storage indexes, flash and XRMEM caching, and RDMA reads are all still in the data path. Exascale changes how storage is organized and provisioned, not how Exadata accelerates your SQL.
Vaults and escli in practice
A vault is basically your new disk group, with one visible difference: ASM names start with +, Exascale vault names start with @.
| Old way (ASM) | New way (Exascale) |
|---|---|
+DATAC1 | @DATAVAULT |
+RECOC1 | @RECOVAULT |
| Size fixed when grid disks are carved | Size is a quota you can change online |
Managed with asmcmd | Managed with escli |
Everyday escli commands
escli is the Exascale command-line tool. It follows Linux habits: ls to look, mk to make, ch to change, rm to remove.
# Look around
escli lsstoragepool # how big is the shared pool, and how full?
escli lsvault # which vaults exist, and how much do they use?
escli lsfile @DATAVAULT # which files live in this vault?
escli lsuser # who has access?
# Make, change, remove
escli mkvault @DEVVAULT
escli chvault @DEVVAULT # for example, change its size limit
escli rmvault @DEVVAULT # careful: removes the vaultOption names for quotas and attributes can differ between Exadata System Software releases. Run escli help mkvault or check the Exascale documentation for your version, and always practise on a dev system first.
Pointing the database at a vault
-- Old ASM way
ALTER SYSTEM SET db_create_file_dest = '+DATAC1';
-- Exascale way
ALTER SYSTEM SET db_create_file_dest = '@DATAVAULT';After that, CREATE TABLESPACE works as usual and Oracle places the files in the vault.
Update your monitoring
Space-check scripts built on v$asm_diskgroup won't cover Exascale. Add checks based on escli lsvault and escli lsstoragepool, and alert at two levels:
- Vault level: is a vault close to its quota?
- Pool level: is the whole shared pool filling up? Because it is shared, one runaway vault affects everyone.
Snapshots and thin clones
This is the feature most DBAs fall for. Think about the request every DBA knows: "Can you refresh DEV from PROD by tomorrow morning?" The old answer is an RMAN duplicate that copies every block, takes hours, and doubles the space.
The easy analogy: a shared textbook
Thirty students need the same 1,000-page textbook. You could photocopy it thirty times (30,000 pages). Or everyone reads the same original, and when a student wants to write on page 52, they get their own copy of just that page. That second approach is a thin clone: it shares every unchanged block with the source and stores only the blocks that change. It is created in minutes, because almost nothing is copied.
| Term | Plain meaning | Writable? |
|---|---|---|
| Snapshot | A frozen photo of the data at one moment | No |
| Clone | A new working copy made from that photo | Yes |
How you do it for PDBs
On Exascale, snapshots and clones are integrated with standard Oracle SQL. There's no sparse disk group or test master to prepare.
-- Thin clone of a PDB for dev or test
CREATE PLUGGABLE DATABASE DEVPDB FROM PRODPDB SNAPSHOT COPY;
-- Named point-in-time snapshot before a risky change
ALTER PLUGGABLE DATABASE SNAPSHOT before_patch;Source requirements, such as whether the source PDB can stay open read-write, depend on your database version and Exascale release. Confirm them in the documentation before you build a runbook around these commands.
Where DBAs use it every day
- Dev and test refresh in minutes instead of hours.
- Patch testing: clone PROD, patch the clone, test safely.
- Bug reproduction: give developers their own copy of the exact problem data.
- Safety net: snapshot before a risky change so you have a quick fallback point.
Migrating to Exascale
The good news: moving to Exascale uses tools you already know. The right path depends mainly on your database version and how much downtime you can accept.
Step 1: decide native or volume-based
- Oracle AI Database 23ai / 26ai: store files natively in vaults and get the full benefit, including no ASM on the compute nodes and built-in thin clones.
- Older releases such as 19c: run on Exascale Volumes, typically with ACFS. You gain elastic, pooled storage, but not every native feature. Many teams use this as a first step and go native after upgrading.
Step 2: pick a migration method
| Method | Downtime | Good for |
|---|---|---|
| Data Guard switchover (often driven by Zero Downtime Migration) | Minutes | Large production databases |
| RMAN backup and restore, or duplicate | Hours, depends on size | Simple moves, non-production |
| PDB relocate or unplug/plug | Low | Consolidation into a new CDB on Exascale |
| Data Pump export/import | Higher | Upgrades combined with reorganization or character set work |
| Online datafile move to a vault | None for the move itself | Existing 23ai/26ai databases already on an Exascale-enabled system |
Step 3: before cutover
- Size vault quotas with growth headroom, and set pool-level alerts.
- Rebuild space monitoring around
escli(see above). - Update backup scripts and RMAN destinations from
+RECOpaths to@vaults. - Run a performance baseline (AWR) before and after, so you can prove the result.
- Write the runbook and rehearse a full switchover on non-production.
The EBS DBA's checklist
Oracle E-Business Suite adds extra care, because certification moves more slowly than the database platform.
- Check certification first. Confirm your exact combination of EBS release, database version and Exascale deployment in the certification section of My Oracle Support before promising anything to the business.
- Expect the volume route for 19c. Many EBS 12.2 estates run on 19c, which means Exascale Volumes rather than native vault files.
- Thin clones are only half an EBS clone. A storage clone copies the database. You still need Rapid Clone,
adcfgcloneand your post-clone scripts for the application tier. - Review online patching space. ADOP patch editions and patching cycles consume space. Size the vault quota to include it.
- Retest your custom scripts. Anything that hard-codes
+DATApaths, such as cloning, archiving or purge scripts, needs updating to@vault paths.
Where Exascale fits, and where it doesn't
Strong fit
- Consolidation platforms hosting many small to medium databases.
- Dev and test estates with frequent refreshes.
- Teams wanting Exadata performance in AWS, OCI, Azure or Google Cloud without dedicated infrastructure, with pay-per-use elasticity.
Think twice
- Very large, stable, single-tenant workloads that already fit dedicated Exadata well.
- Applications whose certification hasn't caught up with Exascale or your target database release.
ASM to Exascale cheat sheet
| Traditional Exadata | Exascale |
|---|---|
| ASM disk group | Vault |
| Grid disks carved per cluster | Storage pool shared by all clusters |
+DATAC1 | @DATAVAULT |
asmcmd, cellcli | escli |
| Local VM image storage | Exascale Volumes |
| Sparse disk group and test master | Built-in snapshots and thin clones |
v$asm_diskgroup space checks | escli lsvault, escli lsstoragepool |
Old Exadata: each cluster owns its own piece of storage.
Exascale: all clusters share one big, secured pool.
Vaults replace disk groups, @ replaces +, and thin clones take minutes.
Final thoughts
Exascale changes the Exadata DBA's job from carving and babysitting disk groups to managing pooled, policy-driven storage. The performance that made Exadata famous stays exactly where it was. My advice: start with a dev or test use case, get comfortable with vaults, escli and PDB snapshot clones, then plan production moves with Data Guard or ZDM.
What has your experience with Exascale been so far? Share your questions and lessons learned in the comments. I read every one.
References
- Oracle Exadata Exascale, Oracle documentation
- About Oracle Exadata Exascale, System Administrator's Guide
- Exadata Exascale product page, Oracle
- Exadata Exascale announcement, Oracle Exadata blog (July 2024)
- What's new in Exadata Database Service on Dedicated Infrastructure
- Oracle and AWS launch Exadata on Exascale Infrastructure, IT Brief (August 2026)
