Oracle's Diagnostics Pack and Tuning Pack are, collectively, the single most common source of accidental Oracle Database license violations in enterprise environments. The mechanism is straightforward — and Oracle has designed it that way. Automatic Workload Repository (AWR) data collection begins as soon as Oracle Database Enterprise Edition is installed, and any DBA who has ever run an AWR report, accessed Active Session History, or configured Oracle Enterprise Manager to collect performance data has triggered Diagnostics Pack usage. The feature usage statistics in every Oracle Database record this access permanently. Oracle's LMS audit scripts find it in minutes. The back-license claim follows. This guide explains exactly what these packs cover, how they get accidentally enabled, and how to remediate the exposure.
Oracle Diagnostics Pack is an add-on option for Oracle Database Enterprise Edition that provides access to a suite of performance monitoring and diagnostic tools. At $10,000 per processor per year (subscription-style pricing through Oracle's license model), it is one of Oracle's most commercially significant database options — and also its most frequently used audit leverage point.
The Diagnostics Pack includes: Automatic Workload Repository (AWR) — Oracle's primary performance statistics repository; Active Session History (ASH) — in-memory session sampling that feeds AWR; Automatic Database Diagnostic Monitor (ADDM) — Oracle's automated performance analysis engine; Oracle Database Resource Manager (advanced features); AWR Compare Periods reports; AWR Baselines; and most of the performance-related v$ and DBA_ views that query AWR data. The critical point is that AWR data collection itself begins automatically when Oracle Database EE is started — there is no installation step required for AWR to be active. The Diagnostics Pack license is required if any of its features are accessed, not just if they are configured.
AWR Is Always Running: AWR snapshots are automatically taken every 60 minutes by the MMON background process in Oracle Database EE by default. This is independent of whether you have Diagnostics Pack. The license is triggered not by AWR collecting data, but by any user, tool, or script accessing AWR data — querying DBA_HIST_* views, running AWR reports, accessing performance pages in OEM, or any other consumption of AWR content. This is the distinction Oracle draws, and it makes accidental use almost inevitable in any actively managed database environment.
Oracle Tuning Pack is an add-on to the Diagnostics Pack — it is only available to customers who also license the Diagnostics Pack, and it adds specific query optimization and SQL analysis capabilities. At $5,000 per processor per year, the Tuning Pack is audited as a second layer of pack exposure, typically immediately after Diagnostics Pack usage is confirmed.
The Tuning Pack includes: SQL Tuning Advisor (the built-in SQL analysis tool accessible from both OEM and command line); SQL Access Advisor (index and materialised view recommendations); Automatic SQL Tuning (the background process that automatically analyses high-load SQL); SQL Profiles (persistent SQL execution plan modifications created by SQL Tuning Advisor); and SQL Plan Management (SPM) in its full automatic mode. The Tuning Pack is commonly activated whenever a DBA runs the SQL Tuning Advisor from Oracle Enterprise Manager's "Top SQL" screen — a routine performance troubleshooting workflow that automatically triggers Tuning Pack usage in OEM's default configuration.
Oracle Diagnostics Pack and Tuning Pack are priced as annual option licenses in addition to the base database license. The per-processor per-year pricing is based on the same processor count as the underlying Database EE license.
| Pack | List Price Per Processor/Year | 10 Processors / Year | 32 Processors / Year |
|---|---|---|---|
| Diagnostics Pack | $10,000 | $100,000 | $320,000 |
| Tuning Pack | $5,000 | $50,000 | $160,000 |
| Both Packs Combined | $15,000 | $150,000/yr | $480,000/yr |
In an Oracle audit scenario, pack claims are typically presented as back-license (historical unpaid license) plus support costs from the earliest documented date of usage — often stretching back 5–10 years based on DBA_FEATURE_USAGE_STATISTICS historical data. A 32-processor environment with 5 years of undocumented Diagnostics and Tuning Pack usage could generate an $2.4M back-license claim before negotiation. Our audit defense service has successfully challenged and reduced claims of this type across dozens of engagements.
Our compliance review runs the same queries Oracle's LMS team uses to identify pack usage — before Oracle does. Most environments we review have pack usage they were not aware of. Early detection gives you options. Waiting for the audit letter does not.
The most common path to accidental Diagnostics Pack compliance exposure follows a predictable pattern: a DBA troubleshoots a performance issue, opens an AWR report (or ADDM report, or ASH report), and Oracle records the feature access in DBA_FEATURE_USAGE_STATISTICS. This happens on day one of any actively managed Oracle Database EE environment. The DBA is unaware that this creates a license obligation. The obligation accumulates for years. Oracle's LMS team finds it in the audit.
The third-party monitoring tool scenario is particularly common and particularly difficult to defend against. When an organization connects a commercial monitoring tool to Oracle Database and the tool's Oracle integration queries AWR data for performance metrics, every poll creates a Diagnostics Pack usage event. The organization's DBA team may have no idea this is happening, and the monitoring tool vendor typically does not document which specific queries trigger Oracle license obligations.
Oracle Enterprise Manager (OEM / Cloud Control) is Oracle's own database management platform — and it is simultaneously one of the most powerful management tools available and one of the most aggressive sources of accidental pack usage. OEM's default configuration for managing Oracle Database EE databases enables Diagnostics Pack features automatically, without prompting for any license acknowledgement.
When an Oracle Database target is added to OEM with default monitoring settings, OEM immediately begins querying AWR for performance data, accessing ASH for session monitoring, running ADDM analysis, and displaying Performance Hub data — all of which are Diagnostics Pack features. Oracle has partially addressed this through its Management Pack controls in OEM (Settings → Management Packs), which allow administrators to configure which packs are enabled per target. However, the default state is packs-enabled, and many OEM deployments have never been reviewed for pack configuration.
Oracle's own documentation recommends configuring OEM Management Pack settings to match your licenced pack position. In practice, this guidance is frequently not implemented. Our compliance review service includes an OEM pack configuration audit as a standard component of any database license review.
Oracle records every feature usage event in the DBA_FEATURE_USAGE_STATISTICS view. This view is the authoritative source Oracle's LMS team uses to demonstrate pack usage in audit proceedings. Querying this view is the first step in any compliance assessment — and it must be done before any audit letter arrives, because post-audit remediation is much more limited in its impact.
SELECT name, version, detected_usages, total_samples,
first_usage_date, last_usage_date,
currently_used
FROM dba_feature_usage_statistics
WHERE name IN (
'Automatic Workload Repository',
'ADDM',
'Active Session History (ASH)',
'AWR Baseline',
'AWR Baseline Template',
'AWR Report'
)
ORDER BY last_usage_date DESC;
SELECT name, version, detected_usages, total_samples,
first_usage_date, last_usage_date,
currently_used
FROM dba_feature_usage_statistics
WHERE name IN (
'SQL Tuning Advisor',
'SQL Access Advisor',
'SQL Profile',
'Automatic SQL Tuning Advisor',
'SQL Plan Management'
)
ORDER BY last_usage_date DESC;
If DETECTED_USAGES > 0 for any of these features, Oracle's LMS team will assert that the pack was used — regardless of whether the access was intentional or whether the feature was only used once. The FIRST_USAGE_DATE establishes the earliest date from which back-license could be claimed. If the usage date is 5 years ago, Oracle will calculate back-license from that date. This is why early detection and remediation matter so much.
The complete set of features covered by each pack is longer than the examples above — our Oracle Diagnostics Pack Licensing guide includes the full feature list. For a comprehensive estate assessment, our compliance review service runs the full LMS script set against your environment.
Our comprehensive white paper includes the full Oracle LMS audit playbook — what scripts Oracle runs, what they look for, and how to prepare a complete defense against Diagnostics and Tuning Pack claims.
Once pack usage has been identified, the priority is to stop further usage and document the disablement. This serves two purposes: it eliminates ongoing accrual of license exposure, and it provides evidence for audit negotiations that the pack is no longer in use and back-license should not extend to the remediation date.
AWR snapshots can be disabled by setting the STATISTICS_LEVEL parameter to BASIC. At the BASIC level, Oracle does not collect AWR statistics. This eliminates AWR-based Diagnostics Pack feature usage going forward. However, setting STATISTICS_LEVEL to BASIC also disables the Cost-Based Optimizer's adaptive statistics and several other features — it should be tested carefully before applying to production databases.
-- Check current setting SELECT name, value FROM v$parameter WHERE name = 'statistics_level'; -- Disable AWR collection (requires restart or ALTER SYSTEM) -- WARNING: Test in non-production first — disables optimizer statistics collection ALTER SYSTEM SET statistics_level = BASIC SCOPE=BOTH; -- Confirm AWR snapshot interval (0 = disabled) SELECT snap_interval FROM dba_hist_wr_control;
In Oracle Enterprise Manager, disable Diagnostics Pack and Tuning Pack for each managed database target: navigate to Settings → Management Packs, select the database target, and set Diagnostics Pack and Tuning Pack to "Not Enabled." This prevents OEM from querying AWR and ASH data for those targets, eliminating the OEM-driven pack usage pathway.
For each third-party monitoring tool connected to Oracle Database, identify which Oracle views and queries it uses. Tools that query DBA_HIST_* or V$ACTIVE_SESSION_HISTORY need to be reconfigured to use non-AWR alternatives (V$ dynamic performance views, which do not require Diagnostics Pack) or the Oracle integration should be disabled if pack licenses are not being purchased. Most monitoring vendors can provide a list of queries their tools execute against Oracle Database.
When Oracle's LMS team presents a Diagnostics Pack or Tuning Pack claim based on DBA_FEATURE_USAGE_STATISTICS, the claim is not automatically valid or unchallenged. There are several legitimate lines of defense that our audit defense service has successfully deployed:
Oracle's feature usage statistics record any access to a feature, including automated system processes that trigger AWR sampling independently of human action. The mere fact that a usage event is recorded does not prove that the customer intentionally used the pack or derived commercial benefit from it. In cases where usage events are attributable to automatic Oracle background processes rather than DBA-directed queries, this distinction has supported reduced claims in negotiation.
If pack features have been disabled and no further usage events are recorded after a specific date, Oracle's back-license claim should in principle extend only to the period of actual use, not indefinitely. Documenting the remediation date and demonstrating clean feature usage statistics post-remediation supports a claim that back-license should not extend beyond the remediation date.
Oracle routinely settles pack-related back-license claims at a fraction of the calculated theoretical liability, particularly when the customer can demonstrate: the usage was unintentional, usage has been remediated, and the customer is willing to purchase pack licenses on a going-forward basis. Our audit defense team has negotiated settlements averaging 25–40% of Oracle's initial pack claim across multiple engagements. The Oracle Audit Negotiation guide covers this process in detail.
The most critical piece of audit defense guidance: do not respond to Oracle's LMS audit request without independent advisory. Any data you provide to Oracle, any admission of pack usage, and any discussion of remediation steps becomes part of Oracle's evidence base for calculating the back-license claim. See our guide to responding to an Oracle LMS audit letter.
Weekly briefings on Oracle audit trends, option licensing traps, and compliance risk management — from former Oracle insiders.
Our forensic compliance review runs the complete Oracle LMS script set against your estate — identifying all pack usage, quantifying back-license exposure, and delivering a remediation plan that closes the gap before any audit letter arrives.
Free Research
Download our Oracle SaaS Subscription Negotiation Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the SaaS Negotiation Guide →