Oracle Diagnostic Pack Licensing

Required for: Using features like AWR, ADDM, ASH, and SQL Tuning Advisor.
License Type: Charged separately for Enterprise Edition databases.
Enforcement: Enabled automatically with Enterprise Manager, requiring licensing if used.
Alternatives: Disable features CONTROL_MANAGEMENT_PACK_ACCESS to avoid compliance issues.
Audit Risk: Oracle audits can detect unauthorized usage, leading to penalties.

Table of Contents

Oracle Diagnostic Pack Licensing

Oracle’s Diagnostic Pack is an add-on for Oracle Database that provides deep-performance diagnostics and monitoring capabilities. However, using it requires careful attention to licensing.

This guide explains the licensing models (Named User Plus vs. Processor), the rules and restrictions for using the Diagnostic Pack, what components it includes, common compliance pitfalls, and how to detect usage.

It is aimed at IT asset managers and general audiences, balancing technical insight with practical compliance guidance across all Oracle Database versions.

Licensing Models for Oracle Diagnostic Pack

Oracle offers two primary licensing metrics for the Diagnostic Pack: Named User Plus (NUP) and Processor licensing. The choice between these models usually depends on the number of database users and the hardware on which the database runs.

It’s important to note that whichever model is used, the Diagnostic Pack must be licensed in the same way and the same quantities as the Oracle Database.

Below is an overview of each model and how to calculate licensing requirements:

Named User Plus (NUP) Licensing

User Plus licensing is based on the count of individuals (or distinct devices) accessing the Oracle Database. This model is suitable for environments with a known, limited user population. When using NUP for the Diagnostic Pack, Oracle requires a minimum number of user licenses per processor to ensure adequate coverage.

Specifically, for Enterprise Edition databases, you must license at least 25 Named User Plus per Processor (per CPU core, after core factor adjustment) or the total number of actual users, whichever is greater. In practice, this means:

If you have a database running on two processor cores (after applying Oracle’s core factor, explained below), the minimum NUP licenses required would be 2 × 25 = 50 NUP, even if you have fewer than 50 actual users.
If the number of distinct users (human or machine accounts) exceeds this minimum, you must license that higher number. For example, if 80 employees or applications access the database, you need 80 NUP licenses (since 80 exceeds the 50 minimum in this scenario).

The NUP model is cost-effective when you have a small, countable user base. It’s critical to count all individuals and devices that directly or indirectly use the database features (including those using applications that connect to the database). Always ensure the NUP count meets Oracle’s minimum-per-processor rule.

Processor-Based Licensing

Processor-based licensing is generally used for environments where user counts are high, fluctuating, or not easily tracked (for instance, public-facing applications or large enterprise systems).

Under the Processor licensing model, you license the Diagnostic Pack based on the processing power of the servers running the Oracle Database. All processors (CPU cores) on those database servers must be licensed if the Diagnostic Pack is used.

Oracle defines “processors” as cores and a core factor for licensing purposes. Each hardware platform has a core factor (as defined by Oracle’s Core Factor Table) that reduces the core count for licensing. The formula for Processor licenses is:

Processor Licenses Required = (Number of cores) × (Core Factor)

Oracle rounds up fractional values to the next whole number. For example, if a server has 8 cores and the core factor is 0.5 (common for x86 processors), the calculation is 8 × 0.5 = 4, so 4 Processor licenses are needed. This calculation must be done for each server or physical partition where the Oracle Database using the Diagnostic Pack is installed or running.

Processor licensing is often chosen when the user population is “uncountable” or requires more NUP licenses than processor licenses (Oracle’s contracts often make Processor licensing more economical above a certain scale of users). The key point is that the Diagnostic Pack must be licensed on every processor where the database is active, just like the database itself.

Aligning with Database Licensing

The Diagnostic Pack’s licensing metric must align with the database’s. If processors license your Oracle Database Enterprise Edition, they should also license the Diagnostic Pack (in the same quantity).

