Oracle Diagnostics Pack vs. Tuning Pack: Understanding Features, Differences, and Licensing Requirements

Oracle Diagnostics Pack vs. Tuning Pack

Oracle’s Diagnostics Pack and Tuning Pack are complementary add-ons for Oracle Database Enterprise Edition that often confuse IT leaders.

This article demystifies the two packs by explaining what each does, how they differ, and their licensing requirements.

Aimed at CIOs, CTOs, and procurement heads, it provides a clear breakdown of Diagnostics Pack vs. Tuning Pack features, outlines when you might need one or both, and details the rules for licensing each pack (including Oracle’s prerequisite that you can’t use Tuning Pack without Diagnostics Pack).

By understanding these differences, enterprises can make informed decisions about which pack(s) to invest in for their database performance needs while remaining compliant.

Read Avoiding Oracle Diagnostics & Tuning Pack Licensing Pitfalls.

Overview: Oracle’s Performance Management Packs

Oracle Database Enterprise Edition provides basic functionality, but for advanced performance monitoring and tuning, Oracle offers two key management packs: the Diagnostics Pack and the Tuning Pack.

Both are powerful tools for database administrators to maintain and improve database performance.

However, they are sold separately from the base database license, and each serves a distinct purpose:

• Oracle Diagnostics Pack: Focused on monitoring, diagnostics, and historical performance data. It helps DBAs identify issues by collecting detailed performance statistics and providing analysis tools.
• Oracle Tuning Pack: Focused on SQL optimization and proactive tuning. It helps DBAs and developers improve performance by giving intelligent recommendations to optimize queries and indexes.

While they have different roles, these packs are often used together for a full performance management solution. It’s important to understand that the Tuning Pack builds upon the Diagnostics Pack – Oracle requires that you license the Diagnostics Pack as a prerequisite to using the Tuning Pack.

In other words, you can purchase the Diagnostics Pack independently (for robust monitoring), but you are not supposed to purchase the Tuning Pack alone. Legally, any use of Tuning Pack features requires both licenses.

Let’s delve into each pack’s capabilities and compare their licensing aspects.

Oracle Diagnostics Pack: Key Features and Benefits

The Diagnostics Pack provides a suite of tools to monitor the health and performance of your Oracle databases. Think of it as the “eyes and ears” of the database, continuously collecting data and diagnosing issues.

Key features include:

• Automatic Workload Repository (AWR): AWR is a built-in repository that regularly gathers and stores performance data (typically every hour). It retains this history (e.g., 7 days by default, extendable with more storage) so you can do historical analysis. DBAs can generate AWR reports to see resource usage, wait events, SQL statistics, etc., over time or for specific snapshot intervals.
  Benefit: Provides a detailed timeline of database performance. For example, if the database slowed down overnight, an AWR report can show what changed by comparing snapshots before and after the slowdown.
• Automatic Database Diagnostic Monitor (ADDM): ADDM automatically analyzes the AWR data after each snapshot and identifies the top performance bottlenecks. It provides findings and recommendations in plain language.
  Benefit: Saves time for DBAs by pinpointing issues (like “high IO waits due to missing index on table X”) and suggesting remedies, rather than the DBA manually combing through raw stats.
• Active Session History (ASH): ASH samples the state of active sessions in the database every second (or a configurable interval). This fine-grained data (a subset of which is also stored in AWR) helps analyze what sessions were doing at any moment, including what they were waiting on.
  Benefit: ASH data allows real-time or near-real-time insight into performance. If an incident occurs (e.g., queries hanging or CPU spiking), ASH data can reveal which session or SQL is the culprit and what resource it’s waiting for.
• Enterprise Manager Performance Pages: When you have Diagnostics Pack, Oracle Enterprise Manager (OEM) displays rich performance screens (like Performance Home, Top Activity, etc.). These interactive dashboards show live and historical performance metrics, database load, query timings, and more.
  Benefit: A visual, at-a-glance health check. Instead of running manual queries, a DBA can open OEM, see if the database is under stress, and drill down into specific problem areas via the GUI.
