Oracle LMS Analyser: What It Is, How It Works, and How to Use It Proactively

What Is the Oracle LMS Analyser?

The Oracle LMS Analyser is a collection of SQL scripts and operating system commands developed by Oracle's License Management Services (LMS) team — now operating under the umbrella of Oracle's Global Licensing and Advisory Services (GLAS). It is the primary technical data collection instrument Oracle deploys during formal licence audits and compliance reviews.

When Oracle initiates a licence audit, one of its first actions is to send the LMS Collection Tool to the customer with a request to run it across all systems hosting Oracle software. The scripts interrogate each Oracle Database instance and supporting infrastructure, collecting detailed information about installed products, activated options, processor counts, user activity, and feature usage history. Oracle's LMS team then analyses this output to calculate the customer's licence obligation as Oracle sees it.

Critically, the same tool is freely available to customers on My Oracle Support (MOS). Any organisation with an active Oracle support contract can download the current version of the LMS Collection Tool and run it on their own systems — without triggering an audit or notifying Oracle. This ability to run the scripts proactively is one of the most valuable audit defence tools available to Oracle customers.

What Does the LMS Analyser Collect?

The LMS Collection Tool is substantially more comprehensive than most Oracle customers realise. At its core, it executes hundreds of SQL queries against each Oracle Database instance. Recent versions contain over 694 individual SELECT statements, interrogating dozens of Oracle system views and data dictionary tables. The key categories of information collected include:

Database Product Inventory

The scripts identify every Oracle product installed on the system — not just the database engine, but every option pack, management pack, and database feature that is present in the binary installation. This includes products that may have been installed as part of the Oracle Database installer but were never intentionally used. If a product is installed, the script records it.

Feature Usage Statistics

This is the most critical — and most misunderstood — section of the LMS output. Oracle Database maintains an internal view called DBA_FEATURE_USAGE_STATISTICS that tracks every database feature and option that has ever been accessed on the instance. The tracking includes:

• The name of each feature or option
• Whether it has been used (TRUE/FALSE)
• The first date it was used
• The last date it was used
• A usage count (number of times detected in use across samples)
• The version in which first use occurred

This historical record is permanent and cannot be reset. If a DBA accidentally enabled Partitioning five years ago when testing a query, the DBA_FEATURE_USAGE_STATISTICS view still records that use — and the LMS script will capture it. Oracle will present this as evidence that the Partitioning option requires a licence, regardless of whether it is currently in active use.

Hardware and Virtualisation Information

The LMS scripts also collect operating system and hardware information to support Oracle's processor licence calculations. This includes the number of physical CPUs, cores per CPU, whether hyper-threading is enabled, the virtualisation platform in use (if any), and evidence of the physical topology relevant to Oracle's Core Factor Table calculations. For virtual environments, the scripts attempt to determine whether hard or soft partitioning is in use.

Named User and Concurrent User Counts

For databases licensed on a Named User Plus basis, the scripts collect user account data to determine the minimum user count. This includes active accounts, proxy accounts, and application accounts. Oracle uses this data to verify that the Named User Plus licence count meets the minimum of 25 users per processor (for Oracle Database EE) or other applicable minimums.

Oracle Database Options Activation Status

For Database Options such as Partitioning, Real Application Clusters, Advanced Security, Active Data Guard, Oracle Label Security, and Oracle Multitenant, the scripts record both the installation status and the usage history. An option that is installed and has ever been used — even once — is treated by Oracle as requiring a licence for the full history of the deployment.

Management Pack Usage

Oracle's management packs — including the Diagnostics Pack and Tuning Pack — require separate licences and are frequently activated unintentionally through Oracle Enterprise Manager. The LMS scripts detect Enterprise Manager configuration and access to pack-specific functionality. This is one of the most common sources of unplanned compliance findings: organisations discover that DBAs running Automatic Workload Repository (AWR) reports or SQL Tuning Advisor recommendations through Enterprise Manager have been using Diagnostics Pack and Tuning Pack functionality, both of which require separate licences.

The LMS Collection Process During an Audit

When Oracle's GLAS team initiates an audit, the LMS collection process follows a structured sequence:

