Oracle LMS Audit Script Analysis: What the Scripts Find and How to Respond

The Structure of Oracle LMS Audit Script Output

Oracle's LMS database collection scripts produce output across several distinct sections, each addressing a different dimension of licence compliance. The primary output files contain data on database product installations, feature usage statistics, hardware configuration, and user counts. Understanding what Oracle looks for in each section — and where Oracle's interpretation of that data tends to be most aggressive — is essential for mounting an effective audit defence.

The scripts are read-only: they execute SELECT queries and do not modify any database objects. They can be run without impacting production database performance, though Oracle recommends running them during off-peak hours for particularly large databases due to the volume of system view queries executed.

Section 1: Database Options and Feature Usage

This is the section that generates the most significant compliance claims in Oracle audits. The LMS scripts query DBA_FEATURE_USAGE_STATISTICS and related views to produce a comprehensive record of every Oracle Database feature and option that has been detected as used on the instance since it was created.

Oracle maps each feature in this view to one of three categories: features included in the base Database licence, features included in a specific option pack, and features included in a management pack. Any feature in the second or third category that appears as "used" in the output is treated by Oracle as evidence that the corresponding option or management pack requires a licence.

The Highest-Risk Features and Options

Annual costs shown are approximate support-level costs (22% of list price), not perpetual licence list prices. The perpetual list prices are substantially higher — Oracle Partitioning, for example, is approximately $11,500 per processor in perpetual licence cost plus 22% annual support.

Section 2: Oracle Enterprise Manager and Management Pack Usage

Oracle Enterprise Manager (OEM) is the primary monitoring and management interface for Oracle databases. Oracle positioned it as a management tool included with the database licence — but access to the most valuable OEM features requires separately licensed Management Packs that many organisations have never knowingly purchased.

The key Management Packs that LMS scripts identify:

• Database Diagnostics Pack: Provides access to Automatic Workload Repository (AWR), Active Session History (ASH), Automatic Database Diagnostic Monitor (ADDM), and performance-related reporting. Almost universally used by DBAs for performance analysis — and almost universally unlicensed by organisations that did not specifically purchase it.
• Database Tuning Pack: Provides access to SQL Tuning Advisor, SQL Access Advisor, and SQL Plan Management. Frequently used in conjunction with the Diagnostics Pack during performance tuning exercises.
• Configuration Management Pack: Provides configuration tracking and change management capabilities in OEM.
• Provisioning and Patch Automation Pack: Provides automated patching and provisioning through OEM.

To prevent Management Pack usage from being recorded, DBAs must configure OEM to disable Management Pack access for each database target. The configuration path in OEM is: Setup → Management Packs Access. Set the pack access for each target to "None" for packs you do not licence. This does not retroactively remove historical usage, but it prevents future usage from accumulating.

Section 3: Hardware and Processor Counting

The LMS scripts collect hardware configuration data to support Oracle's processor licence count. For on-premises installations, this includes the number of physical CPUs, cores per CPU, hyperthreading status, and the server model — all needed to apply the Core Factor Table correctly.

For virtualised environments, the scripts collect information about the virtualisation platform in use. This section is where Oracle's claim methodology becomes most aggressive in VMware environments: the scripts will detect VMware as the hypervisor, Oracle will classify this as soft partitioning, and the audit claim will demand processor licences for the entire physical cluster rather than the VM's assigned resources.

Common processor counting challenges worth raising with Oracle:

• Incorrect physical topology detection: In some virtualised environments, the LMS script output records virtual hardware parameters rather than physical ones. Where the script data does not accurately reflect the underlying physical hardware, this can be challenged with documented evidence of the physical configuration.
• Core Factor Table application errors: Oracle's analysts occasionally apply incorrect Core Factor multipliers. Verify that the processor model in the LMS output correctly matches the physical hardware and that the correct core factor has been applied.
• Cloud environment misclassification: Scripts run on cloud instances (Azure, AWS, OCI) should use cloud counting rules (vCPU-based counting), not physical hardware counting. Misclassification between cloud and on-premises counting rules is occasionally seen in Oracle's analysis of hybrid environments.