• Alerts and Thresholds: Diagnostics Pack enables advanced alerting in OEM for performance metrics. For example, you can set up that if average active sessions exceed a threshold or if a tablespace is running out of space (OEM uses AWR/ASH data), it triggers an alert.
  Benefit: Proactive problem management. The DBA team can be notified of issues before users call, and the alert often includes ADDM analysis of the problem.

In summary, the Diagnostics Pack is about detecting and diagnosing problems. It’s heavily centered on AWR as the foundational data and ADDM as the analysis engine. Organizations that need deep visibility into database behavior, especially over time, find Diagnostics Pack invaluable.

However, remember: using any of the above features (AWR, ADDM, ASH, OEM performance views) requires a Diagnostics Pack license for that database.

Oracle Tuning Pack: Key Features and Benefits

The Tuning Pack is more about resolving and optimizing – it provides tools to actively tune SQL statements and database objects to improve performance.

Some of its primary components are:

• SQL Tuning Advisor: This feature analyzes individual SQL statements and recommends actions to improve their execution. The advisor might suggest creating an index, restructuring the SQL, or gathering new statistics for a slow query. It can even sometimes generate a SQL Profile (auxiliary information that the optimizer can use to improve a plan).
  Benefit: Automates the expertise of a performance engineer. Instead of manually trial-and-error tuning a query, the DBA can get guided recommendations, saving time and potentially finding optimizations they might miss.
• SQL Access Advisor: This tool examines your database workload and suggests changes to data structures. Based on patterns in data access, it might recommend adding indexes, partitioning tables, creating materialized views, etc.
  Benefit: The Access Advisor helps improve overall database throughput by ensuring the right supporting structures are in place. For example, if many queries would benefit from an index on the CUSTOMER table’s REGION column, the Access Advisor will highlight that.
• Real-Time SQL Monitoring: When a long-running SQL or PL/SQL operation executes, Real-Time SQL Monitoring (accessible via OEM or APIs) shows its real-time progress and resource consumption. You can see which step of the execution plan is active, how many rows have been processed, CPU/memory usage, etc.
  Benefit: Great for troubleshooting why a critical SQL is running slowly while it’s running. A DBA can observe if it’s stuck on a full table scan or waiting on I/O, and take action (or at least better estimate completion time). This feature is crucial for reactive tuning during performance incidents.
• SQL Profile and SQL Plan Management Tools: The Tuning Pack includes capabilities to manage execution plans. For instance, it can suggest SQL Profiles (which you can use to influence the optimizer) or help create Baselines for plan stability (note: some plan management features are part of base EE, but the Tuning Pack extends them with automatic tuning tasks).
  Benefit: It ensures the database is optimized not only once but also stays optimized. It can prevent plan regressions by locking in known good plans or guiding the optimizer when generating new plans.

One key point: The Tuning Pack’s advisors depend on data from the Diagnostics Pack.

For example, the SQL Tuning Advisor will use information from AWR and the optimizer to find better plans. Real-Time SQL Monitoring uses instrumentation built into the database, enabled via the Diagnostics Pack. That’s why Oracle mandates the Diagnostics Pack license if you use the Tuning Pack – they are technically intertwined.

Licensing Requirements and Key Differences

From a licensing perspective, Oracle treats both packs similarly in many ways.

For example, both are licensed per Oracle Database instance, using either Processor or Named User Plus metrics (matching your DB license metric), and both must have license counts matching the database on which they’re used.

Here are the licensing essentials and differences:

