Oracle launched Exadata Exascale architecture in 2024 as a next generation data-intelligent storage platform, available alongside Automatic Storage Management (ASM), the long-time standard bearer for Oracle Database storage. Initially, Oracle introduced Exascale for on-premises deployments of the Exadata Database Machine. At the same time, Oracle also brought to market a new cloud service based on Exascale technology: the Exadata Database Service on Exascale Infrastructure. The Exadata Database Service on Exascale Infrastructure runs on shared Exadata compute and storage resources to provide a lower-cost entry point to run business-critical workloads on Exadata in the cloud.

Recently, Oracle extended the capability to deploy Exascale storage architecture on the Exadata Database Service on Dedicated Infrastructure, meaning that customers are now able to provision databases on Exascale storage alongside databases running on ASM. This coexistence option provides a way for customers with existing ASM-hosted database environments to leverage Exascale technology for new deployments on the same Exadata system, and it provides a path for customers to migrate from ASM to Exascale when it is convenient.

Why are we so passionate about Exascale?

To appreciate what makes Exascale transformative, it helps to look back at the path Oracle has taken in bringing database storage management from single-database deployments to cloud-scale over the past few decades.

In the beginning: file systems and raw devices

In the early days of the Oracle Database, databases were hosted on either traditional file systems or raw devices. File systems were created on top of physical disks, usually aggregated and/or protected with software RAID and Logical Volume Managers (LVMs). While requiring high amounts of manual administration and being difficult to optimize, this model was relatively straightforward, using the familiar file system hierarchy, access, and permissions model. This was the era when DBAs segregated “data” tablespace datafiles onto different physical volumes from their corresponding “index” datafiles to distribute load, achieve greater aggregate performance, and avoid saturating a subset of disks and degrading performance. File systems of the day faced maximum capacity and file size limitations, such as 16 TiB max for an ext2 file system, and 2 GiB file size max for NTFS. These limits increased file and volume management overhead for administrators. Additionally, differences in operating system implementations and their interactions with file systems created the potential for lost writes in the event of an unplanned outage.

For high-performance and early shared-access database deployments, some customers opted for raw devices to store Oracle datafiles. These provided the database with direct access to data on a disk partition, streamlining IO calls. But administrators had to map each device or partition to a single datafile, and expanding a file required resizing the underlying partition, raising the risk of potential mistakes and further increasing administrative burden. And, for both file systems and raw device environments, Oracle database professionals largely had to rely on storage and operating system teams to manage high availability, data protection, and performance aspects of the database storage.

ASM introduced a paradigm shift

ASM brought revolutionary changes to storage consumption and management for Oracle Database implementations when it was introduced with Oracle Database 10g Release 1 in 2004. As a system designed and optimized for storing Oracle Database files, ASM shifted stewardship of database storage to the DBA, while simplifying management, eliminating manual datafile placement, and handling device aggregation, redundancy, and load distribution automatically. ASM supported direct and asynchronous IO calls natively, bypassing the OS’s IO call stack and file system buffer cache, enhancing IO performance and enabling Oracle to accurately report on IO latencies.

ASM provides a lightweight software RAID-like model known as SAME (Stripe And Mirror Everything), distributing discrete allocation units across all disks in the disk group to maximize device utilization and performance. This enables ASM to issue physical IO calls only to relevant disks—independently and in parallel—to satisfy queries without having to assemble sub-block chunks into something meaningful to the database. With ASM acting as an extent mapper, it can easily relocate allocation units to ensure even distribution of data over devices, including after the addition of new devices and, crucially, before the removal of existing ones. This gives administrators an easy way to scale their storage up and down and even achieve online storage system migrations. ASM also helps reduce the likelihood of operational mistakes by moving device partitioning and allocation to ASM, removing the devices from interaction with normal file systems accessible to the OS users and administrators.

When the Exadata Database Machine was first launched in 2008, ASM was the natural choice for storage management. Not only did ASM provide high performance, data protection, and management simplicity, it was co-engineered with the database and Exadata software to enable extreme performance by integrating with ground-breaking technologies that evolved over the years to include Exadata Smart Scan, Storage Indexes, Exadata Smart Flash Cache, Exadata RDMA Memory (XRMEM), and Exadata Columnar Caching on Exadata Storage Servers, to name a few. Exadata and ASM also enabled customers to consolidate multiple databases onto a single platform, increasing efficiency and manageability. This combination also made it possible to create Database-as-a-Service offerings that served as precursors to many of today’s public cloud environments.

