What are the Oracle LMS scripts?
The Oracle LMS scripts are the standardised data collection programs that Oracle's License Management Services group, now operating in many regions as Global Licensing and Advisory Services, runs against a customer's environment during an audit. Their purpose is to enumerate, without ambiguity, what Oracle software is installed, which separately licensable options and management packs are present, and which features have actually been used. For the database the collection is largely a set of queries against the data dictionary; for middleware and operating systems it gathers deployment and core information.
The crucial property of the scripts is that they are deterministic and the customer can run them. There is no secret to the database measurement: it reads views the customer owns. This means the data on which an audit finding is built is data the customer can see first, in full, at any time. That single fact reframes the LMS scripts from a threat that happens to you into the most useful preparatory tool available, which is why they sit at the centre of the tools and tactics cluster.
What do the database scripts actually measure?
For the Oracle Database, the scripts concentrate on three things: which options are installed, which separately licensed features have been used, and the parameters that bear on licensing such as core counts and edition. The workhorse is the feature usage measurement, drawn principally from the view DBA_FEATURE_USAGE_STATISTICS, which records each tracked feature, whether it has been used, how many times, and when it was last sampled.
The feature usage view remembers. Switching an option off does not erase the record that it was once used, and the auditor reads that history.
This is where many findings originate. The view persists a record of usage even after an option is disabled, so a feature exercised briefly years ago, perhaps by accident or during an evaluation, remains visible. The scripts also enumerate installed options regardless of whether they were ever used, and capture the processor and core data that drive the Processor metric calculation. The combination, options installed plus features used plus cores present, is the skeleton of a database compliance position, and reconciling it against entitlement is the work of the effective license position.
Why do the scripts produce false positives?
The scripts measure technical usage; they know nothing about your contract or your intent. That gap is the source of the false positives that make raw script output a poor basis for a settlement and a strong basis for a negotiation if the customer is prepared. Several recurring patterns inflate the apparent shortfall.
Management tooling triggers feature usage that the customer never deliberately enabled: a monitoring pack feature flagged because a default Enterprise Manager configuration touched it, or a partitioning flag raised by an internal operation. Brief evaluation use, long since stopped, persists in the history. And the scripts cannot see that a restricted use grant or a specific ordering document authorises an option they have flagged. Each of these is defensible, but only by a customer who understands the cause and holds the contract, which is why running and reading the scripts in advance, rather than receiving them as a verdict, is decisive. The disciplined contestation of these flags is the core craft of audit defence.
How to run the LMS scripts yourself
A customer can reproduce the substance of the database measurement with standard privileges and read only queries. Oracle provides collection tooling on request, and equivalent queries against the feature usage and options views are well documented. The objective is not to replicate Oracle's exact packaging but to obtain the same underlying picture: which options are installed, which features show usage, and what the core data implies.
| Target | What to collect | Why it matters |
|---|---|---|
| Installed options | Options inventory per instance | Presence alone can be argued by Oracle |
| Feature usage | DBA_FEATURE_USAGE_STATISTICS history | The primary source of findings |
| Core and edition | Processor, core, edition data | Drives the metric calculation |
| Packs | Diagnostic and Tuning pack access | Commonly used without entitlement |
Collecting this across the estate, on a schedule rather than once, produces the measurement layer described in the measurement tools guide. The output feeds directly into reconciliation, and it lets the customer find and fix genuine gaps quietly, on its own terms, before an audit converts them into leverage.
Reading the output without panicking
The first time a team runs the feature usage query, the output usually looks alarming, because it lists usage of features the team did not know were in play. The discipline is to treat every flag as a question rather than a liability. For each flagged item the team asks three things: what caused the usage, is the option or pack actually entitled under our contracts, and if not, what is the cheapest defensible remediation.
Many flags resolve immediately as entitled, as management tool artefacts, or as historical evaluation use that can be argued. The residue, genuine unentitled usage, is then a known quantity that can be remediated by disabling the feature, purchasing deliberately, or restructuring before any audit. The point is that a flag examined calmly in advance is a manageable task, while the same flag presented in an audit report is a negotiating weapon in Oracle's hand. Reading the output yourself first is what moves the flag from their column to yours.
Scripts beyond the database
While the database scripts are the most discussed, LMS collection extends across the stack. For WebLogic and other middleware the scripts gather deployment topology and core data relevant to the Processor metric. For the operating system and virtualization layer they collect the information Oracle uses to argue licensable boundaries, which is where soft partitioning disputes originate. For applications and analytics the collection focuses on user counts and module access relevant to the applicable metrics.
The common thread is that every layer's collection feeds the same reconciliation, and every layer carries its own defensible arguments, particularly around virtualization and restricted use. A customer running a serious self measurement programme extends it beyond the database to the whole estate, because the auditor will, and the analytics tier in particular hides usage based exposure that our BI and analytics advisory sees repeatedly. The full picture across products is assembled in the effective license position.
Using the scripts as a defence, not a threat
The reframing this article argues for is simple but rarely practised: the LMS scripts are a customer tool. The measurement is open, deterministic, and runnable in advance, so the customer that runs it routinely is never surprised, never negotiating against a number it has not seen, and always able to separate the real shortfall from the false positives. The customer that waits to receive the scripts in an audit has handed Oracle the first, and often decisive, interpretation of its own estate.
Building self measurement into the operating rhythm, quarterly at minimum, turns the scripts from an instrument of audit pressure into the backbone of a prepared position. It is the most concrete expression of the principle that runs through the whole tools and tactics cluster: measure yourself before Oracle does.
The buyer side view
The Oracle LMS scripts are not a black box and not a verdict. They are open, deterministic measurement that any prepared customer can run, read, and interpret before an auditor ever arrives. The buyer that does so sees the same options, the same feature usage history, and the same core data Oracle would see, separates the defensible flags from the genuine gaps, and remediates the latter quietly and cheaply. Start with the tools and tactics pillar, build the measurement layer from the measurement tools guide, and reconcile the result into an effective license position. The script that frightens unprepared customers is the same script that protects prepared ones.
Oracle LMS scripts: frequently asked questions
Can I run the Oracle LMS scripts myself?
Yes. The measurement the scripts perform is standard data dictionary querying that any DBA with appropriate privileges can run. Oracle also provides collection tooling, and equivalent open queries are widely documented. Running them yourself before an audit is the foundation of a prepared position, because you see exactly what the auditor will see. This is the heart of audit defence.
What is DBA_FEATURE_USAGE_STATISTICS?
It is an Oracle data dictionary view that records which database features have been used since the database was created, with sample dates and counts. Auditors rely on it heavily because it persists evidence of option usage even after the option is switched off, which is why innocent or accidental usage can surface as a finding. See Oracle Database licensing.
Do the LMS scripts produce false positives?
Frequently. Feature usage views flag usage triggered by management tools, default jobs, or brief evaluation, and they do not know whether your contract grants the option. A flag is the start of an investigation, not a proven shortfall, and many flags are defensible once the cause and the entitlement are examined.
Are the LMS scripts safe to run on production?
The standard measurement queries are read only against the data dictionary and impose negligible load, which is why DBAs run them routinely. As with any production activity, run them under change control and review the specific scripts provided, but the core feature usage and options queries are low risk read operations.