If NUP licenses your database, the Diagnostic Pack must be licensed by NUP for at least the same number of users (and meet the 25-per-processor minimum) . Oracle does not allow mixing metrics for a given database environment. This alignment ensures that the Diagnostic Pack coverage is sufficient for the database on which it runs.

Example: Suppose an Oracle Enterprise Edition database is running on a server with four cores (core factor 0.5)—that would require two Processor licenses for the database. If you enable Diagnostic Pack on that database, you also need two Processor licenses for the Diagnostic Pack.

Conversely, if that database were licensed as 100 Named User Plus, you would need at least 100 NUP licenses for the Diagnostic Pack (assuming 100 is above the 25-per-core minimum for the number of cores in use).

Rules and Restrictions

Using Oracle Diagnostic Pack comes with specific rules and restrictions that organizations must adhere to to remain compliant.

Below are the key conditions that must be met before you use any Diagnostic Pack features:

Enterprise Edition Only: The Diagnostic Pack is only available with Oracle Database Enterprise Edition; it is not licensed for Standard Edition (or other editions) databases. This means you cannot legally use Diagnostic Pack features on a Standard Edition database unless you upgrade that database to Enterprise Edition and purchase the Diagnostic Pack licenses. Even though the software components (like AWR, ADDM, etc.) may exist or function in Standard Edition in a limited way, using them without an EE license plus a Diagnostic Pack license is a violation (we’ll cover this compliance issue below). In summary, you must be running Enterprise Edition to use the Diagnostic Pack, and the pack license is an additional cost on top of the Enterprise Edition database license.
License Must Match Database Deployment: As noted earlier, the Diagnostic Pack must be licensed with the same metric and for the same scope as the attached database. You cannot license the database for one number of processors or users and can only partially license the Diagnostic Pack for a subset of that database. Oracle’s policy is that the pack’s license count must align with the database’s license count on that server or cluster. For example, if a database runs on eight processors (requiring 8 EE database licenses), you need eight processor licenses of Diagnostic Pack for that database. If you have an Enterprise Edition database with 50 NUP licenses, you must have at least 50 NUP licenses for the Diagnostic Pack on that same database. The packs cannot be split or shared across different databases; each database using Diagnostic Pack features needs its corresponding pack license.
Database Version Compatibility: The Diagnostic Pack has been available since Oracle Database 10g (when features like AWR and ADDM were introduced) and continues through 11g, 12c, 18c, 19c, and beyond. The licensing rules are consistent across versions – using Diagnostic Pack features on any supported Oracle Database Enterprise Edition version requires a license for that pack. There is no “free” use in newer versions: Oracle’s licensing documentation and license agreements clarify that these packs are separate, chargeable options in all versions. The only exception is Oracle’s Autonomous Database cloud services, where certain features might be included differently under cloud subscription terms (outside the scope of this on-premise-focused discussion). For traditional on-premise or IaaS deployments, assume the Diagnostic Pack always requires explicit licensing if used, regardless of the database version.
Prerequisite for Tuning Pack: Oracle offers a separate add-on called the Tuning Pack (for advanced SQL tuning and indexing recommendations). Importantly, you cannot license or use the Tuning Pack without licensing the Diagnostic Pack. Diagnostic Pack is a prerequisite because many Tuning Pack features build on Diagnostic Pack data (for example, SQL Tuning Advisor uses information from AWR and ADDM). So, if your team intends to use Oracle’s Tuning Pack, you must first budget for and ensure compliance with Diagnostic Pack licensing. In an Oracle audit, using any Tuning Pack feature will imply you should have both Tuning and Diagnostic Pack licenses.
No Free or Partial Usage: No “limited” Diagnostic Pack usage concept without a license exists. Any use of its features (even occasionally) in a production, test, or development environment technically requires a full license on that database. Oracle’s contracts also typically require a feature to be licensed if installed or enabled. While Oracle provides a parameter to disable pack features (covered later), the onus is on the customer to ensure unlicensed features are not used. Simply having the software component available (because it’s bundled in Enterprise Edition binaries) is not an issue; it arises when you invoke or access those features without purchasing the rights.
Licensing True-Ups and Environment Scope: Ensure that every environment (production, development, QA, etc.) where Diagnostic Pack is used is properly licensed. The licensing model is the same across all environments – no discounted or free usage for non-production unless specified in your Oracle contract. Often, organizations forget to license non-production databases for the pack even while DBAs use AWR or ADDM in those environments, leading to compliance gaps. Additionally, if you scale your environment (add more users or processors), you must procure additional licenses to remain compliant; Oracle typically expects you to true-up licenses if an audit finds usage beyond what you purchased.

