The Diagnostics Pack and Tuning Pack are the most common silent findings in an Oracle audit. They price per Processor and switch on without an install. Here is how a buyer shuts the trap off.
The Oracle Diagnostics Pack lists at $7,500 per Processor and the Tuning Pack at $5,000. Both cover tooling your DBAs already use, and both switch on without an install. One AWR report on a sixteen Processor cluster is a $200,000 finding at list.
The Diagnostics Pack and Tuning Pack are the most common silent findings in an Oracle audit. They price per Processor, they cover features developers and DBAs use every day, and they switch on without a separate install.
This guide sets out how the auto use trap works, what sits inside each pack, how the exposure number is built, and how a buyer shuts the trap before it becomes a settlement line.
Both are management packs that price on top of Enterprise Edition, per Processor. They cover the performance tooling inside the database and inside Enterprise Manager.
Neither is a product you install. Both are code paths already compiled into the engine you are running, gated by one initialisation parameter and by your contract.
The Diagnostics Pack covers the Automatic Workload Repository, Active Session History, the automatic database diagnostic monitor and the performance pages in Enterprise Manager. Any query against the AWR views is licensable use, and so is a hand written SELECT against a DBA_HIST table.
Oracle draws the boundary in the options and packs table of the Oracle Database 23ai Licensing Information User Manual. Read that table before you read anything a reseller sent you.
The Tuning Pack covers the SQL Tuning Advisor and SQL Access Advisor. It requires the Diagnostics Pack as a prerequisite, so the two are almost always found together.
Enterprise Manager carries its own separately licensed packs, and audit letters routinely mix them into a database finding. Keep them in different columns on your own worksheet.
These are priced separately from Diagnostics and Tuning and are governed by the Enterprise Manager licensing information manual, not the database one. A finding that lumps them together is a finding you can split.
The free set is larger than most DBA teams believe, and knowing it by name is what makes a NONE decision survivable. Everything in the left column below is licensable. Everything in the right column ships with Enterprise Edition at no extra license fee.
Licensable pack features and the free equivalent that does the same job
| What a DBA reaches for | Pack it consumes | Free equivalent with no pack |
|---|---|---|
| awrrpt.sql and any DBA_HIST view | Diagnostics | Statspack from spcreate.sql, plus the V$ dynamic views |
| V$ACTIVE_SESSION_HISTORY and its DBA_HIST twin | Diagnostics | Your own sampler polling V$SESSION on a scheduler job |
| ADDM findings and the automatic diagnostic monitor | Diagnostics | The alert log, ADRCI, and a read of the Statspack report |
| Performance Hub and the EM performance pages | Diagnostics | The base target home pages and your own V$ queries |
| Real Time SQL Monitoring reports | Diagnostics and Tuning | SQL trace at level 12 and tkprof on the trace file |
| DBMS_XPLAN.DISPLAY_AWR | Diagnostics | DBMS_XPLAN.DISPLAY_CURSOR and EXPLAIN PLAN |
| SQL Tuning Advisor and SQL Profiles | Tuning | Manual plan analysis, hints, and statistics work |
| SQL Access Advisor recommendations | Tuning | Index design by hand against measured workload |
Sources: the options and packs table in the Oracle Database Licensing Information User Manual, read against My Oracle Support Doc ID 1317265.1.
Three boundaries produce most of the disagreement in the room. Take a position on each one before the meeting, in writing, with the manual reference beside it.
Partitioning, Advanced Compression, Advanced Security, Multitenant beyond the free pluggable database allowance, and Real Application Clusters are separate options with their own prices. They appear in the same feature usage output and in the same audit letter.
Keep them on separate lines of your response. A settlement that bundles options and packs into one number is a settlement you cannot audit later.
The trap is that these packs are on by default in Enterprise Edition. A DBA running a standard AWR report has used a licensable feature, and the database records it that week.
Where the packs switch on silently
| Action | Pack consumed | How it happens | Defense |
|---|---|---|---|
| Run an AWR report | Diagnostics | Default DBA workflow | Set control parameter off |
| View EM performance page | Diagnostics | One click in console | Restrict EM packs |
| Run SQL Tuning Advisor | Tuning | Default tuning step | Disable advisor |
| Query DBA_HIST views | Diagnostics | Ad hoc SQL | Revoke access |
| Monitoring agent polls AWR | Diagnostics | Scheduled collector, no human | Repoint the agent at V$ views |
| Nightly maintenance window runs | Tuning | AUTO_SQL_TUNING_TASK autotask | Disable the autotask client |
CONTROL_MANAGEMENT_PACK_ACCESS governs pack access at the engine, and it takes three values: NONE, DIAGNOSTIC and DIAGNOSTIC+TUNING. Enterprise Edition ships at DIAGNOSTIC+TUNING.
That is the trap in one line, because the permissive setting is the factory setting and consumption starts before anyone has made a decision. The parameter is dynamic, so ALTER SYSTEM SET control_management_pack_access='NONE' SCOPE=BOTH SID='*'; takes effect without a restart.
It is documented in the Oracle Database 23ai Database Reference. Set it in the spfile and in the DBCA template you clone from, or the next database your build pipeline provisions comes back permissive.
Enterprise Manager hands the same features out through the console, where a manager with read only access can trigger them in one click. In Cloud Control the path is Setup, then Management Packs, then Management Pack Access, and it switches pack access off per target so the licensable links grey out.
Do it the same day you set the parameter. The parameter protects the database. This protects the person.
Every estate we have cleaned has had at least one of these, and usually two. Put a control against each before you report the estate as clean.
White Paper · Oracle Database
Oracle Options & Management Packs
Why the options cost more than the database. Read it free.
Oracle publishes both numbers, which is unusual enough to be worth using. The Oracle Technology Global Price List carries the Diagnostics Pack at $7,500 per Processor and the Tuning Pack at $5,000 per Processor, perpetual, before discount.
Named User Plus is $150 and $100, under the same 25 Named User Plus per Processor minimum that applies to Enterprise Edition. Annual technical support is 22 percent of the net license fee and is billed on the packs separately from the database.
| Item | Processor, perpetual, list | Named User Plus, perpetual, list | Named User Plus minimum |
|---|---|---|---|
| Database Enterprise Edition | $47,500 | $950 | 25 per Processor |
| Diagnostics Pack | $7,500 | $150 | 25 per Processor |
| Tuning Pack | $5,000 | $100 | 25 per Processor |
| Both packs together | $12,500 | $250 | 25 per Processor |
| Annual technical support | 22 percent of net license fee | 22 percent of net license fee | Not applicable |
Source: Oracle Technology Global Price List, list prices before discount. Oracle publishes no discount schedule for the packs; the pack discounts we observe track the database discount on the same order rather than beating it, so read the list column as the ceiling.
The Tuning Pack cannot be bought on its own. Diagnostics is a prerequisite, so the honest unit price of wanting the SQL Tuning Advisor is $12,500 per Processor, not $5,000.
Say that out loud in the first meeting. It moves the item from a rounding error to a line the CFO has to see.
Pack findings scale with the licensed Processor count, not with how often the feature ran. One AWR report on a sixteen Processor cluster can imply sixteen Processor licenses for each pack.
The metric has no usage dimension. There is no concept of a pack hour, a pack seat, or a pack report, so there is nothing for the number of executions to attach to.
That is why the only two levers that matter are the Processor count you can defensibly claim and the date range you can defensibly close. Volume is not a lever, however unfair that feels in the room.
Oracle multiplies your licensed Processor count by the list price of each pack, then adds back support for every year since the first recorded use. Nothing in that chain references how much you used the feature.
Take a two node RAC cluster. Each node has two sockets and an eight core Intel Xeon in each socket. Substitute your own core count and core factor as you read down.
| Step | Arithmetic | Result |
|---|---|---|
| Cores in the cluster | 2 nodes x 2 sockets x 8 cores | 32 cores |
| Core factor, Intel Xeon | Oracle Processor Core Factor Table | 0.5 |
| Processor licenses required | 32 x 0.5 | 16 |
| Diagnostics Pack, list | 16 x $7,500 | $120,000 |
| Tuning Pack, list | 16 x $5,000 | $80,000 |
| Both packs, license only | $120,000 + $80,000 | $200,000 |
| Support, one year at 22 percent | $200,000 x 0.22 | $44,000 |
| Back support, three years | $44,000 x 3 | $132,000 |
| Finding as Oracle presents it | $200,000 + $132,000 | $332,000 |
The trigger for that whole column can be one AWR report, run once, on one node, by a contractor who has since left. The packs do not price on how much you used them. They price on the Processor count of the database underneath them.
On 16 Processors the minimum is 16 x 25 = 400 Named User Plus. At that floor, Diagnostics is 400 x $150 = $60,000 and Tuning is 400 x $100 = $40,000.
Both packs land at $100,000 on that metric against $200,000 on the Processor metric. It only holds if you can count and cap every human and every device that reaches the database, which on anything internet facing you cannot.
Check it on the back office clusters anyway. That is where it survives contact with an auditor.
Audit worksheets are built by people under time pressure from data you supplied. In our pack disputes, at least one of these three appeared in the first draft more often than not.
Two columns decide how much of that Oracle gets to ask for: FIRST_USAGE_DATE and LAST_USAGE_DATE in DBA_FEATURE_USAGE_STATISTICS. Pull them before Oracle does.
It records that a licensable code path executed, on which database, when it was first seen and when it was last seen. This view is the entire case.
It sits on the table WRI$_DBU_FEATURE_USAGE joined to WRI$_DBU_FEATURE_METADATA, and it is written by the MMON background process on the interval in its own SAMPLE_INTERVAL column, which defaults to 604800 seconds, one week. LAST_SAMPLE_DATE tells you when the sampler last ran.
Two things follow at once. Setting the parameter to NONE this morning changes nothing in the view until the next sample fires, so force one with EXEC DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING(SYSTIMESTAMP); and bank a dated row showing CURRENTLY_USED as FALSE. And nothing you do removes the rows already written.
Run this before anyone outside the team asks for anything. Keep the output with a date, a hostname and the name of whoever ran it.
SELECT dbid, name, version, detected_usages, currently_used,
first_usage_date, last_usage_date, last_sample_date
FROM dba_feature_usage_statistics
WHERE detected_usages > 0
AND ( name LIKE '%Workload Repository%'
OR name LIKE '%ADDM%'
OR name LIKE '%Active Session History%'
OR name LIKE '%AWR%'
OR name LIKE '%SQL Tuning%'
OR name LIKE '%SQL Access Advisor%'
OR name LIKE '%SQL Profile%'
OR name LIKE '%SQL Monitoring%'
OR name LIKE '%Diagnostic Pack%'
OR name LIKE '%Tuning Pack%')
ORDER BY dbid, name;Feature names vary by release, so treat that list as a starting filter and read the full unfiltered output at least once per database. The version column tells you which release wrote each row, which matters when a finding straddles an upgrade.
Oracle ships no supported procedure to clear feature usage. AWR retention does not reach it, so the DBA_HIST tables roll off while the usage row stays. It survives instance restart, database upgrade and RMAN restore.
Deleting from WRI$_DBU_FEATURE_USAGE by hand is unsupported, it is visible, and in a dispute it converts a licensing argument into a conduct argument. Nobody wins that one.
FIRST_USAGE_DATE is how far back Oracle will try to run back support. LAST_USAGE_DATE is your side of the trade.
If the last recorded touch predates the current contract term, or predates the day you set the parameter to NONE, you are arguing about a closed historic event rather than an ongoing entitlement. On the cluster above, each year of back support pushed out of scope is $44,000.
Put both dates in writing before the first call, not after Oracle has drafted its position.
My Oracle Support Doc ID 1317265.1 ships options_packs_usage_statistics.sql. This is the script an Oracle LMS or GLAS data request points you at, and its output separates product level usage from feature level detail and flags the entries it knows to be bug driven.
Run it yourself, on every database, and read the output before you send anything. A buyer who has already reconciled that output against their own entitlement runs the meeting. A buyer seeing it for the first time on Oracle's screen does not.
It costs you the performance stack, not just the bill. This is the part the disable advice skips, and it is why estates flip the parameter, break a support case, and flip it back.
| Parameter value | Diagnostics features | Tuning features | What you give up |
|---|---|---|---|
| NONE | Blocked | Blocked | AWR snapshot collection, ADDM, ASH history in DBA_HIST_ACTIVE_SESS_HISTORY, Real Time SQL Monitoring, the Enterprise Manager performance pages and Performance Hub |
| DIAGNOSTIC | Permitted | Blocked | SQL Tuning Advisor, SQL Access Advisor, SQL Profiles, Real Time SQL Monitoring, the automatic SQL tuning task |
| DIAGNOSTIC+TUNING (shipped default) | Permitted | Permitted | Nothing, and you are carrying $12,500 per Processor of exposure |
Three consequences follow. DBMS_SQLTUNE calls return ORA-13717 once tuning access is blocked, so any in house script that calls the advisor breaks on the night you flip it.
The awrrpt.sql report has no snapshots left to report on, which lands the first time you open a severity 1 service request and Oracle Support asks for an AWR report you cannot produce. And DIAGNOSTIC is a real setting that most estates skip.
If you own Diagnostics and not Tuning, that middle value matches your entitlement exactly and keeps AWR alive. Very few estates ever set it.
Statspack ships with the database at no additional license cost, installs from spcreate.sql in $ORACLE_HOME/rdbms/admin, and is covered by My Oracle Support Doc ID 149113.1. It gives you snapshot based history without touching either pack.
Schedule snapshots at the interval your team actually reads, set a retention that matches your incident review window, and take one baseline snapshot before the change so you have a comparison point. A Statspack install nobody schedules is not a replacement.
Do not reach for STATISTICS_LEVEL set to BASIC as the control instead. It disables AWR as a side effect, but it also switches off timed statistics and a set of self management features you want, and it is a worse trade than the parameter built for the job.
Run this test per database, once, and record the answer with a date and an owner. It takes about two minutes per database and it is the artefact an auditor cannot argue with.
Sources: first two figures from the Redress Compliance advisory engagement file, 2024 to 2025. Third figure is 16 x $7,500 plus 16 x $5,000 from the Oracle Technology Global Price List.
The Diagnostics Pack is not bought. It is stumbled into. The control parameter is the cheapest license decision an Oracle DBA team can make.
Every Oracle rep and a fair number of DBAs land on the same recommendation: the packs are small next to the database, everyone ends up using them, buy them and stop worrying. That recommendation is priced for the seller.
In the estates we sweep, the packs are genuinely wanted by three or four people on a handful of servers, and recorded on everything else because the parameter shipped permissive and nobody edited the build image.
Covering the whole estate to legitimize a habit that lives on six databases is how a $12,500 per Processor add on becomes the second largest line on the Oracle invoice, behind the database itself.
The alternative takes about a week. Set NONE as the default in the DBCA template, promote a named and dated list of databases with a change record attached to each, buy for that list, and keep the list current.
It is also the best audit answer you will ever hand over, because it is short, it is dated, and it agrees with the view.
Defense starts with the control parameter and ends with a narrow, evidenced settlement scope. Everything between those two points is date work.
Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on every database that does not need the packs, and DIAGNOSTIC on the ones where you own Diagnostics but not Tuning. That stops the clock on new exposure the moment the ALTER SYSTEM lands.
Install Statspack on those databases first so the DBAs are not blind on Monday, then force a sampling run so the view carries a dated row proving the use stopped.
Pull the feature usage history. Separate deliberate, licensed use from accidental touches. Argue the accidental events down where the contract and facts allow.
The wording matters more than the volume of analysis behind it. These five lines, used in this order, have moved more money in our pack disputes than any spreadsheet.
A pack finding settled as a compliance purchase carries no future value and often lands at a worse rate than the same product bought inside a renewal. Where the timing allows, move the item into the next support renewal or the next order and buy it as a decision rather than a penalty.
Ask for the licensed list to be named on the ordering document, and ask for back support to be addressed explicitly rather than left implied. An unwritten understanding about historic use has a way of resurfacing at the next audit.
White Paper · Advisory
Oracle Database Options & Management Packs Licensing
The separately licensed options and packs that ship enabled by default, trigger on one click, and drive most Oracle audit findings, plus how feature usage is detected, prevented, and defended. Read it free.
The Diagnostics Pack is a per Processor management pack covering the Automatic Workload Repository, Active Session History, and Enterprise Manager performance pages. Any query against the AWR views counts as licensable use.
The Tuning Pack is a per Processor management pack covering the SQL Tuning Advisor and SQL Access Advisor. It requires the Diagnostics Pack as a prerequisite, so the two are almost always licensed together.
Both packs are enabled by default in Enterprise Edition. A DBA running an AWR report, opening an Enterprise Manager performance page, or running the tuning advisor consumes the pack without any separate installation.
Set the database parameter CONTROL_MANAGEMENT_PACK_ACCESS to NONE on every database that does not need the packs. Then restrict pack access inside Enterprise Manager so administrators cannot trigger use by accident.
Pack findings scale with the licensed Processor count, not usage frequency. A single AWR report on a sixteen Processor cluster can imply sixteen Processor licenses for each pack, plus back support.
Query the DBA_FEATURE_USAGE_STATISTICS view. It records which packs were used and when. This is the same data Oracle relies on in an audit, so reviewing it first removes the surprise.
No. AWR, ASH, and the automatic diagnostic monitor all require the Diagnostics Pack. Free alternatives such as Statspack exist for basic performance data without the pack, though with less depth.
It does if the collector reads AWR or ASH data. Many third party monitoring agents poll DBA_HIST views on a schedule, which produces continuous recorded usage with no human involved, so check what your agent queries and repoint it at the free V$ views.
Not by default. Buying estate wide because it is convenient turns a small need into a large bill. Disable the packs where they are not needed and license them only on the servers that genuinely require the advisory features.
Diagnostics Pack is $7,500 per Processor and $150 per Named User Plus. Tuning Pack is $5,000 per Processor and $100 per Named User Plus. Both are perpetual list prices from the Oracle Technology Global Price List before discount, with annual technical support adding 22 percent of the net license fee on top.
Oracle anchors back support to FIRST_USAGE_DATE in DBA_FEATURE_USAGE_STATISTICS. On a sixteen Processor cluster carrying both packs the license is $200,000 at list and support at 22 percent is $44,000 a year, so every year of back support argued out of scope is worth $44,000. Check whether the first usage date falls inside the current contract term before you concede anything.
Yes. NONE stops AWR snapshot collection, ADDM, ASH history, Real Time SQL Monitoring and the Enterprise Manager performance pages, and DBMS_SQLTUNE calls return ORA-13717. Install Statspack from spcreate.sql first so you still have performance history when Oracle Support asks for it.
No. Oracle ships no supported way to purge DBA_FEATURE_USAGE_STATISTICS or the WRI$_DBU_FEATURE_USAGE table beneath it, and it survives restart, upgrade and restore. Deleting rows by hand is unsupported and reads as destroyed evidence.
Yes. Reading AWR or ASH data on a readable standby is Diagnostics Pack use on that standby's own Processor count, in addition to the primary. Set the parameter on the standby as deliberately as you set it on production, and see our guidance on Oracle disaster recovery licensing for how the standby itself is licensed.
Every option and pack licenses on the full processor count of the database beneath it, and the two cheapest switch on by default. The worked math and the strip and prove playbook.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.