Setting CONTROL_MANAGEMENT_PACK_ACCESS to Stop Diagnostic and Tuning Pack Findings Going Forward

One dynamic parameter closes the door on roughly $12,500 per processor of unlicensed pack exposure, but only from the moment you set it. This guide shows the exact syntax, the scope traps in Multitenant, the known false positives, and how to turn the change into evidence an auditor cannot ignore.

The Parameter Is the Control Point, and Oracle Knows It

Since 11g, Oracle has designated one initialization parameter as the sanctioned gate on Diagnostics and Tuning Pack functionality: the Licensing Information guide states plainly that "beginning with Oracle Database 11g, the CONTROL_MANAGEMENT_PACK_ACCESS initialization parameter controls access to the Diagnostic Pack and Tuning Pack." That matters because it is Oracle's control, not a third-party hack, so nobody in an audit can argue you disabled something you were not entitled to disable. The permitted values are exactly three: NONE, DIAGNOSTIC, and DIAGNOSTIC+TUNING. Note what is missing. There is no Tuning-only value, because the documentation is explicit that "a license for DIAGNOSTIC is required for enabling the TUNING pack." If you want SQL Tuning Advisor, you are buying both packs, full stop. The 26ai Reference (section 2.59) also sets out the default that creates most of the damage we see in the field: Enterprise Edition defaults to DIAGNOSTIC+TUNING, as does Oracle AI Database Free, while all other editions default to NONE. In other words, every EE database you provisioned in the last fifteen years shipped with both packs open unless somebody deliberately closed them. In our audit-defense casework this single default is the largest source of accidental Diagnostics and Tuning findings in EE estates, ahead of Enterprise Manager clicks and ahead of scripted AWR reports.

Every Enterprise Edition database you provisioned in the last fifteen years shipped with both packs open unless somebody deliberately closed them.

The buyer consequence is sharper than most DBAs realize. Oracle's own Options and Management Packs Usage Reporting script reads this parameter directly and reports it alongside feature usage, meaning the auditor sees your setting next to your AWR and ADDM pack signatures in the same output. A database left at DIAGNOSTIC+TUNING with pack rows showing TRUE is read as intent: access was granted, access was used. Leave the default in place and you have volunteered the vendor's best argument.

The Exact Change: Syntax, Scope, and the Multitenant Trap

The command is one line, and the second half of it is the half people get wrong:

• ALTER SYSTEM SET control_management_pack_access=NONE SCOPE=BOTH;
• Verify with SHOW PARAMETER control_management_pack_access and separately confirm the SPFILE value, not just the running instance.

Omit SCOPE=BOTH and the parameter reverts to its original value at the next restart. That is the most common failed remediation we encounter: a change applied months ago, an intervening patch cycle, a quiet reversion, and a fresh set of pack rows accumulating for the period the customer believed was clean. Worse, the DBA remembers making the change and states so in writing to the auditor, which converts a configuration mistake into a credibility problem. The good news is that the parameter is dynamic, so no restart is required to take effect, meaning there is no maintenance-window excuse for delay. Set it with SCOPE=BOTH, then re-verify after the next planned bounce and record both checks.

Multitenant is where scope becomes a real trap. The 26ai Reference lists this parameter as "Modifiable in a PDB: No." You cannot run it inside a pluggable database, and you cannot engineer per-PDB exceptions with it: one CDB-level value governs every container underneath. If your commercial position is that three PDBs are licensed for Diagnostics and eleven are not, this parameter will not give you that split, and no combination of scopes will. Plan accordingly, either by segregating unlicensed workloads into their own CDB or by accepting a licensed value across the whole container. The same isolation issue affects your evidence: Oracle's reporting script, when connected to a PDB, sees only local data, so estate-wide proof requires collection in every container plus the root.

Two further scope failures show up repeatedly in RAC and Data Guard estates. In RAC, every instance needs the same value, and a SID-specific setting left over from earlier tuning work will silently keep one node open. In Data Guard, the standby has its own SPFILE, and standbys are routinely missed entirely, which is how customers end up with pack usage recorded on a database nobody thought was running anything. Check the standby explicitly, before and after switchover, and capture the parameter alongside the DBA_FEATURE_USAGE_STATISTICS output from each node so your remediation record covers the whole cluster and not just the instance you happened to be connected to.

