What do Oracle LMS scripts do?
Oracle LMS scripts collect usage and configuration data from your databases to measure license consumption for an audit, and they are now administered under GLAS, the successor to LMS. The scripts query each database instance and return a picture of what is installed and what has been used: the edition, the options and management packs present, feature usage statistics, processor and core information, and Named User counts. That output becomes the factual basis Oracle uses to build a finding.
Because the scripts read directly from the database, their output carries an air of objectivity, as if it simply reports the truth of the estate. It does not. The scripts report what is installed and what features were touched, but they do not interpret entitlement, distinguish operational use from accidental enablement, or understand the boundary between a licensable host and a whole cluster. Those interpretations are added afterward, and they are where inflation enters.
Do you have to run Oracle's scripts?
Running Oracle's collection scripts is a decision, not an obligation, because your contract defines what you must provide, and it rarely names a specific tool. The audit clause typically requires you to provide reasonable cooperation and information about your usage, but where it does not compel a particular collection method, you have room to propose how the data is gathered. Treating the scripts as mandatory the moment they are requested concedes a choice the contract leaves open.
This matters because the scripts are not neutral. They are built to surface everything that could be licensable, and their default reading of ambiguous situations favours the higher count. A buyer who understands that running them is a choice can negotiate the method as part of scope, agree what data is genuinely needed, and avoid handing over output that overstates the position before any of it has been reviewed.
How do LMS scripts overcount?
LMS scripts overcount in two main ways: across virtualization layers and by reporting installed features as in use. On virtualization, the scripts and the policy behind them read a whole VMware cluster as licensable, because Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning. On a large cluster where only a few hosts run Oracle, that single behaviour can multiply the real count many times over, counting cores that never executed Oracle software.
On options, the scripts report management packs and database options as present, and the finding then treats them as used at full list price. A single Enterprise Manager click can enable Diagnostics or Tuning Pack, and many options install by default, so the script honestly reports them while the reality is that no one ever ran them. The script cannot tell the difference between an option in active production use and one enabled by accident, so the raw output overstates exposure unless someone makes that distinction.
| Script output | What it reports | Why it can mislead |
|---|---|---|
| Options and packs | Installed and feature usage flags | Installed is not the same as used |
| Processor data | Cores and processor type | May read a whole cluster as licensable |
| Named User Plus | User counts | Minimums and metric depend on contract |
| Disaster recovery | Standby instances present | Ignores the 10 day rule on failover |
Why review script output before submission?
You review script output before submission because what you submit becomes the factual basis for the finding, and raw output is the most common reason a finding comes back far larger than the real position. Once the data is in Oracle's hands, the argument shifts from preventing an overcount to disputing one, which is a weaker place to negotiate from. Reviewing first means correcting the known overcounts, separating installed options from used ones, and confirming that processor and user data reflect the actual deployment before any of it is handed over.
The review is methodical, not adversarial. It checks each category of output against the real estate: are the cores attributed to Oracle the cores actually running it, were the flagged options ever operationally used, is the Named User count measured against the right metric and minimum, and are standby systems being counted as live production. Where the output is wrong, it is corrected with evidence, and where appropriate equivalent evidence from the buyer's own records is provided instead. This is ordinary diligence, and it is the single most effective step between scope and findings.
When in the audit do scripts come up?
Scripts come up at the data collection stage, after scope is agreed and before findings are presented, which is exactly why scope is settled first. Agreeing scope in writing before any data moves means the scripts, if they run at all, run only against the systems the contract supports, in the format agreed, over the agreed period. A buyer who lets scripts run before scope is pinned down has effectively conceded scope through the data, because the output exists and the argument becomes whether to exclude it.
Preparation changes how this stage goes. A buyer who already holds a clean map of the estate, the entitlements and the architecture can validate or replace script data quickly and spot an overcount immediately. A buyer assembling that picture for the first time under a deadline is far more likely to return raw output that overstates usage, simply to show progress. The scripts are most dangerous to the unprepared and most manageable to those who know their own estate.
How do the scripts read feature usage?
The scripts read feature usage by querying internal tables that record whether a feature has ever been touched, which is why they cannot tell genuine operational use from a single accidental trigger. A database tracks when a feature is used in a way that the scripts can surface, but that record does not capture intent or context. A management pack enabled by one click in Enterprise Manager, or an option that installs by default and runs a background process once, registers the same way as a feature in daily production use. The script reports the flag; it does not interpret it.
This is the root of the options overcount, and it is why the buyer separates installed from used during review. The usage history, the configuration records and the operational logs establish whether a flagged feature ever did meaningful work. Where it did not, that distinction is the basis for removing the line from a finding, and disabling the feature as part of settlement prevents the flag, and the finding, from recurring. The script is honest about what it sees, but what it sees is not the same as what was used.
How do the scripts report processor data?
The scripts report processor and core data from the host they run on, which means in a virtualized estate they can attribute far more cores to Oracle than actually run it. On physical hardware the count is relatively direct, read against the core factor table that assigns a multiplier to each processor type. In a VMware environment, the combination of the scripts and Oracle's partitioning policy, which does not recognise VMware as hard partitioning, can treat every core in the cluster as licensable, regardless of where Oracle workloads actually run.
Correcting this is where the largest reductions appear, because a cluster wide count can be many times the real footprint. The buyer establishes the actual placement with host affinity rules, vMotion configuration and deployment records, and tests the contractual basis of the cluster wide claim, since the policy document is not the contract and the signed agreement wins where they conflict. The processor line in a finding is therefore never accepted on script output alone; it is recomputed from the cores that genuinely run Oracle, read against the correct core factor.
The next step
This article is part of our LMS Scripts and Audit Data cluster. Read the pillar, the Oracle audit defense guide, for the full picture, and these related reads: alternatives to running Oracle's scripts, and the data room for an Oracle audit. For a deeper resource, download the Options and Packs Detection Guide.