Oracle Exadata Exascale: What Actually Changes for ASM (and RMAN) Users
The headlines say 'bye bye ASM.' The scope is narrower, more Exadata-specific, and more of a migration path than a cutover here's what I found when I looked into it.
I came across "Oracle Exadata Exascale" recently and had the same reaction most DBAs probably will: a wave of blog titles along the lines of "bye bye ASM," and no immediate sense of whether that's a headline exaggeration or something I need to plan around on my own systems. So I went and read the actual Oracle documentation and a handful of technical deep-dives instead of reacting to the title alone. Here's what's actually true, what's Exadata-specific, and what it means for RMAN and the non-database-file use cases (Data Pump staging, GoldenGate trail files, general shared storage) that a lot of us run on top of ACFS.
What Exascale actually is
Exascale is a new storage architecture for Exadata that decouples the database and Grid Infrastructure clusters from the underlying storage servers. Instead of each cluster owning its own dedicated ASM disk groups carved out of specific storage cells, Exascale pools storage centrally and lets multiple Grid Infrastructure clusters and databases share it, over RDMA, with per-tenant isolation.
The architecture genuinely changes shape, not just terminology:
Old (ASM): physical disks → cell disks → grid disks → disk groups
New (Exascale): physical disks → cell disks → pool disks → storage pools → vaults
A vault is the new top-level container a logical, resizable allocation with its own limits on space, IOPS, cache, and flash capacity. Where a disk group was a fixed slice of specific physical disks that had to be rebalanced whenever you resized it, a vault draws from a shared pool and can grow or shrink without the rebalancing operations ASM administrators have budgeted downtime and I/O headroom for since forever.
The part of this that's easy to undersell is where the storage-management work actually happens. With ASM, extent allocation, layout, and rebalancing are computed by an ASM instance running on the database server it's real CPU and memory spent on storage logic, on every node, for every cluster. Exascale moves that work down to the storage tier itself: the storage servers manage pools, vaults, and extent placement directly, and the database host just talks to shared storage over RDMA instead of running the allocation logic locally. That's not a cosmetic change it's the mechanism behind most of the other benefits here (shared pools across clusters, resizing without a database-side rebalance, per-vault resource limits), and it's also a big part of why this requires specific RDMA-capable hardware rather than being a software update you can apply anywhere.
It's worth being precise about how far that offload actually goes, because it's more than "ASM does less work" on Exascale, there is no local ASM instance running on the database compute nodes at all. The storage logic lives entirely in the cells; compute nodes talk to a Vault instead of mounting ASM disk groups, and even OCR and the voting files move into the Vault instead of living in an ASM disk group the way they do today. That has a practical side effect a lot of ASM administrators will appreciate: the whole category of ASM/CRS startup-ordering problems, ora.asm failing to come up before the database resource depends on it, disk groups not mounting in the right sequence after a node reboot, the MOS notes everyone has bookmarked for exactly this doesn't have anywhere to occur if there's no ASM instance in the boot chain to begin with. I haven't seen Oracle market that explicitly as a headline benefit, but it falls directly out of removing the ASM instance, not a separate fix layered on top.
Why ASM needed this, specifically on Exadata
ASM isn't being replaced because it did its job badly it's 20+ years old and has held up remarkably well. The pain points Exascale addresses are pretty specifically Exadata-flavored, though:
Disk group resizing was disruptive. Growing a disk group meant adding disks or triggering a rebalance; both are real operations with real I/O cost, and neither is instant.
Capacity was locked to whichever virtual cluster it was assigned to. On a virtualized Exadata system, each VM cluster got its own disk groups carved out of the shared storage cells, and moving capacity between clusters meant real reconfiguration, not a resize.
Thin cloning forced a bad tradeoff. Sparse disk groups gave you fast thin clones but required the parent to be read-only. ACFS gave you a writable parent but at a real performance cost and without Smart Scan. There wasn't a version of "fast AND writable AND full offload" available.
Cross-cluster storage sharing was awkward. Flex disk groups improved redundancy granularity but didn't solve the fundamental problem of two separate VM clusters wanting access to the same pool of storage.
Vaults, a shared pool, and native snapshot/cloning support are Oracle's answer to those four things specifically not a general indictment of ASM as a technology.
The question to ask before any of this matters to you: are you on Exadata?
This is the part I think gets lost in "bye bye ASM" headlines, and it's the most important paragraph in this post for most readers: Exascale is exclusive to Exadata engineered systems. It requires Exadata hardware with RDMA-capable RoCE Network Fabric X8M-2 or later, explicitly excluding the 8-socket X8M-8 and X9M-8 models and it's available on the on-premises Exadata Database Machine, Exadata Cloud Service, Exadata Cloud@Customer, and (more recently) through Oracle's cloud partnerships, including Exadata on Exascale for Oracle AI Database@AWS.
If you're running Oracle Database on commodity Linux servers which describes a large share of real-world ASM deployments, including plenty of production fleets that have never touched an Exadata rack none of this applies to you today. ASM on non-Exadata hardware is unaffected, unchanged, and not going anywhere as a result of this announcement. The "ASM is going away" framing only makes sense inside the specific, narrower context of Exadata storage management.
What actually changes if you ARE on Exadata
Even within that narrower Exadata scope, this isn't a forced migration. Oracle has been explicit that Exascale and ASM coexist Exascale can run alongside databases that are still on traditional ASM disk groups on the same Exadata system, which is a migration path, not a cutover deadline. If you're happy on ASM-managed Exadata storage today, nothing compels you to move.
What you gain if you do adopt it: a single consolidated storage pool instead of separate DATA/RECO silos (less wasted space, one FRA sizing decision instead of one per disk group), support for mixing storage-server generations in the same pool, storage scaling from gigabytes to petabytes instead of Exadata's traditional minimum footprint of roughly three storage servers and ~150TB, and per-vault resource limits that solve the noisy-neighbor problem in multi-tenant/consolidated environments.
RMAN and the non-database-file question
This is the part I was most curious about myself, since it's where "storage architecture change" stops being abstract and starts touching daily operational habits.
Non-database files (ACFS) are still there — and arguably more flexible. ACFS filesystems can now be created directly on Exascale block volumes, via a new escli workflow (mkvolume → mkvolumeattachment → mkacfsfilesystem), without needing a traditional ASM disk group underneath. Oracle's own documentation calls out the exact use cases DBAs have always used ACFS for outside the database itself: VM image storage, Data Pump export/import staging, GoldenGate trail files, and general shared file access (including NFS export from ACFS-on-Exascale). If your non-database file workflows live on ACFS today, that use case survives the transition it's just running on a different substrate.
RMAN itself is more nuanced, and the answer depends on which flavor of Exadata you're on. On Oracle's managed cloud offering Exadata Database Service on Exascale Infrastructure Oracle pushes hard toward its own managed backup automation (Oracle Managed Backups / dbaascli) rather than DBA-driven RMAN scheduling. The documentation is direct about it: don't mix RMAN-scheduled backups with Oracle Managed Backups, don't use RMAN configuration to override the pre-tuned cloud settings (encryption algorithm, compression level, section size are all fixed), and if you want full manual RMAN control you have to explicitly disable the cloud automation first via bkup_api. RMAN is still fully supported for point-in-time recovery operations restoring a datafile, tablespace, or table even under the managed-automation model.
That's a meaningfully bigger behavioral shift for a backup admin than the underlying storage architecture is. If you're used to owning your RMAN configuration end to end, the managed Exascale cloud service asks you to hand a good chunk of that over to Oracle's automation rather than layer your own scheduling on top of it. I'd treat this as the detail worth confirming directly against current documentation for your specific platform before you touch anything the constraints above are documented for the OCI-managed service specifically, and I would not assume they transfer unchanged to a self-managed on-premises Exadata Database Machine running Exascale software, where the operational responsibility model is different. If you're planning an actual migration, this is the one area I'd verify with Oracle support or your account team rather than extrapolate from a blog post yes, including this one.
Where this leaves ASM users, practically
Not on Exadata: nothing changes. Keep doing what you're doing.
On Exadata, staying on ASM: also nothing forced. Exascale and ASM coexist on the same hardware; there's no announced end-of-life for ASM-managed Exadata storage.
On Exadata, considering Exascale: budget time to rethink capacity planning around vaults and pools instead of disk groups it's a genuine mental model shift, not just a rename and if you're moving to the Oracle-managed cloud service specifically, review your RMAN/backup strategy against the managed-automation constraints before you migrate, not after.
Using ACFS for non-database files today: the same use cases (staging, GoldenGate trails, VM images, shared/NFS storage) are supported on Exascale volumes, and it's worth a look regardless of your database migration timeline, since it doesn't require moving your actual databases off ASM first.
