Redefining Data Elasticity in the Cloud: Oracle Exadata Exascale

As I mentioned in my last post, let’s take a moment to explore a bit more of the Exa part in the OCI and see what I believe is the next frontier in terms of DB infrastructure: Oracle Exadata Exascale, a breakthrough innovation that decouples Oracle Database and Grid Infrastructure clusters from the underlying physical storage servers.

If you thought Automatic Storage Management (ASM) was the peak of storage optimization, Exascale is here to rewrite the rules, introducing a hyper-elastic, multitenant architecture without sacrificing Exadata’s raw performance.

Moving Beyond the Traditional ASM: The Exascale Storage Architecture

Historically, Exadata relied on a direct coupling via ASM (a technology introduced in DB 10g) to manage disk groups (DATA, RECO) tied to dedicated storage cells. With Exascale, Oracle introduces an innovative software tier that aggregates a massive, centralized pool of storage servers interconnected by the Exadata RDMA Network Fabric.

Instead of legacy disk groups, the architecture here relies on three core logical components:

  • Exascale Storage Pool: The global physical capacity aggregated from all High-Capacity and Extreme Flash storage servers inside the OCI infrastructure tier.
  • Exascale Vaults: Logical partitions carved out of the global storage pool. Each Vault belongs to a specific tenant, providing space management, encryption boundaries, and isolated performance quotas.
  • Exascale Direct Volumes (EDVs): Virtual block devices presented directly to the compute VM nodes. By leveraging hardware-based RDMA, VMs access blocks directly with microsecond latency, completely removing ASM cluster synchronization overhead while preserving advanced data mirroring.

This decoupling also allows for seamless legacy coexistence: As an example, for environments in transition, you can run a legacy Oracle 19c cluster using traditional ASM side-by-side with a new cluster running natively on Exascale with Oracle Database 23ai.

ExaDB-XS: Democratizing Exadata on OCI

The primary cloud implementation of this technology is the Exadata Database Service on Exascale Infrastructure (ExaDB-XS), which aligns this architectural advancement with the flexibility and auto-scaling capabilities offered by the cloud, as well as shattering the financial barrier to entry.

Previously, leveraging the power of Exadata required provisioning dedicated infrastructure (a Quarter Rack or robust fixed shapes). With ExaDB-XS, Oracle delivers granular, per-second elasticity, allowing architects to start small and scale dynamically.

Architectural AttributeMinimum Initial ConfigurationScaling Capability
Compute Power8 ECPUs per Virtual Machine (VM)Scalable in increments of 4 ECPUs up to 2000 ECPUs
RAM Memory22 GB per VMElastic allocation based on computational demand
Database Storage300 GB initial allocationDynamic expansion from Gigabytes to Petabytes in the shared Vault

Performance Pillars: Smart Scan and AI Vector Search

Exascale does not just inherit the Exadata name; it amplifies its most valuable specialized hardware features through distributed intelligence:

  • Smart SQL Offload in the Cloud: Heavy analytical queries continue to be processed directly within the storage cells (offloading), returning only the filtered rows back to the compute VMs.
  • AI Smart Scan: The major game-changer for modern workloads. AI Vector Search processing (essential for RAG architectures and AI workloads in Database 23ai) is completely offloaded to the Exascale storage pool, drastically accelerating vector searches at massive scale.

Smart Cloning with Redirect-on-Write (RoW)

For development and data engineering teams, managing test environments (Dev/Test) has always been a challenge for storage allocation and provisioning time. Exascale solves this natively using Redirect-on-Write technology.

You can spin up Thin Clones of Pluggable Databases (PDBs) instantaneously. Unaltered blocks are seamlessly shared between the parent database and the clones. Additional storage is only consumed for newly modified blocks, completely eliminating the need to manage complex, dedicated Test Masters.

Deployment Steps: Vault First, Compute Later

Like in the Exadata Service, before deploying an Exadata VM Cluster, you must create and define its infrastructure first (Exascale Storage Vault). Because the compute layer relies on Exascale Direct Volumes (EDVs) to mount cluster file systems and initialize Grid Infrastructure, a valid, active Vault must exist to allocate and map those storage resources from the very first second of the VM life cycle.

However, unlike the Exadata, here there’s an excellent flexibility during the provisioning workflow. When launching the “Create VM Cluster” wizard, you do not need to drop out of the screen if you forgot to build the storage layout beforehand. The OCI Console lets you either pick a pre-existing Exascale Vault (ideal for sharing a single storage pool across multiple VM Clusters) or provision a brand-new Vault dynamically on-the-fly within that very same VM creation screen.

Conclusion: When to Adopt ExaDB-XS?

Exadata Exascale redefines the role of the infrastructure architect on OCI. It represents the perfect match for mission-critical scenarios requiring the reliability of RAC (Real Application Clusters), but with the flexibility of the cloud.

If your roadmap focuses on microservices, consolidating multiple small databases with strict isolation, or deploying AI workloads with Database 23ai, Exascale’s hyper-elastic model is the natural architectural choice for the coming years.

To learn more about the ExaDB-XS, below is the official documentation:

https://docs.oracle.com/en-us/iaas/exadb-xs/index.html

In the next post, I will continue reviewing the Exa options in OCI and share a bit about Globally Distributed DBs.

See you there!

Discover more from Red Architects

Subscribe now to keep reading and get access to the full archive.

Continue reading