Interpreting Oracle LMS Database Script Output: A Guide for SAM Managers

What Are Oracle LMS Database Scripts?

Oracle's License Management Services (LMS) — more recently rebranded internally as the Global Licensing and Advisory Services (GLAS) group — maintains a library of SQL-based collection scripts used during formal software audit processes. These scripts are delivered to customers under non-disclosure obligations as part of an audit engagement, but any customer with active Oracle Support can also download them from My Oracle Support (MOS) for internal use.

The database scripts are not simple inventory tools. They are forensic instruments designed to extract the maximum amount of compliance-relevant data from every Oracle Database instance in your environment. They query system views, hardware identification tables, user registries, and — most critically — historical feature usage logs that Oracle uses to construct its audit findings.

Understanding what these scripts collect, how they present findings, and what each data point means for your licensing position is the single most important capability a SAM manager can develop when managing an Oracle database estate. This guide provides that foundation.

The LMS Collection Tool: Structure and Components

The LMS Collection Tool is a package of scripts that Oracle organises into functional modules, each targeting a different category of licensing data. When Oracle initiates a formal audit, they typically request that the customer run the full suite across every database server in scope and return the output files in CSV or structured text format.

Core Script Modules

The collection package contains several distinct script modules. The Database Options and Packs script — the most critical from a compliance standpoint — queries DBA_FEATURE_USAGE_STATISTICS and related views to enumerate every licensable database option and management pack that has ever been used. The CPUq script (lms_cpuq.sh) is a shell-level utility that collects physical hardware information including processor model, core count, and thread configuration. The user script enumerates all database accounts and connects that data to applicable Named User Plus metrics where relevant.

Additional modules cover Real Application Clusters topology, virtualisation configuration, Oracle E-Business Suite module usage, and Middleware product installation detection. Each produces a separate output file that Oracle's analysts aggregate into a unified compliance picture.

Running the Scripts: What SAM Managers Need to Know

The database scripts require SYSDBA privileges to execute. They do not make changes to any database objects — they are read-only queries. Running the scripts does not automatically transmit data to Oracle. The output files remain entirely within your environment until you choose to share them. This is an important point: running the LMS scripts internally for self-assessment is entirely safe and does not trigger or accelerate an audit process.

Scripts must be run on each Oracle Database instance individually. In large estates with hundreds or thousands of instances, this creates a significant operational challenge that most SAM teams address through scripted orchestration using tools like Ansible, custom shell wrappers, or commercial SAM platforms that natively support Oracle LMS script execution.

Understanding DBA_FEATURE_USAGE_STATISTICS

DBA_FEATURE_USAGE_STATISTICS is the single most consequential Oracle system view in any licensing audit. This view maintains a persistent, cumulative record of every Oracle Database feature, option, and management pack capability that has ever been accessed on the instance — regardless of whether that access was intentional, whether the relevant license was purchased, or how long ago the access occurred.

How the View Works

The Oracle Database kernel automatically updates DBA_FEATURE_USAGE_STATISTICS each time a licensable feature is invoked. The view records the feature name, the first time it was used, the last time it was used, and a detection count that represents the number of database usage samples (taken approximately weekly) during which the feature was detected as active. A detection count of 1 means the feature appeared active during at least one weekly collection interval. A count of 52 means it appeared active in every weekly sample over a full year.

The critical implication for SAM managers is this: the view does not reset. If a DBA ran an AWR report three years ago — an action that requires the Diagnostics Pack license — that access is recorded and remains visible indefinitely. If Partitioning was used on a test database later cloned to production, the usage history migrates with the data. Oracle auditors review this history and use it to assert a compliance requirement for the entire period of detected usage.

Key Columns in the Output

When you receive or run the LMS options script output, the data maps directly to DBA_FEATURE_USAGE_STATISTICS columns. The most important fields are: NAME (the feature or option identifier), CURRENTLY_USED (TRUE or FALSE — whether the feature is actively in use at time of execution), DETECTED_USAGES (the cumulative detection count), LAST_USAGE_DATE (the timestamp of most recent active detection), and AUX_COUNT (a secondary metric used for certain features like user counts or session counts).

A CURRENTLY_USED value of FALSE does not mean you are out of scope for that feature's license. Oracle will flag any feature with a non-zero DETECTED_USAGES value regardless of current status. The LAST_USAGE_DATE is used to determine how far back the compliance obligation extends.

