Oracle Diagnostic Pack and Tuning Pack: The Expert Licensing Guide

Why Diagnostic Pack and Tuning Pack Are the Most Dangerous Oracle Licences

There is no other area of Oracle licensing where the gap between "what customers think they have" and "what Oracle thinks they owe" is wider than with the Diagnostic Pack and Tuning Pack. These two management packs are not exotic, rarely-used features — they are the foundational performance monitoring and tuning tools that virtually every Oracle DBA uses daily. AWR snapshots, execution plan analysis, wait event histograms, SQL tuning recommendations — all of these originate from Diagnostic Pack or Tuning Pack features, and all of them create documented, timestamped evidence of usage that Oracle's LMS team will find and cite in an audit.

The commercial exposure is significant. At list price, the Diagnostic Pack costs $7,500 per processor per year (or $150,000 as a perpetual licence), and the Tuning Pack costs $5,000 per processor per year ($100,000 perpetual). On a 32-processor enterprise database environment, unlicensed Diagnostic and Tuning Pack usage represents $400,000 in potential retroactive claims per year — plus Oracle's standard support on top of that. Organisations that have been running unlicensed packs for five or more years face claims that can easily reach seven figures.

This guide is written from the perspective of ex-Oracle LMS auditors who have assessed hundreds of enterprise database environments. The patterns are highly predictable, the remediation is straightforward, and the commercial outcomes are far better for organisations that act proactively than for those who wait for Oracle to initiate an audit.

What Is the Oracle Diagnostic Pack?

The Oracle Diagnostic Pack is an add-on management capability for Oracle Database Enterprise Edition that provides advanced database health monitoring, performance baselining, and root cause analysis tools. It is not included in the base Enterprise Edition licence and must be purchased separately. It is not available for Standard Edition 2 under any circumstances.

Automatic Workload Repository (AWR)

AWR is the heart of the Diagnostic Pack. It is Oracle's built-in performance data warehouse, collecting and storing detailed database statistics at regular intervals — by default, every 60 minutes. AWR stores this data in the SYSAUX tablespace and retains it for 8 days by default. AWR provides the raw data that underpins virtually all performance analysis in Oracle Database EE environments: execution plans, wait events, SQL statistics, system-level metrics, and session activity.

Accessing AWR data — whether through Oracle Enterprise Manager, SQL*Plus queries against DBA_HIST_ views, or third-party tooling that reads those views — requires a Diagnostic Pack licence. AWR is also the data source for Oracle's pre-packaged AWR reports (awrrpt.sql), which are widely distributed in DBA toolkits and routinely run in environments without any consideration of the licensing implications.

Critically, AWR data collection begins automatically as soon as Oracle Database Enterprise Edition is installed. The MMON background process starts collecting snapshot data from the moment the database is first started. You do not need to explicitly enable AWR — it is on by default unless you set CONTROL_MANAGEMENT_PACK_ACCESS = NONE before the first startup. This means that in practice, every Enterprise Edition database that has ever been started without explicitly disabling pack access has AWR usage evidence recorded in DBA_FEATURE_USAGE_STATISTICS.

Active Session History (ASH)

Active Session History is a continuous sampling mechanism that records the state of every active database session once per second. This real-time granularity makes ASH invaluable for diagnosing transient performance events — bottlenecks that occur for 10–30 seconds and would never appear in AWR's 60-minute snapshots. The V$ACTIVE_SESSION_HISTORY view provides current in-memory ASH data, while the DBA_HIST_ACTIVE_SESS_HISTORY view provides the persisted historical view. Both require a Diagnostic Pack licence to query.

ASH data feeds into Oracle's performance dashboards in Enterprise Manager, the Real-Time SQL Monitoring feature, and multiple third-party monitoring tools. Any tool that reads V$ACTIVE_SESSION_HISTORY or DBA_HIST_ACTIVE_SESS_HISTORY — even for display purposes — is invoking a Diagnostic Pack feature.

Automatic Database Diagnostic Monitor (ADDM)

ADDM is Oracle's automated analysis engine that periodically analyses AWR snapshots and generates recommendations for resolving performance problems. ADDM runs automatically after each AWR snapshot is collected and stores its findings in the database. Viewing ADDM reports in Oracle Enterprise Manager or querying the DBA_ADVISOR_ views (specifically DBA_ADVISOR_TASKS where the advisor name is 'ADDM') constitutes Diagnostic Pack usage.

