Ask any Oracle DBA what they pull up first when a database is slow, and the answer is almost always the same. Run an AWR report. Check ASH for what was actually running during the bad window. Let ADDM tell you where the time went. It is muscle memory, and it is also, in most environments I have walked into, completely unlicensed.

The setting nobody set

Oracle Database Enterprise Edition ships with the Diagnostics Pack and Tuning Pack enabled by default through the CONTROL_MANAGEMENT_PACK_ACCESS parameter. Nobody has to turn these on. They are already on. A DBA does not need to make a deliberate choice to use a licensed feature. They need to run a single AWR report, once, during a legitimate production issue at two in the morning, and Oracle’s own feature usage tracking has now recorded a licensable event that does not go away.

That tracking lives in DBA_FEATURE_USAGE_STATISTICS, and it does not forget. It records first use and last use for every tracked feature, and it does not care whether the use was three years ago on a system that has since been decommissioned. If it shows up in that view, an auditor will ask about it, and past usage does not expire just because the need for it did.

What actually trips the wire

The Diagnostics Pack covers AWR, ADDM, and Active Session History. Generating an AWR report, viewing ADDM findings, or querying ASH views all count, and it does not matter whether a person did it manually or a third party monitoring tool did it on their behalf through a database connection. If that tool queries the same views, the usage attributes to your database the same way.

The Tuning Pack covers SQL Tuning Advisor, SQL Access Advisor, and automatic SQL tuning. It has a hard dependency on the Diagnostics Pack, so you cannot license one without the other underneath it, though you can license the Diagnostics Pack alone if you want the visibility without the automated advisors. Auto task maintenance jobs, which ship enabled by default in a lot of environments, can generate Tuning Pack usage on their own without a person deliberately invoking anything.

I have inherited more than one environment where a previous DBA enabled a feature like this years earlier, for a reason nobody documented, and the environment carried that exposure silently until someone finally reviewed the feature usage data. It is rarely malicious. It is almost always someone doing their job the way they were trained to do it, on a system where nobody had connected performance troubleshooting to the licensing consequence of that troubleshooting.

The workaround, and its real limits

The standard advice is to set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on any database that is not licensed for these packs, and fall back to Statspack for performance snapshots. Statspack is free, and it genuinely does not carry the same licensing trigger. It also does not give you ASH, does not sample active sessions at the granularity AWR does, and does not give you the historical baseline comparison that makes root cause analysis fast instead of guesswork. It is a real mitigation, not a real substitute, and treating it as equivalent to AWR is how a performance investigation on an unlicensed system takes three times as long as it should.

Third party monitoring tools carry the same nuance people assume solves the problem and does not. If the tool connects to your database and reads from the same underlying views AWR depends on, the usage still attributes to your database. The vendor’s marketing rarely leads with that detail.

What I actually check first in a new engagement

Before I recommend anything about performance tuning strategy, I pull DBA_FEATURE_USAGE_STATISTICS and compare it against the actual license entitlement on record. That single query tells me whether the environment has been quietly running exposed for years, and it changes how I sequence everything that follows. There is no point building a tuning roadmap around AWR data if the database is not licensed to be generating that data in the first place. That conversation needs to happen first, not as a footnote after the fact.

This is also the exact reason I built explicit license acknowledgment into how Regent handles AWR polling. Before Regent touches performance data on your environment, it makes you confirm in configuration that the Diagnostics Pack is actually licensed. Not because the software cannot technically run without that confirmation, but because a tool that pulls AWR data on your behalf and never mentions the licensing dependency is quietly inheriting your exposure into its own recommendations. I would rather slow the setup down by one step than build a product that repeats the same silent assumption that gets environments in trouble in the first place.

If you have not pulled your own feature usage statistics recently, that is a five minute query with a much longer tail if you skip it. The Oracle License Risk Assessment covers this along with the rest of your licensing position, but you do not need to wait for an engagement to run that one check yourself.

Have a question about what your own environment is actually showing?

The discovery call is free, 20 minutes, and focused entirely on your situation. If an assessment does not make sense, I will tell you that in the first five minutes.