Exascale: Oracle Database storage for the multicloud era

As Oracle Database environments have scaled and migrated to the cloud in large numbers, Oracle recognized an opportunity to re-imagine ASM to deliver a truly cloud-scale storage system to address current and future needs. Exascale introduces advanced capabilities such as pooling vast storage resources with minimal capacity partitions for simpler, more efficient management. It enables seamless addition of new storage—including newer, higher capacity devices—into existing systems. Fast thin clones can now be created and managed directly within the Oracle Database environment, making it easier to support development and QA efforts with minimal additional infrastructure. Exascale also enables sharing storage capacity across VM clusters for greater utilization, and it allows database clones to be mounted across VM clusters. This lets customers take full advantage of Exadata performance while running workloads on different compute resources.

Exascale technology revolutionizes Oracle Database deployments in the cloud. Exascale introduces the concept of a “vault”, which presents a single, secure, logical storage allotment from your Exascale storage pool with built-in, transparent high redundancy for every object stored in it. There is no need for separate disk groups, eliminating the planning required and storage capacity partitions those create. And a single vault can support the storage needs of all databases in a single VM cluster, as well as in multiple VM clusters, facilitating sharing of data across clusters. Managing storage capacity in a vault is as simple as monitoring the total consumption against the total allocation. Vaults may be configured to auto-scale, seamlessly growing themselves as consumption nears capacity. And, since Exascale automatically detects the content type of files stored in a vault and applies the appropriate redundancy to each, there is no related planning or action required by the administrator.

Exascale introduces a re-imagined database cloning mechanism leveraging redirect-on-write algorithms, with out-of-place writes for greater efficiency in capturing changes. Exascale also offers the ability to store thin-provisioned objects, such as the changed blocks comprising a writable thin clone, together in the same vault. These changes allow Exascale to efficiently store and manage virtually unlimited writable thin clones from a source database or a snapshot of a database without the need for a read-only test master copy. In fact, almost any database on Exascale storage can be thin-cloned—read/write, read-only, primary, standby, and pluggable databases (PDBs). You can also thin-clone other thin clones! This provides a usability leap over previous thin cloning technology, and a massive improvement over cloning volumes at the storage layer, presenting the cloned volumes to the same or another host, and mapping and mounting them to allow interaction with the database. Exascale can simply create a new cloned database that looks and behaves like any other database. The newly cloned database may be run on the same VM cluster as its source, or on any other VM cluster that shares the source database vault. This allows databases to share compute and storage resources, or segregate workloads where desired, while still benefiting from full Exadata performance features for both.

Exascale shifts storage extent management from the database server to the storage tier where it can scale with no involvement from DBAs. Eliminating the ASM instance from the database server frees up resources there and simplifies memory management for administrators. More importantly, moving storage management to the storage tier in Exadata increases performance for operations such as rebalancing data or restoring redundancy when the platform automatically recovers from disk failures or planned maintenance. Best of all, resizing an Exascale vault happens without requiring a rebalance operation, saving time and resources over similar scaling operations on ASM.

Exascale technology provides seamless centralized VM storage, which delivers practically unlimited file system space for VMs. This enables it to support more and larger VM images than could be stored on the limited storage available in the database servers. Storing the VM images on shared storage also facilitates VM mobility to reduce the impact of planned database server maintenance. VM mobility is available on Exascale on the Exadata Database Machine today.

And finally, Exascale is developed by the Exadata engineering team, and co-engineered with Oracle Database to ensure the extreme performance, security, availability, scalability, and manageability you expect from Exadata systems are available to your database workloads with no changes to your applications or operational model.

Summary

With all the capabilities we discussed here, we are incredibly excited about Exadata Exascale! With low pay-as-you-go pricing for the Exadata Database Service on Exascale Infrastructure, we encourage you to try out Exascale technology today.


For more information, refer to these important links to help you get started.