Contacts
Book a call
Close

Contacts

#4 – 647 Neal Dr, Peterborough, Ontario K9J 6X7

1.888.978.5129

info@metrixdata360.com

Oracle Database Options Are Licensed by Use, Not Purchase.

Oracle database options

Oracle Database Enterprise Edition will let you use almost every extra-cost option and management pack it sells without a license key, a prompt, or a warning. It will also keep a permanent record of what you did.

I have spent a lot of the last few months on Oracle database licensing, and of everything I work on, this is the part I find hardest. The processor math is demanding, but at least it follows rules. Options and packs are different. A database administrator clicking a screen decides the bill, often years before anyone in software asset management (SAM) looks at it.

Why Can Someone Turn On a Paid Option Without Buying It?

Because Enterprise Edition installs the code for nearly every option and pack by default and does not check whether you have paid for it. Use triggers the license obligation, not purchase or installation.

There is no activation step. Partitioning, Advanced Compression, Active Data Guard and the rest sit inside the same binaries you already licensed. When someone uses one, the database records it in a view called DBA_FEATURE_USAGE_STATISTICS.

That view is worth understanding precisely, because the detail cuts both ways. A sampling job writes to it roughly weekly, not at the instant of use, and it holds a first usage date, a last usage date and a count of detections. Volume never appears. So a single advisor run and three years of production monitoring can look similar at a glance, and the flag does not expire either way.

Oracle’s own licensing guide still lists the Diagnostics Pack, Tuning Pack and most options as extra-cost items on Enterprise Edition. That is true of the current manual for Oracle AI Database 26ai, the release that replaced Oracle Database 23ai in October 2025 (the manual is dated August 2026). The rename changed the branding. It did not change how Oracle counts options.

Isn’t There a Setting That Blocks It?

There is one, it covers only two packs, and it ships switched on. The parameter CONTROL_MANAGEMENT_PACK_ACCESS controls the Diagnostics Pack and Tuning Pack, and its default on Enterprise Edition is DIAGNOSTIC+TUNING (as of October 2026).

So a freshly built database allows and records use of the two packs that show up most often in audits, straight out of the box. Most of the other options have no equivalent switch at all.

Oracle does not price these two independently either. Its own reference states that you need a Diagnostics license before you can enable Tuning, so a Tuning Pack finding never arrives alone.

This is where my starting assumption needed correcting. I used to say “there are no restrictions.” The more precise version is worse: the only restriction Oracle provides defaults to off, and it does nothing about history that already exists.

How Does It Actually Get Switched On?

Through routine administration that nobody records as a purchasing decision. Nobody I have met decided to deploy an unlicensed pack. They were troubleshooting a slow query.

Option or pack A common way it gets used Control available
Diagnostics Pack Opening a performance page in Oracle Enterprise Manager (OEM), or querying Automatic Workload Repository (AWR) history CONTROL_MANAGEMENT_PACK_ACCESS, plus pack access settings in OEM
Tuning Pack Running SQL Tuning Advisor, or an automatic tuning task nobody disabled Same parameter, plus disabling the automatic task
Partitioning A vendor application or upgrade script creating partitioned tables None built in. Usage also persists after you drop the partitioned tables
Advanced Compression Compression options your team picks during backups, exports or table changes None built in
Any of the above Cloning a database, which can carry the usage history into the copy None built in

Third-party monitoring tools are worth a separate mention. Some read AWR data directly, which can record Diagnostics Pack use with no person involved at all.

How Big a Problem Is This, Really?

Big enough that it is usually the first line an Oracle audit prices.

Oracle Licensing Experts’ 2026 Accidental-Use Index, which covers 205 audited Enterprise Edition estates, puts accidental option or pack use in 71% of them, with the Diagnostics Pack the most common finding at 43%, ahead of Tuning Pack at 31% and Partitioning at 24%. Redress Compliance reports unlicensed pack usage on 20% to 40% of the databases it baselines. Palisade Compliance puts the figure above 80% of audited customers.

These are firms that sell audit defense, and the spread between 40% and 80% tells you how loosely to read the exact figures. The direction matches what I see.

The cost multiplies because Oracle prices packs on the same processor or Named User Plus basis as the database underneath them. Oracle can price one click on one server against every processor you license on that server, and charge back support from the first usage date. Check Oracle’s current technology price list before you model anything (as of October 2026).

There is also more scrutiny of Oracle’s licensing practices in general. On 1 September 2026, MLex reported, and Reuters confirmed, that the European Commission was gathering views from third parties on Oracle’s licensing conduct. A Commission spokesperson said that at this stage, there is no formal investigation into any company. I would not treat that as relief. Your contract and your usage view are what count.

Why Does Nobody Catch It?

Because the person who controls the switch and the person who owns the bill are rarely in the same conversation. Database administrators own the parameter. SAM or IT asset management (ITAM) teams own the effective license position (ELP), the reconciliation of what you deployed against what you own.

In practice, nobody owns the setting itself. I have seen this get worse when people leave. On one estate I worked on, the database contacts (who knew why certain options were in use) moved on, and only the usage view remained: dates and counts with no context. The flag outlives the person. The reason for it does not.

That context is what decides how defensible a finding is. “A DBA opened a page once during an upgrade in 2022” is a very different conversation from “our production monitoring runs on AWR.” If you cannot say which one happened, you are negotiating without it.