The 18+ Chargeable Database Options: What Each One Means

Oracle Database has more than 18 separately licensable options and management packs. SAM managers must understand which options require a separate license, what database activity triggers their detection, and where accidental usage is most common.

Options That Generate the Most Audit Findings

Diagnostics Pack is consistently the most common unexpected finding in Oracle audits. It is triggered by Automatic Workload Repository (AWR) reports, Active Session History (ASH) data, Automatic Database Diagnostic Monitor (ADDM) alerts, and Enterprise Manager performance monitoring dashboards. DBAs who use EM for routine monitoring frequently activate Diagnostics Pack without realising it is a separately licensed capability.

Tuning Pack typically co-exists with Diagnostics Pack findings because it depends on the AWR infrastructure. The SQL Tuning Advisor, Automatic SQL Tuning, and SQL Access Advisor all require Tuning Pack. Any environment where DBAs use automatic tuning tasks or EM's SQL performance features will show Tuning Pack usage.

Partitioning is required when database tables or indexes use Oracle's partitioning framework. This is common in data warehousing environments, large OLTP systems, or when DBAs have created partitioned tables for performance reasons without connecting the action to a licensing obligation. Partitioning usage is also frequently inherited when databases are cloned from licensed environments.

Real Application Clusters (RAC) requires a license for each node in the cluster. The LMS scripts detect RAC topology through cluster configuration data. RAC is typically intentionally deployed, but the number of nodes in scope can be disputed if the environment has grown since the original license purchase.

Advanced Security — formerly covering Transparent Data Encryption and network encryption features — is triggered when encryption at rest or in transit is configured at the database level. Cloud migrations frequently activate TDE as a default configuration setting, creating an Advanced Security exposure that organisations discover only during an audit.

Active Data Guard requires a separate license for each standby database that is open for read access while in recovery mode. A standby opened for reporting or load balancing purposes without an Active Data Guard license is one of the most expensive hidden exposures in Oracle database environments. Database Vault, Label Security, OLAP, Spatial and Graph, and Data Mining (now Machine Learning) are options that appear in the output when those components have been invoked, even in demo or development contexts.

Management Packs Beyond Diagnostics and Tuning

The Configuration Management Pack and Provisioning and Patch Automation Pack are triggered through certain Enterprise Manager lifecycle management functions. The Change Management Pack is activated by EM's schema comparison and database change management features. These packs are frequently flagged in organisations that have deployed Enterprise Manager broadly as a central operations platform without separately licensing the management pack capabilities it exposes.

Reading the CPUq Output: Processor Licensing Calculations

Oracle's processor-based licensing model requires organisations to license Oracle software based on the number of physical processor cores in the servers where the software is installed and running. The CPUq script collects the hardware data Oracle uses to validate processor license counts.

What CPUq Collects

The CPUq shell script executes platform-specific commands to identify the server hardware model, number of physical processor sockets, number of physical cores per socket, and total thread count. It also attempts to identify virtualisation layer information where applicable. The output is a structured text file that Oracle maps against the Oracle Processor Core Factor Table — the published multiplier list that converts physical cores to the number of Oracle Processor licenses required.

Core Factor Table Application

Intel Xeon and AMD EPYC processors carry a core factor of 0.5, meaning two physical cores equal one Oracle Processor license. SPARC processors use a factor of 0.25 in some configurations. IBM Power processors have factors ranging from 0.5 to 1.0 depending on the specific model. The core factor application should be validated manually by SAM teams, as hardware configuration data can sometimes be misread by the scripts in complex virtualised environments.

In physical server deployments the licensing calculation is straightforward: identify all sockets, count all cores, apply the relevant core factor. The complexity arises in virtualised environments where Oracle does not recognise most hypervisor-based partitioning as a valid basis for sub-capacity licensing — meaning the entire physical host's core count is typically in scope, not just the allocated vCPUs.

User Metrics in the LMS Output

For database environments licensed on a Named User Plus (NUP) basis rather than a Processor basis, the LMS scripts collect data to support a user metric compliance assessment. The user script queries DBA_USERS to enumerate all active database accounts, along with session and connection data to establish usage patterns.

Named User Plus Minimums

