Oracle license compliance scripts, explained. A feature used once is priced like one used daily.

Oracle's compliance scripts are read only and report a feature history your databases have kept since installation. The central view records that a priced option was used and nothing about how much, so one accidental test can cost as much as daily production use.

Oracle's license compliance scripts read what your databases have already recorded about themselves. They change nothing, and most of what they report has been accumulating since each database was installed. The expensive surprise sits in one view, DBA_FEATURE_USAGE_STATISTICS, which notes that a priced feature was used and keeps no measure of how much.

I worked at Oracle before we started Redress, and this collection is where most Oracle database claims begin. This page explains what each script collects, how a single detection becomes a license claim, and how to run the same collection yourself before Oracle asks.

What are Oracle license compliance scripts?

They are SQL and operating system queries that Oracle's audit team asks you to run during a formal license review. The output is a usage report, and it becomes the basis of Oracle's compliance position. Oracle packages the current set as the Oracle Collection Tool.

The team behind them is Oracle License Management Services (LMS), which Oracle now also presents as Global Licensing and Advisory Services (GLAS). The scripts come as a family, and the member you are asked to run tells you what the review is about before anyone says so.

Oracle may also send its Global Deployment Matrix, an online form for listing the Oracle programs you run. Treat it as part of the same collection, because every line you enter is a deployment you have confirmed in writing.

Do the scripts change anything in your database?

No. They query data dictionary views, write a text or spool file, and make no modification to the database. Oracle describes the Collection Tool output as human readable, so you can read every line before it leaves your building.

Being read only matters in two ways. It removes the technical objection to running the scripts yourself, which is the most valuable step you can take before a review begins. It also means the data exists whether or not you ever run them, because the database has been recording feature usage since installation.

Can a verified third party tool replace the scripts?

For some products, yes. Oracle runs a verification program for third party tools, including Flexera, Snow Software and ServiceNow, and has validated their usage data for specific Oracle products. Ask Oracle in writing which products your tool release covers before you offer its output in place of the scripts.

How does DBA_FEATURE_USAGE_STATISTICS record option and pack usage?

It records that a feature was detected, with a first and a last date, and stores nothing about volume. This view drives most options findings. The script from My Oracle Support Doc ID 1317265.1, options_packs_usage_statistics.sql, maps its feature rows to the priced options and management packs.

• NAME and VERSION. The feature and the database release in which it was tracked, so an upgraded database carries rows from older releases.
• DETECTED_USAGES. How many samples found the feature in use. It counts weeks in which usage appeared; transactions, users and data volume are never recorded.
• CURRENTLY_USED. TRUE or FALSE for the most recent sample only.
• FIRST_USAGE_DATE and LAST_USAGE_DATE. The first and last samples that detected use. Oracle reads these dates when it decides how many years of back support to price.
• LAST_SAMPLE_DATE. When the database last checked. A date weeks or years old means the view is stale.
• FEATURE_INFO and AUX_COUNT. Feature specific detail, often the best evidence of what happened.

The difference between the two usage columns is covered in detected versus currently used, and the date columns in first and last sample dates.

Why is one test priced like years of production use?

The view was built to note that a capability was exercised, and Oracle applies its prices to that note. A single administrative click, a default setting or a one time test registers the same way as continuous production use. The report does not tell them apart, and neither does the license metric.

Why can a collection read empty?

Collection runs weekly under the MMON background process. A database patched or restarted in the current week can show no recent sample, and an empty read can hide real usage. Check LAST_SAMPLE_DATE on every database before you trust any output, including your own.

To force a sample, DBAs commonly run the internal procedure DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING(SYSDATE) in a change window. It is undocumented, so query LAST_SAMPLE_DATE again afterward to confirm a new sample was taken. The gaps in feature usage sampling page covers the edge cases.

What does a single detection cost at list price?

It costs a full option license for every processor, or every named user, that the database itself must be licensed for, whatever the usage count says. Options follow the metric and quantity of the database they run on. A hypothetical example shows how far apart intensity and price can sit.

Say a production database runs on one server with two 16 core Intel Xeon Gold chips. Oracle's core factor table rates those chips at 0.5, so 32 cores become 16 processor licenses. The usage view shows three priced rows.

The single export is the most expensive line on the claim, and nothing in the report says it was a one off. What changes that outcome is the context you record for each row. The core factor table and the Oracle price list carry the full rates, and Enterprise Edition options pricing covers the other options.

How do you run the scripts on your own databases first?

Download the script from My Oracle Support, run it on every database yourself, and read the result before Oracle sees anything. It is read only, so the only preparation is database access and a change window for the forced sample.

1. Build the list. Every database, with its host, environment and owner, including standby and disaster recovery copies.
2. Check the sample date. Query LAST_SAMPLE_DATE and force a sample wherever it is more than a week old.
3. Run options_packs_usage_statistics.sql in SQL*Plus and keep the spool file exactly as produced.
4. Read the PRODUCT USAGE section first. It lists each priced option or pack with its usage status and its first and last usage dates.
5. Then read FEATURE USAGE DETAILS. It shows which feature row triggered each product, with DETECTED_USAGES and TOTAL_SAMPLES.
6. Record the context for every detected row while the people who made the change still remember it.

