Oracle Diagnostics Pack: The Accidental Compliance Trap Hitting 40% of Enterprises

What is Oracle Diagnostics Pack?

Oracle Diagnostics Pack is a separately licensed Oracle Database option that provides access to Oracle's most powerful performance diagnostics infrastructure. It is not a bolt-on product you install separately — it is a licence that unlocks features already built into Oracle Database Enterprise Edition. This is what makes accidental enablement so common: the features are present and operational by default; accessing them is what triggers the licence requirement.

Oracle Diagnostics Pack is priced at $7,500 per Named User Plus (minimum 25 NUP) or $19,800 per processor licence. Annual support adds 22% — approximately $4,356 per processor licence per year. For a 50-processor Oracle Database deployment, a retroactive Diagnostics Pack licence claim covering three years represents approximately $2.97M in licence fees plus $1.96M in back support — a $4.93M audit finding for a feature set your DBAs likely used without any awareness of the licence requirement.

Features That Require an Oracle Diagnostics Pack Licence

The following features in Oracle Database Enterprise Edition require a Diagnostics Pack licence. Oracle's position is that any use of these features — even a single query, even by a monitoring agent running in the background — constitutes consumption of the Diagnostics Pack and triggers the licence requirement for all processor licences on that database server.

Features that do NOT require Diagnostics Pack include: Statspack (Oracle's older, free performance tool), V$SESSION and basic V$ performance views, Oracle Enterprise Manager basic monitoring, and performance data collected purely from V$ views without accessing DBA_HIST_* tables. Statspack is the free, compliant alternative to AWR for environments without Diagnostics Pack licences.

Oracle Tuning Pack: The Companion Compliance Trap

Oracle Tuning Pack is a separate, additional-cost option that requires Diagnostics Pack as a prerequisite. It provides SQL Tuning Advisor, SQL Access Advisor, and Automatic SQL Tuning. Like Diagnostics Pack, its features are built into Oracle Database EE and are accessible to DBAs who have no awareness of the licence requirement.

Oracle Tuning Pack is priced at $7,500 per NUP or $19,800 per processor (same as Diagnostics Pack). In an Oracle LMS audit, it is standard practice for LMS to claim both Diagnostics Pack and Tuning Pack simultaneously — because the feature access pattern of a typical DBA environment includes both. The combined back-licence claim for Diagnostics Pack + Tuning Pack at $39,600 per processor across a 50-processor estate is $5.94M in licences before adding three years of back support at 22%.

How Oracle LMS Scripts Detect Diagnostics Pack Usage

Oracle's LMS audit scripts query the DBA_FEATURE_USAGE_STATISTICS view — Oracle's built-in feature tracking mechanism — to identify whether Diagnostics Pack and Tuning Pack features have been accessed. This view records every Oracle feature that has been used since database creation, with the most recent usage timestamp and total usage count. It cannot be retroactively cleared by the customer.

The feature usage tracking is automatic, passive, and persistent. Every time a DBA queries a DBA_HIST_* view, Oracle records this as AWR usage. Every time OEM's Performance Hub is opened, Oracle records this as Diagnostics Pack consumption. When Oracle LMS runs its USMM scripts, the DBA_FEATURE_USAGE_STATISTICS data is extracted and analysed centrally. The LMS team identifies the processor count of the server, cross-references against your licence entitlement, and presents the gap as an audit finding.

If this query returns rows with detected_usages > 0, Oracle will claim a Diagnostics Pack licence requirement for that database. The first_usage_date tells you how far back the usage goes — and Oracle will calculate back-support charges from that date. If the feature was first used three years ago, Oracle's claim covers three years of licence fees plus three years of support at 22%.

The CONTROL_MANAGEMENT_PACK_ACCESS Parameter

Oracle provides a database initialisation parameter — CONTROL_MANAGEMENT_PACK_ACCESS — that is intended to govern which management pack features are accessible. The possible values are DIAGNOSTIC+TUNING (the default), DIAGNOSTIC, and NONE. Setting this parameter to NONE is supposed to disable access to both Diagnostics Pack and Tuning Pack features and prevent their use.

The practical challenge is that this parameter was introduced to help customers manage their licence position — but Oracle's position during LMS audits is that historical usage recorded in DBA_FEATURE_USAGE_STATISTICS before the parameter was set still triggers a historical licence obligation. Setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE today does not retroactively eliminate the licence requirement for past usage. It only prevents future usage.

Furthermore, the parameter does not prevent all routes to Diagnostics Pack feature access. Certain monitoring agents, third-party observability tools, and Oracle Enterprise Manager plug-ins may continue to access AWR data even when the parameter is set to NONE. Effective remediation requires both parameter configuration and validation of all monitoring tooling against the DBA_FEATURE_USAGE_STATISTICS data.

The defensive approach is to set CONTROL_MANAGEMENT_PACK_ACCESS = NONE on all unlicensed databases immediately, document the date this was done, and then evaluate the historical usage period to determine the actual licence exposure. This establishes a clean going-forward position and limits the scope of any historical claim to the period before remediation.

The AWR Baseline Trap and Third-Party Monitoring Tools

Many enterprises discover their Diagnostics Pack exposure not through internal DBA activity, but through third-party monitoring and observability tools. Products from major monitoring vendors — APM tools, database performance monitoring platforms, infrastructure monitoring suites — frequently collect Oracle AWR data as part of their standard Oracle integration. The vendor's agent queries DBA_HIST_* views, populates its own dashboard, and records the usage in Oracle's DBA_FEATURE_USAGE_STATISTICS. Your DBA team may never have manually accessed AWR — yet Oracle's LMS scripts show years of Diagnostics Pack usage.

This creates a difficult negotiating position: the usage was generated by a tool your organisation legitimately deployed for infrastructure monitoring, without any intent to access Diagnostics Pack features. Oracle's position is that the intent is irrelevant — the feature was accessed, the licence was required. Challenging this position requires demonstrating the source of the usage, the absence of direct DBA-level AWR queries, and — in some cases — the vendor's own documentation of how their tool works.

If a third-party monitoring tool is the source of your Diagnostics Pack exposure, you may have a contractual claim against the monitoring vendor for misrepresenting their tool's Oracle licensing implications. This is a separate matter from the Oracle audit defence, but it can inform your overall posture and recovery options. Our Oracle Compliance Review identifies the source of all feature usage in your estate — distinguishing DBA-driven usage from automated tooling usage — which directly affects both the negotiating position and the remediation strategy.

Responding to an Oracle Diagnostics Pack Audit Claim

When Oracle's LMS team presents a Diagnostics Pack finding, the default claim will cover the maximum available period and apply list pricing. Before accepting, accepting, or negotiating from Oracle's stated position, there are several areas to challenge through forensic analysis of the usage data.

Challenge the usage period. Oracle calculates back-licence charges from the first_usage_date in DBA_FEATURE_USAGE_STATISTICS. But DBA_FEATURE_USAGE_STATISTICS can contain dates that reflect data migration, database clones, or AWR snapshot imports — not necessarily live usage. If a database was cloned from another environment and the AWR history was carried across, the first_usage_date may pre-date your actual use of the feature. Investigate whether the usage dates are genuine or artefactual.

Challenge the usage quantity. A single query against a DBA_HIST_* view that returns zero rows — perhaps from an automated script that checks whether AWR data exists — still records as detected usage. Challenge whether the usage represents meaningful consumption of Diagnostics Pack functionality or is artefactual tool activity with zero business value.

Challenge the pricing basis. Oracle's audit claims are presented at list price. Your actual contractual pricing for Oracle Database options may include the discount levels negotiated in your Master Agreement. Back-licence charges should be applied at your contracted discount level, not at list. This distinction alone can reduce the claim by 40-60%.

Use the audit settlement as a purchasing opportunity. Many Oracle Diagnostics Pack audit settlements result in the customer purchasing Diagnostics Pack licences at a negotiated price that is lower than the initial audit claim but includes a multi-year support commitment. If you have a genuine Diagnostics Pack usage requirement — if your DBAs need AWR and ADDM for performance management — buying licences at settlement pricing may be the best commercial outcome. Structure the negotiation to maximise the discount on both the back-licence fee and the going-forward licence price.

Remediation: Going-Forward Diagnostics Pack Compliance

For organisations that need AWR and ADDM functionality — and most large Oracle Database environments genuinely do — the remediation options are: purchase Diagnostics Pack licences for the databases that require the functionality, or migrate performance management to Statspack and eliminate Diagnostics Pack usage entirely.

Statspack is Oracle's older (pre-AWR) performance data collection tool. It provides much of the same data as AWR, collected on a scheduled basis rather than Oracle's continuous AWR collection. Statspack requires installation and configuration, and it does not have the same tight integration with ADDM and OEM's Performance Hub. But for environments where the primary need is SQL-level performance data and wait event analysis, Statspack provides adequate functionality without the Diagnostics Pack licence requirement.

For organisations that purchase Diagnostics Pack, structure the licence procurement to cover exactly the databases that require the functionality. Diagnostics Pack licensing is per-processor, and you are required to licence all processors on the server (not just those running databases that use AWR). This means consolidating Oracle workloads onto fewer, more densely utilised servers can reduce your Diagnostics Pack cost relative to a sprawling estate of lightly utilised Oracle servers.

Our Oracle Licence Optimisation service identifies the minimum Diagnostics Pack footprint required to support your operational needs — and restructures your Oracle environment to reduce the processor count in scope, minimising both the licence fee and the 22% annual support charge.