Oracle's Named User Plus metric carries a minimum density requirement: the number of Named User Plus licenses must be at least 25 per Processor license that would otherwise apply to the same server. If a server has two physical sockets with 10 cores each at a 0.5 core factor, the minimum NUP count is 100 (10 Processor licenses × 25 minimum). Many organisations find their actual user counts fall below this minimum when they attempt to move from Processor to NUP licensing, creating an unexpected exposure.

The LMS output for user metrics typically includes total user counts, active user counts (those with recent login activity), and service account identification. SAM managers should reconcile these counts against their actual entitlement documentation and validate that all human users who access Oracle-connected applications are included in the NUP count — not just direct database users.

The LMS_OPTIONS.CSV File: A Line-by-Line Reading Guide

The primary output file from the database options script is typically delivered as LMS_OPTIONS.CSV. SAM managers should approach this file systematically. Every row represents a licensable feature or option. The key columns to focus on are the feature NAME, the DETECTED_USAGES count, the CURRENTLY_USED flag, and the LAST_USAGE_DATE.

Triage Categories

Organise all rows into three categories after initial review. The first category — Licensed and in use — contains features with non-zero detection counts where you hold the corresponding license. These require no immediate action but should be documented in your entitlement mapping. The second category — Detected but unlicensed — contains features with non-zero detection counts where you do not hold a corresponding license. Every row in this category is a potential audit finding requiring investigation and remediation. The third category — Not detected — contains features showing zero or null detection counts, generally out of scope for the current assessment.

Investigating Unlicensed Detections

For every unlicensed detection, SAM managers must answer three questions before deciding on a remediation path. First: was the usage genuine and ongoing, or a one-time accidental invocation? A DETECTED_USAGES count of 1 with a LAST_USAGE_DATE three years ago is a fundamentally different risk than 200 ongoing detections. Second: can the usage be remediated going forward by disabling the feature, changing configuration, or restricting access? Third: what is the commercial impact of purchasing the license retroactively versus challenging the finding with Oracle?

Answering these questions requires collaboration between SAM managers, DBAs who can identify what triggered the usage, and legal or procurement teams who understand the contractual context. Rushing to purchase licenses without this analysis frequently results in organisations paying for exposures that could have been defended or minimised.

Proactive Self-Assessment: Running LMS Scripts Internally

The most effective Oracle compliance programme does not wait for Oracle to initiate an audit. SAM managers who run the LMS collection scripts internally — at least annually, and ideally before every major contract renewal or negotiation — gain a significant strategic advantage. They know their exposure before Oracle does, they have time to investigate and remediate, and they approach any Oracle engagement from a position of knowledge rather than reactive defence.

How to Obtain the Scripts

The LMS Collection Tool is available for download from My Oracle Support (MOS) under Note 1317238.1. Access requires an active support contract. The download package includes the full suite of database, middleware, and application scripts along with a user guide documenting the expected output format for each script module.

Building a Self-Assessment Process

A structured self-assessment begins with inventory validation — confirming that every Oracle Database instance in your environment is included in the scope of the script execution. Missing a single production database from a self-assessment can create a blind spot that Oracle discovers during a formal audit. Work with your DBA team and cloud operations to ensure complete coverage including databases running on cloud infrastructure (OCI, AWS, Azure, GCP), containerised environments, and databases managed by application vendors on your behalf.

Once scripts have been executed and output files collected, create a centralised analysis workbook that maps each detected feature to your entitlement records. Where gaps are identified, escalate immediately — do not allow unlicensed feature usage to continue while the business case for licensing is being evaluated. Each additional week of continued usage extends the historical exposure Oracle will eventually calculate.

Document the remediation actions taken and the dates they were completed. This documentation is valuable both for your own governance programme and as evidence in any future Oracle audit negotiation. Oracle auditors can sometimes be persuaded to limit back-calculation periods to the date a genuine remediation was implemented, if that remediation can be demonstrated credibly.

Common SAM Manager Mistakes When Reading LMS Output

Experience across hundreds of Oracle audit engagements highlights several recurring errors that SAM managers make when first working with LMS output data.

Treating CURRENTLY_USED = FALSE as Safe

A FALSE value in the CURRENTLY_USED column does not mean the feature is out of scope. It means the feature was not detected as active at the precise moment the script ran. Oracle will calculate a compliance obligation based on the entire period represented by non-zero DETECTED_USAGES data, regardless of current status. Never dismiss any row with a non-zero detection count simply because current usage shows as FALSE.