1. Oracle provides the customer with the appropriate version of the LMS Collection Tool and a formal request letter specifying the scope (which systems to run the scripts on) and the deadline for returning output files
2. The customer's DBA team runs the scripts across all systems in scope — typically all servers that host Oracle software, including production, development, test, and disaster recovery environments
3. The scripts generate output files — typically CSV or XML format — which the customer returns to Oracle's GLAS team
4. Oracle's LMS team analyses the output using proprietary internal tools to calculate the licence position and identify compliance gaps
5. Oracle presents its findings to the customer in a Licence Review Report, which forms the basis of any settlement negotiation

The entire process from initial contact to findings delivery typically takes three to six months for large organisations, and the period during which scripts are run and output is collected is a key risk window. Data returned to Oracle cannot be recalled, and errors in script execution — running scripts on the wrong servers, or providing incomplete output — can be used by Oracle to justify broader assumptions.

How to Use the LMS Analyser Proactively

The proactive use of the LMS Collection Tool is one of the most effective Oracle compliance strategies available. The process is straightforward:

1. Download the current version of the Oracle LMS Collection Tool from My Oracle Support. The tool is accessible through MOS under the licence management services section and is updated periodically to reflect new database versions and options.
2. Run the scripts across your Oracle estate — all production, development, test, and DR instances — using the same procedure Oracle would follow during an audit.
3. Analyse the output files to identify which database options and management packs are recorded as used in DBA_FEATURE_USAGE_STATISTICS, which hardware configurations are recorded, and what the implied licence count is under Oracle's methodology.
4. Compare the LMS-implied licence count against the licences you actually own. Any gap represents potential audit exposure.
5. For any option recorded as used that you do not licence, investigate whether the usage was intentional, whether it can be deactivated going forward, and whether Oracle's methodology for counting it is technically correct.

Organisations that run the LMS scripts proactively and maintain a current Oracle licence position consistently achieve better outcomes in formal audits than those that encounter the data for the first time when Oracle presents findings. The difference is not just knowledge — it is negotiating position. When you know your Oracle exposure before Oracle presents it, you can prepare challenges, gather supporting documentation, and engage in settlement discussions from a position of preparation rather than reaction.

Interpreting LMS Output: Key Items to Review

The LMS output files contain a large volume of technical data. The items with the highest compliance risk relevance are:

• Options with TRUE or non-zero usage count in DBA_FEATURE_USAGE_STATISTICS: Each of these represents a potential licence claim. Review each one against your licence entitlement and assess whether Oracle's classification is technically accurate.
• Enterprise Manager configuration: If Enterprise Manager is connected to any Oracle Database, the Diagnostics Pack and Tuning Pack features need to be actively disabled if you do not licence them. The LMS output will show whether EM_DIAGNOSTICS_PACK and EM_TUNING_PACK usage is recorded.
• Processor count and core topology: Verify that the hardware data the scripts collected accurately reflects your physical configuration, particularly for virtualised environments where the scripts may record virtual hardware rather than physical.
• Database version and Standard Edition eligibility: The LMS output will reveal database versions and editions. Confirm that instances running Enterprise Edition features are properly licensed as EE, and that any Standard Edition 2 instances comply with the SE2 restrictions (maximum 16 vCPUs, one instance per server).

Common LMS Findings and How to Respond

The most frequent LMS findings that generate significant Oracle compliance claims are:

• Diagnostic and Tuning Pack usage via Enterprise Manager: Typically the largest single source of unexpected compliance findings. Disable EM access to AWR reports, SQL Tuning Advisor, and related features if you do not have Diagnostics and Tuning Pack licences.
• Database Partitioning activated in development or test: Developers frequently use table partitioning without realising it requires a separate licence. Production databases are obvious targets; the LMS scripts will find it on dev and test instances too.
• Advanced Security / Transparent Data Encryption: TDE is part of the Advanced Security Option and requires a separate licence. Many organisations encrypt databases using TDE without realising the licence implication.
• Active Data Guard used for high availability: Active Data Guard (read-only standby) is a separate licence from Oracle Database EE. Passive Data Guard (standby not open for reads) does not require a separate licence. The LMS script distinguishes between these configurations.
• Oracle Label Security and Oracle Database Vault: Both are security options requiring separate licences that are sometimes enabled as part of compliance hardening without licence review.

For each finding, the immediate question is whether the usage is technically accurate, whether your licence agreement's terms cover the usage, and whether the option can be deactivated going forward — noting that past usage will remain in the feature usage history. Engaging independent Oracle licensing expertise before responding to Oracle's findings is strongly recommended. Oracle's initial compliance claims routinely overstate the actual obligation by 40 to 70 percent, and technically well-prepared challenges consistently achieve material reductions.