A buyer side guide to Oracle license compliance scripts in 2026. What the LMS measurement script collects, why feature usage history drives the cost, and how to run and read the output before Oracle ever asks.
Oracle license compliance scripts are the data collection programs Oracle uses to measure your database usage during an audit. The most important is the LMS measurement script, and it reports far more than installation. It captures options and management packs that may have been used once, by accident, and never disabled.
This guide is for database administrators and procurement leaders facing an Oracle measurement request in 2026. Read it with the LMS audit script analysis guide, the script output interpretation guide, and the audit triggers guide.
They are SQL collection programs that read internal data dictionary views and produce a usage report. Oracle's License Management Services team provides them during a formal review, and the output becomes the basis of the compliance position.
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.
It captures the database version and edition, installed options, management pack usage, feature history, and the counters Oracle uses to size a user based metric. It reads views the application layer never touches.
The collection family and what each part is for
| What you are asked for | What it measures | What the request tells you |
|---|---|---|
| The options and packs report, from My Oracle Support Doc ID 1317265.1 | Priced database options and management packs, per instance | The review is about options and packs, which is the highest value finding type |
| The wider database measurement collection | Version, edition, components, users, sessions, high water marks | A full database position is being built, not a spot check |
| A server or environment worksheet | Hosts, sockets, cores, chip type, clusters, environment purpose | Processor math is coming, so virtualization scope is in play |
| Middleware or applications collection | WebLogic, Fusion Middleware and application user counts | The scope has moved beyond the database estate |
| Java detection output | Installed Java runtimes across desktops and servers | A separate commercial conversation, on a separate metric |
File names and versions change between releases. Ask which document ID and which version you are being asked to run, and record the answer. Two different script versions can produce two different findings from the same database.
Knowing the source views is what lets you check the output rather than accept it. Almost everything in a database collection comes from a short list.
Oracle documents these views publicly in the Oracle Database Reference. You can query every one of them yourself, today, without asking anyone.
Because Oracle counts a feature as used if it was ever activated, even briefly. The DBA_FEATURE_USAGE_STATISTICS view records that history and it does not expire.
Two mechanics make this worse than it sounds. The record survives the workload that created it, and it travels: restore or clone a database and the usage history moves into the copy with the datafiles.
Run them read only, on your own schedule, with a fresh sample forced first. Nothing in a properly scoped collection modifies the database, and the risk sits in the console, not the query.
Yes. Your own database team can run the collection against your databases. Doing so before Oracle asks gives you time to read the output, disable unused options, and prepare context.
The wider triangulation this feeds into, against entitlement and support records, is set out in our guide to checking your Oracle license information.
The one genuine self inflicted risk is not the SQL. It is a curious administrator opening Enterprise Manager performance or advisor pages while investigating, which registers a priced pack that was not previously in use.
Read it as a list of claims, not as a bill. Each line needs context: was the feature used in production, was it a one time accident, is it already covered by the contract. That context changes the number.
The options and packs report is structured, and most teams only read the first part of it. The detail underneath the summary is where your argument lives.
These are two different statements and they are routinely read as one. Currently used describes the most recent weekly sample only. Past usage describes the whole recorded history.
A feature that is currently unused but historically used is still a finding, because the obligation attached when it ran. A feature currently used once, this week, is a purchase conversation you can still get in front of.
The number that separates them is detections against total samples. Three detections against 214 samples is a demo. Two hundred and fourteen against 214 is production. A settlement template treats both identically unless you supply the ratio.
Common script findings and the buyer side response
| Finding | Where it comes from | Often accidental? | Buyer side response |
|---|---|---|---|
| Diagnostics Pack used | AWR or ADDM reports | Yes | Disable, document date. |
| Tuning Pack used | SQL Tuning Advisor | Yes | Restrict access, evidence. |
| Partitioning used | Partitioned objects | Sometimes | Confirm need, repartition. |
| Advanced Compression | Compressed segments | Sometimes | Uncompress if not needed. |
| Cloud Management Pack | Self service or chargeback pages | Yes | Set pack access to deny, prove the portal is gone. |
| Option flagged on a clone | History carried in from the source database | Yes | Show the refresh lineage so it is not counted twice. |
This distinction is the whole discipline. Facts are what the views returned. Inferences are the licensing conclusions someone drew from them, and inferences can be argued with evidence.
Fact, inference, and what you can legitimately show
| Collected fact | Inference drawn | Evidence that changes the reading |
|---|---|---|
| Detection count above zero | The option is in use and must be licensed | Detections against total samples, plus the dated change that stopped it |
| V$OPTION shows an option installed | The option is deployed | Installed and linked is not used. The feature usage view is the usage record |
| First usage date on a row | Continuous use from that date | Clone or restore lineage, and the sample ratio in between |
| Cores and sockets on a host | Processor licenses required for that host | Cluster topology, pinned capacity and what actually ran there |
Source: Redress Compliance advisory engagement file, 2024 to 2025. Stated as ranges observed across roughly 30 to 40 measurement reviews, not as measured averages.
Agree scope, script version, environments and recipients in writing, before the first collection runs. That is not obstruction. It is the ordinary discipline of complying with a contractual right precisely rather than approximately.
Assume it is read more broadly than the compliance conversation you are in. A measurement file is a detailed description of your estate, and the same detail informs how your next proposal is priced.
That is a reason for precision, not for evasion. Send what the agreement requires, send it accurately, and send facts rather than someone else's conclusions.
Ask once, in one message, and keep the reply. What happens after the formal letter arrives is covered in our Oracle audit guidance, which deals with scope letters and response sequencing in detail.
Run them early, read them honestly, and remediate what you can. A clean position you built yourself is far stronger than a reaction to someone else's version of the same data.
Disable options you do not use and stop the usage at the source. Document the date you disabled each one. Future collections then show the option as no longer currently used.
Remediation stops the meter. It does not rewind it, because the first usage date stays in the view for the life of the database. That is exactly why the dated evidence matters.
Not without review. Provide what your agreement requires, reconciled and in context, rather than an unexamined dump. Raw data invites the highest available interpretation of every line.
Review your own output first for three things: rows you cannot explain, environments that should not have been in scope, and any file that does not carry an instance name and a date.
Before you respond to a formal measurement request. The interpretation of the output, not the collection of it, decides the cost. That is where experienced review pays for itself.
The common advice is that running the scripts is risky, so the safest move is to wait until Oracle asks. We disagree, and the arithmetic is one sided. The risk being described is not the SQL, which is read only and changes nothing; it is a console click that enables a priced pack while someone investigates. Set pack access to deny first and that risk is gone. What waiting actually buys you is the loss of every remediation week you would have had, and the certainty that the first party to read your position is the one invoicing you. In the reviews we have run, self collection first bought 8 to 12 weeks of runway.
There is a second half to this that the standard advice also misses. Running the scripts once is not a program. A single collection ages out within a quarter, and an undated file with no named owner persuades nobody.
Put the collection on a cadence with an owner, which is a software asset management question rather than a database one. The script is a tool. The practice around it is what produces the number you can defend.
The script does not produce a bill. It produces a list of claims. Whoever reads those claims first, with context, controls the number, and that should be you, not the auditor.
The Oracle LMS measurement script is a SQL collection program that reads internal database views to report version, edition, installed options, and feature usage history. Its output forms the basis of an Oracle compliance review.
Yes. Your own database team can run the collection scripts. Running them before Oracle requests data lets you read the findings and remediate unused options first.
Yes, in the sense that matters: the collection is read only, performs no DML, and touches no application data. It needs a user with SELECT on the data dictionary and writes a spool file. The real risk sits elsewhere, in an administrator opening Enterprise Manager pages that enable a priced pack while investigating.
It is the data dictionary view that records which database features have been used and when. It drives most Oracle options findings because it captures even brief or accidental usage.
Currently used describes the most recent weekly sample only, while past usage describes the entire recorded history. A feature that stopped a year ago still shows in the history and still creates a licensing question. Always read both alongside detections against total samples.
Yes. Oracle generally treats any activation as usage. A single AWR report or one partitioned table can flag a chargeable option as used, because the view records detection rather than intensity.
Feature usage history lives inside the database and travels with a restore or clone. A test system seeded from production inherits the production usage rows, including the first usage date. Keep dated refresh tickets so the same usage is not counted twice.
They do, but a careless query does not. Feature usage must be read per container, using the container aware view or by connecting to each pluggable database. Querying only the root can hide usage that a later collection will find.
Not without review. Provide what the agreement requires, reconciled and in context, rather than an unexamined dump. Raw output invites the highest interpretation of every line and removes your chance to explain accidental usage.
Assume it is read more broadly than the review conversation itself, because the same estate detail informs commercial proposals. That is a reason to be precise about scope and accurate about content. Ask in writing who the named recipients are, and keep the answer.
Often yes. Disable the unused option, stop the activity at the source, and document the date. Later collections then show the option as no longer currently used, although the historical first usage date remains.
In our reviews, context and remediation commonly reduced raw exposure by 25 to 50 percent, depending on how much of the usage was accidental and how clean the contract terms were. That is engagement experience across roughly 30 to 40 reviews, not a guaranteed outcome.
Before responding to a formal measurement request. The interpretation of the data, not its collection, determines the cost, so independent review pays off at that stage.
An Oracle audit is decided by two feature usage views the database has filled in since day one. What the GLAS and LMS scripts collect, and how to read them before Oracle does.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The standard advice is to wait for Oracle to run the scripts and then respond. We disagree. In the measurement reviews we have run, the teams that collected and read the output first cut their exposure by a quarter to a half. The buyer side move is to never let the auditor read your data before you do.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One short note on Oracle licensing moves, audit posture, partitioning policy, and the buyer side levers we are running in client engagements. No noise.
