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

Key Output Files at a Glance

Oracle's LMS Database collection script generates multiple output files. Understanding what each file contains and how it drives compliance decisions is the foundation of effective SAM practice. Here is the quick reference guide:

LMS_OVERVIEW.csv — Environment & Instance Summary

The LMS_OVERVIEW.csv provides a high-level summary of each scanned Oracle database instance: server/host name, instance name/SID, Oracle version and edition, hardware/CPU info (cores, chip type), and environment metadata (OS, cluster name, virtualization info).

What to Check

Sample Interpretation

Host: dbserver01 | DB Name: ORCL | Version: 19.3.0.0 EE | Cores: 16 (Intel) | Cluster: 2-node RAC

Interpretation: Enterprise Edition on 16 Intel cores requires 8 processor licenses (core factor 0.5). Two-node RAC means the RAC option must also be licensed on those 8 processors. Verify you have at least 8 EE Database licenses and 8 RAC option licenses for this environment.

LMS_OPTIONS.csv — Database Options & Packs Usage

This is the most critical output file. It lists the status and usage of every separately licensable database option (Partitioning, Advanced Compression, Advanced Security, RAC, etc.) and management pack (Diagnostics Pack, Tuning Pack). Each row shows the option name, a used flag (TRUE/FALSE), detected usage count, and last usage date.

The LMS script tracks historical usage, not just current status. Even if you disabled a feature before the audit, if it was ever used, it will appear with a last usage date and Oracle will flag it. A TRUE or non-zero usage count for any option you haven't purchased is a compliance gap.

Sample Output & Interpretation

Database: ORCL

Installed_Products.txt — Inventory of Installed Components

This file lists every product and component installed in your Oracle Home directory. It's not a usage report; it's an inventory of what's present. Components include database server binaries, tools, utilities, and optional packs.

Risk: Installed Not Equal to Used

Oracle's position is that installed components can be used and therefore must be licensed even if they're currently dormant. This is a contentious point in audits. Oracle may claim that because a feature is installed and available, it poses compliance risk and must be licensed. You may argue that installation without active usage should not drive licensing requirements, but Oracle has escalation leverage in audit disputes.

The safer defensive position is to remove installed components you do not actively use and license those that remain.

How to Use This File

Cross-reference Installed_Products.txt with your LMS_OPTIONS.csv. If an option appears installed but marked FALSE (not used), verify this is intentional. If you can safely uninstall it or disable it, do so proactively. This removes a vulnerability before Oracle audit escalation.

Feature Usage — Granular Usage Statistics

The Feature Usage report (DBA_FEATURE_USAGE_STATISTICS in the script) provides granular sub-feature data. Each row identifies a feature name, first usage date, last usage date, a CURRENTLY_USED flag, and raw detection counts.

This is the forensic layer. When LMS_OPTIONS.csv says TRUE for an option, Feature Usage tells you exactly which sub-features triggered the TRUE flag. This is your evidence layer in audit disputes.

Sample Output & Interpretation

Feature Name: Partitioning (basic) | First Usage: 2023-09-10 | Last Usage: 2024-07-15 | Currently Used: YES

What This Means: Partitioning was first used in September 2023 and remains in active use. Oracle will count the entire period from first to last usage as licensable exposure.

Your Action: If this is a past legacy project now removed, gather evidence (backup files, decommissioning dates, data dictionary queries showing no partitioned objects). If partitioning is still active, you must have Partitioning licenses. If not, either remove partitioned objects or purchase licenses retroactively.

LMS_DBA_USERS.csv — Database Users & Named User Licensing

This file lists every database user account with creation date, last login, lock status, and expiration flags. It drives Named User Plus (NUP) licensing calculations.

NUP licensing is common in smaller deployments (under 100-150 users). Each named user must be licensed. The LMS script counts distinct users and Oracle uses this as your minimum NUP footprint.

NUP Minimum Calculation

Oracle's rule is simple: count unique named users in OPEN status (not locked/expired). This count is your minimum NUP license requirement. If you have 75 open users but only purchased 50 NUP licenses, you have a 25-user compliance gap.

Locked or expired accounts are sometimes challenged. Oracle may argue they are still licensed named users even if dormant. To be defensible, thoroughly remove users you no longer need and document decommissioning dates.

Common Red Flags in LMS Output

• Edition Mismatch: Instance running Enterprise Edition but licensed for Standard Edition. Major finding. Requires immediate action: upgrade license or downgrade instance edition.
• Unlicensed RAC: RAC option showing TRUE but not in your license schedule. This is escalated in every Oracle audit. Remediation is expensive (retroactive licensing or decommissioning nodes).
• Excessive Options Usage: Multiple options (Partitioning, Compression, Advanced Security, Diagnostics) marked TRUE without corresponding licenses. This drives major compliance gaps and expensive true-up negotiations.
• Processor Count Discrepancy: Cores reported in LMS_OVERVIEW don't match your purchasing records or infrastructure. This typically underestimates exposure (you're running more cores than licensed).
• Missing Instances: You know instances exist but they don't appear in LMS output. This means they were never scanned. Oracle will count this as unaccounted exposure and demand compliance investigation.
• Historical Usage in Disabled Features: A feature is disabled today but Feature Usage shows past usage. Oracle counts the entire period as licensed exposure even if feature is no longer enabled.
• Unexplained User Count: LMS_DBA_USERS shows significantly more users than you expected (test accounts, developer accounts, system accounts). This inflates NUP licensing exposure.

