Oracle Diagnostic Pack and Tuning Pack Licensing

1. Understanding Oracle Diagnostic and Tuning Packs

Oracle's Diagnostic Pack and Tuning Pack are add-on software packs that enhance database performance management. They are not included in the base Oracle Database licence — they must be purchased separately. They are only available for Oracle Database Enterprise Edition (EE); Standard Edition databases are not entitled to use these features without an upgrade to Enterprise Edition. For a comprehensive overview of all Oracle Database licensing models, see our Oracle Database Licensing Guide.

Diagnostic Pack

The Diagnostic Pack offers advanced monitoring tools to diagnose database health and performance bottlenecks. Key components include the Automatic Workload Repository (AWR), which collects and retains performance statistics; Active Session History (ASH), which provides real-time and historical session-level data; and the Automatic Database Diagnostic Monitor (ADDM), which analyses AWR data to identify problems and recommend solutions. These tools give DBAs deep visibility into what is happening inside the database — but every use triggers a licensing requirement.

Tuning Pack

The Tuning Pack provides SQL optimisation tools designed to resolve the performance issues identified by diagnostics. Key features include SQL Tuning Advisor, which analyses SQL statements and recommends execution plan improvements; SQL Access Advisor, which recommends index and materialised view changes; and SQL Plan Baselines, which lock in stable execution plans. Together with the Diagnostic Pack, the Tuning Pack offers a powerful — but expensive — performance management suite.

In practice, if a Standard Edition environment utilises Diagnostic Pack functionality — for example, a DBA running an AWR report — it would be considered out of compliance unless the database is licensed under Enterprise Edition with the packs. For a guide to other Oracle Database add-on options, see our guide on Oracle Data Masking and Subsetting Pack Licensing.

2. Licensing Model and Requirements

Oracle licences the Diagnostic Pack and Tuning Pack in the same way it licences the database itself. The packs' licensing metrics and quantities must exactly match those of the underlying database for each covered instance.

Per Processor Licence