Section 4: Named User Plus and User Counting

For databases licensed on Named User Plus (NUP) basis, the LMS scripts collect DBA_USERS data including the number of accounts, their type, and proxy account relationships. Oracle uses this to determine whether the NUP licence count meets the applicable minimum per processor (25 for Oracle Database EE, 5 for SE2).

NUP counting is most relevant for databases with known, limited user populations — such as internal HR or finance applications. For databases that have grown organically over time, the user account count may have accumulated application service accounts, legacy accounts, and test accounts that inflate the apparent user count. Each of these should be reviewed and — where accounts are genuinely inactive or non-human — documented to support a lower NUP count.

Challenging Oracle's LMS Script Findings

Oracle's initial compliance report based on LMS script analysis applies worst-case interpretations consistently. The following are the most effective technical challenge categories:

Challenge 1: Historical vs Current Feature Usage

Oracle's methodology treats any feature ever recorded in DBA_FEATURE_USAGE_STATISTICS as a current licence requirement. However, this is not necessarily accurate — the feature may have been used in testing during a prior database version, may have been used accidentally and immediately deactivated, or may have been used during a development phase that has since concluded.

The challenge requires demonstrating the specific circumstances under which the feature was first used, the context (development, testing, or production), and any documentation that the feature was deliberately deactivated or the use was inadvertent. Oracle does not automatically accept these challenges, but detailed documentation significantly improves the negotiating position.

Challenge 2: Feature Is Not Separately Licensable for Your Use Case

Certain features appear in DBA_FEATURE_USAGE_STATISTICS but do not require separate licences in all configurations. For example, Oracle Label Security is included without additional licence cost when using Oracle Database Enterprise Edition for certain workloads. The determination of whether a feature requires a separate licence depends on the specific licence agreement terms — which is why reviewing your actual Oracle contracts, not just Oracle's standard price list assumptions, is essential.

Challenge 3: Oracle Enterprise Manager Misconfiguration

If Management Pack usage was inadvertent — resulting from OEM's default configuration rather than deliberate decision — and the organisation has no access to Management Pack-specific features in normal operations, this can be documented as a misconfiguration. While Oracle does not have a blanket "inadvertent use" defence, demonstrating that the usage was technical artefact rather than business value extraction supports a negotiated reduction.

Challenge 4: Technical Accuracy of the Script Output

LMS scripts executed under certain conditions — particularly on RAC environments, during database upgrades, or on databases with unusual configuration — can produce inaccurate output. If the script results contain data that does not match the actual database configuration or installation state, this can be challenged by running the scripts again under controlled conditions and comparing results.

The Settlement Process and Oracle's Tactics

After Oracle presents its Licence Review Report based on LMS analysis, the standard Oracle tactic is to propose a commercial settlement: purchasing the missing licences at a "discounted" price that typically represents 40 to 60 percent of list price, combined with support fees increasing at 8% per year from the settlement date.

Oracle's negotiating position is structured to create urgency. Settlement proposals typically have stated deadlines, and Oracle's sales team will emphasise that the "discount" offered is time-limited and that formal audit processes would result in higher costs. These tactics are standard and should not drive decisions. Settlement terms should be based on a thorough technical analysis of whether Oracle's compliance claims are accurate, not on artificial urgency.

Independent Oracle licensing advisors who have worked on both Oracle's side and the customer's side consistently report that Oracle's initial settlement proposals can be reduced by 40 to 70 percent through: technical challenges to the LMS findings, contractual analysis of what licences actually cover, and competitive negotiation using Oracle's desire to resolve the matter efficiently rather than proceed to formal legal dispute.

The single most important factor in Oracle audit outcomes is the preparation and expertise of the customer's advisory team. Organisations that engage independent Oracle licensing experts at the earliest stage of an audit — before any data is provided to Oracle and before any informal discussions have established positions — consistently achieve better outcomes than those that attempt to manage the process internally or engage expert advice only after Oracle's findings have been presented.