Oracle Diagnostics & Tuning Pack: How Accidental Use Creates Audit Exposure

The Hidden Licensing Landmine

Oracle Diagnostics Pack and Tuning Pack represent a category of licensing risk that most IT teams overlook until an audit begins. Unlike traditional database licenses that organizations deliberately purchase, these packs auto-enable on Enterprise Edition instances and accumulate usage data passively through Active Workload Repository snapshots collected every 60 minutes by default. When Oracle License Management Services (LMS) audits your infrastructure, their scripts query DBA_FEATURE_USAGE_STATISTICS and find evidence of pack usage dating back years. At that point, the "accidental" usage becomes a compliance violation, and Oracle demands licenses for every processor that ever touched those features, plus 22% annual backdated support fees.

These two packs are the single most common source of unplanned Oracle licensing costs in enterprise audits. In our experience advising 500+ organizations through Oracle audits, Diagnostics and Tuning Pack undercounting appears in roughly 70% of findings. The combination creates exposure because Tuning Pack actually requires a Diagnostics Pack license to function; you cannot license one without the other.

How Auto-Enablement Traps Organizations

The mechanics of this trap are straightforward. When you deploy Oracle Database Enterprise Edition, the parameter CONTROL_MANAGEMENT_PACK_ACCESS defaults to "DIAGNOSTIC+TUNING". This is not an explicit licensing choice. The system simply enables both packs automatically, and neither requires any action from the DBA to begin collecting data. Diagnostics Pack costs $7,500 per processor annually, while Tuning Pack adds $5,000 per processor on top of that. Combined, these reach $12,500 per processor per year, plus $2,750 per processor annual support fees if you want to keep the licenses current.

Once CONTROL_MANAGEMENT_PACK_ACCESS is set to "DIAGNOSTIC+TUNING", the database begins populating AWR snapshots continuously. By default, Oracle collects these snapshots every 60 minutes automatically. Each snapshot represents a data point proving that you accessed Diagnostics and Tuning features. A single AWR report created through the database's reporting interface creates a permanent audit trail in the data dictionary that LMS auditors will find.

The damage compounds because this happens in the background. DBAs rarely think about pack licensing when they run tuning reports or check AWR data. The features feel like part of the standard database functionality. Because Oracle does not enforce license checks at runtime, the database provides these features and allows you to consume them freely. Oracle's licensing model relies entirely on customer compliance. You are expected to have licenses before using the features, not the other way around.

What Oracle Auditors Actually Look For

Oracle LMS audits use scripted queries against a handful of data dictionary views to detect pack usage. The primary indicator is DBA_FEATURE_USAGE_STATISTICS, which logs every use of licensed features including Diagnostics Pack and Tuning Pack. When auditors compare your licensing inventory against this view, any mismatch becomes a finding. If the view shows usage of Diagnostics Pack features across 64 processors but your license documentation covers only 16 processors, Oracle will claim you owe licenses for the difference plus support back to the earliest usage date found in the statistics.

The historical nature of this view makes it especially dangerous. Feature usage statistics can go back several years depending on your database initialization and maintenance practices. When you disable a pack via CONTROL_MANAGEMENT_PACK_ACCESS, the existing usage records remain in the database. Oracle interprets these historical records as evidence of licensing obligation. This is why a single AWR report generated years ago can expose you: it proves you accessed the pack at some point in the past.

Organizations often underestimate the breadth of auditor access during LMS engagements. Beyond DBA_FEATURE_USAGE_STATISTICS, auditors run queries against v$database, v$instance, and inventory tables to cross-reference processor counts against your claimed licensed configurations. They also check for AWR tables and examine your database parameter files. Our Oracle audit risk assessment tool mimics these queries to help you identify exposure before auditors do.

Backdated Compliance Demands and Support Fee Shock

When Oracle finds pack usage without corresponding licenses, they will calculate exposure retroactively. If your database logs show you used Diagnostics Pack starting in 2019 but never purchased licenses, Oracle demands payment for 2019, 2020, 2021, and every year forward to the current date. On a 64-processor system, this means 64 processors times $7,500 per processor times 5 years of claimed unlicensed usage equals $2.4 million in immediate pack licenses.

The cost becomes even more severe when support fees apply. Oracle demands 22% annual support costs on all backdated licenses. This means the $2.4 million pack obligation generates an additional $528,000 in Year 1 support costs alone. Many organizations discover only at this stage that they cannot afford retroactive licensing. The conversation then shifts to negotiating a settlement, and not all negotiations succeed.

You can prevent this entirely by controlling what features your database actually uses. Setting CONTROL_MANAGEMENT_PACK_ACCESS to "NONE" disables both Diagnostics and Tuning packs immediately. This stops new AWR snapshots from being recorded and prevents future usage detection. However, it does not erase historical feature usage data already in DBA_FEATURE_USAGE_STATISTICS. If you take this step after years of automatic pack usage, you will still face audit findings for historical usage; you are only preventing future exposure.

Best Practices for Pack Licensing Compliance

The fundamental tactic is to make an explicit, documented decision about whether you need these packs. If you do not plan to use Diagnostics or Tuning features, document that decision and set CONTROL_MANAGEMENT_PACK_ACCESS to "NONE" across all your Enterprise Edition instances. This setting takes effect immediately and prevents new usage from being recorded.

If you do need these packs for legitimate tuning and diagnostic work, purchase the appropriate licenses before enabling the features. Keep your license documentation aligned with your actual processor counts and deployment footprint. Our Oracle CIO licensing playbook provides a framework for building this documentation.

For organizations with existing deployments already configured with CONTROL_MANAGEMENT_PACK_ACCESS set to "DIAGNOSTIC+TUNING", the audit risk assessment becomes critical. Query DBA_FEATURE_USAGE_STATISTICS directly on affected instances to see what date the feature first appears. This tells you the extent of historical exposure. If usage begins years ago and you have no licenses, your best course is to engage with Vendor Shield protection before inviting LMS into your environment. Vendor Shield provides negotiation support and helps establish realistic settlement positions when Oracle makes compliance demands.

Finally, understand that these packs fall into a category of Oracle offerings where the vendor's licensing position is deliberately aggressive. Diagnostics Pack and Tuning Pack are priced as premium add-ons, and Oracle expects you to have explicit licenses for them. There is no free tier, no included usage, and no grace period. If the feature is enabled on your database and produces usage data, Oracle interprets that as evidence of licensing obligation. The default configuration makes this nearly inevitable unless you take active steps to disable these packs.