• Enterprise Edition Only: Both packs can only be licensed on Oracle Database Enterprise Edition (EE). If you use Standard Edition (SE/SE2), you are not allowed (nor able) to use these packs. So, if a company runs EE for production and SE for test, the packs can only apply to the EE systems.
• Matching the Database License Metric: Use the same metric as your database. If the processor licenses your database, you will purchase pack licenses from the processor for the same number of processors. If your database is licensed by Named User Plus (NUP), you must license the packs by NUP. Oracle also enforces the minimum of 25 Named Users per processor rule for NUP on each pack, just like for the database. For example, suppose your database EE is on four processors. In that case, you need at least 100 NUP licenses for Diagnostics Pack (4×25) if you go with NUP metric – even if you have 50 users, Oracle’s minimum would force 100 in that case. The same count would then apply to Tuning Pack.
• Diagnostics Pack as Prerequisite: A critical difference in licensing is that you cannot license only the Tuning Pack. Oracle’s policy is that the Tuning Pack “requires” the Diagnostics Pack. Practically, when ordering, if you try to buy Tuning Pack licenses, Oracle (or their reseller) will typically remind you to include Diagnostics Pack licenses as well, unless you already own them for that same database environment. In license terms, if an Oracle audit finds you’re using Tuning Pack features, they will expect to see licenses for both packs for that database, so if you plan to use the Tuning Pack, budget for two licenses per DB: one for Diagnostics, one for Tuning (matching the quantities).
• Ability to License Diagnostics Pack Alone: You can, however, license Diagnostics Pack by itself. Some customers choose to do this if they want the monitoring and diagnostics capabilities, but are okay without the tuning automation. This could be a cost-saving move: Diagnostics Pack (with AWR/ADDM) gives much insight, and the team might handle tuning manually without the SQL advisors. Oracle permits this scenario. So you might have, for example, 10 databases where you license Diagnostics Pack, but you license Tuning Pack on only 5 of them (the ones where you actively need the advisors). That’s fine; whenever Tuning Pack is present, Diagnostics is too. And, on the databases where you didn’t license Tuning Pack, you must avoid using those tuning features.
• Cost Difference: List price-wise, Diagnostics Pack is typically more expensive than Tuning Pack. For instance, Oracle’s price list might say: Diagnostics Pack – $7,500 per processor, Tuning Pack – $5,000 per processor (prices can change, but this ballpark shows Diagnostics is ~50% more). This indicates Oracle sees more value (and demand) in the Diagnostics Pack. For Named User Plus, the prices are proportionally lower (with the standard minimums). So if cost is a concern, some companies first buy the Diagnostics Pack (higher cost but essential for baseline monitoring) and hold off on the Tuning Pack unless there’s a clear need.
• Feature Separation: In terms of features, Oracle delineates which pack covers what. As a rule of thumb:
  • All the monitoring, data collection, and reactive analysis features (AWR, ADDM, ASH, performance pages) fall under Diagnostics Pack.
  • All the advisory, optimization, and proactive tuning features (SQL Tuning Advisor, SQL Access Advisor, SQL monitoring) fall under Tuning Pack, but with the caveat that Diagnostics Pack must also function fully.

Here’s a quick reference comparing the two:

“Prerequisite” under Diagnostics Pack means that a feature uses Diagnostic Pack data; therefore, Diagnostic Pack must be licensed if that feature is used. In effect, Tuning Pack features also demand a Diagnostics Pack license.

If you have both packs licensed, you’ll use them together seamlessly. If you have only the Diagnostics Pack, your DBAs can still manually tune SQL (just without the advisor’s help) and use third-party tools or their expertise to fill the gap.

If you attempted to use Tuning Pack features without Diagnostics, aside from licensing violation, you might find some things don’t work fully because AWR might be disabled – it’s not a scenario Oracle supports.

When Do You Need Each Pack?

Determining which pack you need (or both) comes down to your organization’s requirements and resources:

