When Oracle audits you, the measurement engine is usually the Oracle LMS (License Management Services) collection scripts — and learning to read their output before Oracle interprets it for you is one of the highest-leverage moves in Oracle audit defence. The scripts gather an enormous amount of data from each database, and the raw output frequently overstates what is actually used versus merely available. The difference between those two readings is where most contested findings live.
What the LMS script is
The LMS collection tool (variously branded over time, including the "Review Lite" and measurement scripts, and more recently tooling aligned with Oracle's GLAS — Global Licensing and Advisory Services) is a set of SQL queries Oracle asks you to run against each database. It reads data-dictionary and dynamic-performance views to report installed options, feature-usage history, option-usage flags, processor and core counts, and named-user information. Crucially, the customer runs it on their own systems and returns the output — which means you can and should review that output before it leaves your control.
Options and packs: installed vs used
The most consequential section is feature usage, drawn largely from DBA_FEATURE_USAGE_STATISTICS and the options-usage views. Two traps recur. First, several chargeable options and management packs are installed and enabled by default in Enterprise Edition — Diagnostics Pack and Tuning Pack functionality, for example, can register usage simply because a DBA opened a performance screen in Enterprise Manager or queried an AWR view. Second, the feature-usage table records that a feature was detected at least once, not that it is in production use. A single historical touch can light up a pack as "used."
| LMS output signal | What it literally means | What Oracle may claim |
|---|---|---|
| Feature usage "currently used / detected" | Feature was invoked at least once since install | The option is in use and must be licensed |
| Partitioning detected | A partitioned object exists or was created | Partitioning option licensable on all cores |
| AWR / ADDM access logged | Someone queried a performance view or report | Diagnostics Pack in use |
| SQL Tuning Advisor invoked | Advisor was run once, possibly by default jobs | Tuning Pack in use |
| Options installed flag = TRUE | Binary option present in the install | Sometimes conflated with usage |
Building the defensible reading
The defensible position separates three states for every option: not installed, installed but never used, and genuinely used in production. Oracle's contract entitles it to payment for use, not for the mere presence of a binary or a one-time, inadvertent invocation. For each flagged option, the buyer-side work is to establish when usage was recorded, what triggered it, whether it was a default Enterprise Manager action, and whether the feature can be cleanly disabled or removed going forward. Well-documented, this routinely removes packs that the raw script appeared to charge for.
Buyer takeaway: Never return LMS script output without reviewing it first. The raw collection is a starting hypothesis, not a verdict. Inadvertent management-pack usage and one-off feature touches are the most commonly reversed findings, but only if you analyse the output before Oracle frames it. Our audit defence service validates LMS output line by line before any data is shared.
Process discipline around the scripts
Treat the LMS scripts as discoverable evidence. Run them in a controlled environment, retain a copy of exactly what was produced, and analyse it against your entitlements before responding. Where output is ambiguous, you are entitled to ask Oracle to explain the specific contractual basis for each claimed shortfall rather than accepting an aggregate number. This converts an opaque spreadsheet into a line-by-line negotiation you can actually win.
Related: VMware soft-partitioning and disaster recovery licensing. Anchor pillar: Oracle audit defence.
Named-user and processor sections
Beyond options and packs, LMS output reports processor and core counts and Named User Plus (NUP) data. Two checks matter here. On the processor side, confirm that the core count reflects the correct hardware boundary — physical cores on the licensed hosts or partitions — and that Oracle's Core Factor has been applied where applicable rather than a raw core count. On the NUP side, verify that the minimum-user rules per processor have been applied correctly and that the population counted reflects actual authorised users and devices, not an inflated directory export. Both are areas where the raw collection can overstate the requirement and where a careful reading recovers real money.
Common questions
If a management pack shows usage, do I automatically owe for it?
Not automatically. Oracle is entitled to payment for genuine use, but Enterprise Edition installs several packs enabled by default, and a single inadvertent action in Enterprise Manager can register usage. Establishing what triggered the flag, and when, frequently reverses the finding.
Should I run the LMS scripts myself or wait for Oracle?
Run them in a controlled way and analyse the output before sharing anything. The customer produces the data, so the opportunity to review and contextualise it exists only before it leaves your hands.