Oracle LMS Audit Scripts: What They Measure & How to Prepare

1. Oracle LMS Script Landscape Overview

Oracle's Licence Management Services team relies on a suite of scripts and tools to collect the data it analyses in producing a compliance report. The specific tools deployed depend on the Oracle products in scope, the operating environment, and the infrastructure platform. Understanding which tools Oracle uses — and when — allows your team to prepare appropriately and to manage each data collection exercise with appropriate scrutiny.

The core Oracle LMS audit toolset comprises: USMM (Usage Monitoring and Measurement) for Oracle Database environments; Review Lite for a broader Oracle product scan; Oracle License Review (OLR) for Java SE deployments; and various supplementary data collection requests for VMware vCenter exports, Active Directory user counts, and application log analysis. Oracle GLAS — the Global Licensing and Advisory Services brand that has partially replaced LMS in Oracle's public communications — uses the same underlying toolset with some procedural refinements.

2. USMM — Oracle's Primary Database Audit Tool

What USMM Collects — The Compliance Data

USMM's core compliance data collection includes: the Oracle Database version and edition; all installed Oracle Database options (Diagnostics Pack, Tuning Pack, Advanced Security Option, Partitioning, Real Application Clusters, Active Data Guard, GoldenGate, In-Memory, Label Security, Database Vault); the value of the CONTROL_MANAGEMENT_PACK_ACCESS parameter that determines which management packs are enabled; the DBA_FEATURE_USAGE_STATISTICS view showing whether licensed features have been actively used; processor model, socket count, and core count for the host; and cluster membership for RAC environments.

What USMM Collects — The Sales Intelligence Data

Beyond compliance measurement, USMM captures data that Oracle's sales team uses in subsequent commercial conversations: database size and growth trajectory (from segment space analysis); the number and names of database instances (revealing product complexity and growth); the Oracle AWR (Automatic Workload Repository) retention period (indicating active AWR usage — a Diagnostics Pack feature — regardless of the CONTROL_MANAGEMENT_PACK_ACCESS parameter value); Oracle Grid Infrastructure configuration details; and Data Guard configuration including whether standby databases are active or passive.

3. Oracle Review Lite — Broader Product Scope

What Review Lite Captures

Review Lite operates at the operating system level rather than within the Oracle Database instance. It scans Oracle Home directories, Oracle inventory records, installed Java runtime environments, and Oracle middleware installations. Key data points include: all Oracle software installed under any Oracle Home, regardless of whether it is actively in use; Oracle WebLogic Server installations including version and the number of managed servers; Oracle Forms and Reports installations that may no longer be in active production use but are installed and therefore attributable; Java SE JDK and JRE installations on server endpoints; and Oracle Fusion Middleware component inventory.

Review Lite's operating system scope creates a specific risk: Oracle software that was installed historically, is no longer in active production use, but has not been formally decommissioned and removed from the Oracle inventory appears as an installed and therefore licensed product. This is a common source of inflated compliance claims — Oracle attributes licence requirements to products installed but not used, and customers lack the documentation to demonstrate non-use. Our License Optimisation service includes a systematic decommissioning review to eliminate these ghost installations before Oracle arrives.

4. Oracle GLAS Tools — Java SE and Modern Deployments

Oracle's Java SE Audit Methodology

Oracle's approach to Java SE auditing changed fundamentally with the January 2023 shift to the Employee Metric. Pre-2023 Java SE audits focused on counting individual JDK and JRE installations on individual endpoints. Post-2023, Oracle's audit methodology for Java SE focuses on: total employee count across the global organisation (including subsidiaries and affiliates); the determination of which legal entities are included in the licence scope; and the identification of any Java SE usage in the environment — because under the Employee Metric, if Oracle SE is used anywhere in the organisation, all employees must be licensed. See our Java SE Employee Metric guide for the detailed counting rules.

For Java SE audits, Oracle will request data from your IT asset management system, endpoint discovery tools, or enterprise software inventory in addition to or instead of running scripts. Your ITSM and SAM (Software Asset Management) data will be analysed for Java SE installation records. The risk is that your SAM tool captures far more Java installations than are in active production use — test environments, developer workstations, legacy systems — all of which Oracle attributes to the Employee Metric calculation if they find any Java SE present. Our Oracle Java Licensing service provides forensic Java estate analysis and Employee Metric calculation support.

5. Data Oracle Collects Beyond Compliance — The Sales Intelligence Dimension

A significant portion of the data collected by Oracle's audit scripts serves no compliance measurement purpose. It serves Oracle's commercial intelligence function — feeding information about your technology environment, your strategic direction, and your commercial vulnerabilities into Oracle's account management and sales planning systems. Understanding which data points serve this purpose allows you to challenge data collection that exceeds the legitimate audit scope.

6. Highest-Risk Data Points in Oracle Script Output

The following data points in Oracle's script output are responsible for the largest compliance claims in the majority of enterprise Oracle audits. These are the areas that deserve most attention in both your pre-audit independent inventory and your challenge of Oracle's eventual compliance report.

CONTROL_MANAGEMENT_PACK_ACCESS Parameter