By following these rules – using Diagnostic Pack only with Enterprise Edition, matching the license metrics/counts to your database, and ensuring prerequisites are met – you establish the proper licensing foundation and avoid most legal pitfalls associated with this Oracle option.

Included Components of the Oracle Diagnostic Pack

The Oracle Diagnostic Pack license covers a suite of performance monitoring and diagnostic features built into the Oracle Database.

Understanding what is included under this pack is essential to know which tools require the extra licensing. According to Oracle’s documentation, the Diagnostic Pack includes the following major components and features:

Automatic Workload Repository (AWR): AWR is a built-in repository that automatically collects and stores database performance statistics. It takes snapshots of performance data (like wait events, system statistics, object usage metrics, etc.) at regular intervals. AWR data is then used for analysis and generating reports on database performance over time. Using AWR (beyond the limited “STATSPACK” alternative) is a Diagnostic Pack feature, meaning that querying AWR views, generating AWR reports, or modifying AWR settings requires the pack license. AWR forms the backbone of Oracle’s performance diagnostics, retaining historical metrics that DBAs can review to identify trends or issues.
Automatic Database Diagnostic Monitor (ADDM): ADDM is an engine that analyzes the data collected in AWR and automatically diagnoses potential performance problems. After each AWR snapshot, ADDM provides findings and recommendations (e.g., identifying a CPU bottleneck, a poorly performing SQL, or insufficient indexing). The Diagnostic Pack license covers accessing ADDM analysis or reports. Essentially, ADDM distills the raw data from AWR into actionable insights, but because it relies on AWR, it’s part of the same pack.
Active Session History (ASH): ASH is a feature that samples the state of active sessions in the database every second (or more frequently) and records it. This allows fine-grained analysis of what sessions are doing over time (for example, which SQL a session was executing, which wait event it was on, etc., at any given moment). ASH data is accessible via views like V$ACTIVE_SESSION_HISTORY, and using these requires a Diagnostic Pack license. ASH is essentially a real-time window into database activity and is extremely useful for troubleshooting short-lived issues, but again, it’s part of the licensed pack.
Performance Monitoring (Database and Host): The Diagnostic Pack covers a range of general performance monitoring tools at the database and host (server) levels. This includes the performance pages in Oracle Enterprise Manager (OEM) that show database throughput, wait class statistics, host CPU/memory usage, etc. All those dashboards and charts in OEM that provide live monitoring of Oracle Database performance metrics are part of the Diagnostic Pack. The pack license is required whether you access these metrics via OEM, command-line, or custom scripts querying Oracle’s performance views. You’re likely in Diagnostic Pack territory if you leverage Oracle’s built-in performance monitoring views and charts beyond basic functionality.
Event Notifications and Alerts: Oracle Enterprise Manager’s ability to send alerts for certain conditions (like metrics exceeding thresholds) relies on the Diagnostic Pack. The pack includes event notification features – such as setting up notification methods, rules, and schedules for alerts and viewing alert histories. For example, if you configure alerts for CPU usage or tablespace capacity in OEM and use Oracle’s notification system (email, SNMP, etc.), those features require the Diagnostic Pack. The license also covers the underlying plumbing of alert logs accessible via the data dictionary views for metric history and alerts.
Baseline Metrics and Adaptive Thresholds: The Diagnostic Pack provides dynamic metric baselines and adaptive threshold features. This means the database can maintain baseline performance metrics (e.g., typical hour-of-day performance) and adjust alert thresholds dynamically based on statistical deviation. Setting and using baseline metrics or templates, comparing snapshots to a baseline, etc., are part of the diagnostic Pack. This is useful for detecting performance anomalies by comparing against historical normal performance.
Blackouts: In OEM, you schedule periods to suppress alerts (for example, during planned maintenance). The ability to set blackouts for targets is included in the Diagnostic Pack. It’s a minor feature, but it is worth noting that using OEM’s blackout feature on a database technically falls under the Diagnostic Pack licensing.
Memory Performance Analysis: The pack includes memory-access-based performance monitoring. This can refer to features like Oracle’s memory advisors or the ability to track memory usage patterns over time, helping DBAs decide on SGA/PGA sizing. These memory advisories and related views require the Diagnostic Pack.
Additional Views and APIs: Many Oracle data dictionary views and PL/SQL packages are part of the Diagnostic Pack. For instance, the package DBMS_WORKLOAD_REPOSITORY (managing AWR snapshots and reports) is part of this pack, as is DBMS_ADDM. Dynamic performance views like V$ACTIVE_SESSION_HISTORY (and its underlying table X$ASH) are part of this pack. Even certain advisor-related views (DBA_ADVISOR_% regarding ADDM tasks) fall under Diagnostic Pack usage. Oracle documentation provides a detailed list of the specific views/procedures tied to the pack, and it’s extensive. A feature or view related to AWR, ADDM, ASH, or performance diagnostics likely requires a Diagnostic Pack license.