Like AWR collection, ADDM analysis runs automatically in the background on all EE databases unless explicitly disabled. Every ADDM analysis job recorded in DBA_FEATURE_USAGE_STATISTICS becomes potential evidence in an Oracle audit.

What Is the Oracle Tuning Pack?

The Tuning Pack extends the Diagnostic Pack with proactive, prescriptive SQL optimisation capabilities. You cannot purchase or use the Tuning Pack without also licensing the Diagnostic Pack — Oracle defines this as an explicit dependency in its licensing documentation. If Oracle finds Tuning Pack usage in an audit, it will claim both Diagnostic Pack and Tuning Pack fees.

SQL Tuning Advisor

SQL Tuning Advisor analyses individual SQL statements and recommends optimisation approaches — new indexes, SQL profiles, statistics refreshes, or query restructuring. It is invoked through Oracle Enterprise Manager's SQL Tuning page, through the DBMS_SQLTUNE package, and — critically — through Oracle's automated maintenance jobs. Oracle Database EE includes scheduled maintenance windows during which the automated SQL tuning job (which invokes SQL Tuning Advisor) runs automatically. Unless this job is explicitly disabled, it will run, generate Tuning Pack usage evidence, and potentially apply automatic SQL profiles without any DBA awareness.

SQL Access Advisor

SQL Access Advisor analyses a workload and recommends partitioning strategies, indexes, or materialized views to improve performance. It is invoked through Oracle Enterprise Manager or through the DBMS_ADVISOR package with the SQL Access Advisor type. Like SQL Tuning Advisor, it is part of Oracle's maintenance automation and can be triggered indirectly through tooling that the DBA may not associate with the Tuning Pack.

Automatic SQL Tuning

Automatic SQL Tuning is the continuous background process that runs SQL Tuning Advisor against high-load SQL statements identified in AWR and automatically implements SQL profiles when confident improvements are found. This feature runs as part of Oracle's maintenance automation with no explicit DBA action required. Organisations that have never touched Oracle Enterprise Manager may still have Automatic SQL Tuning evidence in their feature usage statistics simply because Oracle's default maintenance job scheduler has been executing in the background since installation.

Pricing: What Oracle Charges for These Packs

At Oracle's 2026 list prices, the Diagnostic Pack is available as a perpetual licence at $150,000 per processor, with annual support (at 22% of the licence fee) adding $33,000 per processor per year. That support fee increases by 8% per year — so a 32-processor environment paying $1,056,000 in Year 1 support will be paying approximately $1,437,000 in Year 5 support on Diagnostic Pack alone.

The Tuning Pack is priced at $100,000 per processor perpetual, with $22,000 annual support per processor. Combined Diagnostic and Tuning Pack support on a 32-processor environment is approximately $1,760,000 per year in Year 1, growing at 8% annually. Over a 5-year audit lookback period, the total claim for a 32-processor unlicensed environment can approach $10 million when retroactive licence fees, back-support charges, and interest are included in Oracle's settlement demand.

Enterprise discounts on packs are available — typically 40 to 60 percent off list in a competitive negotiation — but these are only achievable when negotiating proactively as part of a broader Oracle relationship discussion, not when responding to an audit claim under commercial pressure.

The CONTROL_MANAGEMENT_PACK_ACCESS Parameter: The Most Important Setting

Oracle provides a single database initialisation parameter — CONTROL_MANAGEMENT_PACK_ACCESS — that controls whether the Diagnostic Pack, the Tuning Pack, both, or neither are accessible. Understanding and correctly configuring this parameter is the most important single action in managing pack licensing compliance.

The parameter accepts three values:

• DIAGNOSTIC+TUNING (the default): Both packs are enabled. AWR collection, ASH sampling, ADDM analysis, SQL Tuning Advisor, SQL Access Advisor, and Automatic SQL Tuning are all active. Usage evidence accumulates continuously.
• DIAGNOSTIC: Only the Diagnostic Pack features are enabled. Tuning Pack features — SQL Tuning Advisor and SQL Access Advisor — are blocked. This is appropriate only if you have licensed the Diagnostic Pack but not the Tuning Pack.
• NONE: Both packs are disabled. AWR collection stops (existing data is retained but new snapshots are not collected). ASH continues to collect in memory (V$ACTIVE_SESSION_HISTORY) but is not persisted. ADDM does not run. SQL Tuning Advisor and SQL Access Advisor are blocked. DBA_FEATURE_USAGE_STATISTICS will no longer record new usage for these features.