What NONE Actually Stops, Feature by Feature

The single most useful distinction when you set CONTROL_MANAGEMENT_PACK_ACCESS=NONE is between collection and reporting. Oracle blocks both, but not in the same way, and the difference is what confuses DBAs into thinking the change did not take. Querying V$ACTIVE_SESSION_HISTORY returns zero rows the moment the parameter flips, because the in-memory ASH buffer is gated at read time. Documented tests confirm a plain count against that view returning 0 with NONE in place, and returning live data again the instant the value goes back to DIAGNOSTIC. AWR behaves differently: the snapshot job keeps running on schedule and keeps creating snapshot IDs, but the snapshots are hollow. No new rows land in DBA_HIST_ACTIVE_SESS_HISTORY or any other DBA_HIST_* view. This has been the documented behavior since 11gR1, and it matters for audit defense because a snapshot count alone proves nothing about pack usage. The advisor and repository APIs are blocked server-side, which is the strongest part of the control: a developer cannot accidentally re-enable pack functionality from a session, because the block is not a permission you can grant around.

Two gaps deserve explicit attention because vendors raise them. First, the parameter is a database-side control and does nothing to Enterprise Manager. Oracle's own licensing documentation describes removing Diagnostics Pack access in the Grid Control or Cloud Control console, which disables the associated links and tabs. If you leave EM pack access granted, you have left a second door open and a second evidence trail. Second, Real-Time SQL Monitoring has a tracking defect history, so plan for it to appear in your usage view regardless. Treat both as separate work items in the remediation record described in the guide to which management pack rows actually cost you, not as reasons to doubt the parameter change itself.

What It Does Not Retroactively Clear

Here is the part vendors count on you misunderstanding. NONE stops future accrual. It does not touch a single historical row in DBA_FEATURE_USAGE_STATISTICS. FIRST_USAGE_DATE, LAST_USAGE_DATE, LAST_SAMPLE_DATE, TOTAL_SAMPLES and DETECTED_USAGES all persist exactly as they were, because the weekly refresh job only updates the current row set. It does not rewrite prior samples and it does not delete anything. Anyone who tells you the parameter erases history, whether that is a well-meaning DBA or an Oracle field resource looking for a quick close, is wrong, and you should not build a negotiating position on it.

What you do get is a clean forward window, and it is worth more than people assume. After the next sample, CURRENTLY_USED flips to FALSE and CURRENT_USAGE drops to zero for the pack rows, because both columns describe the last sampling interval (one week by default), not the lifetime of the database. The historical columns remain the auditor's claim basis. The forward columns become your remediation proof. That split is the entire negotiation: Oracle will argue DETECTED_USAGES and a FIRST_USAGE_DATE from 2019 establish a licensable deployment, while your case is that the usage was incidental, is now technically impossible, and the current-period columns show it. The distinction between those two column families is set out in the DETECTED_USAGES versus CURRENTLY_USED analysis, and the argument that a handful of touches is not a deployment is built from FIRST_USAGE_DATE and LAST_USAGE_DATE evidence.

NONE gives you a clean forward window, not a clean record, and only one of those two things is yours to control.

In our negotiation experience, the historical rows rarely disappear from a claim, but they do get repriced. A pack row with a single-digit DETECTED_USAGES count, a FIRST_USAGE_DATE tied to a documented patching or troubleshooting event, and a hard parameter block from a dated change record is a very different conversation from a row showing continuous weekly usage across three years. Set the parameter, then spend your effort on characterizing the history rather than pretending you deleted it.

Timestamping the Remediation So It Counts as Evidence