• Diagnostics Pack Only – When Monitoring is the Priority: If your main goal is to keep the databases running smoothly, diagnose issues quickly, and have skilled DBAs who can interpret data and do manual tuning, the Diagnostics Pack alone might suffice. Many enterprises start here. Diagnostics Pack will let your team see what’s going wrong when the database misbehaves. For example, AWR and ADDM will identify the top queries or bottlenecks if you have a performance slowdown. A good DBA can take that information and fix issues (rewrite a query, add an index) without the Tuning Pack’s automated suggestions. Choose Diagnostics Pack if you value visibility and root cause analysis, and if your team can handle tuning with the information provided.
• Tuning Pack (with Diagnostics) – When Optimization Needs Automation: Consider adding Tuning Pack to proactively optimize SQL and reduce manual effort in tuning. This is especially useful if you have many applications or hundreds of SQLs where manual review would be too time-consuming. Tuning Pack shines in environments where performance is critical and you can’t afford lengthy trial and error. For instance, if you’re running a large ERP or data warehouse and periodically need to tune complex queries, the SQL Tuning Advisor can greatly speed up that process. It’s also helpful if your team might not have deep expertise in Oracle SQL optimization – the advisor essentially packages Oracle’s expert knowledge. Organizations with both packs can set up regular tuning tasks (Oracle can run nightly tuning for top SQLs and flag those for review). Go for the Tuning Pack if maximizing performance is a top priority and you want to leverage Oracle’s automation to assist your DBAs.
• Neither Pack—When to skip? It’s worth noting that some smaller Oracle users or those with less intense performance requirements might use neither pack (to save cost). They rely on basic built-in views and scripts or third-party monitoring tools. This can work if your workloads are stable, you rarely have performance issues, or your budget is extremely tight. However, medium to large enterprises usually find that Diagnostics Pack at least pays for itself by reducing downtime and troubleshooting time.
• Phased Approach: You can adopt a phased approach: license Diagnostics Pack first, evaluate how often tuning advice is needed beyond what your team can deduce. If your DBAs frequently spend hours tuning queries and could benefit from Oracle’s advisors, you can invest in the Tuning Pack. Since Tuning Pack is the lower-cost of the two, adding it later is straightforward (just remember you can’t do it the other way around – you wouldn’t add Tuning without having Diagnostics already).
• By Environment: Some companies license both packs for production (where performance is mission-critical and downtime is costly), but only the Diagnostics Pack for certain non-production or secondary systems to save money. For example, you might want the ability to troubleshoot test environments with AWR data (so Diagnostics Pack there). Still, you might not need the tuning advisors in test, assuming the heavy lifting for tuning happens in prod or pre-prod. This mix-and-match is a way to balance cost and benefit.

Staying Compliant with Both Packs

If you decide to use either or both packs, ensure compliance by:

• Tracking usage: Document which databases have which pack enabled. Oracle’s contracts require that the usage of packs is licensed on a per-instance basis. There’s no “floating” license concept; you can’t, for example, use one Diagnostics Pack license on DB1 today and tomorrow on DB2 – each database using it needs its license (unless you uninstall from one and move it, but you can’t use it on two databases).
• Software controls: As discussed, use the CONTROL_MANAGEMENT_PACK_ACCESS parameter to enforce that only the packs you’ve licensed are active. For instance, if you bought the Diagnostics Pack but not the Tuning Pack on a DB, you can set CONTROL_MANAGEMENT_PACK_ACCESS = DIAGNOSTIC it to allow Diagnostics Pack but not Tuning Pack features. This prevents accidental use of a Tuning Pack feature you didn’t license.
• License equal to Database footprint: Remember that licensing is tied to the database’s size. If you add CPU cores to a server or add users (in NUP terms), you likely need to true-up both your DB licenses and the pack licenses. Always maintain that 1:1 correspondence in scale. If a database grows from 4 processors to 8, your Diagnostics and Tuning Pack licenses should be doubled accordingly.

Understanding the distinct roles and requirements of Diagnostics Pack vs. Tuning Pack can help you better plan your Oracle licensing strategy. The key is to pay only for what you need and not hamstring your DBAs by denying them critical tools.

Many enterprises find value in the Diagnostics Pack for keeping systems healthy, and use the Tuning Pack more selectively for major optimization efforts.

Recommendations