It’s worth noting that Oracle Enterprise Manager (OEM) has a management pack access control where you can enable or disable packs for a database target. If Diagnostic Pack access is enabled in OEM, all those aforementioned features in the OEM console (Performance tab, ADDM reports, etc.) are assumed to be licensed. Oracle even provides a way to disable those links if you haven’t licensed the pack – a good practice if you want to prevent accidental use (discussed later).

Understanding these components helps IT asset managers identify which tools DBAs can use without a license. For example, generating an AWR report or looking at ASH data is not free—it’s part of the Diagnostic Pack.

For completeness, Oracle’s Tuning Pack (a separate license) includes other features like SQL Tuning Advisor and SQL Access Advisor; those are not included in the Diagnostic Pack, though they often work in conjunction. Remember, to use Tuning Pack features, you must also have a licensed diagnostic pack, but the diagnostic pack covers the diagnostics and monitoring tools listed above.

Common Compliance Issues

Oracle’s licensing can be complex, and many organizations inadvertently fail to comply with Diagnostic Pack licensing.

Here are some common compliance issues to watch out for and why they occur:

Using Diagnostic Pack Features Without a License (Unauthorized Usage): One of the most frequent violations is when DBAs or developers use Diagnostic Pack features without the organization having purchased the license. This can happen because the features are readily available in Oracle Database Enterprise Edition – for example, AWR snapshots are collected by default, and views like DBA_HIST_* can be queried, or someone runs an AWR report script. If the Diagnostic Pack is not licensed, any use of its features is unauthorized. Oracle’s audit teams can detect this because tools like AWR store historical usage data that Oracle can later review. AWR data itself can reveal unlicensed usage during an audit. For instance, if an audit finds AWR snapshots and reports exist on a database but no Diagnostic Pack license was purchased for that server, that’s a compliance gap. It’s important to train DBAs and users not to invoke AWR, ADDM, or ASH features on unlicensed databases. Simply installing Enterprise Edition (with these features present) isn’t a violation by itself; it’s the use (accessing data, running reports, etc.) that constitutes usage. Unauthorized usage can result in hefty back-license fees and penalties if discovered.
Using Diagnostic Pack on Standard Edition: Sometimes, an Oracle Standard Edition (SE) database user might attempt to use Diagnostic Pack functionality. Technically, some Diagnostic Pack data may still be present or collectible in SE (for example, the STATISTICS_LEVEL parameter, if set to TYPICAL, still gathers some stats). However, Oracle’s policy is that the Diagnostic Pack is an Enterprise Edition-only option. Using it on Standard Edition is prohibited unless that database is licensed as Enterprise Edition. In practical terms, if you use any Diagnostic Pack feature on Standard Edition, you must license the database as Enterprise Edition with Diagnostic Pack. This means a complete licensing uplift (this effectively prohibits SE users from using it). A common scenario is an organization runs Standard Edition (which is cheaper and does not include AWR/ADDM for free). Still, a DBA unknowingly generates an AWR report or turns on a feature that is part of the Diagnostic Pack. This puts the company out of compliance. To remain safe, Standard Edition users should use free tools like STATSPACK for performance monitoring and know that AWR/ADDM/ASH features are off-limits without an Enterprise Edition + Diagnostic Pack license.
Exceeding Licensed Capacity (Over-Deployment): Another compliance issue arises when Oracle Database (and Diagnostic Pack) usage grows beyond what was initially licensed. For example, you might have licensed Diagnostic Pack for four processors but moved the database to a new server with eight processors without updating your license count. You licensed 50 Named Users for the pack, but over time, 100 distinct users (or devices) have accessed the database’s performance views or reports. In such cases, you have more usage than you paid for. Oracle’s rules require that you license all processors and users using the database with the Diagnostic Pack, so exceeding those numbers means non-compliance. There is no automatic warning when you exceed your entitlement – it will only be caught in an audit or by a proactive internal review. The principle to remember is that your Diagnostic Pack licenses must cover the full scope of the database deployment at all times. Regularly check if your environment has grown (more cores, additional servers in a cluster, more user accounts, etc.) and true-up your licenses accordingly to avoid this issue.
License Metric Mismatch or Misalignment: This issue occurs if an organization mistakenly licenses the Diagnostic Pack in a way that doesn’t match the database license. For instance, NUP licenses for Diagnostic Pack can be purchased while the database is licensed by processors (or vice versa) for the same server. Oracle’s policy is clear that the metrics should match – you can’t mix metrics for the same workload. A mismatch could also occur in counts – e.g., you have 100 NUP for the database but only bought 50 NUP for the Diagnostic Pack. In Oracle’s eyes, that’s 50 NUP worth of Diagnostic Pack usage unaccounted for (unless you somehow restricted usage to only those 50, which in reality is impractical). Any shortfall in pack licenses relative to the database usage is treated as non-compliance. Always ensure that for each database instance using the Diagnostic Pack, the number of licenses and the license type for the pack are exactly equal to that of the database itself. If you migrate a database from one licensing model to another (say, from NUP to Processor because your user counts grew), convert the Diagnostic Pack licensing accordingly.
Inadequate Controls Leading to Inadvertent Use: Oracle databases have many features enabled by default. A fresh install of Oracle Enterprise Edition will have Diagnostic Pack capabilities turned on (the default parameter CONTROL_MANAGEMENT_PACK_ACCESS is “DIAGNOSTIC+TUNING”). The database will start collecting AWR data and automatically allow ADDM analysis unless you proactively disable it. Many companies fall into accidental non-compliance because they didn’t realize this and did not restrict access. For example, a DBA might casually run an AWR report for troubleshooting, not realizing the company hasn’t licensed that pack. Inadvertent use is still counted as usage. Oracle expects customers without Diagnostic Pack licenses to disable those pack features to prevent accidental use. Not doing so is risky – if an audit finds that the features were accessible and used, “I didn’t know” is not an acceptable defense. This issue is common in dev/test environments where DBAs assume they can use all features freely. To avoid it, you should explicitly turn off Diagnostic Pack on any database that isn’t licensed (we’ll discuss how to detect and control usage next).
Lack of Internal Monitoring and Record-Keeping: A softer compliance issue (but one that can aggravate the above problems) is not keeping track of what features are being used and not maintaining documentation. Oracle’s license audits can span several years of usage. If you cannot demonstrate which databases had the packs enabled or how many users accessed them, Oracle will default to assuming worst-case usage. Some organizations also lose track of their license entitlements versus deployments. For instance, licenses might be procured for a project, and later, the databases are repurposed or scaled up without updating the asset management records. This can lead to either over-licensing (wasting money) or under-licensing (compliance risk). Oracle recommends regular internal audits and maintaining documentation of where Diagnostic Pack is installed/enabled and how it’s being used.