The parameter change takes effect the moment you issue it, but the evidence that it took effect does not appear until the hidden weekly job runs. Waiting seven days is a mistake, because if an audit letter lands on day three you have a changed SPFILE and a feature usage view that still says TRUE. Build the dated evidence pack in a single maintenance window instead. Step one: extract DBA_FEATURE_USAGE_STATISTICS in full (name, version, detected_usages, currently_used, first_usage_date, last_usage_date, last_sample_date, total_samples) plus SHOW PARAMETER control_management_pack_access, and save both to a timestamped file with the DBID and instance name in the header. Step two: apply ALTER SYSTEM SET control_management_pack_access=NONE SCOPE=BOTH; at the CDB root, since the parameter is not modifiable in a PDB. Step three: force the sample rather than wait, using the method documented in MOS Doc 1629485.1, ALTER SESSION SET "_SWRF_TEST_ACTION"=53;, then confirm that MAX(LAST_SAMPLE_DATE) from the view has advanced to today and re-extract the same columns. You now hold a before file and an after file separated by minutes, with the parameter change sitting between them.

Collect per container. Oracle's own reporting script, when connected to a PDB, sees only local data because Multitenant isolation blocks cross container visibility, so a single root level extract will not prove anything about the twenty pluggables underneath it. Loop the collection across the CDB root and every PDB, and keep the output files named by container. Retain three artifacts alongside the extracts: the SPFILE or a CREATE PFILE dump showing the persisted value, the alert log lines recording the ALTER SYSTEM (Oracle writes parameter changes there with a timestamp, which is independent corroboration you did not author), and a change ticket carrying a named approver, the date, the business justification, and the affected instance list. Understanding how the underlying columns are read matters here, and our note on how DETECTED_USAGES and CURRENTLY_USED are weighed differently explains which fields an auditor will pull first.

One more reason to own the evidence rather than rely on Oracle's tooling: the MOS Options and Management Packs Usage Reporting script has not been maintained for recent releases and, per Version 1's licensing guidance updated January 2026, should not be used for license compliance assessment on 23c and later. If the vendor's instrument is stale, your dated, per container, self collected pack is the better record, and in twenty five years of these discussions the party holding the contemporaneous timestamped extract sets the baseline.

Known False Positives That Survive the Change

Setting NONE does not guarantee a clean report, and you should assume it will not. Oracle has published MOS Doc ID 1983280.1, titled "Tuning Pack - SQL Profiles Shows TRUE even Though Control_management_pack_access is Disabled," covering Enterprise Edition 11.2.0.3 and later. Separately, Bug 23734270 records that DBA_FEATURE_USAGE_STATISTICS shows permanent usage of Real-Time SQL Monitoring. Both rows will appear in a post remediation extract, both are Tuning and Diagnostics Pack signatures, and neither reflects a user action after your change. An auditor running the script will present them as findings unless you get there first.

The buyer-side move is pre-emption, in writing, before the script runs. Include the affected rows in your own submitted report, annotate each with the MOS document or bug number, and state plainly that the row is a known product defect rather than a usage event. Attach the parameter proof and the forced sample date so the sequence is unambiguous. Then hold the line: a defect acknowledged by the vendor in its own support library is not a licensable event, and you should decline to price it. Oracle field auditors will not volunteer these references, so the rebuttal burden sits entirely with you, and preparing it after the findings letter arrives costs far more ground than preparing it beforehand. The same pattern of stale or sticky rows appears elsewhere in the view, as covered in our analysis of why Partitioning still reports as used after the objects are dropped. Treat every surviving TRUE as something to explain in advance, not something to argue about later.

What the Exposure Is Worth If You Do Nothing

Run the arithmetic before you decide the parameter change is optional. Under the 2026 Oracle Technology Price List, Diagnostics Pack lists at roughly $7,500 per processor ($150 per Named User Plus) and Tuning Pack at roughly $5,000 per processor ($100 per NUP), each carrying the standard 22% annual support uplift. Because Tuning cannot be licensed or enabled without Diagnostics, the realistic per-processor claim is $12,500, not $5,000, whenever a tuning advisor row appears in the pack signatures inside DBA_FEATURE_USAGE_STATISTICS. Packs follow the metric of the underlying database license, so a database licensed by processor generates a processor pack claim, and NUP-licensed databases inherit the same 25-users-per-processor minimum applied against Enterprise Edition at $47,500 per processor. Multinational estates should note that non-US price lists (the Japan list being the common comparison point) are published in local currency and do not simply track the USD figures at spot rate, so a global true-up quote assembled by Oracle's LMS team is worth re-pricing country by country rather than accepting a single converted total.

