What the LMS Scripts Actually Collect

What do Oracle's LMS scripts collect?

Oracle's LMS scripts, now run under Global Licensing and Advisory Services, collect database versions and editions, processor and core counts, enabled options and management packs, and a history of feature usage drawn from the database itself. They are diagnostic queries that read system views and configuration, then package the results for Oracle to interpret against your licensed metrics. The scripts are thorough, and that thoroughness is exactly why their output is read carefully before anyone submits it.

The most consequential data the scripts gather is feature usage history. Oracle databases record which features and options have been touched, sometimes once, sometimes briefly, sometimes by an automated process. The script harvests that history and presents it as usage. Combined with processor and topology data, it produces a picture that can look like far more licensable deployment than the contract actually obliges. Understanding what is in that picture is the first step to correcting it.

How do the scripts detect options and management packs?

The scripts detect options and management packs by reading the database feature usage views, which flag any option or pack that has been enabled or exercised, even momentarily. This is where many of the most surprising findings originate, because a single Enterprise Manager click can enable Diagnostics Pack or Tuning Pack, and many options install by default with the database. The feature usage view does not distinguish a deliberate, business critical deployment from an accidental, one time touch.

The result is that a routine scan can surface options usage no one knew existed. Partitioning, Advanced Compression, Diagnostics Pack, and Tuning Pack are common examples, each separately licensable, each capable of appearing in the output through default installation or a stray administrative action. Because the script reports the flag rather than the intent, the raw output overstates genuine adoption. Reconciling that against actual business use, and disabling what was enabled in error, is core to the data discipline covered in building your own deployment inventory.

How does the script output overcount?

The script output overcounts because it reads topology and feature flags rather than contractual deployment, and Oracle interprets both in the way most favourable to a finding. Across a virtualization layer, the scripts can report every core in a cluster as if Oracle ran everywhere, because the partitioning policy does not recognise VMware, Hyper V, or KVM as hard partitioning. The raw output therefore embeds the cluster wide premise before any human has reviewed it.

Overcounting also appears in the feature usage data, where a momentary touch becomes reported usage, and in processor counts where the core factor table is applied to hardware that never hosted Oracle in production. None of this is a malfunction. The scripts faithfully report what they see. The issue is that what they see is not the same as what the contract requires you to license, and the gap between the two is where inflated findings live. The full sequence of how this feeds an audit is set out in the Oracle audit defense guide.

Do you have to run the scripts?

You do not automatically have to run Oracle's scripts, because running them is a decision, not an obligation. What you must provide is set by the audit clause in your contract, and that clause rarely says you must execute Oracle's specific tooling and submit its raw output. The obligation is usually to provide accurate information about your deployment, which you can often satisfy from your own records rather than from a tool that reads topology as deployment.

This distinction matters because the choice of data source shapes the entire negotiation. If you run the scripts and submit raw output, you start from Oracle's most expansive reading. If you provide reconciled, contract anchored data from your own inventory, you start from the position the agreement actually supports. Recognising that the policy document is not the contract, and that contract language beats policy, is what gives you the standing to make that choice deliberately.

Why is the output reviewed before submission?

The output is reviewed before submission because submitting it raw concedes every overcount it contains, and those overcounts are difficult to walk back once Oracle has built a finding on them. Review separates genuine, business critical usage from accidental flags, reconciles topology to real deployment, and documents the basis for each correction. It turns a raw scan into a defensible statement of position.

This review is also where documentation begins to matter, because a corrected position only holds if it is evidenced. The discipline of producing records that withstand challenge is covered in documentation that survives scrutiny. Done together, reviewing the script output and documenting the reconciliation are what protect the 60 to 80 percent reduction a line by line review typically achieves.

Your next step

Understanding what the scripts collect is what lets you decide how to respond to a data request rather than reacting to it. Our free guide walks through the data discipline in full, alongside the wider audit sequence in the Oracle audit defense guide.