Overlooking Management Pack Exposure in EM Deployments

Organisations that have deployed Oracle Enterprise Manager as their central database operations platform frequently underestimate the management pack exposure this creates. Every AWR report, every SQL tuning recommendation, every performance monitoring session delivered through EM potentially touches a licensed management pack capability. SAM managers should audit all EM functionality in use and map it against licensed management packs before any Oracle engagement.

Focusing Only on Production Databases

Oracle's licensing obligation extends to development, test, and UAT environments unless those environments are specifically licensed as a development-only edition or are covered by a contractual development use provision. LMS scripts run against non-production databases frequently reveal option usage that mirrors production patterns — particularly in environments where production database backups are regularly restored to test systems, bringing all production feature usage history with them.

Underestimating Virtualisation Scope

In VMware, Hyper-V, Nutanix, and similar virtualised environments, Oracle requires that all physical cores across all hosts that could potentially run Oracle workloads are licensed — not just the vCPUs allocated to Oracle VMs. The CPUq script captures physical host information, and Oracle maps this against all Oracle VM instances in the cluster. SAM managers who calculate license requirements based on vCPU allocations rather than physical host cores consistently underestimate their licensing position.

After the Analysis: Working with Oracle

If your internal LMS analysis reveals material compliance gaps, the question of how to engage with Oracle becomes strategically important. There are generally three paths: self-remediation and normalisation before any Oracle engagement, proactive disclosure as part of a broader commercial negotiation, or defensive preparation for a likely formal audit.

Self-Remediation Before Oracle Engagement

If you identify unlicensed feature usage that can be disabled or remediated, completing that remediation before Oracle initiates any formal review is the strongest position available. Once Oracle has delivered an audit letter, the scope and timeline are Oracle's to control. Before that point, you control the narrative, the scope, and the timing.

Remediation may involve disabling specific database options at the configuration level, restricting DBA access to EM features that trigger management pack usage, disabling automatic tuning tasks, or migrating workloads off servers where unlicensed options are in use. Each action should be documented with timestamps and verified through a follow-up LMS script execution.

Negotiating Oracle Audit Findings

Where remediation is not practical and a compliance gap cannot be eliminated, the focus shifts to negotiating the commercial resolution. Oracle audit findings are frequently overstated. The initial claims presented by Oracle's audit team often include maximum-scope calculations that assume the worst interpretation of every data point. Organisations with strong technical evidence — credible self-assessment data, clear documentation of feature usage context, DBA testimony about the circumstances of historical usage — consistently achieve better outcomes than those who simply accept Oracle's initial figures.

Remember that Oracle's support fees increase at 8% per year. Any back-calculated compliance claim that Oracle seeks to resolve through a new license purchase will carry that ongoing support obligation. The commercial value of a clean negotiated settlement, structured as a forward-looking license purchase with minimal retroactive liability, is almost always higher than accepting Oracle's first offer on an audit finding.

Building an Ongoing LMS Governance Programme

A mature Oracle SAM function does not treat LMS script analysis as a reactive exercise triggered by audit risk. It treats it as a routine governance activity — a regular health check on Oracle compliance status that feeds into commercial planning and contract management.

Best practice is to run LMS scripts at least once per year across the full Oracle estate, with additional targeted runs before any Oracle negotiation, ahead of any major infrastructure change (cloud migration, virtualisation project, hardware refresh), and after any database upgrade or clone operation. Maintain a central register of all Oracle Database instances, their current option usage status, their licensing coverage, and the date of the last LMS compliance check.

Invest in DBA training so that the people who interact with Oracle databases daily understand which actions trigger licensable feature usage. A DBA who understands that running an AWR report requires a Diagnostics Pack license is far less likely to create an undocumented compliance gap. Establish change management controls that require licensing review before any new Oracle option or pack is enabled in a production environment.

Organisations that embed LMS governance into their standard SAM processes consistently spend less on Oracle support, face fewer audit surprises, and negotiate from stronger positions when Oracle comes calling. The investment is modest; the return is substantial. For Oracle estates of any significant scale, independent advisory support from specialists with direct LMS audit experience is a cost-effective safeguard against the exposures that internal teams most commonly miss.