One AWR report, and it prices like the whole estate
The Oracle Diagnostics Pack lists at 7,500 dollars per processor and the Tuning Pack at 5,000. Both cover tooling your DBAs already use, both switch on without an install, and both price on the licensed processor count of the database beneath them, never on how often the feature ran. That is why a single AWR report on a sixteen processor cluster is a 200,000 dollar finding at list, triggered by a report a contractor ran once and has since left.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on 30 to 38 Oracle management pack disputes worked 2024 to 2025.
Executive summary
The trap is one initialisation parameter, and it ships permissive. Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, so consumption starts before any purchase decision is made.
A single AWR report, one Enterprise Manager performance page, a query against a DBA_HIST view, or the nightly automatic tuning task is licensable use of the whole licensed processor count.
Neither pack is a product you install: both are code paths already compiled into the engine you are running, gated only by that parameter and by your contract.
The parameter is dynamic, so setting it to NONE takes effect without a restart, but nothing you do afterwards removes the usage rows already written.
Pack findings scale with licensed processors, never with how often the feature ran.
The metric has no usage dimension: there is no pack hour, no pack seat, no pack report, so a single use event covers the whole licensed server, not one session, and every node of a cluster counts including the failover target.
One AWR report on a sixteen processor cluster implies sixteen processors of each pack, which is 120,000 dollars of Diagnostics plus 80,000 of Tuning, 200,000 dollars of license before back support. Add three years of support at 22 percent and Oracle presents the finding as 332,000 dollars.
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.
The Tuning Pack cannot be bought alone, so the honest unit price of the SQL Tuning Advisor is 12,500 dollars per processor.
Diagnostics is a prerequisite for Tuning on every metric, so the two are almost always found together, and wanting the SQL Tuning Advisor means buying both at 7,500 plus 5,000 per processor.
Say that out loud in the first meeting, because it moves the item from a rounding error to a line the CFO has to see.
Oracle publishes no discount schedule for the packs; the discounts we observe track the database discount on the same order rather than beating it, so read the list column as the ceiling.
DBA_FEATURE_USAGE_STATISTICS is the entire case, it cannot be purged, and its date columns move the money.
The view records that a licensable code path executed, on which database, when first seen and when last seen, written by the MMON process on a weekly sample, and it survives instance restart, upgrade and RMAN restore.
FIRST_USAGE_DATE is how far back Oracle runs back support; LAST_USAGE_DATE is your side of the trade, because a last touch that predates the current term or the day you set NONE is a closed historic event, and each year pushed out of scope on the worked cluster is 44,000 dollars.
In four out of five estates the recorded usage could not be tied to any request, change ticket or purchase order, and in nine engagements the trail led to a monitoring agent, not a person.
What each pack covers, 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 |
| 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 |
The free set is larger than most DBA teams believe, and knowing it by name is what makes a NONE decision survivable.
Three grey edges produce most of the disagreement, so take a written position on each before the meeting: SQL Plan Management baselines are Enterprise Edition, but the automatic evolve advisor task can reach into tuning functionality depending on release.
Running Statspack is free even where AWR also runs, and it does not launder existing AWR usage; and querying AWR data on a readable standby is still Diagnostics use, on the standby's own processor count as well as the primary's.
Keep the Enterprise Manager packs, Database Lifecycle Management, Cloud Management, and Data Masking, in separate columns, because they are governed by the Enterprise Manager licensing manual, not the database one, and a finding that lumps them together is a finding you can split.
The Data Masking pack follows the same auto-enable pattern.
How the auto-enable trap works, and how it comes back
- The control parameter most buyers miss: CONTROL_MANAGEMENT_PACK_ACCESS takes NONE, DIAGNOSTIC or DIAGNOSTIC+TUNING, and Enterprise Edition ships at the permissive setting. ALTER SYSTEM SET control_management_pack_access='NONE' SCOPE=BOTH takes effect without a restart; set it in the spfile and in the DBCA template you clone from.
- The gold image: a DBCA template or VM template still carrying the shipped default reintroduces DIAGNOSTIC+TUNING on every new build, so the next database your pipeline provisions comes back permissive.
- The clone: an RMAN duplicate copies the source spfile and the source feature usage rows, so a refreshed test database arrives both permissive and pre-incriminated with the parent's history.
- The upgrade: a database upgrade that rebuilds the parameter file from a default template drops a non-default setting nobody re-applied afterward.
- The supplier: a managed service provider or monitoring vendor sets it back because their tooling needs AWR, and a third party agent polling DBA_HIST generates pack usage on databases no DBA has logged into. Put the parameter value in the contract schedule, not in an email. Setting NONE also removes AWR, ASH, ADDM and Real Time SQL Monitoring, so install Statspack in the same change window.
Oracle options and management packs
Why the options cost more than the database, how usage is detected, and the strip and prove playbook worked end to end.
Get the white paper →How Oracle turns one AWR report into a number
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, and nothing in that chain references how much you used the feature.
Take a two node RAC cluster, each node two sockets with an eight core Intel Xeon: 32 cores at the 0.5 Intel core factor is 16 processor licenses, so Diagnostics at 16 times 7,500 is 120,000, Tuning at 16 times 5,000 is 80,000, both packs 200,000 in license alone.
One year of support at 22 percent is 44,000, three years of back support is 132,000, and the finding as Oracle presents it is 332,000 dollars.
The trigger for that whole column can be one AWR report run once on one node by a contractor who has since left.
The Named User Plus floor is the one place the number sometimes falls: on 16 processors the minimum is 400 Named User Plus, so Diagnostics at 400 times 150 is 60,000 and Tuning at 400 times 100 is 40,000, both packs landing at 100,000 against 200,000 on the processor metric.
But it only holds if you can count and cap every human and device reaching the database, which on anything internet facing you cannot.
Check it on the back office clusters, where it survives contact with an auditor.
Then look for the three arithmetic errors that appeared in the first draft more often than not in our disputes: the core factor dropped so the sheet counts cores rather than processors and doubles the number on any 0.5 chip.
Decommissioned hosts still counted because feature usage rows survive the server, and clones counted as separate estates when the same DBID on four refreshed test databases is one history copied four times.
The core factor mechanics sit in the core factor analysis, and the full price stack in the Oracle price list.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle management pack disputes, 2024 to 2025
Between January 2024 and December 2025 Fredrik Filipsson worked 30 to 38 Oracle management pack disputes, and not one began with a customer deciding to buy the packs. They began with a shipped default and a script. The evidence base is one view, and it behaves in ways that decide the settlement:
Databases where CONTROL_MANAGEMENT_PACK_ACCESS sat at its permissive shipped value, including databases nobody had logged into in a year.
What each year of back support pushed out of scope was worth on the worked sixteen processor cluster. LAST_USAGE_DATE is the column that closes those years.
The view sits on WRI$_DBU_FEATURE_USAGE, sampled weekly by MMON, and setting the parameter to NONE this morning changes nothing in it until the next sample fires, so force one with DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING and bank a dated row showing CURRENTLY_USED as FALSE.
Oracle ships no supported purge, AWR retention does not reach the row, and deleting from the base table by hand is unsupported, visible, and converts a licensing argument into a conduct argument nobody wins.
Several things run themselves and get recorded: AWR takes a snapshot every 60 minutes under the default STATISTICS_LEVEL, so the Automatic Workload Repository row appears where no human ever opened a report.
AUTO_SQL_TUNING_TASK runs in the default maintenance window and consumes the Tuning Pack, so check DBA_AUTOTASK_CLIENT before accepting a Tuning finding as a human decision.
And DETECTED_USAGES counts samples, not people, so 200 is a weekly sampler that ran 200 times, not 200 reports, and an auditor presenting it as volume should be corrected on the record.
Run options_packs_usage_statistics.sql from My Oracle Support Doc ID 1317265.1 yourself, on every database, and read the output before you send anything, because a buyer who has reconciled that output against entitlement runs the meeting and a buyer seeing it first on Oracle's screen does not.
Your first five moves
- Run the usage query on every database this week and keep the output with a date, a hostname and the name of whoever ran it, filtering DBA_FEATURE_USAGE_STATISTICS for the AWR, ADDM, ASH, SQL Tuning and SQL Profile names.
- Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE in the spfile and the DBCA template, install Statspack in the same change window, and force a sample to bank a dated CURRENTLY_USED FALSE row.
- Switch the Enterprise Manager pack access off per target the same day, because the parameter protects the database and the console setting protects the person who can trigger a pack in one click.
- Close the four re-enable paths: the gold image, the clone, the upgrade, and the supplier, and put the parameter value in the contract schedule rather than an email.
- Pull FIRST_USAGE_DATE and LAST_USAGE_DATE before Oracle does, and check the core factor, the decommissioned hosts, and the cloned DBIDs in any worksheet. The Oracle practice runs the defense with you.
Frequently asked questions
How much do the Oracle Diagnostics and Tuning packs cost?
The Diagnostics Pack lists at 7,500 dollars per processor and the Tuning Pack at 5,000, both perpetual and before discount, on top of Enterprise Edition, with annual support at 22 percent of net license billed separately from the database.
On Named User Plus they are 150 and 100 per user under the 25 per processor minimum. Because the Tuning Pack requires the Diagnostics Pack, the honest unit price of the SQL Tuning Advisor is 12,500 dollars per processor, not 5,000.
Why does one AWR report create such a large finding?
Because the packs have no usage dimension: there is no pack hour, seat or report, so a single use event licenses the whole processor count of the database, and every node of a cluster counts including a failover target.
One AWR report on a sixteen processor cluster implies sixteen processors of each pack, 200,000 dollars in license, and Oracle adds three years of back support at 22 percent to present 332,000. The only levers are the processor count you can defensibly claim and the date range you can close.
How do the Diagnostics and Tuning packs get enabled by accident?
Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, the permissive value, so consumption starts before any purchase decision.
A default AWR report, an Enterprise Manager performance page, a DBA_HIST query, or the nightly AUTO_SQL_TUNING_TASK all record licensable use that week. They come back on through gold images, RMAN clones, upgrades that rebuild the parameter file, and monitoring agents whose tooling needs AWR.
Can you delete Oracle feature usage history?
No, and you should not try. Oracle ships no supported procedure to clear DBA_FEATURE_USAGE_STATISTICS, AWR retention does not reach it, and the row survives instance restart, database upgrade and RMAN restore.
Deleting from the underlying WRI$_DBU_FEATURE_USAGE table by hand is unsupported, visible, and in a dispute converts a licensing argument into a conduct argument nobody wins. The correct move is to set the parameter to NONE, force a sample, and bank a dated CURRENTLY_USED FALSE row.
What does setting the pack parameter to NONE cost you?
It removes AWR, ASH, ADDM and Real Time SQL Monitoring along with the packs, so install Statspack in the same change window to keep a free performance baseline, using the V$ dynamic views, the alert log and ADRCI, SQL trace with tkprof, and DBMS_XPLAN.DISPLAY_CURSOR for the tuning work.
The free set is larger than most DBA teams believe, which is exactly what makes a NONE decision survivable rather than a loss of capability.
How do you defend a Diagnostics or Tuning pack finding?
Pull FIRST_USAGE_DATE and LAST_USAGE_DATE before Oracle does, because a last touch that predates the current term or the day you set NONE is a closed historic event rather than an ongoing entitlement, and each year closed on a sixteen processor cluster is 44,000 dollars.
Then check the worksheet for the dropped core factor, decommissioned hosts still counted, and cloned DBIDs presented as separate estates, and keep options and packs on separate lines so the settlement stays auditable.
