Reading Oracle LMS script output. Line by line.

Oracle LMS collection scripts report option, pack, and feature usage from every database. Knowing how to read it, and where it overstates, is core SAM defense work.

Oracle License Management Services runs collection scripts that read internal views and dump usage to CSV. The output looks authoritative. It is not the same as a license position.

A row in the feature usage table means the database recorded that a feature was exercised. It says nothing about whether the use was intentional, ongoing, or licensed. Reading it well is a SAM skill.

What do the Oracle LMS scripts actually collect?

The scripts query data dictionary and dynamic views to report database version and edition, installed options, management pack usage, and feature usage history. The core source is the feature usage statistics view.

The rows that matter most

• Options: separately licensed database options such as Partitioning or Advanced Security.
• Management packs: Diagnostics and Tuning Pack usage, the most frequent false positive.
• Feature usage: first and last use dates and detected usage counts.

Oracle describes the program through its License Management Services group. The data is real. The interpretation is contestable.

How do you spot a false positive in the output?

Start with the first usage date. If a feature shows usage from the day the database was created, it was almost certainly a default job or template, not a deliberate decision.

Diagnostics and Tuning Pack rows deserve special scrutiny. A single click in Enterprise Manager can record pack usage. Oracle documents the pack content in the database licensing information manual, which is the reference for what each pack covers.

Questions to ask each usage row

• Was this feature ever configured deliberately, or did it run by default?
• Does the first usage date align with a real project, or with database creation?
• Is the detected usage count consistent with a production workload?

How should a SAM manager reconcile output to entitlement?

Map every flagged option against your purchased entitlements and the database edition. Some options are included in Enterprise Edition. Others require a separate license. Edition context changes everything.

Build a three column view: detected, used, licensed. Detected is what the script saw. Used is what survives a false positive review. Licensed is your entitlement. The gap between used and licensed is the only number worth discussing. The Oracle Software Investment Guide sets out how Oracle expects deployments to be counted.

Oracle publishes the metric and edition rules in its processor core factor table and contract documents. Reconcile against those, not against the raw dump.

How do you respond to an inflated LMS finding?

Never accept the raw output as a license position. Acknowledge the data collection, then respond with your reconciled analysis showing false positives removed and entitlement applied.

The response posture that works

• Separate detected, used, and licensed in writing.
• Document each false positive with its likely trigger.
• Reference the licensing manual and your contract for edition entitlements.
• Negotiate from the reconciled used number, not the script total.

Where the common advice on Oracle LMS output is wrong

The standard guidance is to treat the LMS script output as an authoritative license position and reconcile your purchases to it. We disagree. In roughly 30 to 40 audit defenses we ran, the raw output overstated real licensable usage in most cases, often by 20 to 50 percent, because a usage row records that a feature was touched, not that it was deliberately deployed. Treating the dump as truth hands Oracle a negotiation anchored at the worst case. The buyer side move is to invert the burden: separate detected from used from licensed, document every false positive trigger, and respond only from the reconciled used figure. The script is an input, not a verdict.

20 to 50%

Typical overstatement in raw output

1/3 to 2/3

Claim removed on reconciliation

30 to 40

Audit defenses benchmarked

Source: Redress Compliance advisory engagement file, 2024 to 2025.

The LMS script tells you what the database touched. It does not tell you what you owe. Confusing the two is the most expensive mistake in an Oracle audit.

What to do next

1. Collect the full LMS script output and keep the raw files unaltered for reference.
2. Flag every option and pack row with a usage date matching database creation.
3. Build the detected, used, licensed three column reconciliation for each database.
4. Document the likely benign trigger for each false positive.
5. Apply edition entitlements from your contract and the licensing manual.
6. Respond to Oracle from the reconciled used number, not the raw script total.

Frequently asked questions

What do Oracle LMS scripts collect?

The LMS collection scripts query data dictionary and dynamic performance views to report database version and edition, installed options, management pack usage, and feature usage history including first and last use dates.

Does a usage row mean I owe a license?

No. A usage row means the database recorded that a feature was exercised at least once. It does not establish that the use was deliberate, ongoing, or that the feature requires a separate license in your edition.

What is the most common LMS false positive?

Diagnostics and Tuning Pack usage is the most common false positive. A single click in Enterprise Manager can record pack usage even though the pack was never deliberately adopted for production work.

How do I tell a false positive from real usage?

Check the first usage date and detected count. Usage dated to database creation, or a very low count, usually points to a default job or accidental access rather than a deliberate, licensed workload.

What does detected, used, licensed mean?

It is a three column reconciliation. Detected is what the script saw, used is what survives a false positive review, and licensed is your entitlement. Only the gap between used and licensed is worth negotiating.

Should I accept the LMS output as my license position?

No. Acknowledge the data collection, then respond with a reconciled analysis. The raw output is an input to the conversation, not a verdict on what you owe.

Where are Oracle option and pack rules defined?

Oracle defines edition entitlements and pack content in the database licensing information manual, and metric rules in the processor core factor table and your contract documents. Reconcile against those, not the dump.

Can I challenge an inflated Oracle finding?

Yes. Document each false positive with its likely trigger, apply your edition entitlements, and negotiate from the reconciled used figure. A well evidenced reconciliation routinely removes a large share of the initial claim.