Oracle Diagnostic Pack and Tuning Pack Licensing Advisory
Executive Summary: The Oracle Diagnostic Pack and Tuning Pack are optional add-ons for Oracle Database Enterprise Edition, providing powerful performance monitoring and tuning capabilities.
However, Oracle Diagnostic Pack and Tuning Pack licensing come with significant cost and compliance implications. IT asset managers must ensure these packs are correctly licensed (per processor or user) in line with their database licenses, as misuse can lead to substantial unbudgeted costs.
This advisory outlines how these packs are licensed, typical pitfalls (like inadvertent usage), cost drivers, and strategies to optimize licensing and avoid compliance issues.
Understanding Oracle Diagnostic and Tuning Packs
Oracle’s Diagnostic Pack and Tuning Pack are add-on software packs that enhance database performance management.
- Diagnostic Pack: Offers advanced monitoring tools (e.g., Automatic Workload Repository (AWR), Active Session History, ADDM) to diagnose database health and bottlenecks.
- Tuning Pack: Provides SQL optimization tools (e.g., SQL Tuning Advisor, SQL Access Advisor, SQL Plan Baselines) to resolve performance issues identified by diagnostics.
These packs are not included in the base Oracle Database license – 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.
In practice, if a Standard Edition environment utilizes Diagnostic Pack functionality, it would be considered out of compliance unless the database is licensed under EE with the packs.
Licensing Model and Requirements
Oracle licenses Diagnostic Pack and Tuning Pack in a similar way to its database licenses:
- Per Processor License: Common for server or enterprise environments. You must license every processor core of the database where the pack is used (after applying Oracle’s core factor, aligning with how your Oracle EE is licensed). If processor licenses your database EE, the packs must be licensed on all the same processors of that database server.
- Named User Plus (NUP) License: Suitable for environments with a defined user count. You must license at least as many named users for the pack as the database has (respecting Oracle’s minimum of 25 NUP per processor). For example, if an Oracle EE database is licensed for 100 named users, the Diagnostic and Tuning Packs must also be licensed for a minimum of 100 users each. Mixing metrics is not allowed – the packs’ licensing metric and quantities must exactly match those of the underlying database on each covered instance.
Tuning Pack requires Diagnostic Pack: Oracle has made the Diagnostics Pack a mandatory prerequisite for the Tuning Pack.
You cannot license or deploy Tuning Pack on a database unless Diagnostic Pack is also licensed for that database.
Essentially, if you want tuning features, you pay for both packs.
Licenses are typically sold as perpetual licenses (one-time purchases), with an annual support fee (approximately 22% of the license cost) for ongoing support and updates.
These packs need to be licensed per database instance where they are used. Simply installing Oracle Enterprise Manager or having the software present doesn’t incur cost – it’s the use of the pack features (e.g., running an AWR report or SQL Tuning Advisor) that triggers the licensing requirement.
Read Oracle Diagnostics Pack vs. Tuning Pack: Understanding Features, Differences, and Licensing Requirements.
Pricing Structure and Cost Implications
Licensing these packs can significantly increase Oracle database ownership costs. Oracle’s list pricing (perpetual license) for on-premises use is approximately:
| Oracle Software License | Per Processor List Price (USD) | Named User Plus Price (USD) |
|---|---|---|
| Database Enterprise Edition (EE) | $47,500 per processor | ~$950 per user (min 25 per proc) |
| Diagnostics Pack (add-on) | $7,500 per processor | ~$150 per user (min 25 per proc) |
| Tuning Pack (add-on) | $5,000 per processor | ~$100 per user (min 25 per proc) |
Pricing is an approximate list price for perpetual licenses; annual support (~20–22% of the license price) is an additional cost.
As shown, Oracle Diagnostic Pack and Tuning Pack licensing adds approximately $12,500 per processor (before discounts) to the base database license cost.
In other words, enabling both packs can increase the license fees for an Oracle database by about 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 licenses or as part of a larger agreement.
Nonetheless, the costs are substantial, and the ongoing support fees mean a recurring expense.
Cost drivers include:
- Processor Count: More cores = more licenses required. High-core servers drive up pack costs proportionally.
- User Count (for NUP licensing): Even a small number of users requires meeting the 25-per-core minimum, so small deployments on powerful servers may face high minimum costs.
- Environments Covered: Each database that utilizes pack features requires licensing. Using packs on multiple development and test instances can multiply costs.
- Maintenance Fees: Yearly support charges add to TCO. For example, a Diagnostic Pack license at $7,500 incurs approximately $1,650 in annual support.
Read Avoiding Oracle Diagnostics & Tuning Pack Licensing Pitfalls: A CIO Compliance Guide.
Compliance Risks and Pitfalls
Oracle is known for strict license compliance, and the Diagnostic and Tuning Packs are common audit flashpoints.
Key pitfalls to avoid:
- Inadvertent Usage: Many Oracle DBAs enable AWR or run Oracle’s performance advisors habitually, unaware that these actions require pack licenses. 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 organization hasn’t purchased the packs for those databases, you’re out of compliance. This “accidental usage” is a leading cause of surprise audit findings. - Standard Edition Trap: As noted, Standard Edition databases aren’t allowed to use these packs. However, the software might not technically prevent it – for instance, a DBA might execute an AWR report on Standard Edition. In an audit, Oracle would treat that as unlicensed use of Enterprise Edition and the packs. The remedy would be a hefty purchase of EE licenses and the packs for that server – a very expensive mistake for a small oversight.
- 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 licenses on the database, you cannot simply license 10 users for the packs – the counts must align.
- Feature Enabled by Default: Certain Oracle features can inadvertently enable pack usage. For example, the database parameter
control_management_pack_accessmight be left at “DIAGNOSTIC+TUNING” (the default on Enterprise Edition), meaning the database is actively collecting AWR data. If you didn’t license the packs, that default setting itself can put you in non-compliance unless no AWR snapshots are retained. It’s crucial to disable pack features on unlicensed instances (set that parameter to “NONE” if you don’t intend to use the packs). - Audits and Evidence: Oracle’s License Management Services (LMS) scripts retain historical evidence of pack usage. Even if you only used a pack feature briefly (e.g., one AWR report run two years ago), the audit can uncover it and require back licensing. Past usage doesn’t “expire” – you’re expected to have been licensed at the time of use.
Optimizing Usage and Alternatives
Many enterprises only truly need the Diagnostic and Tuning Packs on certain critical systems.
Here are strategies to optimize costs and reduce risk:
- Selective Deployment: Enable and license only the packs on databases that genuinely require the advanced performance features (e.g., mission-critical production systems that require constant tuning). For less critical environments (such as dev/test or small apps), 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 Diagnostic Pack. While Statspack is more manual and less feature-rich than AWR, it can help troubleshoot performance without incurring license liability. Similarly, standard SQL tracing and manual tuning can be used as alternatives to the Tuning Pack in some cases – albeit with more DBA effort.
- Internal Auditing & 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 usage, you can take corrective action (disable it, or procure a license) before Oracle’s official auditors do. This due diligence can save huge sums and strengthen your position in contract negotiations.
- Align License Metrics: Optimize between processor vs. NUP licensing based on your environment. For example, if you have a small, defined user population accessing the database, Named User Plus licensing may be more cost-effective than processor-based licensing. Conversely, for web applications or those with large user counts, processor licensing eliminates the complexity of counting users. Select the model that yields the lower cost while still meeting Oracle’s rules, and ensure consistency between the database and packs.
- Consider ULAs or Bundles: If your organization expects to use Diagnostic/Tuning Packs widely (across many servers or in an unrestricted manner), consider negotiating an Oracle Unlimited License 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 can provide cost predictability if the scope justifies it; however, be cautious of the certification at the ULA end.
- Negotiate at Purchase Time: The best opportunity to get a discount on these packs is when you’re making a larger purchase (e.g., buying a batch of database licenses or renewing an enterprise agreement). Oracle sales representatives may be willing to offer a better price for packs if they are part of a larger deal, whereas buying them individually later often means paying closer to the list price. Enterprise ITAM professionals should forecast needs and incorporate optional packs into negotiations upfront when possible.
Real-World Example: Avoiding a Costly Licensing Surprise
Anonymized Scenario: A global manufacturing firm underwent an Oracle license audit and discovered a costly oversight.
The company had eight Oracle Database EE servers (each with two processors) and purchased licenses for those, but never acquired the Diagnostic or Tuning Packs.
However, the DBA team had been routinely using Oracle’s AWR reports and SQL Tuning Advisor on all these systems to troubleshoot performance.
The Oracle audit report showed extensive unlicensed usage of Diagnostic and Tuning Pack features across all servers, amounting to an exposure of 16 processor licenses for Diagnostic Pack and 16 for Tuning Pack (matching the 16 total DB processors).
At list price, this translated to roughly $200,000 in license fees plus another ~$44,000/year in support that Oracle could claim for past and future years – a massive unplanned cost.
Fortunately, the company took swift action. They engaged a licensing consultant and opened discussions with Oracle.
By demonstrating that most tuning activity was only needed on 2 out of the 8 servers, they negotiated to purchase licenses for those two servers’ worth of packs (4 processor licenses each of Diagnostic and Tuning Pack) at a discount, totaling about $60,000, and agreed to cease use of the packs on the other systems.
They implemented strict controls: the control_management_pack_access Setting was disabled on non-licensed databases, and DBAs were trained to use alternative methods (like Statspack) on those systems.
The outcome was a significant reduction of the compliance penalty and a clear plan to remain in compliance.
This example highlights how easy it is to unknowingly fall foul of Oracle Diagnostic Pack and Tuning Pack licensing, and how an informed strategy can mitigate damage.
Recommendations (Oracle Packs)
- Audit Your Usage Regularly: Run Oracle’s feature usage reports on all databases to identify any Diagnostic or Tuning Pack feature usage. Catching unauthorized use early lets you correct course before audits occur.
- Disable Packs on Unlicensed Systems: Set Oracle’s management pack access parameter to “NONE” on databases where you haven’t purchased the packs. This prevents accidental use of pack features and keeps you safe.
- Match License Metrics Precisely: Always license the packs using the same metric (processor or NUP) and counts as your database. If you scale up your DB licenses (more cores or users), scale up the pack licenses simultaneously.
- Educate DBAs and Users: Ensure your database administrators and developers understand what actions trigger licensing (e.g., running AWR, ADDM, or tuning advisors). Establish internal policies to clearly define which environments are cleared for pack use and which are not.
- 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.
- Strategize at Contract Time: If you anticipate needing these packs, negotiate them in your Oracle agreements up front. Seek bundling into a broader deal for discounts, and consider an Unlimited License Agreement if pack usage will be widespread.
- Monitor and Document: Keep detailed records of which servers have pack licenses and maintain proof (internal sign-offs, settings) that other servers have packs disabled. In the event of an audit, this documentation demonstrates your proactive compliance efforts.
- 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 money and headaches.
Checklist: 5 Actions to Take
- Inventory Your Databases and Features: List all Oracle Database instances in your enterprise. For each, check the configuration (
v$optionor Oracle Enterprise Manager) to see if Diagnostic or Tuning Pack features are enabled or have been used (look at AWR retention, etc.). - Align Licenses with Usage: For any database using pack features, ensure you have corresponding licenses. If not, decide whether to purchase licenses for that instance or disable the features immediately. Remember that the Tuning Pack also requires Diagnostic Pack licensing.
- Configure Controls: Implement technical controls on databases where packs are not licensed – for example, disable management packs and remove access to AWR reports and tuning advisor scripts. This prevents well-intentioned staff from inadvertently using something they shouldn’t.
- Train and Communicate: Hold a workshop with DBAs and relevant IT staff to go over Oracle’s rules for Diagnostic and Tuning Packs. Communicate which environments are licensed for their use. Make it part of your onboarding for new DBAs and include reminders in internal documentation.
- Review and Negotiate Contracts: If an Oracle renewal or enterprise agreement is upcoming, review your future need for these packs. Engage procurement and vendors early to negotiate favorable terms. If you’ve curtailed usage to only what’s necessary, you’ll be in a strong position to purchase just the needed licenses (potentially at a discount) and avoid overspending.
FAQ (Oracle Packs Licensing)
Q: Can we license the Diagnostic or Tuning Pack for just some of the processors on a server?
A: No. Oracle requires that if you use a pack on a database, you must license all processors on which the database is running (just as you license the database itself). You cannot partially license an option on a subset of cores of an instance. It’s all or nothing for each database environment.
Q: Is it possible to use the Tuning Pack without buying the Diagnostic Pack?
A: No. The Tuning Pack cannot be used independently. Oracle’s policy is that you must have a Diagnostic Pack license for the database to enable Tuning Pack features. In essence, Tuning Pack rides on top of Diagnostic Pack – this is a strict prerequisite.
Q: How can I detect if my team accidentally used these packs on a database?
A: Oracle provides views like DBA_FEATURE_USAGE_STATISTICS and parameters like CONTROL_MANAGEMENT_PACK_ACCESS That shows feature usage. By querying those, you can determine if AWR snapshots have been taken, if ADDM or SQL advisors were run, and so on. Oracle’s official LMS audit scripts do this comprehensively. It’s wise to run those internally and review the output for any entries indicating use of “Diagnostics Pack” or “Tuning Pack” features.
Q: Are the Diagnostic and Tuning Packs included with Oracle’s cloud services?
A: When using Oracle Database in Oracle Cloud (e.g., Autonomous Database or Database Cloud Service), the Diagnostic and Tuning Pack functionalities are typically included without separate licensing. However, for on-premises deployments, you must license them separately. (Our focus here is on on-prem perpetual licensing, where these packs are add-ons.)
Q: What happens if we ignore this and Oracle finds unlicensed usage during an audit?
A: Oracle will likely issue a formal compliance notice requiring you to purchase the necessary licenses retroactively, potentially with backdated support fees. In some cases, they may impose penalties or require an immediate true-up. This can be very expensive (often hundreds of thousands of dollars or more, depending on the scope of usage). It’s better to proactively address any gaps – either by licensing the packs for the relevant systems or removing/disabling the usage – before it comes to an audit scenario.
