Oracle Diagnostics vs Tuning Pack: What Each Contains & Costs in 2026

What are the Oracle Diagnostics and Tuning Packs?

The Oracle Diagnostics Pack is a separately licensed Oracle Database Enterprise Edition option that delivers automated performance diagnosis — the Automatic Workload Repository (AWR), the Automatic Database Diagnostic Monitor (ADDM), Active Session History (ASH), and the performance and alert metrics surfaced in Oracle Enterprise Manager. Its job is detection: it captures what the database is doing and identifies bottlenecks.

The Oracle Tuning Pack is a separately licensed Enterprise Edition option that delivers remediation — the SQL Tuning Advisor, the SQL Access Advisor, SQL Profiles, Automatic SQL Tuning, and Real-Time SQL Monitoring. Its job is prescription: it takes the data the Diagnostics Pack collects and recommends concrete fixes such as new indexes, materialized views, or rewritten execution plans.

Both are part of Oracle's database management packs family, both are available only with Enterprise Edition, and neither is included in Standard Edition 2. The packs are also the most commonly triggered options in the entire Oracle catalogue because the underlying features run automatically — which is exactly why they dominate accidental-usage findings in our Oracle Database licensing guide.

How do the Diagnostics and Tuning Packs compare feature by feature?

The clean way to remember the split: the Diagnostics Pack answers "what is slow and why," and the Tuning Pack answers "here is how to make it fast." You can license and use the Diagnostics Pack on its own. You cannot use the Tuning Pack without it.

Why does the Tuning Pack require the Diagnostics Pack?

Oracle makes the Diagnostics Pack a mandatory prerequisite for the Tuning Pack because the Tuning Pack's advisors are built on top of Diagnostics Pack data. The SQL Tuning Advisor analyses high-load SQL identified from AWR; the SQL Access Advisor evaluates workloads captured in AWR snapshots; Real-Time SQL Monitoring depends on Active Session History. Strip out the Diagnostics Pack and the Tuning Pack has nothing to analyse.

The commercial consequence is direct: every Tuning Pack purchase is, in reality, a purchase of both packs. An organisation that wants the SQL Tuning Advisor on a 16-core Intel server — eight processors after the Core Factor Table calculation — pays for eight Diagnostics Pack processors and eight Tuning Pack processors, not eight of the Tuning Pack alone. Procurement teams who budget only for the Tuning Pack are routinely surprised by the combined number.

Across our compliance reviews, more than 80% of databases showing Tuning Pack usage also show Diagnostics Pack usage on the same instance — and where only Tuning Pack appears, it almost always indicates a feature-tracking artefact rather than a licensing position the customer can rely on (Oracle Licensing Experts, 2026). That dependency is the single most misunderstood point in Oracle management-pack licensing, and it is where the largest budgeting errors originate.

How much do the Diagnostics and Tuning Packs cost in 2026?

Both packs are priced per processor at list. Under the Oracle Technology Price List, 2026, the Diagnostics Pack lists at approximately $7,500 per processor (or $150 per Named User Plus) and the Tuning Pack at approximately $5,000 per processor (or $100 per NUP). Each carries the standard 22% annual support uplift. Because the Tuning Pack requires the Diagnostics Pack, the realistic combined list cost is roughly $12,500 per processor per year before support.

Those are list figures. In an audit settlement, Oracle calculates back-license value from the first-used date in the feature-usage history and adds compounded support, which is why an accidentally triggered pack on a large cluster routinely produces a seven-figure opening claim. Our Oracle audit defense service challenges both the scope and the date of first usage before any number is accepted, and our license optimization service right-sizes which servers genuinely need the packs at all.

What triggers the Oracle Diagnostics Pack?

The Diagnostics Pack is the most frequently triggered option in the Oracle catalogue precisely because its features are on by default. A fresh Enterprise Edition install begins taking hourly AWR snapshots automatically. The moment anyone runs awrrpt.sql, queries a DBA_HIST view, or clicks the Performance tab in Cloud Control, feature-usage tracking records Diagnostics Pack activity. None of these actions warns the user that a chargeable option has just been exercised.

SELECT name, detected_usages,
       first_usage_date, last_usage_date
FROM   dba_feature_usage_statistics
WHERE  name LIKE '%Diagnostic Pack%'
   OR  name LIKE '%Tuning Pack%'
   OR  name LIKE '%AWR%'
   OR  name LIKE '%SQL Tuning Advisor%'
ORDER  BY first_usage_date;

Oracle's LMS scripts read exactly these feature-usage views, so prior Diagnostics Pack access remains visible long after anyone stopped running reports. This is the same silent mechanism we document in detail in our guide to accidental Oracle option usage — and it is why the Diagnostics Pack heads almost every list of unlicensed-option findings.

What triggers the Oracle Tuning Pack?

The Tuning Pack triggers from any use of its advisors. The most common paths are running the SQL Tuning Advisor against a high-load statement, running the SQL Access Advisor to evaluate indexing strategy, accepting a SQL Profile recommendation, enabling Automatic SQL Tuning, or using Real-Time SQL Monitoring. Each of these can be launched from a command-line script or, more dangerously, from a single click in an Enterprise Manager tuning wizard.

Two Tuning Pack traps catch enterprises repeatedly. First, the Automatic SQL Tuning task is part of the default automated maintenance windows in some configurations — meaning the database may run a chargeable advisor on a schedule without anyone initiating it. Second, DBAs frequently accept a SQL Profile recommendation that the SQL Tuning Advisor produced, not realising the profile itself is a Tuning Pack artefact that leaves a permanent usage record.

Because the Tuning Pack requires the Diagnostics Pack, a database showing Tuning Pack usage almost always carries Diagnostics Pack exposure on the same instance — so the two claims compound. A forensic Oracle compliance review maps both packs across the estate and separates genuine usage from feature-tracking noise before Oracle's LMS team does.

How do you stop accidental Diagnostics and Tuning Pack usage?

Oracle provides a single, decisive control: the database initialization parameter CONTROL_MANAGEMENT_PACK_ACCESS. It governs which management packs the database is permitted to run, and setting it correctly is the most effective way to prevent future exposure.

The default value, DIAGNOSTIC+TUNING, is the root of most accidental exposure — it leaves both chargeable packs wide open out of the box. Setting the parameter to NONE on databases you do not intend to license blocks the features cleanly. If you own the Diagnostics Pack but not the Tuning Pack, set it to DIAGNOSTIC so the SQL Tuning Advisor cannot run.

One caution: changing the parameter prevents new usage but does not erase historical feature-usage records. If usage has already accumulated, the right sequence is to document the current position, set the control, and have an independent advisor confirm whether the existing records are genuine, accidental, or a known false positive before any conversation with Oracle. Self-reporting raw feature-usage output without that review typically confirms the maximum possible claim — see our case studies for how a structured defense narrows the number.

Oracle Diagnostics vs Tuning Pack FAQ