Contents
Key takeawaysWhat the packs costWhat each pack coversHow the packs get switched onHow a finding is pricedChecking your own usageWhat we saw in disputesWhat auditors sayContract terms to ask forWhat to do nextFAQThe Diagnostics Pack lists at $7,500 per processor and the Tuning Pack at $5,000. Both are on by default in Enterprise Edition and priced on the server's processor count, so one AWR report on a 16 processor cluster is a $200,000 list finding.
- Both packs are on by default. Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS at DIAGNOSTIC+TUNING, so usage is recorded before anyone decides to buy.
- Tuning costs $12,500 per processor in practice. The Tuning Pack requires the Diagnostics Pack, so the SQL Tuning Advisor means buying both packs.
- One use prices the whole server. The metric has no usage dimension, so a single AWR report licenses every processor on every node, including the failover target.
- Dates move more money than volume. Each year of back support closed with LAST_USAGE_DATE is worth $44,000 on a 16 processor cluster.
- The history cannot be purged. Set NONE, force a sample and keep a dated FALSE row instead of touching the base table.
- Check Oracle's worksheet for three errors. A missing core factor, retired hosts and cloned DBIDs appeared in most first drafts we reviewed.
Most Oracle Diagnostics and Tuning Pack findings start with a DBA doing ordinary work on a default install. The argument with Oracle is rarely about whether anyone used the packs. It is about how many processors Oracle can attach to that use, and for how many years.
What are the Oracle Diagnostics and Tuning Pack list prices?
The Diagnostics Pack lists at $7,500 per processor and the Tuning Pack at $5,000 per processor. Both are perpetual licenses sold on top of Database Enterprise Edition. Annual support is 22 percent of the net license fee and is billed separately from the database support line.
| Pack | Processor license | Support per processor, per year | Named User Plus license | Support per NUP, per year |
|---|---|---|---|---|
| Diagnostics Pack | $7,500 | $1,650 | $150 | $33 |
| Tuning Pack | $5,000 | $1,100 | $100 | $22 |
| Both packs together | $12,500 | $2,750 | $250 | $55 |
Named User Plus licensing follows the Enterprise Edition minimum of 25 users per processor, so the per user prices only help on small, closed user populations. The Oracle price list carries the database and option prices these sit next to.
Why does the SQL Tuning Advisor cost $12,500 per processor?
Oracle makes the Diagnostics Pack a prerequisite for the Tuning Pack on every metric. You cannot license Tuning alone, so a team that wants the SQL Tuning Advisor or SQL Profiles is buying both packs. The real unit price is $7,500 plus $5,000, or $12,500 per processor.
State that figure in the first internal meeting. At $5,000 the Tuning Pack looks like a rounding error in the database budget. At $12,500 per processor across a production cluster, it is a line the CFO has to approve.
What discount can you expect on the packs?
Oracle publishes no discount schedule for the packs. The discounts we observe track the database discount on the same order and do not beat it. Treat the list column as the ceiling for any pack quote or audit settlement, and ask for the pack lines at the same percentage off as the database lines.
Which Oracle editions can use the packs at all?
Only Enterprise Edition. Oracle's licensing documentation lists both packs as extra cost options for Enterprise Edition, and the Tuning Pack also requires the Diagnostics Pack. On every other edition the control parameter defaults to NONE, which is why Standard Edition 2 databases rarely produce a pack finding unless someone changed that setting.
Oracle's own cloud differs: Base Database Service Enterprise Edition and above, and Exadata Database Service, include both packs in the subscription.
How to Negotiate an Oracle ULA: No Price List, Just Your Business Case
What do the Diagnostics and Tuning Packs cover, and what is free?
The Diagnostics Pack covers the Automatic Workload Repository (AWR), Active Session History (ASH), ADDM and the Enterprise Manager performance pages. The Tuning Pack covers the SQL Tuning Advisor, SQL Profiles and the SQL Access Advisor. Most of these jobs have a free equivalent that uses no pack at all.
| 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. DBMS_XPLAN.DISPLAY_CURSOR shows the actual plan of a cursor in the shared pool with no pack involved. A team that knows these tools by name can accept a NONE setting and still diagnose a slow system.
Which gray areas cause most of the disagreement?
Three edges produce most arguments with Oracle's auditors. Take a written position on each before the first meeting.
- SQL Plan Management. Baselines are an Enterprise Edition feature, but the automatic evolve advisor task can reach into Tuning Pack functionality depending on the release. Check which release each database runs and whether the task is active.
- Statspack alongside AWR. Running Statspack is free even where AWR also runs. It does not clean up AWR usage that has already been recorded.
- Readable standby databases. Querying AWR data on a readable standby is still Diagnostics use, on the standby's own processor count as well as the primary's.
Do the Enterprise Manager packs follow the same rules?
They sit under a different document. Database Lifecycle Management, Cloud Management and Data Masking are Enterprise Manager packs governed by the Enterprise Manager licensing manual, while Diagnostics and Tuning are defined in the database licensing guide.
Keep them in separate worksheet columns, because a finding that lumps them together can be split and argued part by part. The Data Masking pack follows the same pattern of being enabled by default.
Oracle options and management packs guide
How pack and option usage is detected, what it costs at list, and how to prove it has stopped.
Get the white paper →How do the packs get switched on without anyone buying them?
Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, so pack features work from the first day. Neither pack is a product you install. Both are code paths already compiled into the database engine, gated only by that parameter and by your contract.
From that point, a single AWR report, one Enterprise Manager performance page, a query against a DBA_HIST view, or the nightly automatic tuning task counts as licensable use. It counts for the whole licensed processor count of the server. The parameter takes three values: NONE, DIAGNOSTIC and DIAGNOSTIC+TUNING.
What records pack usage when no person runs anything?
- AWR snapshots. Under the default STATISTICS_LEVEL, AWR takes a snapshot every 60 minutes, so a full performance history builds up in every Enterprise Edition database whether or not anyone opens a report. Any person, script or tool that later reads it records Diagnostics use.
- The automatic tuning task. AUTO_SQL_TUNING_TASK runs in the default maintenance window and consumes the Tuning Pack with no one asking for it.
- Monitoring agents. A third party agent polling DBA_HIST generates pack usage on databases no DBA has logged into.
- Enterprise Manager. A person with console access can trigger a pack page in one click on any target where pack access is still on.
How does the setting come back after you turn it off?
ALTER SYSTEM SET control_management_pack_access='NONE' SCOPE=BOTH takes effect without a restart. In a multitenant database it is set at the container level, because the parameter cannot be changed inside a pluggable database. It then comes back through four routes.
- The gold image. A DBCA template or VM template still carrying the shipped default brings back DIAGNOSTIC+TUNING on every new build, so the next database your pipeline provisions arrives with the packs on.
- The clone. An RMAN duplicate copies the source spfile and the source feature usage rows. A refreshed test database arrives with the packs on and with the parent's usage history already in it.
- The upgrade. An upgrade that rebuilds the parameter file from a default template drops a setting that was never applied again afterward.
- The supplier. A managed service provider or monitoring vendor sets it back because their tooling needs AWR. An email asking them to leave it alone will not hold up later, so write the parameter value into their contract schedule.
Setting NONE also removes AWR, ASH, ADDM and Real Time SQL Monitoring for your own DBAs. Install Statspack in the same change window so the team keeps a performance baseline. The step by step change is in our guide to suppressing the packs with CONTROL_MANAGEMENT_PACK_ACCESS.
How does Oracle turn one AWR report into a $332,000 finding?
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 calculation refers to how often the feature ran. The pack metric has no pack hour, pack seat or pack report, so one use event covers the whole licensed server.
Every node of a cluster counts, including the failover target. The table builds the number for a two node RAC cluster where each node has two sockets of eight core Intel Xeon chips.
| Step | Calculation | Result |
|---|---|---|
| Physical cores | 2 nodes x 2 sockets x 8 cores | 32 cores |
| Processor licenses | 32 cores x 0.5 Intel core factor | 16 processors |
| Diagnostics Pack | 16 x $7,500 | $120,000 |
| Tuning Pack | 16 x $5,000 | $80,000 |
| License subtotal | Both packs | $200,000 |
| One year of support | 22 percent of $200,000 | $44,000 |
| Back support | 3 years x $44,000 | $132,000 |
| Finding as Oracle presents it | License plus back support | $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. Only two inputs move the number: the processor count you can support with evidence, and the date range you can prove is closed. How often the feature ran does not appear anywhere in it.
Can Named User Plus licensing lower the finding?
Sometimes, and it is the one place the number can fall. On 16 processors the minimum is 400 Named User Plus. Diagnostics at 400 x $150 is $60,000 and Tuning at 400 x $100 is $40,000, so both packs come to $100,000 against $200,000 on the processor metric.
It only holds if you can count and cap every person and device using the database, which rules out internet facing systems (see why NUP fails on internet facing systems). Test it on back office clusters with a known user list. The pack count must match the database user count (see matching options and packs to database users).
Which errors should you look for in Oracle's worksheet?
Three arithmetic errors appeared in Oracle's first draft more often than not in our disputes.
- The core factor is missing. The sheet counts cores instead of processors, which doubles the number on any chip with a 0.5 factor. The mechanics are in our core factor analysis.
- Decommissioned hosts are still counted. Feature usage rows survive the server, so a database moved or retired years ago can still show up as a line.
- Clones are counted as separate databases. The same DBID on four refreshed test databases is one history copied four times, and it should be priced once.
What is each year of back support worth?
On the worked cluster, one year of back support is $44,000. FIRST_USAGE_DATE is how far back Oracle runs back support. LAST_USAGE_DATE is your side of the trade, because a last use that predates the current term, or the day you set NONE, marks a closed historic event and supports no ongoing license need.
Say the evidence closes two of the three years in the example. Back support falls from $132,000 to the single open year of $44,000, a reduction of $88,000, and the finding drops from $332,000 to $244,000 before any discount is discussed.
How do you check your own Diagnostics and Tuning Pack usage?
Run Oracle's own script before Oracle asks for its output. options_packs_usage_statistics.sql from My Oracle Support Doc ID 1317265.1 reports options and packs usage from DBA_FEATURE_USAGE_STATISTICS. Run it on every database, including test, standby and cloned copies, and read the output before you send anything to Oracle.
A buyer who has reconciled that output against entitlement runs the audit meeting. A buyer who sees it for the first time on Oracle's screen does not. Our note on running the feature usage report before the audit script sets out the sequence.
Which columns in DBA_FEATURE_USAGE_STATISTICS decide the outcome?
The view records that a licensable code path executed, on which database, and when it was first and last seen. It is written by the MMON process on a weekly sample and survives instance restart, upgrade and RMAN restore.
- NAME and DBID. Filter for the AWR, ADDM, ASH, SQL Tuning and SQL Profile feature names. The DBID tells you whether four rows are four databases or one cloned history.
- FIRST_USAGE_DATE. The date Oracle uses to start back support.
- LAST_USAGE_DATE. The date you use to close years. See first and last sample dates for how the sampling affects both.
- DETECTED_USAGES. The number of weekly samples in which the feature was seen. A value of 200 means the sampler found the feature 200 times; it says nothing about how many reports ran or who ran them.
- CURRENTLY_USED. TRUE or FALSE at the last sample. The difference from DETECTED_USAGES is covered in detected versus currently used.
Add two checks to the same pass. Run SHOW PARAMETER control_management_pack_access on each instance, and query DBA_AUTOTASK_CLIENT to see whether the sql tuning advisor client is enabled, because that answers most Tuning Pack findings before anyone argues about them.
Can you delete the feature usage history?
No, and you should not try. The view sits on WRI$_DBU_FEATURE_USAGE, Oracle ships no supported purge, and AWR retention does not reach the rows. Deleting from the base table by hand is unsupported and visible, and it turns a licensing argument into a conduct argument that neither side wins.
What you can do is create a dated record that usage has stopped. Setting the parameter to NONE this morning changes nothing in the view until the next weekly sample. Force one with DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING and keep the dated row showing CURRENTLY_USED as FALSE.
What have we seen in Oracle management pack disputes in 2024 and 2025?
Between January 2024 and December 2025, I worked on 30 to 38 Oracle management pack disputes. None of them began with a customer deciding to buy the packs. Every one traced back to a shipped default and a script run against it.
- 80 to 90 percent of databases still had CONTROL_MANAGEMENT_PACK_ACCESS at the shipped value, including databases no one had logged into for a year.
- In four out of five customers, the recorded pack usage could not be tied to any request, change ticket or purchase order.
- In nine engagements, the usage trail ended at a monitoring agent with no human login behind it.
The usage view proves that a licensed code path ran. It does not prove that anyone decided to buy it, and that gap is where most of these settlements are made.
Why is setting the parameter to NONE not the whole fix?
The usual advice is to set CONTROL_MANAGEMENT_PACK_ACCESS to NONE and consider the matter closed. We disagree. NONE stops new usage from that day, but the history stays in the view, and the setting can come back through a clone, an upgrade or a supplier without anyone noticing until the next audit.
Treat NONE as the start of a control. Put it in the spfile and every template, switch off pack access per target in Enterprise Manager, and write it into every supplier contract that touches the databases. Then add SHOW PARAMETER to the checklist for every upgrade and clone refresh, since those are the events that reset it.
What will Oracle's auditors say, and how should you answer?
Expect the same few arguments in most pack reviews. Each has a factual reply, and each reply works better with the script output already in hand.
| What the auditor says | What to say back |
|---|---|
| "DETECTED_USAGES shows 200 uses of AWR." | Ask which pricing rule uses that column. None does: the pack is priced per processor or per Named User Plus, so the count only proves the feature was seen, and the argument should move straight to processors and dates. |
| "The Tuning Pack was used, so your team chose to tune with it." | Show DBA_AUTOTASK_CLIENT and the maintenance window history. If AUTO_SQL_TUNING_TASK produced the usage, it came from a shipped default task, which matters when you negotiate the back support years. |
| "First use was years ago, so back support runs from that date." | Show LAST_USAGE_DATE and the dated FALSE sample. Usage that ended before the current term is a closed historic event, and the years in between are open to negotiation. |
| "These four databases each need their own licenses." | Show the DBIDs. Clones of one source carry one copied history, and retired hosts come off the worksheet. |
| "Buy the packs and we can apply a discount." | Ask for at least the discount on the database lines of the same order, and first confirm you need the packs at all. If the team can work with Statspack and NONE, argue the finding as closed historic use and refuse licenses for ongoing use you have already stopped. |
If the findings letter is already on your desk, our guide on how to challenge Oracle audit findings covers the formal response.
What contract terms should you ask for when you settle or buy the packs?
Settlements and new purchases are the two points where you can get written terms. Ask for these; Oracle may refuse some, but each one limits the next finding.
- A release tied to dates. The settlement should state that it covers all recorded Diagnostics and Tuning usage up to a named date, so the same rows cannot be raised again at the next audit.
- Named servers. List the servers and processor counts the pack licenses cover, so a later cluster expansion starts from an agreed base.
- Separate lines per pack. Diagnostics and Tuning on their own lines, apart from other options, so each can be priced, reviewed and audited on its own.
- Discount parity. Pack lines discounted by no less than the database lines they sit beside.
- Supplier obligations. In your managed service and monitoring contracts, the required value of CONTROL_MANAGEMENT_PACK_ACCESS and a duty to tell you before any change.
What does a 12 month cleanup plan look like?
If no audit is open, stop new usage fast and spread the rest over a year. Every week the parameter stays permissive can push LAST_USAGE_DATE forward, so the setting change comes first.
| When | What to do | Evidence to keep |
|---|---|---|
| Month one | Run the Doc ID 1317265.1 script everywhere, install Statspack, set NONE, force a sample | Dated script output per database and the CURRENTLY_USED FALSE row |
| Months two and three | Switch off Enterprise Manager pack access per target, fix DBCA and VM templates, update clone runbooks | Change tickets and a screenshot of each target's pack access page |
| By month six | Amend managed service and monitoring contracts, add SHOW PARAMETER to the upgrade runbook | Signed contract schedules naming the parameter value |
| Month 12 | Rerun the script on every database, including new builds and refreshed test copies | A second dated output showing no new LAST_USAGE_DATE after month one |
What to do next
- This week: run the usage query on every database. 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. Change the spfile and the DBCA template, install Statspack in the same change window, and force a sample to record a dated CURRENTLY_USED FALSE row.
- Switch off Enterprise Manager pack access per target the same day. The parameter protects the database, and the console setting stops a user from triggering a pack in one click.
- Close the four routes back. Fix the gold image, the clone process, the upgrade runbook and the supplier contracts, and put the parameter value in the contract schedule.
- Pull FIRST_USAGE_DATE and LAST_USAGE_DATE before Oracle does. Check any Oracle worksheet for a missing core factor, decommissioned hosts and cloned DBIDs.
- Get help before you reply. The Oracle practice works through the findings with you and prepares the evidence before the first meeting.
Want a second opinion on your Oracle position? Our Oracle licensing consultants are former Oracle insiders who now work only for buyers.
Frequently asked questions
How much do the Oracle Diagnostics and Tuning packs cost?
At list, $7,500 per processor for Diagnostics and $5,000 for Tuning, both perpetual and on top of Enterprise Edition, with support at 22 percent of the net fee each year. On Named User Plus they cost $150 and $100 per user, with a minimum of 25 users per processor. Tuning needs Diagnostics, so the working price is $12,500 per processor.
Why does one AWR report create such a large finding?
The packs are licensed per processor with no measure of how much they were used, so one report licenses the whole server and every cluster node. On a 16 processor cluster that is $200,000 of license. Oracle then adds three years of back support at 22 percent and presents $332,000. The processor count and the date range are what you can argue.
How do the Diagnostics and Tuning packs get enabled by accident?
They are never installed; the default parameter value in Enterprise Edition makes them available from day one. Routine DBA work such as an AWR report, a DBA_HIST query or an Enterprise Manager performance page records use. After you turn them off, gold images, RMAN clones, upgrades and monitoring suppliers are the usual ways they come back.
Can you delete Oracle feature usage history?
No. There is no supported procedure to clear DBA_FEATURE_USAGE_STATISTICS, and the rows survive restarts, upgrades and RMAN restores. Editing WRI$_DBU_FEATURE_USAGE by hand is unsupported and visible to an auditor. Stop new usage with the parameter, force a sample, and keep that dated FALSE row as your evidence that use ended.
What does setting the pack parameter to NONE cost you?
Your DBAs lose AWR, ASH, ADDM and Real Time SQL Monitoring. They keep Statspack, the V$ views, the alert log and ADRCI, SQL trace with tkprof, and DBMS_XPLAN.DISPLAY_CURSOR. For most teams that is enough for daily performance work, as long as Statspack is installed in the same change window.
How do you defend a Diagnostics or Tuning pack finding?
Start with your own copy of the usage data, and use LAST_USAGE_DATE to show which years are closed. Then rebuild Oracle's processor count server by server, removing retired hosts and duplicate clone histories and applying the core factor. Keep options and packs on separate lines so the settlement stays auditable.
Can Oracle Standard Edition 2 use AWR or the Diagnostics Pack?
No. Both packs are extra cost options for Enterprise Edition only, and on other editions CONTROL_MANAGEMENT_PACK_ACCESS defaults to NONE. Standard Edition 2 users rely on Statspack and the V$ views for performance data. If someone changed the parameter on an SE2 database, treat any recorded pack usage as a finding to investigate.