The artifact that settles it is the date pair. Line FIRST_USAGE_DATE and LAST_USAGE_DATE up against your change management records and you turn a story into evidence. A first usage date that matches a patch or upgrade ticket, with the ticket on file, gives you a defensible position. The same date with nothing behind it is an assertion, and assertions do not move settlements.

It is also why I no longer treat a SAM tool’s database report as the answer on its own. Several tools can read feature usage. Fewer can tell you whether a flagged option matters, and none can tell you why anyone used it. That still requires a person to talk to the DBA team.

What I Would Do This Quarter

You can stop new usage in a day. Explaining the old usage takes longer, so start that first.

  1. Run Oracle’s own check. Oracle publishes a script (My Oracle Support note 1317265.1, options_packs_usage_statistics.sql) that maps feature usage to the option or pack it belongs to. Run it on every Enterprise Edition database, including non-production ones. Keep the raw output with a timestamp.
  2. Reconcile it against your ordering documents, database by database. If the view records an option as used and your contracts do not cover it, you have a finding, even if the count is one.
  3. Write down the context while people still remember it. Who, when, why, and whether anything in the business depended on it. Attach the change ticket that matches the first usage date. Date the note.
  4. Set the parameter on purpose. Use NONE, or DIAGNOSTIC if that is all you own, and put the setting in your build scripts and images so new databases do not inherit the default. Know what it costs you before you do: NONE also disables AWR, ADDM and the automatic advisors, which your operations team may be relying on.
  5. Prove the change worked, rather than assuming it. The parameter does not close every route. Monitoring agents, some OEM plug-ins and direct reads of AWR tables can keep incrementing counters afterwards. Resample the usage view weeks later and confirm LAST_USAGE_DATE has not moved past your change date. If it has, you have found the tool that is billing you, and the fix is the tool, not the database.
  6. Check the tools, not just the people. Confirm what your monitoring and backup tools touch.
  7. Ask whether the database needs Enterprise Edition at all. On Standard Edition 2 the pack access parameter defaults to NONE and most of the options catalog does not exist (as of October 2026).

None of this erases history. Changing the parameter today stops future usage. It does not clear what the view already holds, and Oracle’s position is that past usage still counts.

The Part I Keep Coming Back To

Most licensing exposure I deal with comes from a decision someone made: buying too little, deploying too widely, or signing the wrong metric. Options and packs are different. The exposure comes from the product’s defaults, recorded by the product itself, and handed to the vendor’s auditors as evidence.

It is the same pattern my colleague Ben Tight described in Oracle Fusion, where a role assignment nobody treated as a purchase becomes a licensing transaction. Different product, same mechanism: the vendor’s meter runs against configuration decisions nobody priced.

That is not a reason to panic. It is a reason to read the usage view before someone else does, and to make the parameter a governed setting with a named owner instead of a default nobody chose. That ownership question is the whole of what continuous license governance is for, and it is cheaper to answer now than during an Oracle audit.

If the Script Turns Up Something You Cannot Explain

Step one on that list is yours to run. Nobody needs us to execute a SQL script.

The part that takes longer is step three: reconstructing why someone turned an option on years after they left the company, and turning a row in a usage view into something that holds up in front of an auditor.

That is the work we do. MetrixData 360 builds defensible Oracle license positions and defends them in audits. We do not resell Oracle licenses, so the position we build is the one your evidence supports.

See how we approach Oracle licensing and audit defense

Already holding an audit or review letter? Mention it when you reach out. The clock changes what we would do first.

Frequently Asked Questions About Oracle Database Option Licensing

Can you use an Oracle database option without a license key? Yes. Oracle Database Enterprise Edition installs nearly every extra-cost option and management pack by default and performs no entitlement check. There is no key, no prompt and no warning. Use triggers the license obligation, not purchase or installation.

What is DBA_FEATURE_USAGE_STATISTICS? The database view that records which features someone has used. It holds a first usage date, a last usage date and a detection count. A sampling job updates it roughly weekly. Volume never appears, and the record does not expire.

Does CONTROL_MANAGEMENT_PACK_ACCESS stop unlicensed usage? Only partly. It covers the Diagnostics Pack and Tuning Pack, and on Enterprise Edition it defaults to DIAGNOSTIC+TUNING, so Oracle allows both out of the box. Most other options have no equivalent control. Setting it to NONE stops new pack usage at the engine level but does not erase history and does not block every route to AWR data.

How do I check which Oracle options my databases have used? Run Oracle’s own script, options_packs_usage_statistics.sql. Oracle publishes it in My Oracle Support note 1317265.1. The script applies to Oracle Database 11.2 and later and maps feature usage rows to the priced options and packs. Run it on every Enterprise Edition database, including non-production.

Does turning an option off remove the licensing exposure? No. Disabling an option stops usage going forward. The history already in the usage view stays there, and Oracle’s position is that past usage still counts. What changes the outcome is dated evidence explaining the usage, not the removal of the flag.

Does Standard Edition 2 have the same problem? No. On Standard Edition 2 the pack access parameter defaults to NONE and most of the options catalog does not exist, which is why the edition question is worth asking before the licensing one.


Written by Sharon Idaraji, Delivery Specialist at MetrixData 360.