Tip: Many compliance issues can be preempted by setting the initialization parameter CONTROL_MANAGEMENT_PACK_ACCESS = NONE on databases with no Diagnostic Pack (or Tuning Pack) license.

This effectively disables the Diagnostic Pack functionality at the source, preventing intentional and accidental use. Also, remove or restrict OEM access to performance pages in those instances. By doing so, you create a safety net against unlicensed usage.

Next, we’ll cover methods to detect usage, which can also be used to audit your environment for any of the above issues.

Detecting Diagnostic Pack Usage

Knowing whether Diagnostic Pack features have been used in your databases is crucial for compliance.

Oracle provides tools and views to help you identify the usage of optional packs like the Diagnostic Pack.

Here are the primary methods to detect if Diagnostic Pack features are in use:

Check the Control Management Pack Access Parameter: Oracle introduced an initialization parameter called CONTROL_MANAGEMENT_PACK_ACCESS that controls the availability of Diagnostic Pack (and Tuning Pack) features at the database level. This parameter can have three values: NONE (packs disabled), DIAGNOSTIC (only Diagnostic Pack enabled), or DIAGNOSTIC+TUNING (Both Diagnostic and Tuning Pack features are enabled.) By default, on Enterprise Edition, it is set to DIAGNOSTIC+TUNING If you haven’t changed it, the Diagnostic Pack features are available. Querying this parameter won’t tell you if the features were used, but it tells you if the database was allowing their use. Run the following SQL as DBA:sqlCopyEditSELECT value FROM v$parameter WHERE name = ‘control_management_pack_access’; If the value is NONE Then, the Diagnostic Pack was effectively turned off (no usage possible via normal means). If it’s DIAGNOSTIC or DIAGNOSTIC+TUNING, the features were enabled. Remember that you might not have used it even if it was enabled. Further investigation is needed to confirm usage.
Use DBA_FEATURE_USAGE_STATISTICS View: Oracle databases internally track feature usage in a dedicated view DBA_FEATURE_USAGE_STATISTICS. This is a key source for detecting Diagnostic Pack usage. The database updates this information periodically (usually once a week) for various features and options. Each entry in this view corresponds to a specific feature, with columns indicating how many times it was used and the last usage date. Oracle’s auditors rely on this view during compliance audits – it’s essentially the database tattletale for feature usage. To check for Diagnostic Pack related features, you can query this view for feature names like ‘Automatic Workload Repository’, ‘ADDM’, ‘ASH’, ‘AWR Report’, etc. For example:sqlCopyEditSELECT name, detected_usages, last_usage_date FROM dba_feature_usage_statistics WHERE name IN ( 'Automatic Workload Repository', 'Automatic Database Diagnostic Monitor', 'Active Session History', 'AWR Report', 'ADDM' ); If detected_usages is greater than 0 or last_usage_date is not null/recent for these features; that’s a clear sign the Diagnostic Pack has been utilized on that database. The view provides a comprehensive list, including SQL Tuning Advisor usage (which indicates Tuning Pack usage) and others. You should review this for each database and match it against your license entitlements. Oracle documentation notes that this view compiles data from many internal tracking tables to provide a consolidated picture. It’s the most useful source to identify if, when, and how often Diagnostic Pack features were used.
Oracle’s Audit Scripts and Reports: Oracle License Management Services (LMS) provides official scripts to customers (often via Oracle Support) to help audit database options and pack usage. One such script is options_packs_usage_statistics.sql (Oracle Support Document ID 1317265.1). When run on a database, this script will output usage information for all separately licensed options and management packs, including the Diagnostic Pack. It typically lists which packs/options have been used and how recently. IT asset managers can request this script from Oracle Support or find it in Oracle’s knowledge base. They can run it on their databases to get an authoritative report on Diagnostic Pack usage. Using these scripts internally (before any official audit) is highly recommended so you can identify and address any issues. The script’s output can be a bit complex and may require interpretation by someone familiar with Oracle licensing; however, it flags things like “Diagnostic Pack used: YES/NO” for each database.
Enterprise Manager (EM) Usage Logs: If your team uses Oracle Enterprise Manager (Cloud Control or DB Console) to manage databases, EM can inadvertently log Diagnostic Pack usage. For example, if someone accessed the Performance page for a database in EM, that action uses Diagnostic Pack data (like ASH, AWR). EM might not explicitly tell you “you used Diagnostic Pack,” but Oracle, in an audit, can ask for EM repository data or the presence of certain configurations that indicate usage. A practical step is to ensure that EM’s Management Pack Access settings are correctly configured. EM has a UI that disables access to the Diagnostic Pack per target database. If those were not disabled for an unlicensed database, there’s a risk someone accessed pack features. Reviewing who has access to EM and what features they use can help detect if Diagnostic Pack features were likely invoked.
AWR Reports and Snapshot Data: On the database itself, check if any AWR reports have been generated and saved or if the AWR snapshot retention is being used actively. By default, AWR in EE takes snapshots and keeps them for a certain period (e.g., 8 days). Suppose you see those snapshots exist (which you can tell by querying the view DBA_HIST_SNAPSHOT, for instance), especially if someone extended the retention or created AWR baselines or reports. In that case, it indicates active use of the Diagnostic Pack. In a compliance exercise, finding AWR reports (e.g., text or HTML files generated by awrddrpt.sql or awrrpt.sql) on DBA servers is a giveaway that Diagnostic Pack was used. While routine snapshot collection by itself (without anyone querying it) is a gray area, the moment someone queries that data or uses it for analysis, it’s considered usage. So, hunting for AWR report outputs or ASKING DBAs if they have run such reports is part of detecting usage.
ADDM Findings or Tasks in the Database: Similar to AWR, you can check if any ADDM runs have generated findings. For example, querying the view DBA_ADVISOR_FINDINGS for tasks named ‘ADDM%’ could show if any ADDM analysis was conducted. If your DBAs haven’t explicitly run ADDM, Oracle automatically runs it after each snapshot, but the results are usually stored internally. If those results were queried (via OEM or DBMS_ADDM), that’s usage. So, the evidence of ADDM findings being looked at is another indicator.