Setting the parameter is straightforward and takes effect immediately without a database restart:

However, there are critical limitations to understand. First, this change stops future accumulation of usage evidence but does not erase historical evidence already in DBA_FEATURE_USAGE_STATISTICS. Oracle treats any historical usage as evidence of a licensing obligation for the period when usage was recorded — regardless of when you disable the parameter. Second, even with CONTROL_MANAGEMENT_PACK_ACCESS = NONE, certain features may still show residual usage. SQL profile presence in DBA_SQL_PROFILES (applied by SQL Tuning Advisor before the parameter was set) continues to show in feature usage statistics. Third, setting the parameter to NONE removes access to AWR and ASH data that DBAs rely on for performance management — organisations should have an alternative performance monitoring strategy in place before disabling pack access.

How Oracle Detects Unlicensed Pack Usage in Audits

Oracle LMS audits begin with a request to run Oracle's Collection Scripts — a set of SQL scripts that query your database environment and produce a data extract that Oracle reviews. The key view for pack detection is DBA_FEATURE_USAGE_STATISTICS, which records a row for every Oracle feature or pack that has been used on that database instance, along with the first use date, last use date, and total number of detections.

The pack-related features Oracle searches for in this view include AWR Snapshot, Active Session History, Automatic Database Diagnostic Monitor, SQL Tuning Advisor, SQL Access Advisor, and Automatic SQL Tuning. If any of these rows show a non-zero CURRENTLY_USED flag or a non-null LAST_USAGE_DATE, Oracle considers this evidence of usage and will claim the corresponding pack licence for the entire period between FIRST_USAGE_DATE and the audit date.

Oracle also reviews the STATISTICS_LEVEL parameter — if it is set to TYPICAL or ALL, AWR is collecting data and contributing to usage evidence regardless of CONTROL_MANAGEMENT_PACK_ACCESS. Additionally, Oracle reviews the presence of DBA_ADVISOR_TASKS entries for ADDM and SQL Tuning jobs, and the presence of accepted SQL profiles in DBA_SQL_PROFILES. Each of these provides corroborating evidence of pack usage that Oracle will include in its audit findings.

The Challenge of Historical Usage Evidence

A common and dangerous misconception is that setting CONTROL_MANAGEMENT_PACK_ACCESS = NONE after discovering pack usage will resolve the issue. It does not. Oracle's collection scripts will still find the historical FIRST_USAGE_DATE and LAST_USAGE_DATE entries in DBA_FEATURE_USAGE_STATISTICS, and Oracle will claim fees from the FIRST_USAGE_DATE regardless of what you have done since. The only effective approach to historical evidence is to engage experienced Oracle licensing counsel and prepare a structured negotiation position that accounts for the full historical scope — not to attempt to conceal or minimise evidence after the fact.

Alternatives to Oracle Diagnostic and Tuning Packs

The most commercially important insight about Diagnostic Pack and Tuning Pack is that Oracle DBA tooling has no technical obligation to use these features. Oracle's own documentation provides a range of alternatives that do not require pack licences:

V$ views (real-time) without AWR: V$SESSION, V$SQL, V$WAITSTAT, V$EVENT_NAME, and related dynamic performance views provide real-time session, SQL, and wait event data without requiring the Diagnostic Pack. These views have been part of Oracle Database since version 7 and provide substantial diagnostic capability for current-state analysis.

Statistics Level BASIC: Setting STATISTICS_LEVEL = BASIC disables AWR collection and most advisory framework collection, though it also disables some other database monitoring capabilities. This is a more aggressive approach than CONTROL_MANAGEMENT_PACK_ACCESS = NONE and is only appropriate in very specific environments.

Third-party monitoring tools: A significant ecosystem of Oracle performance monitoring tools — including Spotlight on Oracle, SolarWinds DPA, SevOne, and others — provides AWR-equivalent performance analysis by querying the non-pack V$ views without accessing DBA_HIST_ views. These tools can replace the majority of Oracle Enterprise Manager's performance monitoring functionality without triggering pack licensing obligations.