• Assess Your Performance Needs: Before buying, evaluate whether your team needs performance monitoring (Diagnostics Pack) or automated tuning help (Tuning Pack). Align the purchase with actual pain points – e.g., frequent performance firefights justify Diagnostics Pack; numerous complex SQL issues might justify Tuning Pack.
• Start with Diagnostics Pack if Unsure: If the budget is constrained, start by licensing the Diagnostics Pack. It provides immediate value through AWR and ADDM. You can add the Tuning Pack later if you find a strong need for its advisors. This staged approach can prevent overspending on features you might not use extensively.
• Always License Tuning Pack with Diagnostics: If you decide a Tuning Pack is needed, remember to license Diagnostics Pack for the same databases. Never enable Tuning Pack features without confirming you have an equal number of Diagnostics Pack licenses in place—it’s both a compliance requirement and necessary for the features to function correctly.
• Match the License Metric: Use the same metric as your Database (Processor vs Named User Plus) for pack licenses. Monitor your user counts for NUP and apply Oracle’s 25-per-core minimum rule. For the Processor, keep track of core counts and factors. This ensures you remain compliant and avoids any mix-up (Oracle will flag if your packs aren’t licensed the same way as the DB).
• Leverage Pack Features Fully (If Paid): Once you invest in a pack, ensure your team uses it fully. For example, if you bought the Diagnostics Pack, schedule regular AWR analysis and use ADDM reports in your performance reviews. If you bought the Tuning Pack, incorporate SQL Tuning Advisor into your development and QA cycles for query optimization. Maximize the ROI of the licenses by utilizing the tools in day-to-day operations.
• Consider Training for DBAs: Oracle’s pack features are powerful but have a learning curve. Ensure your DBAs are trained to use AWR reports, interpret ADDM findings, and run the tuning advisors. The more proficient they are, the more value you’ll get from the packs (and the more justified the licensing cost becomes). Oracle and third parties offer training courses focused on performance tuning with these packs.
• Use Controls to Prevent Misuse: On databases where you only license one of the packs, configure the system to prevent use of the unlicensed one. For instance, if only the Diagnostics Pack is licensed, set the management pack access to “DIAGNOSTIC” so tuning features are off-limits. This protects you from accidental non-compliance.
• Monitor Feature Usage Regularly: It’s good practice to monitor how often the features are used, even when licensed. This can inform future decisions – if you see that the Tuning Pack’s advisors are barely used, you might reconsider renewing that support or license for certain environments. Conversely, heavy usage of the Diagnostics Pack might prompt you to expand it to more systems. Use Oracle’s feature usage metrics to gauge utilization.
• Evaluate Cost vs. Benefit Periodically: The database environment and team skills can evolve. Reassess whether the packs you’ve licensed are still needed at the same level every year or two. Maybe your team developed internal tools or switched to a different monitoring system, reducing reliance on Diagnostics Pack—or maybe your systems got more complex, increasing the need for tuning automation. Adjust your licensing (in compliance with Oracle’s policies) during renewal or negotiation periods.
• Keep an Eye on Oracle Bundling: Oracle sometimes offers these packs bundled in broader offerings (for example, certain Oracle Cloud services include them, or Oracle may have promotions). Stay informed about Oracle’s product updates – for instance, if Oracle were to introduce a new “Performance Pack” or adjust how packs are sold, you’d want to know. This could potentially provide more cost-effective options or require relicensing decisions.
• Plan Licensing for New Deployments: Whenever a new Oracle EE database is rolled out, decide if it will use the Diagnostics/Tuning Pack upfront. Including that in the project budget is easier than retrofitting later. By planning, you can negotiate better if adding packs as part of a larger purchase. This avoids scenarios where DBAs enable AWR on a new system without management realizing a license is needed – proactive planning ensures compliance from day one.

Read Managing Oracle Diagnostics & Tuning Pack Costs: Pricing, Alternatives, and Strategic Considerations.

FAQ

Q: Can I purchase and use Oracle Tuning Pack without having the Diagnostics Pack?
A: No. Oracle’s licensing rules mandate that the Tuning Pack requires the Diagnostics Pack. In practical terms, the database must also be licensed for the Diagnostics Pack to use any Tuning Pack feature (like SQL Tuning Advisor). If you tried to license only the Tuning Pack, you’d be non-compliant, so if you want the Tuning Pack, budget for both. You can, however, license Diagnostics Pack by itself and not get Tuning Pack – that is allowed, and some customers do just that.

