Database Enterprise Edition is the licence customers know about. The eleven separately-licensable options and seven management packs that bolt onto it are the ones Oracle finds during an audit. In our experience across 340+ engagements, options and packs account for more than half of all Oracle audit exposure — almost always because someone enabled a feature without realising it required a separate licence.
Each Oracle Database option is licensed at a per-processor list price between $11,500 and $23,000, plus 22% annual support. A management pack runs $5,000 to $7,500 per processor. The licence applies to every processor on which the underlying Database Enterprise Edition is licensed — not just the processors using the feature. That asymmetry between deployment scope and feature use is what drives audit findings: a single test database with Partitioning enabled exposes the entire production cluster to a Partitioning licence claim if the cluster shares hardware.
The eleven options most commonly found in deployments are Partitioning, Real Application Clusters (RAC), Active Data Guard, Advanced Security, Advanced Compression, Database Vault, Label Security, Spatial & Graph, OLAP, Real Application Testing, and Multitenant. The seven management packs are Diagnostic Pack, Tuning Pack, Database Lifecycle Management, Cloud Management, Data Masking, Change Management, and Configuration Management. Diagnostic and Tuning Pack are the two most expensive findings in any Oracle audit because they activate silently through routine DBA work.
Diagnostic Pack activates whenever AWR (Automatic Workload Repository) reports are generated, ADDM advisors are run, or active session history is queried. Tuning Pack activates when SQL Tuning Advisor, SQL Access Advisor, or any tuning-related Enterprise Manager screen is opened. Both packs report their usage in DBA_FEATURE_USAGE_STATISTICS — the view Oracle's auditors query first. A single click in OEM Cloud Control by a junior DBA can record use that triggers six- or seven-figure findings on a large estate.
The DBA_FEATURE_USAGE_STATISTICS view tells you what an LMS auditor will find.
Partitioning is enabled by default in any Database Enterprise Edition install. The feature shows up in deployments because DBAs use partitioned tables for performance, because tools and frameworks (Hibernate, certain ETL tools, application migration scripts) create partitioned tables automatically, and because Oracle's own products — including parts of Fusion Middleware, E-Business Suite and some Cloud Control schemas — use Partitioning as a baseline. Each of those routes creates a licence requirement that Oracle will enforce.
A clean Partitioning posture means: an inventory of every partitioned table across every Oracle database instance, a mapping of who created each partition and why, and either a licence position that covers every processor on which a partitioned table exists or a remediation plan to drop the partitions and validate non-use. The remediation route is harder than it sounds because dropping a partition does not erase the historical use record in DBA_FEATURE_USAGE_STATISTICS.
Diagnostic and Tuning Pack are bundled functionally with the database — most database documentation assumes they are available, and most DBA training uses AWR reports as the starting point for any performance investigation. A customer that has not explicitly licensed these packs needs to disable them via the CONTROL_MANAGEMENT_PACK_ACCESS init parameter, audit all sessions for accidental use, and replace AWR/ADDM workflows with Statspack or third-party alternatives. The operational impact of disabling the packs is real, which is why most enterprise customers eventually license them — but the licensing should be a deliberate decision, not a discovered finding.
RAC and Active Data Guard are higher-priced options ($23,000 per processor and $11,500 per processor respectively at list). Findings here are rarer than for Diagnostic or Tuning Pack but more material when they occur. RAC findings come from cluster databases that were stood up for testing or proof-of-value and never decommissioned. Active Data Guard findings come from standby databases that have been opened read-only for reporting — a common architecture pattern that requires the feature.
Includes an options & packs audit checklist used in 340+ engagements.
Advanced Security Option (ASO) is required for Transparent Data Encryption (TDE), network encryption above a basic level, and column-level encryption. Many customers turn on TDE because of regulatory or internal-policy requirements without recognising that the underlying feature is licensable. ASO is $15,000 per processor list. On a large RAC cluster, the finding from accidental TDE use can exceed $1M.
A reasonable posture for ASO is either to license it deliberately as part of a security baseline, or to use database-vault and OS-level encryption alternatives where regulatory requirements allow. The wrong posture is to assume that "we use TDE for compliance" provides any commercial relief — Oracle's auditors will treat encryption use as a licence trigger regardless of motivation.
Multitenant Option enables more than three pluggable databases (PDBs) per container database. Customers running 19c and later need to track PDB counts carefully because Oracle quietly altered the free-tier limits in 21c. A database that was compliant in 19c with three free PDBs may not be compliant in 23c if the free-tier definition changes. Multitenant findings typically appear in environments where consolidation projects pushed PDB counts up without checking the option licensing.
Oracle's LMS measurement scripts query DBA_FEATURE_USAGE_STATISTICS, DBA_HIGH_WATER_MARK_STATISTICS and the OPTIONS view to assemble feature usage evidence. The relevant findings are:
A self-assessment that mirrors LMS's scripts and methodology is the foundation of every Oracle compliance position. Customers who run these scripts internally on a quarterly basis identify and remediate use before it becomes a finding. Customers who wait for an audit are reading the same data alongside an Oracle auditor.
We run the LMS-equivalent scripts ourselves and build the remediation plan.
When options or packs use is discovered before an audit, the customer has options. The cleanest is to disable the feature, remove the artefacts (partitioned tables, encrypted columns, opened standbys), and produce evidence of non-use going forward. That evidence does not undo historical use, but it limits the licence claim to the period of actual deployment and weakens Oracle's position on perpetual licensing.
When discovered during an audit, the negotiating goal shifts to scope reduction. Options that were never deployed on production should be removed from the claim entirely. Options on environments scheduled for decommission can be settled at material discounts. Options on workloads being migrated to OCI can be folded into a cloud commitment at favourable terms. We have seen options claims settle at 20–35% of opening list when these levers are exercised in the right order.
Our Oracle practice runs LMS-equivalent measurement scripts internally so customers know what an audit will find — before Oracle does. Start with a software license compliance assessment to baseline every option in use.
The price-book changes, audit triggers, and negotiation levers we see across 340+ engagements, in one short email — before they reach you as a vendor proposal.