Cross-Referencing LMS Output with Entitlements

After extracting and interpreting LMS output, your next step is reconciliation. Create a detailed map:

For each instance in LMS_OVERVIEW:

• Note edition (EE vs SE)
• Count processor cores and apply Oracle's core factor table
• Calculate required processor licenses
• Verify you have those licenses in your agreement

For each TRUE option in LMS_OPTIONS:

• Verify it's in your license schedule
• Check the quantity matches your deployment
• If unlicensed, flag as compliance gap

For NUP:

• Count open users in LMS_DBA_USERS
• Verify you have at least that many NUP licenses
• If short, you have a gap

Actions for Unexpected or Unlicensed Usage

When you discover gaps, follow this escalation process:

Step 1: Validate the Findings

Re-run the LMS script. Check for data accuracy. False positives do occur (especially with RAC cluster detection, virtualization layer counting errors, and historical feature flags). Validate before escalating.

Step 2: Investigate Scope and Impact

For each gap, quantify it. How many unlicensed processors? How many unlicensed users? What's the monetary exposure if Oracle discovers this? This determines your remediation priority and urgency.

Step 3: Immediate Remediation

Options include: (a) Purchase licenses for current unlicensed deployment, (b) Remove or disable unlicensed features, (c) Decommission unlicensed systems.

Step 4: Document and Quantify the Gap

Create a detailed gap analysis. What was unlicensed? From when to when? What's the dollar exposure? This is essential if Oracle initiates audit later—you'll show that you discovered and remediated proactively.

Step 5: Decide: Purchase, Reconfigure, or Exception

For each gap, you have three levers: buy licenses to cover it, reconfigure systems to eliminate it, or request a contractual exception (rarely granted). Most gaps require purchasing or reconfiguring.

Step 6: Engage Stakeholders

If remediation requires infrastructure changes (removing RAC nodes, downgrades, decommissioning), involve IT ops and application owners. Justify the business case for remediation.

Step 7: Remediate and Verify

Execute your remediation. Re-run LMS afterward to confirm the gap is closed. Document the remediation with dates and evidence.

Step 8: Educate and Prevent

Establish policies to prevent future gaps. Example: require SAM approval before enabling new database options, periodically audit feature usage, educate DBAs on licensing implications of their configuration changes.

Best Practices for Reviewing & Organising LMS Output

• Create a master LMS tracking spreadsheet: Document every instance, edition, core count, and licensed options. Update quarterly. This is your single source of truth for Oracle licensing posture.
• Version and date all LMS exports: Keep dated copies of every LMS collection. You may need historical evidence in a dispute (feature was removed on X date, supported by LMS output from that date).
• Cross-reference with your SAM tools: If you use third-party SAM tools (FlexNet, ITAM, etc.), compare their data to LMS output. Discrepancies reveal hidden deployments or configuration errors.
• Involve your Oracle account team early: If you discover significant gaps, consider proactive discussion with Oracle. They may be willing to negotiate true-up terms or implement a compliance agreement. This is far better than silent remediation followed by Oracle audit surprise.
• Implement controls to prevent future gaps: Require change control approvals for any Oracle infrastructure or configuration change. Implement periodic LMS collection and review (at least quarterly, preferably monthly for large deployments).
• Seek expert review: Oracle's LMS output is complex. If you have large deployments or multiple ambiguous findings, engage a licensing expert to review your LMS data before you submit it to Oracle or face audit questions.

Related Reading: Oracle Licensing & Audit Defence

To deepen your understanding of Oracle compliance, explore these related guides:

• Oracle Audit Response & Defence Strategy
• Oracle Knowledge Hub — Complete reference on Oracle licensing across all products
• Guide to Oracle Vendor Management — Strategic negotiation and relationship management
• Analysing Oracle Middleware with the LMS Tool — Deep dive into middleware LMS output

How Redress Compliance Helps with Oracle Audits

At Redress Compliance, we work with enterprise Oracle licensees to interpret LMS output, identify compliance gaps, and prepare defensible positions before Oracle audit contact. Our advisory services include:

• LMS Output Review: We examine your LMS data, identify red flags, and explain what each finding means for your compliance exposure.
• Audit Simulation: We model how Oracle would interpret your LMS data and where your vulnerabilities lie, so you're not surprised in actual audit.
• Gap Remediation Planning: For each discovered gap, we outline remediation options and their cost-benefit tradeoffs.
• Audit Defence Preparation: If Oracle initiates audit after you've worked with us, we provide technical support to your in-house team during audit response, helping challenge false findings and negotiate settlement terms.

Need Help Interpreting Oracle LMS Output?

Oracle's LMS Database script output can be overwhelming—hundreds of queries, dozens of files, and complex licensing rules that determine whether a TRUE flag costs you nothing or millions. Our Oracle licensing experts review LMS output for enterprises worldwide, identifying compliance gaps, challenging false positives, and building defensible positions before you submit data to Oracle.

We've helped clients save millions by catching and remediating issues proactively. Don't submit your LMS output without expert review.