Q: What is the fundamental difference between what the Diagnostics Pack and the Tuning Pack provide?
A: The Diagnostics Pack is about monitoring and diagnosing the database’s performance. It collects data (AWR snapshots), analyzes it (ADDM), and helps you find problems (through reports, ASH, performance graphs). The Tuning Pack is about optimizing and fixing performance issues. It gives you specific recommendations to tune SQL and indexes (through SQL Tuning Advisor and SQL Access Advisor) and tools to monitor running SQL in real time. In short: Diagnostics = find out what’s wrong; Tuning = figure out how to make it faster. They complement each other. For example, the Diagnostics Pack identifies the slow query, and the Tuning Pack suggests how to tune it.

Q: Do I always need both packs for performance management?
A: Not always; it depends on your needs. Many performance issues can be identified and addressed with just the Diagnostics Pack. Armed with AWR and ADDM data, a skilled DBA can typically resolve common problems (adding missing indexes, rewriting queries, etc.) without the Tuning Pack. The Tuning Pack becomes useful for deeper or more systematic optimization, for example, when you have hundreds of SQL statements to tune or you want Oracle to automatically identify and help fix the worst-performing SQLs. Both packs are the way to go if you have the resources and need maximum performance improvement with minimal manual effort. If you have a limited budget or strong in-house expertise, Diagnostics Pack alone can cover the essentials.

Q: How are these packs licensed in terms of numbers? Do I need a license per database or server?
A: The packs are licensed per the processors or users of each database instance, just like the database itself. If you license by Processor: count the processor cores (with Oracle’s core factor) on the server (or VM) where the database is running – that number of processors is how many pack licenses you need for that database. Count across all nodes if the database runs on a cluster (RAC environment). If licensing by Named User Plus: count the named users of that database (with Oracle’s 25-per-processor minimum as a floor) – that’s how many NUP licenses you need for the pack. In essence, each Oracle Database that uses the pack needs its pack license equivalent to the database license. It’s not a “one license covers all databases” scenario; you allocate licenses to each DB, similar to what you did for the DB software.

Q: Are the Diagnostics Pack and Tuning Pack included with Oracle’s cloud services or any Oracle license bundles?
A: In Oracle’s Cloud (OCI), if you use the “License Included” model for an Oracle Database service (for example, spinning up an Autonomous Database or a Managed DB System where you pay Oracle per hour for the database license), the Diagnostics and Tuning Pack capabilities are generally included as part of that cloud service – you’re effectively paying for their usage in the hourly rate. However, if you use a “Bring Your Own License (BYOL)” model on Oracle Cloud or other clouds, you must have the pack licenses in your entitlement to use those features. Oracle sometimes offers packaging deals on-premises (like limited-time offers or including certain packs if you buy others), but traditionally, Diagnostics and Tuning are almost always separate add-ons. They are not included in the base Enterprise Edition license by default. Always verify current Oracle programs – for instance, Oracle sometimes provides these packs as part of a higher-tier offering (like Oracle’s Diagnostics Pack and Tuning Pack, which were historically bundled in certain Oracle Management Cloud services). But as a rule, assume they’re separate unless explicitly stated in a contract.

Q: What happens if we enable Diagnostics Pack on a database but never use Tuning Pack features? Do we still need to license the Tuning Pack for that database?
A: No, you only need to license the features you use. If you use AWR/ADDM on Database A but never invoke SQL Tuning Advisor or other tuning features, you would just license the Diagnostics Pack for Database A. A Tuning Pack license would not be required if you never use those tuning features on Database A. On Database B, if you use both AWR and SQL Tuning Advisor, then Database B needs both Diagnostics and Tuning Pack licenses. The important part is controlling usage: ensure that your DBAs do not use its features on databases where you didn’t buy the Tuning Pack. Oracle’s audit will look at feature usage per database to see what was used. So, it is perfectly acceptable to have Diagnostics Pack on some systems and not Tuning Pack, as long as Tuning features stay off those systems.

