Oracle Enterprise Manager ships free base functionality alongside chargeable packs, and the boundary is recorded row by row in the feature-usage views. This page names the exact rows that create Diagnostic and Tuning Pack liability, quantifies the exposure, and tells you what to shut off first.
Oracle Enterprise Manager ships free base functionality alongside chargeable packs, and the boundary is recorded row by row in the feature-usage views. This page names the exact rows that create Diagnostic and Tuning Pack liability, quantifies the exposure, and tells you what to shut off first.
Two numbers frame this entire discussion. The Diagnostics Pack lists at roughly $7,500 per processor and the Tuning Pack at roughly $5,000 per processor, each carrying Oracle's standard 22% annual support uplift (Oracle Technology Price List, 2026). Because Tuning cannot exist without Diagnostics, the realistic combined list cost is about $12,500 per processor per year before support. On a modest sixteen-core Intel server (eight processors after the Core Factor Table), that is $100,000 in pack list price stacked on top of the database engine, and the packs alone represent more than 25% of the underlying Enterprise Edition Processor license (Making Data Meaningful, 2024).
List price is Oracle's opening position, not the settlement figure. Enterprise customers routinely negotiate 40% to 70% below list, and the price list's real job is to define the base for discount percentages and support fees. But an audit finding on packs is not priced at your negotiated discount, it is priced at list, backdated, and multiplied by every processor on the licensed server. That asymmetry is why the rows below matter more than the sticker price. This subpage sits under our broader guidance on how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill, and the pack signatures are the single most common finding we defend.
A single AWR report on a sixteen-processor cluster can imply sixteen processors of Diagnostics Pack, priced at list, not at your negotiated discount.
Enterprise Manager licensing has two layers, and Oracle does not draw the line where most DBAs assume it is. Basic monitoring and administration features are included with any Oracle software license or Support contract (Oracle EM Cloud Control 13c Licensing documentation). You can browse targets, run backups, manage users, and set metric thresholds without a pack. The advanced features are grouped into named packs (Diagnostics, Tuning, and others) that must be purchased separately, and the console gives no visible warning at the moment you cross the boundary.
The boundary is finer than the marketing implies. You can configure thresholds and view server-generated alerts for free, but the notifications tied to those alerts require a licensed pack (Oracle EM Cloud Control 13.4 Base Functionality documentation). The Performance Hub page, ASH Analytics, and any AWR or ADDM report generated from the console all sit behind the Diagnostics Pack (Pythian, 2022). In practice, the two most expensive clicks in Enterprise Manager are the Performance tab and the Generate AWR Report button, and neither is labelled as chargeable.
| Feature area | License status | Where it lives |
|---|---|---|
| Target browsing, backup, user admin | Free base functionality | EM base install |
| Metric thresholds and alert viewing | Free base functionality | EM base install |
| Alert notifications | Diagnostics Pack | EM notification rules |
| Performance Hub and ASH Analytics | Diagnostics Pack | EM Performance pages |
| AWR reports and ADDM findings | Diagnostics Pack | awrrpt.sql, DBA_HIST_*, EM console |
| SQL Tuning Advisor, SQL Access Advisor, SQL Plan Baselines | Tuning Pack (requires Diagnostics) | DBMS_SQLTUNE, EM Advisor Central |
Oracle requires the Diagnostics Pack as a mandatory prerequisite for the Tuning Pack. You cannot license or deploy Tuning on a database unless Diagnostics is also licensed for that same database (Redress Compliance, June 2025). There is no Tuning-Pack-only SKU. The dependency is not merely commercial, it is codified in the database engine: the documentation for CONTROL_MANAGEMENT_PACK_ACCESS states plainly that a license for DIAGNOSTIC is required for enabling the TUNING pack (Oracle Database 26 Reference).
In 25 years across this vendor's negotiations, the single most consistent budgeting error I see is a procurement team that priced only the Tuning Pack because the DBA asked for the SQL Tuning Advisor. The organization that wants the advisor on that eight-processor server pays for eight Diagnostics processors and eight Tuning processors, roughly $100,000 at list, not the $40,000 they scoped. Model both packs together or do not model at all.
Oracle's own accounting script, options_packs_usage_statistics.sql (the source behind My Oracle Support Doc 1317265.1), maps specific DBA_FEATURE_USAGE_STATISTICS rows to each pack. This is not interpretation, it is the vendor's own detection logic. If you want to know exactly what a licensing auditor will flag, read the row names, because the auditor runs the same query. Understanding the difference between how the two key columns are weighted is covered in DETECTED_USAGES vs CURRENTLY_USED, and it materially changes how you respond to each row.
The Diagnostics Pack signature rows include the following, taken directly from the script source (GitHub mirror of the MOS script):
The Tuning Pack rows include SQL Tuning Advisor, SQL Access Advisor, and SQL Profile activity. Any single row here that shows CURRENTLY_USED = Y or a non-zero DETECTED_USAGES count is a candidate finding. Detection focuses on three columns: DETECTED_USAGES (a cumulative count that never resets), CURRENTLY_USED (a Y/N flag for the most recent sample), and the CONTROL_MANAGEMENT_PACK_ACCESS parameter. If that parameter is left at its default of DIAGNOSTIC+TUNING, the database is configured to permit both packs, which auditors read as intent to use (Redress Compliance, June 2025).
The row names in Oracle's own usage script are the audit checklist. Read them before Oracle does, not after the LMS engagement letter arrives.
This is the mechanic that surprises people, so it deserves precise language. Running a single AWR report counts as licensable Diagnostics Pack use (Redress Compliance, August 2025). It does not matter that you ran it once, on one instance, to diagnose one incident three years ago. The Automatic Workload Repository row records the event, DETECTED_USAGES increments, and the count persists in history.
The reason the number gets large is scaling. 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 processors of each pack, because the packs price per processor at the same scale as the database engine. A single use event covers the whole licensed server, not one session. That is the difference between a $12,500 budget line and a $200,000 finding, and it is decided entirely by processor count.
Worse, the trap fires with no warning because the features are on by default. A fresh Enterprise Edition install begins taking hourly AWR snapshots automatically. The moment anyone runs awrrpt.sql, queries a DBA_HIST view, or clicks the Performance tab, feature-usage tracking records Diagnostics Pack activity (Oracle Licensing Experts, April 2026). None of these actions produces a warning that a chargeable option was just exercised. Even a bare SELECT against V$ACTIVE_SESSION_HISTORY or a DBA_HIST_* view triggers the requirement, per Oracle ACE Yuan Yao (May 2025), because Enterprise Edition does not automatically grant access to AWR and ASH data. Because a single touch can look identical to a full deployment in the raw counts, the ability to distinguish the two matters. Our guidance on using FIRST_USAGE_DATE and LAST_USAGE_DATE to prove a feature was touched once is the primary defense against a one-off snapshot being priced as permanent deployment.
Oracle's LMS audit scripts read the same DBA_FEATURE_USAGE_STATISTICS views that the free options_packs_usage_statistics.sql reads. The critical point is that the history persists. DETECTED_USAGES is cumulative and does not reset when you stop using the feature, and it does not reset when you drop the objects that caused it. This is the same behavior we document for other options in why partitioning shows as used even after you drop the partitioned tables. Turning the feature off going forward does not erase the recorded past.
There is one nuance that cuts both ways for the buyer. Feature-usage tracking samples on an interval, typically weekly, so a feature exercised entirely between samples may not be recorded at all. We cover this in the sampling gap analysis. That gap is not a defense you can engineer intentionally, but it does mean the recorded usage is a floor, not a complete inventory, and you should never volunteer usage the samples missed.
The sequence matters. Acting out of order either creates new findings or destroys the evidence you need to argue a small one down.
The strategic point for the buyer is this: the packs are among the easiest findings for Oracle to generate and among the most controllable for you to prevent, because the trigger is a documented list of rows and a single parameter. The organizations that get hurt are the ones that discover the rows during an audit. The ones that pay a fair number are the ones that read the rows on their own schedule, turn off what they do not use, and treat any remaining usage as a negotiation input rather than a confession.
Yes, at list price and at the full licensed processor count. Pack findings scale with the licensed processor count, not with how often the feature ran. A single awrrpt.sql execution on a sixteen-processor server records Diagnostics Pack usage that Oracle will price across all sixteen processors, so one report can imply a six-figure liability.
The primary rows are ADDM, Automatic Workload Repository, AWR Report, AWR Baseline, and AWR Baseline Template. Newer script versions add Baseline Adaptive Thresholds, Baseline Static Computations, and EM Performance Page. These come directly from Oracle's own options_packs_usage_statistics.sql, which is the same logic auditors apply.
No. Oracle mandates Diagnostics as a prerequisite for Tuning, and the dependency is enforced in the database engine itself through CONTROL_MANAGEMENT_PACK_ACCESS. If you need SQL Tuning Advisor, budget for both packs at roughly $12,500 per processor combined at list, not for Tuning alone.
Basic monitoring, backup, user administration, and viewing metric thresholds and alerts are free with any Oracle license or Support contract. Alert notifications, the Performance Hub, ASH Analytics, and AWR or ADDM report generation all require the Diagnostics Pack. The console does not warn you when you cross that line.
No. DETECTED_USAGES is cumulative and does not reset when you stop using a feature or drop the related objects. Setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE blocks future recording but leaves historical usage in place, which is why you should capture usage dates before making any changes.
Yes. Statspack provides snapshot-based performance data comparable to AWR without triggering the Diagnostics Pack feature-usage rows, and it ships free with the database. On instances where you have no Diagnostics entitlement, migrate your performance runbooks from awrrpt.sql to Statspack.
Every Oracle option and management pack licenses on the full processor count of the database beneath it. The worked math, the accidental-usage trap, and the strip-and-prove playboo
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.
