Oracle Database options and management packs are the single largest source of Oracle audit exposure — in our 340+ engagements they account for more than half of all claims. There are roughly a dozen separately-licensable options and seven management packs, each priced per processor between $5,000 and $23,000 plus 22% annual support, and each applying to every processor the database is licensed on, not just the ones using the feature. Most findings come from a feature switched on by accident, a tool, or a default — not a deliberate purchase decision.
Options and management packs are chargeable features that bolt onto Oracle Database Enterprise Edition. Enterprise Edition is the licence you bought; the options and packs are the licences Oracle finds. There are around twelve options — Partitioning, Real Application Clusters (RAC), Active Data Guard, Advanced Security, Advanced Compression, Database Vault, Label Security, OLAP, Real Application Testing, In-Memory, Spatial, and Multitenant — and seven management packs: Diagnostic, Tuning, Database Lifecycle Management, Cloud Management, Data Masking & Subsetting, Configuration Management, and Change Management. Each is licensed on the same metric and processor count as the underlying Enterprise Edition, so a feature touched on one processor of a 16-processor cluster can create a 16-processor claim.
This is a pillar guide. It maps the full option and pack universe, the list prices, the silent-activation traps, and the detection-and-remediation workflow. Three companion deep-dives go further: Oracle options & management packs (feature-by-feature pricing and triggers), Oracle Exadata & engineered systems (where options ride along with the hardware), and the Oracle database feature-usage audit (running the LMS scripts yourself). For the broader picture, start from our Oracle licensing guide and Oracle processor licensing explainer.
All figures below are Oracle Technology Global Price List per-processor list prices, before negotiation and before the 22% annual support that compounds every figure. The processor count is derived from physical cores multiplied by Oracle's core factor (0.5 for most x86 chips), so list price is only the starting point — the licensable processor count is where most disputes actually sit.
| Option (per processor) | List price | What activates it |
|---|---|---|
| Real Application Clusters (RAC) | $23,000 | Clustered database stood up for testing and left running |
| In-Memory | $23,000 | INMEMORY attribute set on any table or column |
| OLAP | $23,000 | Analytic workspaces / OLAP cubes created |
| Multitenant | $17,500 | More than the free-tier number of pluggable databases |
| Advanced Security (ASO) | $15,000 | Transparent Data Encryption (TDE) for "compliance" |
| Partitioning | $11,500 | One partitioned table — often created by a tool |
| Active Data Guard | $11,500 | Standby opened read-only for reporting |
| Advanced Compression | $11,500 | OLTP / Advanced row compression enabled |
| Database Vault | $11,500 | Realms or command rules configured |
| Real Application Testing | $11,500 | Database Replay or SQL Performance Analyzer run |
| Management pack (per processor) | List price | What activates it |
|---|---|---|
| Database Lifecycle Management Pack | $12,000 | Provisioning, patch automation, compliance screens in OEM |
| Data Masking & Subsetting Pack | $11,500 | Masking definitions applied to non-prod copies |
| Cloud Management Pack | $7,500 | Self-service / chargeback features in OEM |
| Diagnostic Pack | $7,500 | AWR report, ADDM, or active session history queried |
| Tuning Pack | $5,000 | SQL Tuning Advisor or SQL Access Advisor run |
The pattern that matters: the two cheapest packs — Diagnostic at $7,500 and Tuning at $5,000 — are the most expensive findings in practice, because they activate silently across the largest estates. A DBA who clicks "Performance" in Enterprise Manager on a 40-processor production database has just recorded a use that lists at $300,000 for Diagnostic Pack alone, before support and before it is multiplied across every database in the estate.
The DBA_FEATURE_USAGE_STATISTICS view tells you exactly what an LMS auditor will find.
Because Oracle ships every option and pack inside the same Enterprise Edition binary. There is no installer checkbox that says "you are about to use a $300,000 feature." The licence boundary is enforced commercially, after the fact, not technically at the point of use. Three routes drive almost every accidental finding we see.
First, defaults. Partitioning is available the moment Enterprise Edition is installed; a single CREATE TABLE ... PARTITION BY — issued by a developer, a migration script, or an ORM framework — records use. Second, management tooling. Diagnostic and Tuning Pack activate through the ordinary performance-investigation workflow every DBA is trained on: generate an AWR report, run the SQL Tuning Advisor, open the Performance tab in OEM. Third, Oracle's own products. E-Business Suite, parts of Fusion Middleware, and several OEM schemas use Partitioning and Advanced Compression as a baseline, which means an Oracle application can create an Oracle Database option liability.
Management pack use can be blocked at the database level. Setting CONTROL_MANAGEMENT_PACK_ACCESS = NONE disables Diagnostic and Tuning Pack functionality so it cannot be triggered. The trade-off is operational: you lose AWR, ADDM, and the Advisors, and have to fall back to Statspack or third-party monitoring. That is a deliberate decision a licensing-aware organisation makes — not a discovery an auditor makes for you. Options, by contrast, generally cannot be parameter-blocked; they have to be avoided by design and removed by remediation.
The feature-by-feature detection checklist and remediation playbook used across 340+ engagements.
Through the database's own telemetry. Oracle's LMS measurement scripts query a small set of data dictionary views that record feature use automatically, and the auditor reads the same rows you can read yourself today. The headline view is DBA_FEATURE_USAGE_STATISTICS, supported by DBA_HIGH_WATER_MARK_STATISTICS for count-based options.
| Evidence field | What it proves | Why it matters |
|---|---|---|
| FEATURE_USAGE | Every option/pack used since DB creation | A single sample is enough to open a claim |
| FIRST_USAGE_DATE / LAST_USAGE_DATE | Whether use was historical or ongoing | Sets the window of the licence claim |
| CURRENTLY_USED | Whether the feature is in use now | Separates a live deployment from an old accident |
| DETECTED_USAGES / TOTAL_SAMPLES | How often use was sampled | One-off vs. continuous; weakens or strengthens scope |
| HIGH_WATER_MARK | Peak count (PDBs, sessions, etc.) | Drives count-metered options like Multitenant |
The asymmetry to understand: the view records use, not intent and not licence entitlement. It will happily report that Tuning Pack was used once in 2023 on a database you have since decommissioned. Removing the feature today does not erase the historical row — which is why the only durable defence is to read these views on a quarterly cadence and remediate before a row ever appears. Our feature-usage audit guide walks through the exact queries.
Exposure is not evenly distributed. The high-frequency findings are cheap-per-processor packs that touch the whole estate; the high-severity findings are expensive options on large clusters. The table below reflects the pattern across our Oracle engagements.
| Feature | Finding frequency | Typical trigger | Severity |
|---|---|---|---|
| Diagnostic Pack | Very high | AWR report in routine tuning | High on large estates |
| Tuning Pack | Very high | SQL Tuning Advisor | High on large estates |
| Partitioning | High | Tool-created partitioned table | Medium–high |
| Advanced Compression | Medium | Compression enabled for storage savings | Medium |
| Advanced Security (TDE) | Medium | Encryption turned on for "compliance" | High on RAC |
| RAC / Active Data Guard | Low | Test cluster / read-only standby left running | Very high |
| Multitenant | Rising | Consolidation past the free PDB tier | Medium–high |
Multitenant deserves a flag for 2026. Oracle has changed the free pluggable-database allowance across releases — a posture that was compliant under 19c with three free PDBs is not automatically compliant after a consolidation project pushes the count higher. Track PDB high-water marks as deliberately as you track processor counts. Engineered systems compound this: an Exadata or Exadata Cloud@Customer rack ships configured in ways that make certain options operationally natural, which is why we cover it separately in the Exadata guide.
We run the LMS-equivalent scripts ourselves and build the remediation plan before any audit letter lands.
It depends on whether you find the use before or during an audit. Before an audit, the goal is prevention and clean evidence: disable the feature, remove the artefacts (partitioned tables, encrypted columns, opened standbys, surplus PDBs), block management packs via CONTROL_MANAGEMENT_PACK_ACCESS, and document non-use going forward. Historical rows remain, but a short, closed window of use is a far weaker claim than open-ended ongoing deployment.
During an audit, the goal shifts to scope. Options that were never on production come out of the claim. Workloads scheduled for decommission settle at material discounts. Workloads migrating to OCI fold into a cloud commitment at favourable terms. In our experience, options claims that open at full list settle between 20% and 35% of that opening number when these levers are pulled in the right order — the same discipline we apply in Oracle audit defence. The detail of the sequencing is in the Options & Management Packs Audit Guide.
| Lever | When it applies | Typical effect on the claim |
|---|---|---|
| Remove never-deployed environments from scope | Always | Largest single reduction |
| Disable + document non-use before audit | Pre-audit | Caps the claim window |
| Settle decommission-bound workloads | During audit | Material per-environment discount |
| Fold migrating workloads into OCI commitment | During audit | Converts penalty into spend |
| Contest core-factor / processor count | Always | Reduces the multiplier on every option |
A clean Oracle Database options position has three parts: an inventory of every option and pack ever recorded in DBA_FEATURE_USAGE_STATISTICS across every instance; a deliberate licence-or-remove decision for each one rather than a discovered finding; and a quarterly re-run of the LMS-equivalent scripts so nothing new appears between reviews. Customers who do this read the same data as Oracle's auditors — months earlier, and with time to act. Customers who do not are reading it for the first time across the table from LMS.
Our Oracle practice runs LMS-equivalent measurement scripts internally so you know what an audit will find — before Oracle does. Our Oracle license optimization work then strips the options you pay for but never use. $1.8B+ documented client savings · 68% average audit-claim reduction · buyer-side only since 2016.
Weekly compliance intelligence for IT leaders.