This is the most common model for server or enterprise environments. You must licence every processor core of the database where the pack is used (after applying Oracle's core factor table, aligning with how your Oracle EE is licensed). If Processor licences cover your database EE, the packs must be licensed on all the same processors of that database server. For a detailed explanation of how Oracle processor licensing works, see the Oracle Technology Price List: How to Calculate Pricing.

Named User Plus (NUP) Licence

Suitable for environments with a defined user count, you must licence at least as many named users for the pack as the database has, with a minimum of 25 NUP per processor (per Oracle's minimum). For example, if an Oracle EE database is licensed for 100 named users, the Diagnostic and Tuning Packs must also be licensed for at least 100 users each. Mixing metrics is not allowed.

3. Pricing Structure and Cost Implications

Licensing these packs can significantly increase Oracle database ownership costs. The table below shows Oracle's approximate list pricing (perpetual licence) for on-premises use:

Pricing is approximate list price for perpetual licences; annual support (~20–22% of the licence price) is an additional recurring cost.

Enabling both packs can increase Oracle database licence fees by approximately 25%. For named-user licensing, the cost scales with user count (with a floor of 25 users per processor). Enterprises typically negotiate discounts, especially if purchasing packs alongside database licences or as part of a larger agreement — but the costs remain substantial.

Key Cost Drivers

Processor count is the primary multiplier — more cores means more licences. User count matters for NUP licensing, where even a small number of users requires meeting the 25-per-core minimum. Environment coverage is often overlooked: each database that utilises pack features requires licensing, including development and test instances. And maintenance fees (~22% per year) add a compounding layer: a Diagnostic Pack licence at $7,500 incurs approximately $1,650 in annual support alone.

4. Compliance Risks and Pitfalls

Oracle is known for strict licence compliance, and the Diagnostic and Tuning Packs are among the most common audit flashpoints. Understanding these pitfalls is essential. For a broader view of how Oracle audits work, see our Oracle Licence Audits: Strategic Guide for CIOs.

Inadvertent Usage

Many Oracle DBAs enable AWR or run Oracle's performance advisors habitually, unaware that these actions require pack licences. Oracle's audit scripts (e.g. querying DBA_FEATURE_USAGE_STATISTICS) will reveal the historical usage of pack features such as AWR snapshots or SQL Tuning Advisor runs. If your organisation hasn't purchased the packs for those databases, you are out of compliance. This "accidental usage" is a leading cause of surprise audit findings.

The Standard Edition Trap

Standard Edition databases are not allowed to use these packs. However, the software does not technically prevent it — a DBA might execute an AWR report on Standard Edition without realising the implication. In an audit, Oracle would treat that as unlicensed use of both the Enterprise Edition and the packs. The remedy would be a hefty purchase of EE licences and the packs for that server — a very expensive mistake. For a complete guide to SE2 restrictions, see our Oracle Database Standard Edition 2 Licensing Guide.

Metric Mismatch or Shortfall

If your database is licensed for eight processors but you have only licensed four processors' worth of Diagnostic Pack, that's non-compliance. All optional packs must match the licensed quantities of the database on each machine. Similarly, if you have 50 named user licences on the database, you cannot simply licence 10 users for the packs — the counts must align exactly.

Feature Enabled by Default

Certain Oracle features can inadvertently enable pack usage. The database parameter CONTROL_MANAGEMENT_PACK_ACCESS might be left at its default value of DIAGNOSTIC+TUNING on Enterprise Edition, meaning the database is actively collecting AWR data. If you didn't licence the packs, that default setting puts you out of compliance. It is crucial to set this parameter to NONE on unlicensed instances.

5. Optimising Usage and Alternatives

Many enterprises need the Diagnostic and Tuning Packs only on certain critical systems. Here are strategies to optimise costs and reduce risk:

Selective Deployment

Enable and licence only the packs on databases that genuinely require advanced performance features — typically mission-critical production systems that require constant tuning. For less critical environments (dev/test or small applications), keep the packs disabled to avoid unnecessary licensing costs.

Use Free Tools When Possible

Oracle provides Statspack (a free performance snapshot tool) as an alternative for basic monitoring in environments where you don't have the Diagnostic Pack. While Statspack is more manual and less feature-rich than AWR, it can help troubleshoot performance without incurring licence liability. Similarly, standard SQL tracing and manual tuning (using TKPROF and v$ views) can serve as alternatives to the Tuning Pack — albeit with more DBA effort.

Internal Auditing and Monitoring

Proactively run Oracle's feature usage queries or LMS scripts internally. Regular internal audits can detect if someone has enabled a pack feature. If you find it in use, you can take corrective action (disable it or procure a licence) before Oracle's official auditors do. This due diligence can save huge sums and strengthen your position in contract negotiations.

Align Licence Metrics

Optimise between processor vs. NUP licensing based on your environment. If you have a small, defined user population, Named User Plus licensing may be more cost-effective. For web applications or those with large user counts, processor licensing eliminates the need to count users. Select the model that yields the lower cost while meeting Oracle's rules, and ensure consistency between the database and packs.

Consider ULAs or Bundles

If your organisation expects to use Diagnostic/Tuning Packs widely (across many servers), consider negotiating an Oracle Unlimited Licence Agreement (ULA) or a bundle as part of an enterprise agreement. Oracle sometimes includes certain options in enterprise deals at a discount or allows an all-you-can-use ULA for a fixed fee. This provides cost predictability — however, be cautious of the certification process at ULA end.

Negotiate at Purchase Time

The best opportunity to get a discount on these packs is when making a larger purchase (e.g. buying a batch of database licences or renewing an enterprise agreement). Oracle sales representatives may offer better pricing for packs as part of a broader deal, whereas buying them individually later often means paying closer to list price. Enterprise ITAM professionals should forecast needs and incorporate optional packs into negotiations upfront.

6. Real-World Example: Avoiding a Costly Licensing Surprise

7. Recommendations (8 Expert Tips)

1. Audit Your Usage Regularly. Run Oracle's feature usage reports on all databases to identify any Diagnostic or Tuning Pack feature usage. Catching unauthorised use early lets you correct course before audits occur.
2. Disable Packs on Unlicensed Systems. Set Oracle's CONTROL_MANAGEMENT_PACK_ACCESS parameter to NONE on databases where you haven't purchased the packs. This prevents accidental use and keeps you safe.
3. Match Licence Metrics Precisely. Always licence the packs using the same metric (processor or NUP) and quantities as your database. If you scale up your DB licences (more cores or users), scale up the pack licences simultaneously.
4. Educate DBAs and Users. Ensure database administrators and developers understand what actions trigger licensing — running AWR, ADDM, or tuning advisors. Establish internal policies defining which environments are cleared for pack use and which are not.
5. Leverage Free Alternatives. Use Statspack and manual SQL tuning techniques on systems where you want to avoid buying packs. While less convenient, these tools can cover basic needs without incurring fees.
6. Strategise at Contract Time. If you anticipate needing these packs, negotiate them into your Oracle agreements upfront. Seek bundling into a broader deal for discounts, and consider a ULA if pack usage will be widespread.
7. Monitor and Document. Keep detailed records of which servers have pack licences and maintain proof (internal sign-offs, settings) that other servers have packs disabled. In an audit, this documentation demonstrates proactive compliance efforts.
8. Consider Third-Party Expertise. Engage Oracle licensing experts for periodic reviews or before true-ups. They can identify hidden usage and advise on the most cost-effective licensing approach — potentially saving significant money and headaches.

8. Checklist: 5 Actions to Take

9. FAQs