Oracle Diagnostics and Tuning Pack Licensing

If a single pair of options were responsible for most Oracle database audit findings, it would be the Diagnostics Pack and the Tuning Pack. They are useful, they are reachable through the tools administrators use every day, and they are separately licensed. The combination means they activate constantly without a licensing decision, and the database records every activation. This article explains the mechanism and the controls. It builds on the options audit article and the database pillar.

What are the Diagnostics and Tuning packs?

The Diagnostics Pack and Tuning Pack are management packs for Enterprise Edition, licensed separately per core. The Diagnostics Pack covers the performance monitoring and diagnostic features, most notably the Automatic Workload Repository, known as AWR, and the automatic database diagnostic monitor. The Tuning Pack covers the SQL tuning advisor, SQL tuning sets, and related features that recommend and apply performance improvements.

Crucially, the Tuning Pack depends on the Diagnostics Pack. The Tuning Pack cannot be used without the Diagnostics Pack also being present, so a database that tunes SQL through these tools needs both packs licensed. This dependency doubles the per core charge for the tuning capability and is a frequent source of underlicensing where only one pack was bought.

How the packs activate

The packs activate through ordinary administration rather than through a deliberate deployment. The performance pages in the management console, the AWR reports administrators run to investigate a slow query, and the SQL tuning advisor offered as a one click recommendation all depend on these packs. Using any of them activates the corresponding pack, and the database records the event in its feature usage views.

This is why the packs are the archetype of inadvertent option use. No project decides to deploy them; an administrator simply uses the standard tools to do their job, and the activation follows. By the time an audit reads the usage views, months or years of activations are recorded, and the usage cannot be retracted, as the options audit article explains in detail.

AWR and the Diagnostics Pack

The Automatic Workload Repository is the single most common trigger for the Diagnostics Pack. AWR collects performance snapshots automatically and is the basis for most performance investigation on Oracle. Running an AWR report, or querying the AWR views, activates the Diagnostics Pack. Because AWR is enabled by default and is the natural first tool for any performance problem, the Diagnostics Pack is activated on a large proportion of Enterprise Edition databases without a licensing decision.

The defensive point is that AWR can be disabled or its access restricted, and the historical performance data can be gathered through alternatives that do not depend on the pack. But these choices have to be made deliberately and early, because once AWR has been used the activation is recorded. The control is prevention, not remediation.

The SQL tuning advisor and the Tuning Pack

The SQL tuning advisor is the equivalent trigger for the Tuning Pack. It analyses a problematic SQL statement and recommends improvements such as new indexes or a better execution plan. It is offered prominently in the management console, often as a suggested next step when a slow statement is identified, which makes it easy to invoke without realising it requires the Tuning Pack and, by dependency, the Diagnostics Pack.

Because the Tuning Pack depends on the Diagnostics Pack, a single use of the tuning advisor can imply a requirement for both packs across the entire database. This is the most expensive form of the trap, and it is triggered by exactly the behaviour good administration encourages: investigating and fixing slow SQL. Controlling it requires restricting the tuning tools rather than relying on administrators to avoid them.

What the packs cost

The table shows the dependency cost. Using the tuning advisor on a 16 processor database implies 16 processor licences of each pack on top of the base, because the Tuning Pack drags the Diagnostics Pack with it. Each pack is charged on the full core count of the database, not on the cores where the feature was used, so the cost scales with the hardware exactly as the base database does under the core factor.

How to control pack usage

The primary control is the database parameter that governs management pack access. Setting it to none prevents the packs from being used at all, so no activation can occur. Where the packs are genuinely needed and licensed, the parameter is set accordingly; where they are not, setting it to none removes the inadvertent use risk entirely. This single setting is the most effective control available.

The secondary controls are restricting console access so the performance and tuning tools are not exposed to administrators who should not invoke them, and monitoring the feature usage views proactively so any activation is caught and addressed early. Together these convert the packs from a latent audit liability into a governed, deliberate choice, the same prevention discipline the database licensing service applies across the option stack.

The buyer side view

The buyer side view of the Diagnostics and Tuning packs is that they are the highest probability finding in any database audit, and the only reliable defence is to prevent activation rather than to argue about it afterward. Set the management pack parameter deliberately, restrict the tools that trigger the packs, and monitor usage so nothing accumulates unseen. An estate that does this either licenses the packs because it genuinely uses them, or proves it does not use them at all. For the full prevention framework, see the options audit article, the database licensing white paper, or request a consultation.

Why the packs dominate audit findings

The packs dominate audit findings for a structural reason: their features are the default tools for performance work, they activate without a licensing decision, the activation is recorded automatically, and each pack is charged across the whole database. Every one of those factors points the same way, toward a recorded usage history that an audit reads directly. No other option combines such everyday triggers with such automatic evidence.

Defending a pack finding turns on whether the recorded usage reflects genuine, ongoing reliance or a handful of incidental activations, and on confirming the finding's scope against the actual deployment. That forensic reading is part of the audit defence practice. But the lesson of the packs is that prevention is dramatically cheaper than defence, because the evidence is written the moment the tool is used.

Common pack mistakes

The first mistake is leaving the management pack parameter at its default and trusting administrators not to use AWR or the tuning advisor, which the everyday workflow makes almost inevitable. The second is licensing the Tuning Pack alone without the Diagnostics Pack it depends on, which leaves the database underlicensed for the capability it uses. The third is never monitoring the feature usage views, so activations accumulate silently until an audit reads them.

The fourth is treating the packs as included features because they appear in the standard console, when they are separately licensed options that stack on the Enterprise Edition per core model. Avoiding these is a matter of setting the pack parameter deliberately, licensing both packs together when tuning is needed, and monitoring usage continuously. The packs are the clearest case in the whole estate where a single configuration choice prevents a large, predictable finding.

Free alternatives to the packs

Much of the performance work that activates the Diagnostics and Tuning packs can be done with tools that do not require them. The base database exposes performance views and statistics that predate the packs and remain free to use, and a skilled administrator can diagnose most performance problems through them without touching AWR or the tuning advisor. Manual execution plan analysis and the free statistics views cover a large part of what the packs automate.

The trade off is effort. The packs automate and present the analysis that the free tools require an administrator to assemble by hand, so avoiding them costs skilled time. For estates that genuinely do not need the automation, building performance practice on the free tools removes the audit risk entirely. For estates that rely on the automation, the answer is to license the packs deliberately rather than to use them by accident, a decision that should be made explicitly as part of the option stack governance in the Enterprise Edition article.

The packs in cloud and engineered systems

The licensing of the Diagnostics and Tuning packs changes in some Oracle Cloud and engineered system contexts. Certain Oracle Cloud database services include the management packs as part of the service rather than as separate licences, which removes the inadvertent use risk for those deployments because the entitlement is built in. The same is true of some engineered system configurations where the packs are bundled.

The trap is assuming this bundling extends to on premise or third party cloud deployments, where it does not. A database administrator who is used to the packs being included in a cloud service may use the same tools freely on an on premise Enterprise Edition database and trigger a finding. The entitlement must be confirmed for each specific environment rather than assumed from another, and the on premise default remains that the packs are separately licensed, as the options audit article sets out.