As detailed above, this single parameter drives the majority of Oracle Diagnostics Pack and Tuning Pack compliance claims. It defaults to 'DIAGNOSTIC+TUNING'. If USMM finds this parameter at its default value, Oracle attributes Diagnostics Pack and Tuning Pack licence requirements across every processor running that database instance. Oracle charges approximately $15,000 per processor for Diagnostics Pack and $10,000 per processor for Tuning Pack. For a 100-processor Oracle Database estate, an accidental default setting generates a compliance claim exceeding $2.5M. Identify and remediate this parameter before Oracle runs USMM. See our detailed analysis: Oracle Diagnostics Pack compliance guide.

VMware Cluster Host Count

USMM's VMware integration — supplemented by Oracle's request for vCenter exports — identifies how many physical hosts are in each VMware cluster that contains an Oracle virtual machine. Oracle's soft partitioning policy requires you to licence every core in every host in that cluster. The difference between the core count of the VM (what most organisations believe they need to licence) and the core count of the entire cluster (what Oracle claims) is frequently the largest single item in the audit claim. Detailed analysis: Oracle database licensing on VMware.

DBA_FEATURE_USAGE_STATISTICS

This Oracle data dictionary view records whether individual Oracle Database features — including licensed options — have ever been accessed or executed. Oracle attributes licence requirements based on feature usage entries in this view, even when the usage was accidental (a single accidental AWR query) or historical (a feature used years ago and since disabled). Your pre-audit inventory should review this view for each database instance and assess whether any usage entries can be explained as accidental, test-environment, or historical — all of which can be challenged in Oracle's compliance report.

Java SE Installation Count vs. Employee Count

Post-2023, Oracle's Java SE audit methodology uses the Employee Metric — the total number of employees — rather than individual installation counts. However, Oracle still uses installation data as evidence that Java SE is in active use in the organisation, triggering the Employee Metric threshold. If Oracle finds Java SE installed anywhere in the environment, the Employee Metric applies across the entire global organisation. Pre-audit Java estate rationalisation — removing unused JDK and JRE installations — reduces Oracle's ability to demonstrate active Java SE usage and can be a critical component of Java audit defence.

7. Managing the Data Collection Phase of Your Oracle Audit

The data collection phase — when Oracle runs USMM, Review Lite, or OLR on your infrastructure — is the most critical phase of the entire audit process. The data Oracle collects in this phase becomes the foundation for every subsequent claim calculation. Managing this phase with independent expertise is the most direct way to protect your compliance position.

Review Scripts Before Granting Execution Permission

You are entitled to review the specific scripts Oracle proposes to run before permitting their execution. Oracle's scripts are known to your independent Oracle licensing advisors. Request the exact script versions Oracle intends to use, have your advisors review the data collection scope, and identify any data collection that exceeds the agreed audit scope. Challenge any data collection request that goes beyond what is necessary for compliance measurement of the products in scope.

Your IT Team Supervises Execution

Oracle's LMS team should not have unsupervised access to your systems during script execution. Your own database administrators and system administrators should be present during all script execution, should maintain logs of all commands run, and should retain copies of all raw output before Oracle takes possession of the data. This gives you the evidence base to challenge any subsequent claim that Oracle's analysis is inconsistent with the raw data collected.

Receive and Review Raw Output Before Oracle Analyses It

The raw script output — before Oracle applies its compliance framework, Core Factor Table calculations, and claim methodology — is your most important defence document. Request the complete raw output immediately after each script is run. Your independent advisors should review the raw output against your actual licence entitlements before Oracle produces its compliance report. Discrepancies between the raw data and Oracle's subsequent analysis are grounds for formal challenge. Our Audit Defence team conducts parallel analysis of all raw audit script output on every engagement.

8. Pre-Audit Independent Inventory — The Most Effective Defence

The most effective defence against Oracle's audit script findings is to conduct your own independent inventory before Oracle runs a single script. An independent pre-audit inventory, conducted by former Oracle LMS consultants using the same analytical framework as Oracle's own methodology, gives you four critical advantages that fundamentally change the audit dynamic.

• Identify remediation opportunities: Issues that can be fixed before Oracle measures — CONTROL_MANAGEMENT_PACK_ACCESS parameter defaulting, unused software decommissioning, ghost Oracle Home entries, Java SE installations on decommissioned endpoints — can be remediated before the formal audit measurement. Oracle can only claim what exists at the time of measurement.
• Know Oracle's claim before Oracle presents it: An independent pre-audit inventory produces a preliminary compliance position that tells your organisation what Oracle's claim will approximately be before Oracle presents it. This eliminates the surprise factor that Oracle uses to create commercial pressure.
• Build your challenge evidence base: An independent analysis of the same data Oracle will collect provides your forensic evidence base for challenging Oracle's subsequent compliance report. Your independent analysis is the counter-evidence to Oracle's calculation.
• Control the audit narrative from the start: Organisations that arrive at the Oracle audit kick-off meeting with an independent compliance assessment — prepared by former Oracle LMS consultants — operate from a position of authority, not uncertainty. The audit dynamic shifts immediately.

Our Oracle Compliance Review and License Optimisation services both include pre-audit independent inventory components. Download our Oracle Database Licensing Masterclass for a detailed methodology guide.