Introduction

The new and revolutionary architecture of Exadata, named Exascale, comes with a lot of new things that every Oracle DBA should learn to leverage the power of Oracle Database 23ai running on Exadata systems. One of the most significant and notable difference that any DBA should notice at first time working with Exascale, is the fact that ASM is not used anymore. Instead of ASM diskgroup, Exascale uses an Storage Vault, which is explained and demonstrated by Fernando Simon here.

But a quick resume for the context of this blog post: Oracle Database 23ai was improved to integrate with Exascale software, and send IO requests directly to Exadata Storages nodes using RDMA protocol. So instead of attach storage disks on database nodes to be used by Oracle database instances locally though the ASM diskgroup, now Oracle Database can talk with Storage nodes using an Direct I/O approach.

Here an ilustration of the the architecture considering a simple scenario where Storage Nodes are used exclusively for Exascale (the same Storage node can be mixed with Exascale and legacy ASM deployments):

Spoiler of my next presentation on GUOB Tech Day 2025

New Dynamic VIEW to Monitoring

In Oracle Database 23ai we have a new view V$EXA_VAULT, which provides information about the Exascale Vault used by the current Container Database. Think about the V$EXA_VAULT as a natural replacement to V$ASM_DISKGROUP for Storage monitoring by using SQL queries in tools like Zabbix or similar in the context of Exascale.

Here is the definition of the columns, but I recommend you to read the updated documentation.

The Exascale Vault works as an logical container or “folder” within the Exascale Storage Pool, where we can define capacity limits like the total disk space in GB and IOPS that can be consumed by databases using this Vault, specifying limits for different types of Storage layers like Disk, Flash and XRMEM.

Query

Here I have invested some time improving the formatation of the output, turning the visualization more friendly in SQLPLUS. You will notice that I’m dividing some values by 3, it is because these values are presented in as raw capacity, and I want to see the capacity after that the triple-way redudancy is applied.

set lines 200
col vault_name       heading 'Vault|Name'                     format a20
col hc_iops_prov     heading 'High Capacity|IOPS Provisioned' format 999,999,999.99
col hc_space_prov    heading 'High Capacity|Provisioned (GB)' format 999,999,999.99
col hc_space_used    heading 'High Capacity|Space Used (GB)'  format 999,999,999.99
col hc_percent_used  heading 'High Capacity|Space Used (%)'   format 999.99
col flash_cache_prov heading 'Flash Cache|Provisioned (GB)'   format 999,999,999.99
col xrmem_cache_prov heading 'XRMEM Cache|Provisioned (GB)'   format 999,999,999.99
select vault_name                                    as vault_name
      ,hc_iops_prov                                  as hc_iops_prov
      ,(hc_space_prov/3)/1024/1024/1024              as hc_space_prov
      ,(hc_space_used/3)/1024/1024/1024              as hc_space_used
      ,(hc_space_used/greatest(hc_space_prov,1)*100) as hc_percent_used
      ,flash_cache_prov/1024/1024/1024               as flash_cache_prov
      ,xrmem_cache_prov/1024/1024/1024               as xrmem_cache_prov
from v$exa_vault;

Examples

A) The OCI console display the TOTAL and FREE space of the Storage Vault:

And here the output of our query executed in the database with SQLPLUS:

Vault			High Capacity	 High Capacity	 High Capacity	High Capacity	   Flash Cache	    XRMEM Cache
Name		     IOPS Provisioned Provisioned (GB) Space Used (GB) Space Used (%) Provisioned (GB) Provisioned (GB)
-------------------- ---------------- ---------------- --------------- -------------- ---------------- ----------------
eGEDOpGD		    32,000.00		300.00		214.40		71.47		   .00		    .00

B) Here another example where additional Flash capacity was provisioned in OCI console:

And we can see the value of 120 in the Flash Cache Provisioned (GB) :

Vault                   High Capacity    High Capacity   High Capacity  High Capacity      Flash Cache      XRMEM Cache
Name                 IOPS Provisioned Provisioned (GB) Space Used (GB) Space Used (%) Provisioned (GB) Provisioned (GB)
-------------------- ---------------- ---------------- --------------- -------------- ---------------- ----------------
eGEDOpGD                    32,000.00           300.00          214.40          71.47           120.00              .00

Currenlty the Exadata Exascale Service (ExaXS) don’t have the option to configure XRMEM cache capacity. But this a configurable attribute of Exascale Vault if you have full control as an Exadata administrator, so the view is prepared to show this value when it is configured.

About the suposed triple-way redundancy

If you are asking how I identified that the redundancy is equivalent to HIGH in this query, actually I didn’t. The view don’t have a column indicating the redundancy type used by this Vault, but in this context, I’m using “Oracle Exadata Database Service on Exascale Infrastructure” in OCI, and I know that all ExaCS, ExaCC and ExaXS (this case) are deployed with triple-way redundancy, independetly if the deploy uses ASM or Exascale. But sure, I have tested this to confirm my theory.

Maybe I can need to improve this query in the future, but for now, the fixed math /3 works fine.

Conclusion

In this blog post I shared a brief introduction about how Oracle Database 23ai interacts with Exascale, and how we can start monitoring the available space using SQL query, which can be easily adapted in your monitoring tools.