That $200,000 list claim on one unremediated 16-processor cluster is the number to hold in your head. Oracle rarely stops at the license figure: in our experience across audit defense engagements, the opening position typically bundles backdated support from the FIRST_USAGE_DATE recorded in the feature usage view, which is why a 2019 first-touch date on a 2026 audit turns a six-figure claim into a seven-figure one. The parameter change costs you one ALTER SYSTEM statement and a change ticket. Weighed against $12,500 per processor plus compounding support, it is the cheapest insurance in the Oracle estate, and the only reason to hesitate is if a database genuinely needs and already holds the license.

What to Do First

Work this in a 48-hour sequence and resist the temptation to fix before you capture. First, extract and archive DBA_FEATURE_USAGE_STATISTICS and the current CONTROL_MANAGEMENT_PACK_ACCESS value for every instance and every container, including standbys and non-production, and hash or timestamp the output. You cannot prove what a change fixed if you never recorded the starting state, and the FIRST_USAGE_DATE and LAST_USAGE_DATE columns are the fields Oracle will read back to you. Second, identify which databases genuinely require Diagnostics for operational reasons and confirm in writing whether those instances are covered by existing pack entitlements. Third, apply NONE with SCOPE=BOTH everywhere else, at CDB level in Multitenant estates, and include physical standbys, which auditors count separately. Fourth, force a refresh so the post-change sample lands the same day rather than up to a week later. Fifth, file the change record with approver, ticket number, and the before-and-after query output attached.

The negotiation point matters as much as the technical one. Bring completed remediation evidence to the table before Oracle proposes a purchase, because a documented, dated control converts an open compliance gap into a closed one, and it removes the argument that usage is ongoing. And treat any support request to set the parameter back to DIAGNOSTIC as a licensing decision, not a DBA decision: never revert without written sign-off from whoever owns the Oracle contract.

A documented, dated parameter change converts an open compliance gap into a closed one, and it removes Oracle's argument that the usage is ongoing.

Related advisory: the full topic guide.

Frequently asked questions

Does setting CONTROL_MANAGEMENT_PACK_ACCESS=NONE remove past pack usage from an audit?

No. The parameter stops future collection and flips CURRENTLY_USED to false at the next weekly sample, but FIRST_USAGE_DATE, LAST_USAGE_DATE, TOTAL_SAMPLES and DETECTED_USAGES remain in DBA_FEATURE_USAGE_STATISTICS. Oracle can and will cite those historical rows. Treat NONE as a forward-looking control and handle the historical record as a separate negotiation.

Can I set the parameter to NONE in one PDB and leave it enabled in another?

No. Oracle documents the parameter as not modifiable in a PDB, so it is set at the CDB level and applies to all containers. If some PDBs need Diagnostics and others must be excluded, you either license the whole CDB footprint or separate the workloads into different container databases.

Does the change require a database restart?

No, the parameter is dynamic and takes effect immediately. However, you must use SCOPE=BOTH so the value persists in the SPFILE; without it the setting reverts to the previous value on the next restart. Apply it on every RAC instance and every standby SPFILE as well.

Is there a way to enable Tuning Pack without Diagnostics Pack?

No. There is no Tuning-only value for the parameter, and Oracle documents that a Diagnostics license is required to enable Tuning. Any Tuning Pack purchase is effectively a purchase of both, roughly $12,500 per processor at 2026 list before discount.

Why does my report still show Tuning Pack usage after setting NONE?

MOS Doc 1983280.1 documents Tuning Pack SQL Profiles reporting TRUE on 11.2.0.3 and later even when the parameter is disabled, and Bug 23734270 covers persistent Real-Time SQL Monitoring rows. These are tracking defects, not usage. Cite the document numbers in writing before the audit script is run rather than arguing after the finding lands.

What evidence should I keep to prove the remediation date?

Keep a pre-change and post-change extract of DBA_FEATURE_USAGE_STATISTICS per container, SHOW PARAMETER output, the SPFILE entry, the alert log line, and a change ticket with named approver and timestamp. Force a refresh using MOS 1629485.1 so the post-change sample is dated rather than waiting for the weekly job. That package establishes the clean window.