Which status values in the output matter?

The USAGE column sorts rows into states that a review treats differently. NO_USAGE means nothing was detected. The other values separate usage found in the latest sample from usage found only in earlier samples, and past use still counts in a review.

SUPPRESSED_DUE_TO_BUG marks detections the script itself discounts because of a known Oracle bug; keep those rows and the reason with your evidence. Oracle also keeps a My Oracle Support note listing bugs that cause false detections, so check any surprising row against it. Our guide to the script output walks through each section.

Which mistakes cost the most when running the scripts?

• Trusting an empty read. A restarted database with no recent sample looks clean, then fills with rows you did not plan for.
• Mixing output and interpretation. Keep the raw spool file untouched and put your notes in a separate document. The facts and the inferences will be argued differently, and mixing them weakens both.
• Forgetting copies. Clones and databases restored from backup carry the source database's feature history, so each one needs its own run.
• Switching features off with no record. Disabling an option without a dated change ticket leaves you with the detection and no proof of when use stopped.
• Leaving the pack parameter at its default. Enterprise Edition ships with CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING, so nothing stops a DBA or a monitoring tool from using the packs before anyone has bought them. See controlling Diagnostics and Tuning Pack access.

How do you separate collected fact from inference in the output?

Split the report into what the scripts collected and what Oracle concluded from it, and argue only the second part. The collected facts are hard: a row, a date, a count. The inferences decide the product, the processor count and the years charged, and that is where the money is argued.

Context counts as evidence. For every detected row, these points are a legitimate part of the record:

• When the feature was enabled, and by which account.
• Which environment the database served: production, staging, development or disaster recovery.
• Whether the feature ever served a production workload, or only a test.
• Whether it has since been disabled, with the change ticket and date.

Remediation before the collection is worth more than argument after it. A disabled option with a documented date is a different conversation from a detected option with a price attached. Once a claim has arrived, fighting an audit claim covers the line by line challenge.

Should you wait until Oracle asks before running the scripts?

A common piece of advice is to leave the scripts alone until a formal notice arrives, because output you create can be used against you. We disagree. The history is already in the view, and Oracle will read it either way, so running the scripts first changes only who reads it first and how long you have to act.

Fixing a feature does not erase its past rows, but it stops new usage and gives you a dated record. Collect now, keep the output internal, and fix what you find.

What should you agree with Oracle before running anything?

Agree the script version, the environments in scope and the recipient list, in writing, before the first collection runs. This is contract adherence rather than obstruction. The audit clause defines what Oracle can require, and a collection run without these agreements sets a scope by conduct that no one negotiated.

• Script version. Name it, since versions differ in what they collect and a later one can widen the picture after the fact.
• Environments. List production, staging, development and disaster recovery explicitly, by database name, so the collection does not draw the boundary for you.
• Recipients. Name who at Oracle receives the output, so it does not travel further inside Oracle than the review requires.
• Time to review. Ask for a period to read the output and add context before Oracle drafts any finding.

The clause mechanics are in the Oracle audit overview, and redlining the audit clause lists the terms to change at your next contract.

What will Oracle's auditors say, and how should you reply?

What have we seen in Oracle measurement reviews in 2024 to 2025?

Across roughly 30 to 40 Oracle measurement reviews we handled, the script output was almost never the final number. Accidental options usage drove 30 to 60 percent of the initial finding. These were features touched once and recorded permanently, rather than unlicensed production deployment or deliberate avoidance.

Context and remediation removed 25 to 50 percent of raw exposure. That work stayed on the inference layer and left the collected facts alone. Arguing that a finding is unfair rarely works, because the finding is an accurate report of what the view contains.

The view records that a feature was used. It was never designed to weigh a test against a dependency.

Self collection before Oracle asked gave buyers 8 to 12 weeks of remediation runway. Inside that window, an option no one needed got disabled, documented and dated, and the finding never formed. Outside it, the option was already on a report with a list price beside it, and every later discussion was about reducing a number.

One procedural gap recurred in almost every review: almost no buyer had asked in writing which script version and which environments were in scope before the first collection ran. It is the cheapest protection available and the one most often skipped. The settlement side is covered in the audit negotiation guide.

What else do the scripts capture?

Beyond options and packs, they capture the database version and edition, installed options, management pack usage, feature history, and the counters Oracle uses to size a user based metric such as Named User Plus. They read views the application layer never touches, which is why the history exists whether or not anyone has looked at it.

What to do next

1. This month. Run the options and packs report from Doc ID 1317265.1 on your own databases. It is read only and changes nothing.
2. Before each run. Check LAST_SAMPLE_DATE and force a sample, so a recently patched or restarted database does not give you false comfort.
3. For every detected row. Record environment, date, account and whether the feature ever served production.
4. Within the runway. Disable what no one needs, set CONTROL_MANAGEMENT_PACK_ACCESS to match the packs you own, and file the change date.
5. When a notice arrives. Agree scope, script version and recipient list in writing before anything runs.
6. If a finding lands. Separate the facts from the inferences and price the claim yourself before any settlement talk. The Oracle practice can run the read with you.

Frequently asked questions