In summary, to detect Diagnostic Pack usage, combine parameter checks, feature usage views, and Oracle-provided audit scripts for a thorough assessment. Organizations should run these checks regularly (for example, quarterly) on all Oracle databases and compare the results against what is licensed.

Oracle also recommends internal audits: conducting your license compliance review can catch issues early. By being proactive in detection, you can address unintentional usage (such as disabling features or purchasing the necessary licenses) before Oracle’s official auditors come knocking.

Conclusion

Managing Oracle Diagnostic Pack licensing requires diligence but is achievable with the right knowledge and processes. We covered how the pack can be licensed either per user (NUP) or per processor, always aligning exactly with your Oracle Database Enterprise Edition licenses.

Key rules – like Enterprise Edition exclusivity and the Diagnostic Pack being a prerequisite for the Tuning Pack – set the boundaries for where and how the pack can be used. We listed the rich set of features that the Diagnostic Pack provides, from AWR and ADDM to ASH and performance monitoring tools, so you know which tools in your Oracle environment are part of this licensed pack.

Awareness of common compliance issues (such as unauthorized use, Standard Edition misuse, or license mismatches) can help you avoid the typical traps that lead to audit findings.

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

Author

Fredrik Filipsson

Fredrik Filipsson has 20 years of experience in Oracle license management, including nine years working at Oracle and 11 years as a consultant, assisting major global clients with complex Oracle licensing issues. Before his work in Oracle licensing, he gained valuable expertise in IBM, SAP, and Salesforce licensing through his time at IBM. In addition, Fredrik has played a leading role in AI initiatives and is a successful entrepreneur, co-founding Redress Compliance and several other companies.
View all posts