Oracle Enterprise Manager with pack access disabled: Oracle Enterprise Manager continues to function with CONTROL_MANAGEMENT_PACK_ACCESS = NONE — you retain access to the basic database administration, configuration, and alerting capabilities, but the performance analysis features (Performance Hub, SQL Monitoring, AWR reports) are disabled.

Negotiating a Pack Licence: What Good Looks Like

If your assessment confirms that Diagnostic Pack or Tuning Pack usage has occurred and you need to licence these features, there are several commercial structures to consider. A retrospective licence negotiation — one that addresses historical usage and provides prospective rights — should always be led by experienced Oracle licensing advisors rather than handled directly between your procurement team and Oracle's audit resolution group.

Oracle will typically open a settlement discussion with a claim based on list price for the full historical period. The realistic negotiated outcome is significantly better — typically 40 to 60 percent below Oracle's opening claim — but only if you approach the negotiation with documented evidence of your actual processor count, a clear understanding of the first and last usage dates, and credible commercial alternatives (including the option to disable the packs and purchase equivalent third-party tools instead of settling).

If you are currently a ULA customer and your ULA covers Oracle Database Enterprise Edition with management packs, your Diagnostic and Tuning Pack usage may already be covered by the ULA terms. Review your ULA contract carefully before engaging with Oracle on pack claims — and if your ULA is approaching certification, ensure you understand how pack licence quantities will be captured in the certification process.

For organisations negotiating a new Oracle agreement that includes EE Database licences, always include Diagnostic and Tuning Pack rights in the negotiation. Buying these packs at the time of the initial EE purchase — at the EE negotiated discount rate — is far cheaper than buying them retroactively under audit pressure at a higher blended rate.

The 5-Step Pre-Audit Pack Remediation Plan

For organisations that have identified pack usage without a corresponding licence and want to remediate before an Oracle audit, the following five-step approach provides the most commercially defensible outcome.

Step 1 — Quantify the exposure: Run a read-only query against DBA_FEATURE_USAGE_STATISTICS on every EE database in your estate. Record FIRST_USAGE_DATE, LAST_USAGE_DATE, and CURRENTLY_USED for all Diagnostic and Tuning Pack features. This establishes your true scope and timeline.

Step 2 — Count your processor exposure: Map each database to its physical host. Calculate your processor licence count using the Oracle Core Factor Table for each host. If databases are in VMware, calculate the exposure based on the full cluster unless approved hard partitioning is documented. This gives you the financial exposure figure.

Step 3 — Disable pack access immediately: Set CONTROL_MANAGEMENT_PACK_ACCESS = NONE on all unlicensed databases. This stops the ongoing accumulation of new usage evidence. Document the date and time of this change with a change management record.

Step 4 — Implement alternative monitoring: Identify which DBA workflows depended on pack features and replace them with non-pack alternatives — V$ view queries, third-party tooling, or simplified monitoring procedures. This ensures operational continuity without re-enabling pack access.

Step 5 — Prepare a negotiation strategy: Engage independent Oracle licensing advisors to review your exposure, model settlement scenarios, and prepare a commercial response if Oracle initiates an audit. A pre-positioned strategy delivers materially better outcomes than reacting to Oracle's initial claim without preparation.

Frequently Asked Questions

Does simply having Enterprise Manager installed create a pack obligation?

No. Oracle Enterprise Manager itself does not require a pack licence. The obligation arises from accessing pack-specific features within OEM — specifically the AWR-based performance views, SQL Tuning, and ADDM analysis. Basic database administration through OEM (patch management, configuration, alerts, jobs) does not require the Diagnostic or Tuning Pack.

Are Diagnostic and Tuning Packs available for Oracle Database Standard Edition 2?

No. These packs are only available for, and only applicable to, Oracle Database Enterprise Edition. SE2 cannot legally use Diagnostic or Tuning Pack features. If an SE2 database is found to have feature usage statistics for these packs, Oracle will typically claim that the database should have been licensed as EE — not merely that the packs need to be added to an SE2 licence.

If we set CONTROL_MANAGEMENT_PACK_ACCESS = NONE today, are we safe from Oracle's historical claims?

No. Setting the parameter stops future usage accumulation but does not remove historical evidence from DBA_FEATURE_USAGE_STATISTICS. Oracle's collection scripts will capture the historical FIRST_USAGE_DATE and LAST_USAGE_DATE data and will claim fees for the entire historical period. However, having disabled pack access before an audit does demonstrate good-faith remediation and can support a more favourable settlement negotiation.