Oracle's LMS collection reads views you can read first, using the same script Oracle publishes on My Oracle Support. This playbook shows how to run it estate-wide, how to triage every flagged option into buy, remediate, or defend, and how to close the gaps while the numbers are still yours to control.
Oracle's LMS collection reads views you can read first, using the same script Oracle publishes on My Oracle Support. This playbook shows how to run it estate-wide, how to triage every flagged option into buy, remediate, or defend, and how to close the gaps while the numbers are still yours to control.
The same row in DBA_FEATURE_USAGE_STATISTICS is worth two completely different numbers depending on who reads it first. Oracle's stacking rule is what makes this brutal: an option installed on a 16-processor database must be licensed for all 16 processors, whether or not every core touches it. A fully optioned Enterprise Edition processor (Database plus RAC, Partitioning, Advanced Security, Advanced Compression, Diagnostics, Tuning, and Active Data Guard) lists at $122,000 per processor with $26,840 annual support. On a single 16-core Intel box that is $976,000 in license and $214,720 per year. Scale it to 200 processors and you are looking at $24.4M plus $5.37M annually at list. Nobody pays list, but the discount you get depends entirely on which branch of the timeline you are standing on.
On the pre-audit branch, net-new perpetual EE clears at $33,000 to $40,000 per Processor in Tier 1 deals ($50K to $500K), and options, listed between $7,500 and $23,000 per Processor, frequently discount deeper than base Database when they are bundled into a new acquisition. You are a buyer with a purchase order, a quarter-end date you can pick, and the option to walk. On the post-finding branch you are a compliance defendant. Oracle prices the remediation at list, adds backdated support for the period the counter was ticking, and your discount leverage evaporates because the alternative to signing is a contractual breach claim, not a competing quote. In our negotiation experience the same option set moves 40 to 60 points of discount between those two conversations, and the backdated support line alone often exceeds the license figure. Read how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill before you assume a single flagged row is a small problem.
You control the timing of a feature usage finding right up until the collection request lands in your inbox, and not one day after.
That is the whole leverage argument. The data already exists on your servers. Oracle cannot see it until you hand it over, and the moment you do, every remediation option that costs nothing (turning a feature off, dropping a test object, resetting a parameter) becomes a historical fact you have to buy your way out of instead. Run it yourself, or accept that someone else sets the price. Structure the exercise as a formal internal Oracle license audit with a named owner and a fixed end date, not as a DBA side project.
You do not need to reverse-engineer the collection. Oracle publishes the exact artifact: options_packs_usage_statistics.sql, available from My Oracle Support Document ID 1317265.1, and referenced in the Database Licensing Information User Manual under "Options and Packs." It is the same script Oracle's own field teams and LMS-derived collections lean on. It queries DBA_FEATURE_USAGE_STATISTICS (DFUS), applies to Oracle Database 11.2 and later, runs from SQL*Plus under any account holding SELECT ANY DICTIONARY, and spools its results to options_packs_usage_statistics.txt in the working directory. It can be executed manually against a single instance or fanned out across the estate through the Enterprise Manager Job System.
The output arrives in two sections. The first is a summary of identified features in use. The second is the breakdown of the specific features that triggered the license implication, which is the part that matters, because that is where you find out whether "Partitioning" means a production data warehouse or one interval-partitioned table a developer created in a sandbox in 2019. Read both sections against the guidance on DETECTED_USAGES versus CURRENTLY_USED, because auditors weight those two columns very differently and so should you.
Note carefully what the script is and is not. Oracle's own framing, echoed in the tooling ecosystem built around it, is that this is an informational resource, not a licensing entitlement statement. It reports what a counter incremented. It does not adjudicate what you owe. That distinction is the legal spine of every defend argument later in this playbook, and you should put it in writing in your own internal documentation before the first row is triaged.
Two operational instructions. First, sweep DBA_OPTION_USAGE alongside DFUS rather than treating the script output as complete; the two views do not always agree, and a discrepancy is evidence you want to own before Oracle does. Second, preserve the raw spool file exactly as produced, with a timestamp and a cryptographic hash recorded in a separate log. If a dispute reaches the point where you are arguing about what the counter said on a given date, an unaltered, hashed original is worth more than any spreadsheet you build from it. Store it outside the DBA team's normal working directories.
A partial self-assessment is worse than no self-assessment, because it hands your own executives a clean bill they will repeat to Oracle in writing and then have to retract. The single biggest coverage failure is the container database. Run options_packs_usage_statistics.sql from CDB$ROOT and it lists data for all open PDBs and correctly detects whether Multitenant licensing is required; run it inside a PDB and Multitenant isolation limits the output to that PDB's local data only. Closed and unplugged PDBs are invisible to both routes, which is exactly where the dormant Partitioning or Advanced Compression row sits until someone opens the database three months before a renewal. Users have also reported ORA-65501 when executing the Doc ID 1317265.1 script against a container, so treat any error return as a coverage gap and log it, never as a null result. Below the version floor, the script reports nothing on 11.1 and lower; the widely circulated workaround of widening the version regex is a hack that may produce incorrect results, so on those instances collect manually from DBA_FEATURE_USAGE_STATISTICS and mark the finding as unverified rather than clean.
| Target | Collection route | Known failure mode |
|---|---|---|
| CDB$ROOT | Script direct, spooled per instance | ORA-65501 reported against some containers |
| Open PDBs | Covered by CDB$ROOT run | PDB-local run returns local data only |
| Closed / unplugged PDBs | Open in restricted mode, collect, close | Silent zero, reads as compliant |
| Standby and Active Data Guard | Query DFUS on the primary and on each standby | Read-only opens flagged as ADG usage |
| 11.1 and lower | Manual DFUS query, mark unverified | Script reports nothing; regex hack unreliable |
| Test, dev, DR, decommission queue | Same as production, no exemption | Excluded from scope by assumption |
| 50+ instances | Enterprise Manager Job System | Agents missing on the exact hosts that matter |
Build a coverage register before you build a findings register: every instance name, host, version, edition, CDB or non-CDB, PDB inventory with open state, and the date and route of collection. Anything not collected is a row marked "not collected," never an empty cell. For estates above roughly fifty instances, Oracle documents the Enterprise Manager Job System as the multi-database route, which is faster but inherits your agent coverage, so reconcile the job target list against your CMDB line by line. The reconciliation discipline is the same one described in internal Oracle license audits, and the output feeds directly into how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill if you leave it unreconciled.
Buy only where three tests all pass: the usage is deliberate (a named owner can explain the design decision), it is ongoing (last sample date is current, not a single 2019 touch), and it is load-bearing to production (removing it breaks a service or an SLA). Anything failing one test goes to remediate or defend, not to the purchase order. Then set quantity correctly, which is where most buyers overpay before discount is even discussed: an option is licensed on the same metric and the same quantity as the database underneath it, so an option installed on a 16-processor database must be licensed for all 16 processors regardless of how many cores actually touch the feature. That means the Processor count after core factor, not the feature footprint, sets your bill. In quote reviews I have run, the discount percentage is the only number in the approval pack while the post-core-factor Processor count, which multiplies every other figure, is almost never restated by the buyer.
| Option / pack (2026 list, per Processor) | List | NUP list | Notes |
|---|---|---|---|
| Partitioning | $11,500 | $230 | Most common accidental finding |
| Advanced Security | $15,000 | $300 | TDE and redaction signatures |
| Advanced Compression | $11,500 | $230 | Heavy false-positive history |
| RAC | $23,000 | $460 | Deliberate by definition |
| In-Memory | $23,000 | $460 | Column store population |
| Active Data Guard | $11,500 | $230 | Read-only standby opens |
| Multitenant | $17,500 | $350 | Detected correctly only from CDB$ROOT |
| Real Application Testing | $11,500 | $230 | Capture/replay traces |
| Diagnostics Pack | ~$7,500 | $150 | AWR, ADDM |
| Tuning Pack | ~$5,000 | $100 | Requires Diagnostics: ~$12,500 combined |
Named User Plus prices at one-fiftieth of the Processor price with a 25 NUP per Processor floor, so Processor licensing wins above 50 real users per Processor and NUP is only a genuine saving on small, countable, non-public populations. Never accept a Tuning Pack quote on its own: Oracle's own reference manual makes a Diagnostics license a prerequisite for enabling Tuning, so budget ~$12,500 per Processor combined and price the management pack rows that actually cost you as a pair. On discount, options routinely clear deeper than base Database, with 55 to 75 percent off list observed where options are bundled with a new Enterprise Edition acquisition. Time your buy branch to coincide with that acquisition, not with an audit letter.
An option installed on a 16-processor database must be licensed for all 16 processors, whether or not every core touches the feature.
Remediation only earns you anything if it is completed, evidenced, and dated before a formal collection date lands in your inbox. Oracle's script reports history, not intent, so a parameter you changed the week after the audit letter arrived buys you nothing on the sample Oracle takes, and in my experience it invites the opposite reading: you knew, and you moved. The single highest-yield switch on the Diagnostics and Tuning Pack side is CONTROL_MANAGEMENT_PACK_ACCESS set to NONE, which blocks pack functionality at the engine level rather than relying on DBA discipline. The default most sites are still running is the permissive one (DIAGNOSTIC+TUNING), meaning AWR, ADDM, and the SQL Tuning Advisor are live on every Enterprise Edition instance you built from a template, and at roughly $7,500 per processor for Diagnostics plus $5,000 for Tuning, with Tuning requiring Diagnostics as a prerequisite, that is about $12,500 per processor of exposure that nobody chose. Read the mechanics in the CONTROL_MANAGEMENT_PACK_ACCESS deep dive before you touch a production instance, because setting it to NONE also disables features your operations team may depend on.
The caveat matters as much as the switch: the parameter does not close every route to pack-licensed data. Monitoring agents, third-party observability tools, and some Enterprise Manager plug-ins can still reach AWR tables or issue pack-triggering calls, and those calls can keep incrementing counters after you believe the estate is clean. So prescribe a two-step proof, not a one-step change. Step one: set the parameter to NONE and record the change with a ticket number, timestamp, and instance list. Step two: leave the monitoring stack running and re-validate every tool against DBA_FEATURE_USAGE_STATISTICS on a subsequent sample, checking that LAST_USAGE_DATE for pack signatures does not advance past your change date. If it does, you have found the tool that is billing you, and you fix the tool, not the database.
Two persistence problems remain. Historical rows do not disappear: DETECTED_USAGES and FIRST_USAGE_DATE survive the parameter change, so remediation stops the counter, it does not erase the record. And feature usage can outlive the objects that caused it, which is why partitioning still shows as used after you drop the partitioned tables. Plan your remediation on the assumption that you will still have to explain the history, and document what you did so the explanation is evidenced rather than asserted.
The script's own defect history is the strongest asset a buyer has, and it must be assembled before a dispute, not improvised during one. Oracle documents 14 bugs against the collection logic at MOS Doc ID 1309070.1, and there are undocumented ones beyond that list, which means the output you are being asked to accept as fact is a tool with a published error rate. Known false positives include compression or encryption rows raised by SecureFiles and by RMAN activity that never touched Advanced Compression or Advanced Security, and Spatial reported where only Locator, which is included with the database, is actually deployed. The precedent to keep in your file is Bug 17164904: more than 700 Advanced Compression detections traced to a counter that incremented incorrectly for compression=metadata_only in 12.1.0.1, fixed in 12.1.0.2 and documented at Doc ID 1993134.1. At $11,500 per processor list for Advanced Compression, that class of defect turns into seven-figure claims across a mid-sized estate before anyone checks the version.
Handle the output's own hedges deliberately. Any line containing INVALID or BUG is a usage the script itself has flagged as ignorable or needing further checks, so it is not a finding, it is a question. Extract those lines into a register with instance, version, patch level, feature name, and the matching bug or doc reference, and require Oracle to close each one with a written statement before it enters a compliance total.
Those four columns are what turn one accidental touch into a defensible position rather than an admitted deployment. A row showing DETECTED_USAGES of 1, CURRENTLY_USED of FALSE, and FIRST_USAGE_DATE equal to LAST_USAGE_DATE three years ago describes a DBA who ran a command once, not an estate running a feature, and the distinction between DETECTED_USAGES and CURRENTLY_USED is exactly where auditors and buyers weigh the same data differently. Build the register while the numbers are still yours, because the same evidence presented after a formal claim reads as a defence rather than a fact.
The output you are being asked to accept as fact is a tool with a published error rate.
Run this as a dated project with named owners, not as a DBA favor squeezed between tickets. Days 1 to 5 belong to the inventory, not the script. Build a complete list of instances, hosts, physical cores, CPU model, and virtualization boundary, then compute the Processor count after core factor and have someone other than the person who built it re-derive that number. Across 60 to 80 quote and renewal reviews, the discount line was the only figure in the approval pack while the Processor count after core factor, which multiplies every other number in the deal, was almost never restated or verified by the buyer. Fix that first, because a wrong core count corrupts every price you calculate later.
Price the residual against footprint, not against discount. In renewals we have reviewed, footprint reduction cut total cost 15 to 30 percent more than discount chasing alone, because a deeper percentage off an oversized estate still pays for capacity you do not use. Consolidating options onto fewer licensed Processors beats arguing about the discount line. Finally, treat the entire output as internal work product. Hold the findings under privilege where your counsel supports it, share them on a need-to-know basis, and never volunteer raw spools, remediation notes, or draft triage spreadsheets to Oracle. A self-run audit is leverage only while the numbers remain yours to interpret.
It is options_packs_usage_statistics.sql, published by Oracle on My Oracle Support under Document ID 1317265.1. Run it from SQL*Plus with any account holding SELECT ANY DICTIONARY. It applies to Oracle Database 11.2 and later and spools its results to options_packs_usage_statistics.txt in the current working directory. Preserve that raw spool with a timestamp before anyone edits or summarises it.
No. Running the script internally is ordinary system administration on your own infrastructure, and Oracle's own documentation positions the output as an informational resource rather than a licensing entitlement statement. You are under no obligation to send unrequested results to Oracle. Where possible, run the exercise under legal privilege so that early drafts and internal debate are protected if a formal audit later follows.
Because the collection has a documented defect history: 14 bugs are catalogued under MOS Doc ID 1309070.1, with more undocumented. Known patterns include SecureFiles and RMAN triggering Advanced Compression or Advanced Security rows, Spatial reported where only Locator is installed, and more than 700 Advanced Compression false detections traced to unpublished Bug 17164904 in 12.1.0.1. Treat every row as a claim requiring corroboration from configuration evidence, not as a proven fact.
It stops the exposure going forward at engine level, but it does two things it cannot do. It does not erase historical rows already recorded in DBA_FEATURE_USAGE_STATISTICS, and it does not necessarily close every access route, because monitoring agents, third-party observability tools, and some Enterprise Manager plug-ins may still reach AWR data. Set the parameter, then re-sample DFUS after several weeks to prove the counters have actually stopped.
It is priced on the same metric and quantity as the database underneath it, so an option on a 16-processor database must be licensed for all 16 processors regardless of how many cores use it. At 2026 list, Partitioning is $11,500 per Processor, RAC and In-Memory $23,000, Multitenant $17,500, Advanced Security $15,000, and Tuning effectively $12,500 because it requires Diagnostics. A fully optioned EE processor lists at $122,000 with $26,840 in annual support, which is $976,000 plus $214,720 per year on a single 16-core Intel server.
Yes on non-production and standby, because Oracle counts them and audit findings routinely originate there. Closed and unplugged PDBs are the blind spot: connected to CDB$ROOT the script reports on all open PDBs and correctly detects Multitenant need, but closed PDBs and PDB-local executions produce an incomplete picture. Build a coverage register listing every instance and PDB so you can prove what was sampled and what was not.
The separately-licensed options and packs that ship enabled by default, get switched on with a single click, and become the single largest line item in most Oracle audit findings.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