Q: We have 10 Oracle databases. Can we buy 5 Diagnostics Pack licenses and float them around as needed?
A: Oracle licenses don’t really “float” in that sense. Each license (processor or NUP) is tied to a specific environment at a time. You can’t dynamically allocate them on the fly depending on usage. If you have 10 databases and any of them might use the Diagnostics Pack at any given time, you need to license all 10 for compliance (because, at audit, if any of them use it, that DB must be licensed). However, you could have a scenario where you permanently assign licenses to 5 databases (and only allow pack usage on those 5). You ensure that you never use the packs for the other five databases. That is fine. But you can’t, for example, Monday use a license on DB1, then reassign it to DB2 on Tuesday for a one-off analysis – unless you are completely uninstalling or decommissioning it on DB1. Oracle licenses aren’t concurrent-use or floating; they’re tied to deployed usage. So, plan for which databases will be pack-enabled and license those fully.

Q: Are there any features that overlap? For instance, does the Diagnostics Pack do anything that the Tuning Pack also does, or vice versa?
A: The packs are designed to be complementary with minimal functional overlap. Diagnostics Pack doesn’t do proactive tuning advice – that’s strictly Tuning Pack territory. Tuning Pack doesn’t collect performance stats – it relies on Diagnostics Pack. One can say ADDM vs SQL Tuning Advisor might both identify issues, but ADDM (Diagnostics) might say “Query X is heavy on I/O”, whereas SQL Tuning Advisor (Tuning) will take Query X and try to fix it. They’re sequential in that sense. One area to clarify is SQL Plan Management – Oracle’s feature for managing execution plans. Basic plan stability is available in Enterprise Edition without extra cost. However, some aspects, like automatic SQL profile recommendations, come with the Tuning Pack. Meanwhile, AWR data from the Diagnostics Pack can help with the plan analysis. They mesh together. In short, you won’t pay twice for the exact same capability; each pack has its distinct set of features, with Tuning Pack features generally relying on the presence of Diagnostics Pack.

Q: If I have one Diagnostics Pack license for a processor, can I use it for any database on that processor?
A: Oracle licenses aren’t tied to physical processors in isolation but to the specific installed database product on those processors. If you license one processor of the Diagnostics Pack, it is meant for one processor’s worth of a specific Oracle Database instance. If two databases run on the same physical processor (say via virtualization or multiple instances on one server), technically, each database would need its license if both use the pack. However, in many cases, companies license by processor counting the server’s cores – if multiple DBs are on one server, each with peak usage, you still count the cores of that server once. This is a complex way of saying that Oracle’s license is deployed per the Oracle Database. If you have multiple instances, you generally need to license each. But if those instances are on one server and you license all its processors, that covers all instances on it. It’s usually simpler to consider it per server: license the server’s cores for the pack, and any DB on it is covered. You don’t pay twice if you run multiple DBs on the same licensed cores. But if you have multiple DBs across different servers, each server (or each set of cores) must be licensed. Named User licensing would similarly cover users accessing any database on that server if done correctly. Always align pack licensing with how you licensed the database on that hardware.

Q: How do I explain the value of these packs to non-technical stakeholders when asking for budget?
A: Emphasize the business impact of performance and downtime. For Diagnostics Pack: explain that without it, finding the root cause of a database slowdown is like finding a needle in a haystack. With it, your team can quickly pinpoint issues, reducing downtime or slow periods from hours to minutes. For a business, that means higher uptime and better user experience (e.g., customers on your website won’t suffer slowness as long, internal processes don’t grind to a halt). For Tuning Pack: highlight that it can improve application response times and efficiency. Faster queries mean employees can do more in less time, customers get snappier service, and potentially, you need less hardware because the database is optimized (cost avoidance on infrastructure). Also mention risk mitigation: avoiding big performance failures by proactively tuning. If you have any real examples (like “last year we had an outage that took 6 hours to diagnose – with Diagnostics Pack we could cut that to 1 hour”), use them. Non-technical execs respond to cost, risk, and benefit. So, frame Diagnostics/Tuning Packs as insurance and enhancement for your mission-critical systems. They protect against prolonged outages (which can cost $X per hour in lost productivity or sales) and improve system throughput (enabling business growth or cost savings). Also, compliance-wise, it’s better to budget and buy what you need than risk a non-compliance fine later – that’s another angle to justify the expense.

Read about our Oracle License Management Services.

Do you want to know more about our Oracle License Management Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit