Oracle LMS scripts, read column by column. What the database output proves, and what it only suggests.

Oracle's LMS scripts export a handful of dictionary views to CSV. Most columns describe weekly samples, installed binaries or undated peaks, so raw output overstates what you owe until you review it row by row against your entitlement.

Oracle's database collection scripts are read only SQL. They query a small set of data dictionary and dynamic performance views, write the results to delimited text, and leave your SAM team with a folder of CSV files that look far more conclusive than they are.

Oracle's audit function, long known as License Management Services (LMS) and now called Global Licensing and Advisory Services (GLAS), prices its findings from those files. The distance between what a column records and what a finding asserts is where a SAM manager earns their salary, and closing it is a reading exercise long before it becomes a negotiation.

What do Oracle LMS scripts actually collect?

They collect a defined set of data dictionary and dynamic performance views, plus facts about the host, exported as delimited text. Nothing is installed, nothing is modified, and nothing about your contracts is read.

Oracle describes the audit function on its license management services page. The technical definition of every view discussed below is published in the Oracle Database Reference, and that is the document to quote when a finding describes a column wrongly.

The sources that matter, and what each one is for

• DBA_FEATURE_USAGE_STATISTICS. Feature and option usage history. This is the most consequential source in the whole collection.
• CDB_FEATURE_USAGE_STATISTICS. The same data per container on multitenant databases, with a CON_ID column.
• DBA_HIGH_WATER_MARK_STATISTICS. Peak values reached for sessions, CPU count, datafiles, segment size and similar counters.
• V$OPTION and DBA_REGISTRY. What is linked into the binary, and which components are installed.
• V$LICENSE. Session and CPU high water marks, including core and socket counts.
• V$INSTANCE, V$DATABASE, V$VERSION and V$PARAMETER. Identity, edition, version, and the initialization parameters that drive several of the findings.
• DBA_USERS and DBA_ROLE_PRIVS. The account inventory, which auditors use as a proxy for Named User Plus counting.
• Host facts. Hostname, operating system, CPU model, socket and core counts, and any virtualization signature the collector can see.

Run Oracle's own reporting script before you accept a raw dump

Oracle publishes a database options and management packs usage reporting script through My Oracle Support under Doc ID 1317265.1, available from Oracle Support with a valid support identifier. The file is options_packs_usage_statistics.sql, and it reads the same views the collection tool reads.

The difference is that it applies Oracle's own exclusion logic for known benign detections. Its product and feature sections label each line with values such as CURRENT_USAGE, PAST_USAGE, NO_USAGE and SUPPRESSED_DUE_TO_BUG, the last marking detections Oracle itself attributes to a known defect.

• Oracle's own caveat. The script states that its output is for information only and does not represent your license entitlement or requirement. Quote that line back if a raw dump is ever treated as a verdict.
• The gap is the argument. Where the filtered report and the raw dump disagree, document the difference at the time. It is far harder to reconstruct once a finding has been drafted.
• Timing. The script itself warns that the view refreshes weekly, so new usage can take up to seven days to appear in the report. Run it again a week after any change before you rely on the result.

We cover the sequencing in more detail in our note on running the feature usage report before the LMS script.

How do you read DBA_FEATURE_USAGE_STATISTICS column by column?

Read it as a sampling record. Every column in the view describes samples, and misreading that one fact accounts for most of the inflated findings we see.

The sampling model behind every column

The MMON background process samples feature usage on a fixed interval, by default once a week, which is the SAMPLE_INTERVAL of 604800 seconds. Each sample runs Oracle's detection test for the feature and records whether it passed.

DETECTED_USAGES is therefore a count of weeks with a detection. One accidental second inside a week and seven days of continuous production load produce exactly the same value, and no amount of report formatting changes what the counter measured.

Reading a single row in practice

Take a row for a licensable option with DETECTED_USAGES of 1, TOTAL_SAMPLES of 260, CURRENTLY_USED of FALSE, and FIRST_USAGE_DATE equal to LAST_USAGE_DATE. That pattern describes a single touch: one detection in five years of weekly sampling, never repeated, and absent now.

Set it beside a row showing 260 detections out of 260 samples. Both rows can appear in a finding at the same price, yet only the second describes a deployed capability, and the difference is visible in the raw data before anyone argues about it. The first and last usage dates carry most of that story.

CURRENTLY_USED, past usage, and a fair reading

CURRENTLY_USED reports the most recent sample only, and Oracle's options and packs report renders the same state as a verdict of current usage or past usage. Past usage is not automatically free. If a license was required when the use occurred, the obligation existed then.

What past usage does change is scope. A historical detection on a known date, on a known host, is a bounded event to be priced, which is a much smaller claim than a permanent capability licensed on every server you own. We compare the two columns in detected versus currently used.

Version rows and container rows both accumulate

Rows exist per database, per feature and per VERSION. An upgrade starts a new set of rows and leaves the old ones in place, so usage recorded under 11.2.0.4 with none under 19c means the feature has not been seen since the upgrade.

Multitenant databases add a second layer. Root and pluggable database rows both appear in CDB_FEATURE_USAGE_STATISTICS, and adding them together counts the same activity twice. Summing naively across versions and containers is one of the most mechanical over counts in the process, and also one of the easiest to demonstrate.

What does the high water mark view actually prove?

It proves a counter once reached a peak. It does not say when, for how long or why, and that missing context produces the largest single numbers in many findings.

DBA_HIGH_WATER_MARK_STATISTICS carries a NAME, a HIGHWATER and a LAST_VALUE for each VERSION. HIGHWATER is the highest value seen at any sample, and LAST_VALUE is the value at the most recent sample.

The comparison that tells the story

• HIGHWATER close to LAST_VALUE. A steady state. The peak reflects normal operation.
• HIGHWATER far above LAST_VALUE. A spike. Something happened once, and the counter kept it.
• CPU_COUNT at 96 with a last value of 16. The instance once started on a host with 96 CPUs visible to it. That number, and not the current one, is what appears in a finding.
• SESSIONS high water far above steady state. Frequently a connection pool misconfiguration or a load test, which is not a licensing event.

V$LICENSE tells a similar story through SESSIONS_HIGHWATER, CPU_COUNT_HIGHWATER, CPU_CORE_COUNT_HIGHWATER and CPU_SOCKET_COUNT_HIGHWATER. Those V$LICENSE columns run from the last instance startup, while the dictionary view keeps its peaks across restarts. On a virtualized host that has since been resized, the dictionary view is the memory of what the instance once saw.

What a stale peak can cost, worked through

Take a hypothetical Enterprise Edition database on a physical Intel Xeon server with two threads per core. CPU_COUNT reads 16 today, but the high water is 96 from a period when the instance briefly ran on a larger host during a migration.

The 0.5 factor for Intel Xeon comes from Oracle's core factor table, and the $47,500 per processor is Oracle's current list price for Enterprise Edition. Oracle counts processors on the hardware the software ran on, so the real questions are which host the instance sat on and for how long. A counter with no date attached cannot answer either.

How to put a peak in context fairly

Pair every high water value with your own change records. A peak that coincides with a documented migration window, a hardware fault or a one time load test is a fact with an explanation attached.

This is context, and it cuts both ways. If the peak coincides with two years of production, say so and price it. The view supplies a number, and you supply the only available account of what produced it.

Why does V$OPTION list options you never bought?

Because V$OPTION reports what is linked into the Oracle binary. On a default Enterprise Edition installation most separately licensable options read TRUE straight out of the installer, whether or not anyone licensed or used them.

That makes it an installation fact. Treating it as a usage fact or a licensing fact produces findings for options that have never touched a single object in the database.

Three views, three different questions

• V$OPTION. Could this option be used on this instance? On Enterprise Edition the answer is almost always yes.
• DBA_REGISTRY. Which components were installed, and what state are they in?
• DBA_FEATURE_USAGE_STATISTICS. Was anything actually exercised, and in how many sample windows?

A claim built on the first view without the third is not a claim about use. Ask, in writing, which view each line of a finding was derived from.

Unlinking options with chopt, and the contract question underneath

The chopt utility in $ORACLE_HOME/bin unlinks certain options from the binary. On 19c it handles OLAP, Partitioning and Real Application Testing, and 12c releases also offered it for Advanced Analytics. The database must be shut down while it runs, and afterward V$OPTION reports FALSE and the code path is physically unavailable.

Before relying on that argument, read your own agreement. A small number of Oracle contracts define exposure by reference to installation as well as use, and where that language exists the V$OPTION reading matters far more.

Edition rights, and the 2019 change for two former options

Edition entitlements decide the rest. Which features your edition includes and which need a separate license is set out in the database licensing information manual, and it should be the first document open beside the output.

Entitlements also change over time. Effective December 5, 2019, Oracle included Advanced Analytics and Spatial and Graph with Enterprise Edition and Standard Edition 2 for customers on active support, so detections of those features after that date on a supported database need no separate license. Earlier detections still turn on what you owned at the time.

Which 10 error classes should you find before the output leaves?

These 10 classes cover almost everything we see. Work through them before submission, because each one is far cheaper to explain with evidence now than to dispute in a position paper later.

The default that causes the most findings

On Enterprise Edition, CONTROL_MANAGEMENT_PACK_ACCESS defaults to DIAGNOSTIC+TUNING, while every other edition defaults to NONE. Automatic Workload Repository snapshots then run without anyone enabling them, and Diagnostics Pack usage registers from the moment the database exists.

For the past, the argument rests on facts you can show. Put these points together, with the parameter value:

• The detection arose from a shipped default.
• The first usage date matches the database creation date.
• The hosts involved never had a performance tuning workflow, and your Enterprise Manager logs show no pack pages opened.

Setting the parameter to NONE stops that going forward, and it is the right control on any database where the packs are not licensed. It does not erase history, and it should never be presented as if it does. Our guide to suppressing the Diagnostics and Tuning Packs covers the change itself.

Expect one counterpoint. Oracle requires a Diagnostics Pack license for anyone licensing the Tuning Pack, so a Tuning Pack detection that survives review will be used to claim both packs for the same period.

Clones and standbys carry someone else's history

Feature usage history lives in the data dictionary, so a database cloned or duplicated from production carries production's usage rows and their original dates. A test database can show years of option usage that never happened on its current host. Check your clone records, the DBID and the database creation date against the earliest FIRST_USAGE_DATE.

A physical standby is a block for block copy of its primary, so its dictionary holds the primary's rows. For a database that only ever ran as a failover target, role transition records and failover dates settle the question, and V$DATABASE shows the current role in DATABASE_ROLE.

Account lists are not Named User Plus counts

DBA_USERS lists accounts. Many of them are schema owners, application service accounts or Oracle supplied accounts, and from 12c the ORACLE_MAINTAINED column flags the last group. Map what remains to people or devices before anyone presents the list as a Named User Plus count.

The list can also undercount, because people who reach the database through a shared application account still count as named users. Our note on reconciling the user list covers both directions.

Never reset the view before you submit

Oracle has internal procedures that can refresh or clear feature usage data. Running anything that clears history before an audit submission is falsification, and it is not a gray area.

It also destroys your best evidence. The rows that suggest a detection are the same rows that show it happened once, five years ago, on a version you no longer run.

• Legitimate. Forcing a fresh sample so the current period is up to date. The internal procedure DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING takes a new sample and keeps the earlier history.
• Required. Keeping the raw files unaltered, taking a hash of each one, and recording who produced it and when.

How do you check your own output before Oracle sees it?

Run the same reads Oracle will run, on every database in scope, and keep the results beside the collection files. These are the checks we run first, in this order.

1. Detections. Select NAME, VERSION, DETECTED_USAGES, TOTAL_SAMPLES, CURRENTLY_USED, FIRST_USAGE_DATE and LAST_USAGE_DATE from DBA_FEATURE_USAGE_STATISTICS where DETECTED_USAGES is above zero, ordered by NAME and VERSION. On multitenant databases use CDB_FEATURE_USAGE_STATISTICS and keep CON_ID.
2. Sampling health. Compare LAST_SAMPLE_DATE and LAST_SAMPLE_PERIOD with SAMPLE_INTERVAL. Missed samples make every date even coarser than a week, as our note on sampling gaps explains.
3. Parameters and edition. Read CONTROL_MANAGEMENT_PACK_ACCESS from V$PARAMETER and the edition string from V$VERSION.
4. Identity. Take DBID, CREATED and DATABASE_ROLE from V$DATABASE and set them against the earliest FIRST_USAGE_DATE.
5. Peaks. List HIGHWATER against LAST_VALUE for every row in DBA_HIGH_WATER_MARK_STATISTICS, and the high water columns in V$LICENSE.
6. Installed versus used. Put V$OPTION rows reading TRUE and the DBA_REGISTRY component status next to the feature usage rows for the same options.
7. Scale. Open FEATURE_INFO on every compression, partitioning and pack row, since scale changes the argument. Our guide to management packs in the feature usage view lists the pack feature names.

How should a SAM manager reconcile output to entitlement?

Reconcile in three columns, per database, before anything is aggregated. Detected is what the sampler saw, reviewed is what survives an evidenced error class check, and entitled is what your ordering documents grant.

Only the gap between reviewed and entitled is worth a conversation. Adding up every database first hides both the errors and the surplus.

Look at the final row. Surplus entitlement is as real as shortfall and offsets within the same product family, yet buyers rarely look for it because they are only searching for problems.

The same database priced at list

Now put prices on that reconciliation. Assume the database runs on a hypothetical two socket Intel Xeon server with 16 cores, which at a core factor of 0.5 needs 8 processor licenses. The prices are Oracle's current Technology Global Price List figures per processor.

Three details in that table change how you argue it.

• Backdated support. These totals are license fees only. Findings normally add support on top, and Oracle's price list sets first year support at 22 percent of the license fee, $1,650 per processor for the Diagnostics Pack, so the date of every detection feeds into the size of the claim.
• Real Application Testing. A version split only dates a detection. The row drops out because the review traced those detections to a default job or template, and without that evidence it would be priced like the Tuning Pack row.
• Tuning Pack. The row survives review as a dated, historical event, which is why the Diagnostics prerequisite appears in the total.

Counting rules live outside the output. The Oracle software investment guide sets out how Oracle expects deployments to be counted, and the processor core factor table converts cores into licensable processors.

Reconcile against those documents and your ordering documents. The dump has no view on your entitlement because it has never seen your contract.

What have we seen in recent Oracle audit defenses?

Across the 30 to 40 Oracle audit defenses our Oracle practice ran in 2024 and 2025, raw collection output overstated licensable usage in the large majority of cases. Three patterns came up again and again:

• Feature usage rows flagged options touched once by a default job or a console click, inflating findings by 20 to 50 percent before any review.
• Diagnostics and Tuning Pack rows were the most common single error class, and in most cases traced back to a default initialization parameter rather than a decision.
• Reconciling detected usage against edition and entitlement removed between a third and two thirds of the initial claim, without disputing a single real deployment.

The last point matters most to how you run the response. Those reductions came from reading the data correctly, and none of them required a buyer to deny something that had happened.

How do you respond to an inflated finding?

Respond with a reconciled position and documented exclusions. Acknowledge the collection, then answer from the reviewed column; a flat refusal or a resend of the raw file helps neither side. Our guide to challenging Oracle audit findings covers the formal steps.

What the output proves, and what it merely suggests

• It proves that a sampler recorded a detection inside a sample window, that an option is linked into the binary, and that a counter once reached a peak.
• It suggests that someone chose to deploy a feature, that the use was in production, that it continued, and that it was at a scale worth licensing.
• It says nothing at all about your entitlement, your edition rights, your negotiated definitions, or whether the host was ever in agreed scope.

Write the response in that order. Concede what is proven, evidence what is only suggested, and set apart the questions the data cannot reach.

How to structure the written response

• Present detected, reviewed and entitled as three explicit columns, per database.
• Document every exclusion with its error class, its evidence and its date.
• Cite the edition entitlement and the contract definition for every line you dispute.
• Concede clearly and early where the evidence supports the claim. Credibility on the small lines buys you the large ones.
• Negotiate from the reviewed figure, and never from the script total.

What Oracle's auditors will say, and what to say back

• "V$OPTION shows Partitioning as TRUE." Reply that V$OPTION records what the installer linked, and ask for the DBA_FEATURE_USAGE_STATISTICS row that shows use, with its VERSION and dates.
• "DETECTED_USAGES is 1, and usage is usage." Agree that the week counts if a license was required then, and price it as one dated event on one identified host.
• "Your test databases show years of Diagnostics Pack usage." Show the clone records and the database creation date beside the earliest FIRST_USAGE_DATE, and the CONTROL_MANAGEMENT_PACK_ACCESS default.
• "The CPU high water mark is 96." Point out that Oracle counts processors from the hardware, then supply the change record for the host the instance ran on and the dates it ran there.
• "The collection covered the whole cluster, so we summed it." Ask which node produced each file, then show that the feature usage view belongs to the database, so every node's file repeats the same rows.

Why we do not treat the script output as your license position

The usual guidance is to treat the collection output as authoritative and reconcile your purchases to it. We disagree. The output is a weekly sampling record, and its most important counter records whether a detection fell inside a window, with no quantity of use attached.

Treating it as truth opens the negotiation at the worst available reading of every row. Reverse the burden instead: separate detected from reviewed from entitled, evidence each exclusion by error class, and answer only from the reviewed figure. The script is one input to the licensing conversation, and your contract decides where that conversation ends.

The script tells you what the database noticed. It does not tell you what you owe, and confusing the two is the most expensive reading error in an Oracle audit.

Our white paper on Oracle LMS audit scripts sets out what the GLAS and LMS scripts collect beyond the database views covered here.

When should you run each check during an Oracle audit?

Run them as early as you can. Every check on this page is cheaper before an audit letter arrives than after preliminary findings, and the table shows where each one belongs.

If the letter has already arrived, start with our checklist for what to do when you receive an Oracle audit letter.

What to do next

The full end to end audit process is in our guide to 22 secrets that help in an Oracle license audit, and the wider library sits in the Oracle knowledge hub.

1. Preserve the raw output. Collect every file, keep it unaltered, and record a hash, who produced it and when.
2. Run Oracle's filtered report. Run the options and packs reporting script alongside the raw views, and keep both outputs.
3. Split before you sum. Break every feature usage row out by VERSION and by container before anything is added up.
4. Open FEATURE_INFO. Read it on every compression, partitioning and pack row, because scale changes the argument.
5. Check dates and peaks. Flag every row where FIRST_USAGE_DATE matches database creation and check the initialization parameters, then compare HIGHWATER against LAST_VALUE and pair each spike with a change record.
6. Separate installed from used. Keep V$OPTION lines apart from feature usage lines, and ask which view each finding was derived from.
7. Reconcile and document. Build detected, reviewed and entitled per database, including surplus entitlement, and record every exclusion with its error class, evidence and date before submission.
8. Respond from the reviewed figure. Have counsel review the covering position if any material line is disputed. A finding is a claim quoted at list price, and it can be negotiated like one.

Frequently asked questions