How to Read an Oracle LMS Audit Report Before You Reply
An Oracle License Management Services (LMS, now folded into Global Licensing Advisory Services in most engagements) audit report is not a bill. It is a spreadsheet of raw script output, and the gap between what the scripts print and what you actually owe is usually the largest number in the whole engagement. Reading the report correctly, before you reply to a single line of it, is what decides whether the next conversation is a negotiation or a surrender.
This is a guide to reading the report itself: what the scripts measure, where they systematically overstate usage, and the checks that separate a real finding from a script artefact.
What the scripts actually measure
Oracle's collection scripts are product-specific: one set for the database, another for middleware, another for Java, another for E-Business Suite. Each script queries the system dictionary and configuration views for the product it targets and writes the results to a file you run yourself and return. The scripts do not ask whether a feature is licensed; they ask whether it has ever been touched. That distinction is the whole exercise.
For the database, the option and feature usage views record a flag the moment an option is accessed, whether by a DBA running a default health check, a monitoring tool's connection, or a one-off exploratory query five years ago. The flag does not clear itself, and it carries no context about how the option was touched or how often. A row in the audit report showing Partitioning as "used" can mean a production system built on partitioned tables, or it can mean someone ran a script that queried a partitioned data dictionary view once during a POC that was cancelled.
Where the raw output overstates the position
- Default jobs and console clicks. Several options are flagged by routine maintenance jobs Oracle ships enabled by default, not by application use. A DBA opening a diagnostic screen in Enterprise Manager can trip a Diagnostics Pack flag without running a single tuning query.
- No decay. Usage flags persist for the life of the database unless explicitly reset, so a feature touched once in a test environment three years ago still reads as "in use" today, on a system that has since been repurposed or decommissioned.
- Edition and entitlement are not in the script output. The scripts report what is installed and touched; they do not know what your contract actually licenses. A feature flagged as used against a database you are licensed for at the edition that includes it is not a finding at all, and the raw report does not make that distinction for you.
- Non-production and DR counted the same as production. Unless you have negotiated specific terms, the scripts collect from every instance you point them at, and a like-for-like disaster recovery environment can double a finding that should be reviewed under its own terms.
Reconciling the raw findings against what each database is actually entitled to, and against how each flagged feature was really touched, typically removes a third to two thirds of the initial number before a single dollar is discussed. That reconciliation is the report-reading work, and it has to happen before you draft a reply, not after.
How to read the report, line by line
- Separate the instance list from the findings. Confirm every hostname in the report is one you recognise, still exists, and is licensed under the agreement being audited. Decommissioned systems and instances covered by a different agreement or entity show up more often than expected.
- Match every flagged feature to its actual usage, not its touch. For each row, find who or what accessed the feature, when, and how often. A single timestamp from a default job is not the same finding as a table partitioned in production.
- Apply the core factor table and the current entitlement, not the script's raw core or processor count. The scripts report cores and sockets; they do not apply your factor or your contract's metric. A finding priced at the wrong metric inflates the exposure before you have even discussed the feature itself.
- Check the platform the finding sits on. Oracle's partitioning policy changes what counts as "installed" depending on the hypervisor. A finding on a soft-partitioned host is priced on the whole cluster unless the platform is one of the hard-partitioning exceptions; see hypervisor choice and Oracle licensing for how that changes the arithmetic before you respond to a single row.
- Build your own Effective License Position from the same underlying data before replying. The audit report is Oracle's read of your deployment; an Effective License Position is yours, built from the same discovery data and reconciled against your actual entitlement. A reply grounded in your own position, with the evidence behind every line, is a negotiation; a reply that argues with Oracle's spreadsheet on its terms is not.
What not to do
Do not run the scripts again to "check" the numbers without first understanding what each finding actually reflects; a second run against the same untouched flags returns the same inflated picture. Do not accept the report's totals as a starting point for negotiation; the starting point is your own reconciled position. And do not reply line by line before the whole report has been reconciled: a partial response on early findings can concede a framing that makes the later, larger findings harder to contest.
The underlying discovery data, hosts, editions, options touched and how, entitlement held, is the same data a defensible position and an audit reply both need. Oracle Database Manager builds that reconciliation from the inventory you already collect, so a script-flagged feature is checked against real usage and current entitlement before it becomes a line you have to argue about.
Checklist before you reply
- Every hostname in the report confirmed as real, current, and under the right agreement.
- Every flagged feature checked against actual usage, not a single touch.
- The core factor table and current entitlement applied, not the script's raw counts.
- The hypervisor and cluster checked against Oracle's partitioning policy.
- Your own Effective License Position built and reconciled before a single line is answered.
