The view records detection and not intensity, so a feature touched once bills exactly like a feature used daily

The scripts are read only and they change nothing. What they collect is a history the database has been filling in since day one, and the central view records detection rather than intensity, which is why a single accidental click prices identically to a production dependency.

Prepared by Redress Compliance · August 16, 2026 · Oracle advisory. 30 to 40 Oracle measurement reviews handled, 2024 to 2025.

They are not one script. They are a family, and the family member you are asked to run tells you what the review is really about before anyone says so.

• DBA_FEATURE_USAGE_STATISTICS drives most options findings, and the mapping from its feature rows to priced products lives in options_packs_usage_statistics.sql, from My Oracle Support Doc ID 1317265.1.
• The view records detection rather than intensity. A single administrative click, a default setting, or a one time test registers identically to continuous production use, and the report does not distinguish them.
• Collection runs weekly under MMON, so a database patched or restarted in the current week can read empty. Force a sample before you trust any output, including your own.
• The output mixes collected fact with drawn inference, and only the facts are hard. The inferences are where the money is argued, and they are the part that moves under context.
• Context is evidence, not excuse. When a feature was enabled, by whom, on what environment, and whether it was ever used in production are all legitimate parts of the record.
• Remediation before the collection is worth more than argument after it, because a disabled option with a documented date is a different conversation from a detected option with a price attached.

The uncomfortable feature of Oracle options findings is how badly they map onto anything a reasonable person would call misuse. Across the measurement reviews handled, accidental options usage drove 30 to 60 percent of the initial finding. Not unlicensed production deployment, not deliberate avoidance, but a feature that was touched once and recorded forever. The mechanism is not hidden and it is not malicious: DBA_FEATURE_USAGE_STATISTICS exists to record that a capability was exercised, and it was never designed to weigh a test against a dependency. It records detection. Pricing is applied to detection. Those two facts together generate most of the exposure.

Understanding that changes what the defence actually is. Arguing that a finding is unfair does not work, because the finding is an accurate report of what the view contains. What works is context and remediation, which together removed 25 to 50 percent of raw exposure in our file. Context establishes what the detection actually represents: which environment, which date, which account, whether the feature ever served a production workload. Remediation establishes that it is gone and cannot recur. Neither disputes the data. Both change what the data means, and since the output mixes collected fact with drawn inference, the inference layer is precisely where a well evidenced position moves the number.

The timing asymmetry is the part most estates get wrong. Self collection before Oracle asks bought 8 to 12 weeks of remediation runway in the engagements reviewed, and that window is the difference between two entirely different conversations. Inside it, an option nobody needed gets disabled, documented, and dated, and the finding never forms. Outside it, the same option is already on a report with a list price beside it, and every subsequent discussion is about reducing a number rather than about whether the number should exist. The scripts being read only is what makes the early collection possible; there is no technical reason not to run them on your own estate today.

One procedural failure recurred almost universally and costs more than any technical detail. Almost nobody had asked, in writing, which script version and which environments were in scope before the first collection ran. That is contract adherence rather than obstruction: the audit clause defines the boundary of what Oracle can require, and agreeing scope, script version, and recipient list in writing before running anything is ordinary diligence. A collection run without those agreements has established a scope by conduct that no one negotiated. The clause mechanics sit in the Oracle audit overview, the line by line challenge in fighting an audit claim, and the settlement economics in the audit negotiation guide.

• Agree the script version in writing before anything runs, since versions differ in what they collect and a later version can widen the picture retroactively.
• Agree which environments are in scope, naming production, staging, development, and disaster recovery explicitly rather than letting the collection define the boundary by conduct.
• Agree the recipient list, so output does not travel further inside Oracle than the review requires.
• Force an MMON sample before trusting any run, because a database patched or restarted in the current week reads empty and an empty read is not a clean read.
• Run it yourself first. The scripts are read only, so there is no technical barrier, and the 8 to 12 week runway only exists if you collect before you are asked.
• Keep the raw output and the interpretation separate, since the facts and the inferences will be argued differently and mixing them weakens both.

Across roughly 30 to 40 Oracle measurement reviews handled, the script output was almost never the final number:

Self collection before Oracle gave buyers 8 to 12 weeks of remediation runway. And almost nobody had asked, in writing, which script version and which environments were in scope before the first collection ran, which is the cheapest protection available and the one most often skipped.

The scripts capture the database version and edition, installed options, management pack usage, feature history, and the counters Oracle uses to size a user based metric. They read views the application layer never touches, which is why the history exists whether or not anyone has ever looked at it.

Watch the briefing · 3:16What the SAP Settlement Means for Oracle: Most Likely, You Are NextWhy measurement requests are arriving more often, and what a prepared estate does differently.

What are Oracle license compliance scripts?

SQL collection programs that read internal data dictionary views and produce a usage report. Oracle License Management Services provides them during a formal review and the output becomes the basis of the compliance position. They are a family rather than a single script.

Do the scripts change anything in the database?

No. They are read only. They query data dictionary views, write a text or spool file, and modify nothing. That removes the technical objection to running them yourself, which is the most valuable thing you can do before a review begins.

Why does a feature used once cost the same as one used daily?

Because DBA_FEATURE_USAGE_STATISTICS records detection rather than intensity. The view exists to note that a capability was exercised, not to weigh how much. Pricing is then applied to detection, which is why accidental usage drove 30 to 60 percent of the initial finding in our reviews.

Which view drives options findings?

DBA_FEATURE_USAGE_STATISTICS, with the mapping from its feature rows to priced products living in options_packs_usage_statistics.sql, from My Oracle Support Doc ID 1317265.1. That script is the one to run on your own estate first.

Why can a collection read empty?

Because collection runs weekly under MMON, so a database patched or restarted during the current week may have no data yet. An empty read is not a clean read. Force a sample before trusting any output, including your own.

What actually reduces a finding?

Context and remediation, which together removed 25 to 50 percent of raw exposure in our file. The output mixes collected fact with drawn inference, and only the facts are hard. The inference layer is where a well evidenced position moves the number.

What context counts as evidence?

When a feature was enabled, by whom, on which environment, and whether it ever served a production workload. None of that disputes the collected data. All of it changes what the data means, which is a different and more productive argument.

Why collect before Oracle asks?

It bought 8 to 12 weeks of remediation runway in the engagements reviewed. Inside that window an unneeded option gets disabled, documented, and dated and the finding never forms. Outside it, the same option is already on a report with a list price beside it.

What should be agreed before running anything for Oracle?

The script version, the environments in scope, and the recipient list, all in writing. Almost nobody did this. It is contract adherence rather than obstruction, and a collection run without it establishes a scope by conduct that nobody negotiated.

Does the request itself tell us anything?

A great deal. Being asked for the options and packs report means the review is about options and packs, the highest value finding type. The wider measurement collection means a full database position is being built. A server worksheet means the processor count is being established and virtualization is in play.