Oracle's I/O Resource Manager (IORM) is the Exadata feature that turns a single rack into a multi-tenant database platform - several databases or consolidation tenants sharing the same storage cells, the same database servers and the same RoCE fabric, with administrator-defined floors and ceilings on I/O bandwidth and CPU. IORM is positioned by Oracle as a consolidation enabler, and it is - but it is also a licensing trap. Workload isolation that looks like 'separation' from a DBA perspective is not necessarily separation from an Oracle LMS auditor perspective. Multi-tenant Exadata deployments routinely carry hidden Database options exposure where every shared database picks up the option footprint of the most-licensed tenant. This article decodes Exadata IORM in 2026, the four resource-plan layers, the licensing implications, and the configuration patterns that keep multi-tenant consolidation defensible under audit.
Exadata IORM was designed for performance management - a database consolidation tenant generating heavy I/O should not starve a tenant running latency-sensitive transactions. The Resource Manager throttles cell-level bandwidth, CPU shares and database connections according to a hierarchy of plans. Operationally it works well; that is not the issue.
The licensing issue is that IORM does not draw a contractual boundary. If three databases run on the same Exadata rack and Database A is licensed for Partitioning + Tuning Pack + Diagnostics Pack while Databases B and C are licensed only for the EE base, an LMS auditor can argue that the shared infrastructure exposes all three databases to the options footprint. The argument turns on whether the options were technically usable - not whether they were used. IORM does not change technical usability; it changes runtime priority. The audit exposure remains.
The wider Exadata framework sits in the Oracle Database Licensing Guide; the compliance framework is in the Oracle Compliance Master Guide; the wider audit-defence framework is in the Oracle Audit Guide; the licence optimisation framework around multi-tenant consolidation is in the Licence Optimisation Guide.
IORM operates on a four-layer hierarchy. Understanding the layers is the precondition for any audit-defensible isolation argument.
The four layers compose: the Cluster plan throttles a cluster as a whole; the Database plan throttles each database within a cluster; the Category plan throttles each category within a database; the Intra-database plan throttles consumer groups within a category. An I/O request on Exadata passes through all four layers before reaching the cell.
The performance separation IORM provides is real. A heavily-throttled database cannot starve a higher-priority database of cell I/O bandwidth. The shares are enforced by the storage cells themselves (not just the database servers), so an aggressive workload cannot route around the throttle.
What IORM does not isolate:
The pattern matters. A customer who reads IORM marketing material and believes that 'workload isolation' equals 'licensing isolation' is making the most common Exadata audit mistake.
We run the full diagnostic across your Exadata cluster - DBA_FEATURE_USAGE_STATISTICS analysis, PDB count reconciliation, NUP minimum modelling, BYOL allocation review and IORM-pattern recommendation. Fixed-fee, 2-3 weeks. Typical exposure identified on a multi-tenant Exadata: $1.5M-$4M of unallocated option usage.
Oracle's LMS audit script set for Exadata pulls a uniform set of artefacts regardless of IORM configuration: the contents of DBA_FEATURE_USAGE_STATISTICS for every database on the cluster, the V$OPTION view, the count of databases registered with each storage cell, the IORM plan definitions themselves, and (for CDB deployments) the V$PDBS view.
The audit interpretation is consistent: if any database on the shared cluster shows usage of an option in DBA_FEATURE_USAGE_STATISTICS, the option is treated as 'in use' against the entire activated core count of the cluster unless the customer can demonstrate technical impossibility of use by the other databases. IORM throttle weights do not constitute technical impossibility - they constitute administrative priority.
The successful audit defences against this argument fall into three patterns:
The full LMS audit script set and the defence pattern for each is covered in the Oracle audit Database options blog and the Audit Defense service.
The right IORM configuration depends on the customer's licensing strategy. Three patterns work in 2026.
Pattern 1: Single licensing population, uniform option pool. All databases on the cluster share the same Oracle Database EE Processor licence pool, the same options pool and the same support contract. IORM is used purely for performance management - shares are assigned by business priority, not by licensing population. This is the simplest pattern and the most operationally efficient. Use when all consolidated workloads belong to one business unit or one shared-services tenant.
Pattern 2: Dedicated cluster per licensing population. Each distinct licensing population (e.g., 'Production EE with full options', 'Production EE without options', 'Test/Dev SE2') runs on a separate Exadata cluster, each with its own activated core count and BYOL coverage. IORM is configured within each cluster, not across clusters. Use when option licensing varies significantly across workloads and the cost of cross-population option licensing exceeds the cost of the additional cluster.
Pattern 3: Cross-cluster cell sharing (rare). Multiple Exadata clusters share a common storage cell grid via the Cluster plan layer. This is the only IORM layer that operates cross-cluster. Operationally complex; commercially this still requires uniform option licensing across the shared cells. Use only for very large deployments where the cell sharing economics outweigh the licensing complexity.
Pattern 1 is the default for new Exadata deployments. Pattern 2 is the default for legacy consolidations where the option mix is historically diverse. Pattern 3 is rare and should be evaluated case-by-case.
Container database (CDB) and pluggable database (PDB) architecture intersects with IORM in a specific way. Inside a CDB, PDBs are individual database tenants from an application perspective but share a single SGA, single PGA and single set of background processes from a database engine perspective.
The IORM Database plan operates on the CDB level - each CDB registered with the storage cells gets a share. The Database Resource Manager (intra-database plan) is what allocates resources across PDBs within a CDB.
Licensing implications:
The Multitenant option and the broader CDB / PDB licensing rules are covered in the Oracle Database Licensing Guide.
The diagnostic pass on an existing Exadata deployment is straightforward and worth running annually:
Customers running this diagnostic for the first time routinely discover material exposure - typically Tuning Pack and Diagnostics Pack usage that lacks allocation, and PDB counts that exceed the Multitenant-free threshold. The exposure is fixable before an audit forces it; the cost of fixing it under audit is 3-5x the cost of fixing it proactively.
No. IORM provides performance isolation (I/O bandwidth, CPU shares) but not licensing isolation. Every database registered to the cluster is technically able to invoke any Database option whose binaries are installed on the platform, regardless of IORM throttle weights. Oracle LMS treats options as 'in use' against the full activated core count if any database on the cluster has used them. The correct isolation boundary for licensing is the Exadata cluster, not the IORM database plan.
An IORM database plan operates at the Exadata storage cell level, allocating I/O bandwidth and CPU shares across distinct databases. A Database Resource Manager (DBRM) plan operates inside a single database, allocating CPU and parallel-query slots across consumer groups. IORM is Exadata-specific; DBRM is standard on any Oracle Database EE. The two plans compose: IORM allocates across databases, DBRM allocates within each database.
No. IORM is included with Exadata and does not require the Multitenant option. Multitenant is required only when a CDB hosts more than 3 PDBs (the free PDB count in 19c and 23ai). IORM works equally well on single-tenant Oracle Database deployments (one database per cluster) and on CDB / PDB deployments. The two features are independent.
Technically yes - the storage cells do not distinguish. Operationally and commercially this is hard to defend under audit. The recommended pattern is uniform licensing across a cluster: either all BYOL or all LI. Mixed deployments require very explicit BYOL allocation discipline (which Processor entitlements cover which database, refreshed quarterly) and are typically the highest-risk Exadata audit exposure. Most enterprises segregate BYOL and LI onto separate clusters.
High. The Oracle LMS audit interpretation is that the Diagnostics Pack option becomes in-scope against the full activated core count of the cluster - all databases inherit the option footprint. If the cluster has 96 activated cores and the customer has only 24 cores of Diagnostics Pack licence, the audit finding is 72 cores of unallocated usage. The remediation is either retroactive licence purchase or a contractual settlement. Avoid this by either licensing Diagnostics Pack across the full cluster or disabling it via the STATISTICS_LEVEL = BASIC parameter on every database on the cluster (which removes most Diagnostics Pack features).
Twice a month. Oracle cloud, DRCC, ExaCC contract patterns, audit-defence tactics and BYOL maths. Written by former Oracle insiders.
No spam. Unsubscribe any time. Independent - not affiliated with Oracle Corporation.