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

Interpreting Oracle LMS Database Script Output

Oracle’s License Management Services (LMS) Database collection script – often called Oracle Review Lite – is used during audits to gather detailed data about your Oracle Database installations and usage. It produces output files containing raw technical information on what Oracle products are installed, which database features have been used, how many users exist, and more.

This script provides a comprehensive snapshot of your Oracle deployment, but it does not automatically tell you if you are compliant. The data can be voluminous and is not always easy to interpret without licensing expertise.

Understanding these outputs is critical for software asset management (SAM) managers to perform internal compliance checks and explain results to stakeholders or clients.

This guide offers an expert-level, practical approach to interpreting key LMS script output files, identifying compliance red flags, and aligning the findings with your Oracle license entitlements.

Read Step-by-Step Guide: Analyzing Oracle LMS Tool Output for Database Licensing.

Overview of the Oracle LMS Database Collection Script

Oracle’s LMS Database script is a collection of SQL queries and system checks that Oracle auditors provide to customers during an audit (or a self-assessment). Its purpose is to automatically extract all relevant licensing data from each database server, ensuring no use of licensable features is overlooked.

The script runs hundreds of queries against your databases and system views. For example, it covers all 18 chargeable Oracle Database options (such as Partitioning, Advanced Security, etc.), major management packs (like Diagnostics and Tuning Packs), and hardware and user metrics.

Oracle relies on this thorough data to assess compliance—if a feature was ever enabled or used, the script is designed to find evidence of it.

Why it matters: The LMS script standardizes audit data collection. It captures current configurations and historical usage footprints (including the first and last dates a feature was used). Oracle’s auditors will compare this raw output to your contracts to identify any usage of features or products beyond what you have licensed.

Reviewing this data internally before submitting it to Oracle is a best practice for SAM managers. It allows you to catch any surprises – e.g., an option enabled that you weren’t aware of – so you can investigate or remediate before Oracle’s official analysis. In short, the LMS script is the cornerstone of an Oracle audit, and understanding its output empowers you to manage compliance proactively.

Key Output Files and Data from the LMS Script

When you run the Oracle LMS Database collection script, it will generate several output files (often packaged in a ZIP archive). The exact files can vary by script version, but typically, you will encounter LMS_OPTIONS.csv, LMS_OVERVIEW.csv, LMS_DBA_USERS.csv, Installed_Products.txt, and possibly a detailed Feature Usage report (sometimes the script or SAM tool produces an output of DBA_FEATURE_USAGE_STATISTICS or a FeatureUsage.sql query).

Below, we explain these key files, what information they contain, why they matter for licensing, and how to interpret sample data rows.

LMS_OVERVIEW.csv – Environment and Instance Summary

The LMS_OVERVIEW.csv file provides a high-level summary of each scanned Oracle database instance. It typically includes details like:

• Server/Host Name: e.g. dbserver01 or the machine name where the database resides.
• Oracle Instance Name / SID: The identifier of the database instance.
• Oracle Version and Edition: For example, Oracle Database 19c Enterprise Edition tells you the version number and whether it’s Enterprise Edition (EE), Standard Edition (SE), etc. Edition is crucial because features and licensing rules differ (EE supports extra-cost options; SE does not).
• Hardware/CPU Info: The number of CPUs or cores and hardware type (e.g., 8 CPU cores on Intel x86_64). Oracle uses this to calculate the required processor licenses. For example, 8 cores on a server with an Intel chip might equate to 4 processor licenses after applying Oracle’s core factor if Enterprise Edition is used.
• Environment Metadata: Possibly OS type, cluster name, or virtualization info if available. For instance, if the database is part of a Real Application Clusters (RAC) setup, the overview might note a cluster name or a multi-node configuration.

Why it matters: The overview is your starting point to ensure the inventory is complete and matches your expectations. Check that every Oracle database in your environment is listed and that the edition and version align with what you’ve deployed. From a license perspective, note the edition (EE vs SE): using Enterprise Edition without proper licensing is a huge compliance issue.

Also, note the CPU count – you’ll cross-reference this with your purchased processor licenses. For example, if an instance is on an 8-core server and you have Enterprise Edition, you should have sufficient licenses for those cores (considering Oracle’s core factor). If the script shows a database is part of a cluster (RAC), ensure you’ve licensed the RAC option for each cluster server.

The overview lets you map each instance to an entitlement: Do we have a license for an Oracle Database of this edition on this hardware? If an instance appears that you were unaware of (e.g., a forgotten test database), that’s a red flag to address immediately (it would still need licensing if active).

Read Analyzing Oracle Middleware with the LMS Collection Tool.

Sample interpretation: Suppose LMS_OVERVIEW.csv has a line showing:

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

This indicates that dbserver01 runs an Oracle 19c Enterprise Edition database named ORCL on 16 cores and is part of a 2-node RAC cluster. Licensing interpretation: Enterprise Edition on 16 Intel cores likely requires eight processor licenses (if core factor 0.5), and because it’s RAC, you’d also need the Oracle RAC option licensed on those processors.

You should verify that you purchased at least 8 EE database licenses and 8 RAC option licenses (or your entitlements) for this environment.

LMS_OPTIONS.csv – Database Options and Packs Usage

The LMS_OPTIONS.csv file is one of the most critical outputs. It lists the status and usage of each database’s optional database features and management packs. Oracle Database has several separately licensable options (like Partitioning, Advanced Compression, Advanced Security, etc.) and packs (Diagnostics Pack, Tuning Pack, etc.). LMS_OPTIONS.csv consolidates the options installed and/or used in the database.

Typically, each row will include:

• Option/Feature Name: e.g., Partitioning, Oracle Advanced Compression, Oracle Real Application Clusters, Oracle Diagnostics Pack, etc.
• Detected Usage (Count): How many times was the feature detected as used? This might be a number derived from Oracle’s internal counters (often from the DBA_FEATURE_USAGE_STATISTICS view). For example, “Partitioning – Detected Uses: 5”.
• Currently Used (Yes/No): A flag indicating if the feature is currently enabled or in use (TRUE/FALSE or YES/NO).
• Last Usage Date: The last time the feature was used (if ever) – e.g., “Last Used: 2024-07-15”. Some outputs also show a first usage date.

Why it matters: This file is directly tied to license compliance for add-on options and packs. Oracle licenses its database options separately from the core database license. If an option is used (even once), Oracle’s policy is that it must be licensed for that database environment.

The LMS script output highlights any such usage. As a SAM manager, you must carefully interpret each line: a “TRUE” or non-zero usage for an option you haven’t purchased is a compliance gap. Importantly, the script tracks historical usage, not just current status.

So, even if you disabled a feature before the audit, if it was used in the past, it will show up here (with a last usage date), and Oracle will flag it. Conversely, options that show as “FALSE” (not used) do not require a license (you don’t pay for options that are installed but not used) – although you should ensure they remain unused or uninstalled to avoid accidental activation.

Sample data and interpretation: An excerpt from LMS_OPTIONS.csv might look like:

Database: ORCL  
Option                     | Used? | Detected Uses | Last Usage Date  
Partitioning               | TRUE  | 5             | 2024-07-15  
Advanced Compression       | FALSE | 0             | N/A  
Oracle Diagnostics Pack    | TRUE  | 1             | 2024-06-01  
Oracle Real Application Clusters (RAC) | TRUE |  (see note) | (see note)

• Partitioning = TRUE (Used 5 times): This indicates the Partitioning option was utilized 5 times on database ORCL and was last used on July 15, 2024. Even if Partitioning is not actively used today, the historical usage count of 5 means it was used in the past. From a license perspective, if you do not have Oracle Partitioning option licenses for the servers running ORCL, this is a serious compliance issue – Oracle will expect that you needed Partitioning licenses when those uses occurred. Action: Verify if Partitioning was licensed. If not, investigate why it was used (perhaps a partitioned table or index exists) and consider purchasing a Partitioning license or removing that feature after discussing it with your Oracle rep.
• Advanced Compression = FALSE (0 uses): None of the features that require the Advanced Compression option have been used. If you haven’t purchased Advanced Compression, that’s good – no license is needed since it’s not used. However, Advanced Compression often covers things like OLTP table compression, securefile compression, etc. Ensure your DBAs haven’t enabled any compression beyond what’s allowed with the base license. The “FALSE” here gives you confidence that Oracle should not claim an Advanced Compression license requirement for ORCL at audit time. (It can also indicate the feature is not installed or available in this edition).
• Oracle Diagnostics Pack = TRUE (used): Diagnostics Pack (a management pack for performance monitoring/AWR) shows usage. Often, this is triggered by the usage of Automatic Workload Repository or other performance views. Even a single use (the example shows 1 detected use) means the pack was accessed – perhaps someone ran an AWR report or used Oracle Enterprise Manager on this DB. This is a compliance red flag if you have not licensed Diagnostics Pack. Oracle will bill for it because the script confirms it was used. In practice, many DBAs accidentally use this via OEM or by running a built-in health check. Interpretation: Confirm if your organization has Diagnostics Pack licenses (usually bundled with Oracle Enterprise Manager or purchased separately). If not, you should immediately cease any Diagnostics Pack activity on ORCL (e.g., disable AWR snapshots by setting CONTROL_MANAGEMENT_PACK_ACCESS = NONE to prevent further use) and be prepared to explain this usage or procure licenses.
• Real Application Clusters (RAC) = TRUE: If the database is part of an RAC cluster, the output will indicate RAC is in use (this might appear in LMS_OPTIONS or in the Overview as a clustered environment). RAC being “TRUE” means the database is configured for multi-node clustering. RAC is a separately licensed option that must be licensed for each processor in each cluster node. Interpretation: If you see RAC in use, ensure you have Oracle RAC option licenses. If the output shows RAC, but you only licensed single-instance databases, then you have unlicensed RAC usage – a critical compliance issue. Organizations sometimes enable RAC for high availability or testing without fully realizing it triggers licensing; the LMS script will definitely catch this.

In summary, LMS_OPTIONS.csv is your license compliance report card for database features. Go line by line for each database: every “TRUE” under an option or pack should correspond to something you have entitlement for. If not, mark it as a potential non-compliance item to address.

Installed_Products.txt – Inventory of Installed Components

The Installed_Products.txt (or similarly named file) is usually a text file listing all Oracle software components found on the server or in the Oracle Home directory.

This is akin to an inventory or “lsinventory” output. It can include:

• Oracle Database edition and version installed (e.g., Oracle Database 12c 12.1.0.1.0).
• Components/Options installed by the installer: For example, when Oracle Database is installed, many optional components are installed by default even if not used. You might see items like Partitioning, OLAP, Data Mining, Oracle Label Security, etc., listed as installed products under the Oracle Home.
• Java and other bundled products, such as the Oracle JVM, Oracle XML Database, or the Java SDK version, are included.
• Patches or one-off fixes if the inventory includes patch information (sometimes a separate file or included here, showing patch IDs applied).

Why it matters: This file tells you what’s physically present on the system. While Oracle’s policy is that you only need to license options/packs when they are used (not just because they’re installed), having them installed is risky. If a component is installed, a DBA might inadvertently use it, triggering a license need.

From a SAM standpoint, the Installed Products list helps you double-check that no unexpected Oracle products are lurking on the server. For example, if this file shows Oracle Database Vault is installed, and you haven’t licensed Database Vault, you’ll want to ensure it’s not enabled/used.

It also confirms the edition: if it lists “Enterprise Edition”, you know the binaries support all options (and thus all those options will appear in LMS_OPTIONS.csv as potentially TRUE/FALSE). If it lists “Standard Edition”, options like Partitioning wouldn’t even be applicable.

This inventory is also useful for entitlement cross-reference: ensure that every installed Oracle software product (Database, Middleware, etc., if the script covers multiple, though this one is DB-focused) has a corresponding license in your possession.

For instance, if Installed_Products.txt shows “Oracle Database Enterprise Edition 19.0.0.0” and “Oracle WebLogic Server” (in case of a broader script run), you should have licenses for both the database and WebLogic. If an installed product is something you didn’t expect (e.g., a pack or a different edition), investigate why it’s there.

Sample snippet interpretation: You might see something like:

nginxCopyEditInstalled Products (Oracle Home /u01/app/oracle/product/19.0.0/dbhome_1):
- Oracle Database 19c            19.0.0.0.0
- Oracle JVM                    19.0.0.0.0
- Partitioning                  19.0.0.0.0
- OLAP                          19.0.0.0.0
- Advanced Analytics (Data Mining) 19.0.0.0.0
- Oracle Label Security         19.0.0.0.0
- Oracle Real Application Clusters    19.0.0.0.0
... (etc, listing 100+ components) ...

This shows an Oracle Home where Enterprise Edition is installed with many components. Key points: Partitioning, OLAP, Data Mining, etc., are installed. If LMS_OPTIONS.csv indicated those were not used (FALSE), then they’re just sitting idle – no compliance issue yet, but a potential one if they ever get used.

As a best practice, if you know you will never use certain options, you can remove them or at least be vigilant. Also, if you only intended to install Standard Edition, seeing EE components here means you installed EE, which is a big problem. “Oracle Real Application Clusters” in the install list suggests the binaries support RAC. If this is a single-instance deployment, RAC may not be active (check LMS_OPTIONS.csv to confirm).

In summary, Installed_Products.txt helps you inventory the Oracle components on each server. Use it to ensure no Oracle product runs unlicensed and to understand which optional features are present (and thus could be accidentally used). It complements LMS_OPTIONS.csv: one shows what’s installed, and the other shows what’s used.

Feature Usage (Detailed Usage Statistics)

In some cases, the LMS script or accompanying materials provide a detailed feature usage report – either as part of LMS_DETAIL.csv or a separate output (sometimes the script FeatureUsage.sql is run to dump DBA_FEATURE_USAGE_STATISTICS).

This is a more granular view of how specific features have been utilized. It often includes:

• Feature Name: each tracked feature or sub-feature (Oracle has dozens of tracked features, e.g., “Partitioning (user)”, “Partitioning (system)”, “Advanced Index Compression”, “SecureFile Compression (user)”, “Transparent Data Encryption”, “In-Memory Column Store”, etc.).
• Detected Usages: number of times Oracle detected usage of that feature.
• Currently Used (True/False): Whether the feature is currently in use (according to Oracle’s internal monitoring).
• First Usage Date / Last Usage Date: when the feature was first and last seen in use.

This data is the raw evidence behind the summary in LMS_OPTIONS.csv. Oracle’s internal view DBA_FEATURE_USAGE_STATISTICS logs feature usage and is reset only when you recreate the database or manually reset counters. The LMS script extracts this to show current usage (if the feature is active now) and historical usage counts.

Why it matters: If you need to deep-dive, this file shows which features triggered usage. For example, “Partitioning (user)” vs “Partitioning (system)” can appear separately. “Partitioning (user)” typically tracks user-created partitioned objects (which require a license), whereas “Partitioning (system)” might indicate internal use by Oracle (which generally doesn’t count against you – Oracle usually cares about user-driven usage).

Similarly, for Advanced Compression, it may list each compression feature (OLTP Table Compression, SecureFile Compression, Data Pump compression, etc.) and whether they were used.

This helps you pinpoint what caused a license requirement. If LMS_OPTIONS.csv flags Advanced Compression used, the detailed usage might show, for instance, “SecureFile Compression (user)—TRUE—Last used 2025-01-10,” indicating someone created a SecureFile LOB with compression, triggering the need for an Advanced Compression license.

From a compliance perspective, Oracle will use this level of detail to justify its findings. As a SAM manager, you can use it to:

• Verify if the usage might have been a one-time event or ongoing. (If the detected usage is 1 and was last used two years ago, that’s a different risk than 1000 ongoing usages.)
• Cross-check with DBAs: “Why does it show Partitioning (user) used 5 times? Did we create partitioned tables?” Maybe a developer did it on a test schema. Knowing this allows targeted remediation.
• Provide explanations or challenge Oracle if something looks odd. For example, some features might show “TRUE” due to internal bugs or false positives (there have been cases where features are marked used even if not explicitly used by the customer, due to Oracle background tasks). The output sometimes notes “SUPPRESSED_DUE_TO_BUG” for certain features that Oracle knows to ignore (as seen in the example of Advanced Index Compression in the snippet, which suggests Oracle discounted it because of a known bug). This can be a defense if Oracle mistakenly counts a usage – you have the data to discuss.

Sample interpretation: A FeatureUsage output snippet might look like:

yaml Feature                                  | Detected_Usages | Currently_Used | Last_Usage_Date  
Partitioning (user)                      | 5               | FALSE          | 2024-07-15  
Partitioning (system)                    | 3               | TRUE           | 2024-07-15  
Advanced Index Compression (Advanced Compression) | 1 | TRUE | 2024-09-05  
SecureFile Compression (user) (Adv. Compression)  | 0 | FALSE | N/A  
Transparent Data Encryption (ASO)        | 12              | TRUE           | 2025-02-10  
... etc ...

Interpretation of this example:

• Partitioning (user) shows five uses, currently_used = FALSE. That implies that at one point, five partitioned objects were created, but perhaps they were dropped (so no partitioned table exists currently, hence FALSE currently). The last use was on 2024-07-15. Oracle would still count this as the Partitioning option being used 5 times. License implication: The partitioning option is needed, as discussed earlier.
• Partitioning (system) has three uses. Currently, TRUE suggests Oracle internally used partitioning (could be partitioned indexes for XML, etc.), and it’s active. Oracle typically doesn’t charge for “system” use if there’s no user-driven usage, but it’s a nuanced point. Usually, if (user) usage is zero and only (system) is true, Oracle might not enforce a license, but you’d need to confirm with them. Regardless, in this example, since the (user) had five uses, a moot license is required.
• Advanced Index Compression is a sub-feature of Advanced Compression. I detected one use, and it is still currently used (TRUE) with the last usage on 2024-09-05. This likely means there’s an index created with compression. That alone triggers the need for the Advanced Compression option license. If you see any sub-feature of an option used, you must license the whole option.
• SecureFile Compression (user) shows zero uses (never used). So, not all sub-features were utilized—only the index compression was. However, a license is still required because one part of Advanced Compression was used.
• Transparent Data Encryption (TDE) under Advanced Security Option (ASO) shows 12 TRUE uses. TDE (encryption) is a feature of the Oracle Advanced Security Option. This indicates that someone has encrypted columns/tablespaces (or used Data Redaction, etc.). If ASO isn’t licensed and you see this, it’s a clear compliance issue. You’d need to either stop using TDE or obtain ASO licenses. Often, organizations enable TDE to meet security requirements, sometimes unaware it’s a separately licensed feature – the LMS output will catch it.

The Feature Usage detail is for deep analysis. Not every stakeholder needs to see this level of detail, but you should use it as an internal license specialist to fully understand why a feature was flagged.

It provides the forensic detail behind an option’s usage and will guide your response (e.g., which team used that feature, on which objects, etc.). It’s also useful for cross-referencing with Oracle’s contracts or documentation if you need to challenge a finding.

LMS_DBA_USERS.csv – Database Users and License Metrics

The LMS_DBA_USERS.csv file lists the database users (accounts) in each Oracle database. Typical contents include:

• Username (each account/schema in the DB).
• Account Status (OPEN, LOCKED, EXPIRED, etc.).
• Possibly the Created Date or other attributes of the user.

Why it matters: This ties into Oracle’s Named User Plus (NUP) licensing metric. Many Oracle Database licenses (especially in non-production or smaller environments) are based on NUP, which means you need a license for each named user who accesses the database (with a defined minimum per processor). Oracle auditors will use the user count to verify that you meet the minimums and aren’t under-licensed on a user basis.

For example, Oracle’s standard Database Enterprise Edition rule is at least 25 Named User Plus licenses per processor. If your output shows 10 users on a 2-processor server, the minimum required would still be 50 NUP licenses (even if only 10 actual users). Conversely, if you have 100 users on that server but only bought 50 NUP licenses, you’re under-licensed – a compliance gap.

Additionally, the user list helps identify generic or technical accounts. Oracle may count any enabled account as a user needing a license unless you can argue that it’s an Oracle internal account or a duplicate. Common Oracle-maintained accounts (SYS, SYSTEM, DBSNMP, etc.) are usually not counted toward licensing, but you must be prepared to clarify this.

Suppose you have many application schemas or service accounts. In that case, Oracle might require each to be licensed unless they fall under some multiplexing rule (which Oracle doesn’t allow as an exemption – each distinct named user, human or non-human, typically needs a license if it can log on).

How to interpret: Review the user list for each database:

• Count the number of active (unlocked) user accounts. This is a starting point for how many Named User licenses you’d need if using the NUP metric. If a database has accounts that are no longer in use (e.g., old employee logins), consider locking or removing them to potentially reduce your count (though remember Oracle’s minimums still apply).
• Identify system/service accounts (e.g., SYS, SYSTEM, OUTLN, ANONYMOUS, APEX_PUBLIC_USER, etc.) and application schemas. In an audit, you can often exclude Oracle-supplied accounts and argue that some accounts aren’t individual people (for example, one application account used by a middleware application that 100 users access might count as 1 named user in Oracle’s eyes, although this is a tricky area). Prepare documentation to show which accounts are application integrations versus actual named end-users.
• If you have a Named User Plus license, ensure the count (after any allowable exclusions) does not exceed your purchased quantity. If the script output shows 80 named users on a certain database and you only have 50 licenses, you must true-up your licenses or convert to processor licenses for that environment. User counts aren’t directly a compliance issue if you have a Processor license. However, the output still helps verify that Named User minimums are met (Oracle requires that even if you have processor licenses for production, sometimes your non-production might need to be licensed by NUP – check your contract terms).

For example, LMS_DBA_USERS.csv for DB ORCL might list 120 users, of which 20 are Oracle default accounts and 100 are application or human accounts. If ORCL runs on a 4-processor server, Oracle’s minimum for EE would be 4 * 25 = 100 Named Users minimum.

So, having 100 actual users meets the minimum – you would need at least 100 NUP licenses. If you only purchased 80 NUP licenses for that database, you’re under by 20. Alternatively, if you have processor licenses instead, this user count is informational but not a licensing limit (still, 100 users on 4 processors might have been better licensed as processors anyway).

In summary, use LMS_DBA_USERS.csv to cross-check your user-based licensing. It can also highlight potential issues like generic accounts (which Oracle might challenge as needing separate licenses if used by different people) or just the sprawl of accounts, which could be cleaned up.

Other Files (LMS_DETAIL.csv, LMS_V$LICENSE.csv, LMS_V$SESSION.csv)

Depending on the script, you may see additional files:

• LMS_DETAIL.csv: This often contains very granular details that don’t fit in the main summary, possibly including things like each schema’s size or specifics about feature usage per schema/PDB, etc. It can be quite technical. You may not use this file heavily for license interpretation unless you are investigating a particular detail.
• LMS_V$LICENSE.csv: Oracle’s V$LICENSE view provides some high-water mark statistics, like maximum concurrent user sessions. This is rarely a direct licensing metric today (Oracle used to have concurrent device licenses long ago, but not in modern contracts). However, it might show if any Oracle parameter limits were set. Usually not a compliance driver, but included for completeness.
• LMS_V$SESSION.csv: Possibly a snapshot of current sessions at script run time. This could be used to see how many sessions were active (again, this is not usually directly relevant to license counts, but it can indicate usage patterns). One indirect use could be to see if any unauthorized application (by program name) connects, etc., but that’s more operational.

For SAM purposes, focus on the main files discussed above. The other outputs are mostly to give Oracle’s auditors a complete picture or to support some edge questions during an audit.

Common Red Flags in LMS Output (What to Watch For)

SAM managers should be highly alert for certain patterns that frequently indicate compliance issues when reviewing the LMS script outputs.

Here are some of the most common red flags and what they mean:

• Unlicensed Database Options Showing “Used”: Any option in LMS_OPTIONS.csv marked as used (TRUE) that you know is not covered by your licenses is a red flag. The biggest culprits include Partitioning, Advanced Compression, Advanced Security, Real Application Clusters (RAC), OLAP, Database Vault, Label Security, etc. For example, if Partitioning is TRUE on an instance where you never bought the Partitioning option, that’s likely a compliance gap. Similarly, Advanced Compression = TRUE indicates compressed tables, backups, or Data Pump exports were used – requiring the Advanced Compression option license. Action: Verify if any usage was a mistake (e.g., someone tested a feature) and ensure the option is either licensed or disabled. Oracle will flag even past usage of these features.
• Management Packs Enabled Without License: Check for Diagnostics Pack or Tuning Pack usage indications. Red flags include any “Diagnostic Pack = TRUE” or entries showing the use of AWR, ADDM, ASH, or SQL Tuning Advisor features. These packs are often unknowingly used because Oracle Enterprise Manager or certain PL/SQL packages enable them by default. If your contract doesn’t include these packs, any use is problematic. Even a single AWR report generation can set the flag to TRUE. Action: Immediately disable these packs on databases where they aren’t licensed (using Oracle-provided parameters or by not using the features) and consider purchasing them if you truly need those capabilities.
• RAC and Clustering Clues: If the overview shows databases part of a cluster (RAC) or LMS_OPTIONS.csv shows RAC used, ensure you have RAC option licenses on all nodes. A common red flag is finding RAC enabled on a standby or test system without licenses. Oracle requires RAC to be licensed for any server where the RAC-enabled database can run, even if it’s a passive node. Also, if you intended to use Standard Edition (which includes a form of clustering in SE2 for two nodes up to 16 threads, etc.), but the script shows Enterprise Edition with RAC, that’s a major issue.
• High CPU Counts on Standard Edition: If LMS_OVERVIEW.csv shows a Standard Edition database on a machine with more sockets or cores than allowed (for example, Standard Edition 2 is limited to 2 sockets and certain core counts per server), that’s a compliance problem. Oracle SE licenses have technical and contractual limits; exceeding them effectively means you’re using the software outside permitted terms (Oracle could insist on licensing it as Enterprise Edition). So check the hardware info against the license rules for SE/SE2.
• Unexpected Products or Editions: If Installed_products.txt reveals an Oracle product you have no record of licensing (for instance, Oracle Advanced Analytics or a separate DB product like TimesTen or Oracle GoldenGate installed), that’s a red flag. Sometimes, DBAs install extra components out of convenience. For example, finding “Oracle GoldenGate” binaries or “Spatial and Graph” installed could be unintended. Similarly, if an edition mismatch is found (e.g., you thought you deployed Standard Edition, but the inventory shows Enterprise Edition), you might inadvertently use a higher licensed product.
• Named User Minimums Not Met: By scanning LMS_DBA_USERS.csv, ensure you meet Oracle’s minimum Named User Plus requirements if you see databases with very low user counts on big servers. For example, for 5 users on an 8-core Enterprise Edition database, Oracle would require at least 50 NUP licenses (not 5). The script won’t outright tell you “non-compliant minimum,” but you should flag this scenario as a SAM manager. Oracle will check this during its analysis.
• Multiple Feature Usage Spikes: If Feature Usage details show multiple advanced features used on the same database (e.g., Partitioning, TDE, and RAC are all true on DB X), it could indicate either that the database is very heavily used (and hopefully licensed accordingly) or that there’s been widespread misuse. Any single one is an issue; multiple in one place is a compounded risk and should be escalated to management quickly.
• “Last Used” dates just before the audit or very old dates: If a feature’s Last Usage Date is very recent (say, a month before the audit), Oracle will likely question the ongoing usage. If the date is old (years ago), you might argue it was an old mistake that’s been corrected – but Oracle can still claim back licensing for that period. However, an old date might aid in negotiating (e.g., “We haven’t used that in 2 years since we discovered the issue”). Either way, note those dates for internal discussion.
• Virtualization traps: While not always directly shown in the script output, pay attention if the server names or environment indicate virtualization (like VMware). Oracle’s LMS script might not fully capture virtualization topology in the DB outputs (they have separate scripts for VMware). But if you see a VM name or environment info, remember Oracle’s policy: if DBs are on VMware, Oracle might demand licensing of all physical hosts in the cluster (a notorious policy). This is a red flag not in the data but in the environment: ensure you know if any listed servers are VMs in a larger cluster, and if so, have you properly accounted for that in your compliance position? (This often requires separate analysis outside the LMS output, but it’s worth noting as a SAM manager.)

In short, any indication of a feature or configuration that you did not explicitly license or intend to use should be treated as a red flag. List these findings from the LMS output – the areas to investigate and remediate.

Cross-Referencing LMS Output with License Entitlements

Interpreting the LMS data is only half the battle – the next step is to compare these findings against your organization’s entitlements (contracts and licenses). Cross-referencing ensures that you have a corresponding license for every usage or installation reported by the script.

Here’s how to perform this reconciliation:

1. Gather Your Oracle License Documentation: Compile all relevant contracts, ordering documents, and support renewal summaries that list your Oracle licenses (often identified by product name and quantities, and sometimes CSI numbers). Ensure you know what edition and options you own for each Database deployment. It helps to create a table or spreadsheet summarizing entitlements, e.g., “Oracle Database EE – 4 processor licenses, CSI 12345, for servers X, Y” or “Oracle Database EE – 50 Named User Plus, CSI 67890 for development use on server Z”, and list any Options/Packs licensed (Partitioning, RAC, etc.). This will be your checklist.
2. Map Each Database Instance to a License: Using LMS_OVERVIEW.csv, map each instance to an entry in your entitlement table. For example, if the overview shows an instance on ServerA, do you have a license that covers Oracle Database on ServerA? If licenses aren’t tied to specific servers (they often aren’t, except if you have soft-partitioning issues), at least map it to quantity. E.g., “ServerA, eight cores, requires 4 EE licenses – we have 10 in total, so okay.” If you have license records from the server or business unit, verify that none is missing. You’ve uncovered an unlicensed installation if an instance has no corresponding license in your records. Sometimes, companies forget to license a standby or a test environment – this is the time to catch that.
3. Verify Edition Compliance: If any instance runs Enterprise Edition, ensure you have Enterprise Edition licenses (Standard Edition licenses cannot cover an EE deployment). Also, if any are Standard Edition, ensure the hardware fits SE restrictions (as mentioned in red flags) because a violation there might contractually force an upgrade to EE licenses.
4. Reconcile Database Options/Packs: For each option that LMS_OPTIONS.csv shows as used = TRUE, check if you have purchased that option for the database. Oracle options licenses are typically per processor or NUP, matching the main DB license metric. For example, suppose you have 8 processors of Database EE on ServerA and used Partitioning on ServerA’s DB. In that case, you need 8 processors of the Partitioning option on contract for ServerA (or generally for that deployment). Go through each option: Partitioning, RAC, etc. – do we have these on our contract? If yes, for how many processors or users? Does it cover usage? (For example, you might have Partitioning licensed on only some servers,
   • but the output shows usage on an unlicensed server.)Packs like Diagnostics Pack – these are usually licensed per processor or named user too. If output shows Diagnostics Pack used on 3 databases, ensure those databases’ processors are covered by Diagnostics Pack licenses on your contract. Advanced Security – covers features like TDE, Data Redaction; if used, check for Advanced Security licenses. Sometimes an Unlimited License Agreement (ULA) or a bundle might cover multiple options – check the terms. If you are under a ULA, some of these concerns might be mitigated (ULAs often cover specific products/options unlimitedly for a term). But still, you need to verify what exactly the ULA includes.
   Document a simple matrix: each database vs each option, mark whether usage is detected and whether you have entitlement. Any cell with “Used = Yes” and “Licensed = No” is a compliance gap to address.
5. Match Named User Counts: If you license any databases by Named User Plus, compare LMS_DBA_USERS.csv counts to your license count. For instance, if Database X is licensed for 50 NUP, but the output shows 80 active users, you have a shortfall of 30 licenses. On the flip side, if you have far more licenses than users, ensure you at least meet the contractual minimums (Oracle won’t refund excess, but the minimums must be met if users are fewer than required per processor). Also consider how Oracle counts users: if you have multiplexing (many users connecting via one app account), Oracle will count all end-users, not just the one account. This detail isn’t visible in LMS output, but you should know how it works when justifying counts.
6. Hardware and Processor Verification: Cross-check the CPU info with your license type:
   • If processor-based: use the CPU core counts from LMS_OVERVIEW.csv and Oracle’s core factor table (for on-premise Intel/AMD, usually 0.5 per core) to calculate how many processor licenses are needed per server. Compare that to how many you have purchased. E.g., output says 16 cores Intel = 8 licenses needed; if you bought 8, you’re fine, if only 4, you’re under-licensed. Document any gap.
   • If named user-based: ensure that the number of processors doesn’t violate any user minimums (e.g., 2 processors EE -> need at least 50 NUP). Oracle’s V$LICENSE (if provided) It might show some of these numbers, but calculating manually is safer.
7. Identify and Note Any Historical Use Edge Cases: For features with historical usage (last used long ago) that you did not license, consider if any contractual clauses might help. Generally, Oracle doesn’t care if it was in the past – they treat it as needing a license now or back then. But if you have documentation that you removed the feature before, it might be useful in negotiations. Still, from a cross-reference perspective, assume you need coverage for it.
8. Check for any Products in Output not in Entitlements: The LMS script is primarily for databases, but if it included other outputs (like WebLogic or Java in some combined tool), ensure those products are licensed. For example, occasionally the DB script might also detect Java version usage if run on the server (which could be relevant if you need Java SE subscriptions). If any such hints appear, cross-check with entitlements for those products too.

After cross-referencing, you should have a clear list of discrepancies: instances without licenses, options used without licenses, insufficient NUP counts, etc.

These are your compliance gaps. You may also find that you are fully licensed for everything detected (which is the ideal outcome!). Either way, this process readies you for the next step – deciding on actions to address any gaps.

Actions to Take for Unexpected or Unlicensed Usage

Discovering unlicensed feature usage or any compliance gap in the LMS output can be daunting. However, proactive steps can mitigate risk.

Here’s a plan of action when you encounter unexpected features or usage that you do not have entitlements for:

1. Validate the Findings: First, double-check the accuracy of the output for the specific feature in question. Engage a DBA to confirm the LMS report. For example, if Partitioning is shown as used, ask the DBA to identify partitioned tables or indexes in that database. If the Diagnostics Pack is flagged, check if someone created AWR snapshots or used OEM. Occasionally, there are false positives or misunderstandings (e.g., Oracle might mark a feature as “used” even for an aborted attempt or an Oracle internal use). Confirming the usage gives you context – how and why it was used.
2. Investigate the Scope and Business Impact: Determine where and how widely the unlicensed feature was used. Was it only in a dev/test environment or also in production? Was it a one-time use or ongoing? Identify the business owner or application that led to this usage. This will help decide the next steps (turn it off vs. purchase licenses) and explain the situation to stakeholders. For instance, if Advanced Compression was used just for one backup on one test database, the approach might differ from discovering that your core ERP database has been using Advanced Compression for years.
3. Immediate Remediation (if feasible): If the usage is not critical to business operations, disable or turn off the feature immediately to prevent further non-compliant use. Examples:
   • Unlicensed Partitioning: Stop creating new partitioned tables; consider merging partitions or exporting and reimporting data into non-partitioned tables if possible. Future: Set a policy that no new partitioning is allowed without a license.
   • Unlicensed RAC: If a test cluster accidentally has RAC on, break the cluster or restrict it to one node until licenses are procured. This might not be feasible in production without downtime, but consider if RAC was truly needed or just a failover that could be handled differently.
   • Diagnostics/Tuning Pack: Disable these packs via the database parameter (CONTROL_MANAGEMENT_PACK_ACCESS) or ensure your DBAs stop using related utilities. You might also uninstall or remove the AWR repository if you’re certain you won’t license it to avoid accidental usage.
   • Advanced Security (TDE): This is tougher since it involves encryption—you can’t simply remove encryption without potentially impacting data security. In such cases, you might lean toward getting the license or finding an alternative encryption solution.
   • Advanced Compression: If data is compressed with an option you didn’t license, you could uncompress it (if storage allows) or ensure that the compression feature is not used going forward (e.g., disable OLTP compression by not using that feature on tables).
   • Stop the bleeding—ensure the feature use doesn’t continue, which could worsen compliance and costs. Disabling it before an official audit submission shows good faith effort (though it doesn’t erase past usage).
4. Document and quantify the Gap: Write down exactly what was used without a license – which servers, which databases, how long or how many times (e.g., “Partitioning used on DB X for 5 months in 2024 on two processors”). This will be important for internal discussion and potentially for negotiation with Oracle. It also helps in planning procurement if you decide to buy licenses: you’ll know how many licenses you need and for what period if back-support is needed.
5. Cross-Check Entitlements One More Time: Sometimes, companies have shelf licenses or migration rights that are not immediately obvious. Double-check if the feature might be covered under a broader agreement or if you have spare licenses from decommissioned systems. For example, you might recall a ULA or older package with certain options. Ensure no stone is unturned – it’s better to find a license you forgot you had than to pay for a new one or face penalties.
6. Decide: Purchase, Reconfigure, or Exception? With the info in hand, decide how to address the gap:
   • Purchase licenses: If the feature provides business value and will continue to be used, buying the appropriate licenses (plus perhaps support backdated to cover usage) is the straightforward fix. For instance, if you discovered that an internal app has been relying on Partitioning for performance, you likely need to budget for Partitioning licenses for that database’s processors. Ideally, work with procurement and Oracle or a reseller before Oracle comes knocking (to get better pricing and avoid audit penalties).
   • Uninstall/Disable and avoid use: If the usage was accidental or not worth the cost, plan to remove it and ensure it doesn’t happen again. This could involve technical changes and policy changes. For example, if a developer turns on a feature on a whim, institute controls so that cannot happen without SAM approval.
   • **Seek an exception or custom arrangement: This is rare, but in some audit resolutions, Oracle might offer a discount or waive something if usage was minimal. You commit to not using it again. Or if it was truly an Oracle bug that caused a false flag, you can argue no license should be needed. Don’t count on waivers, but they can happen in edge cases.
7. Engage Stakeholders: Communicate the findings and proposed action to relevant stakeholders. This includes IT management (to implement technical changes), procurement/finance (for license purchase if needed), and perhaps legal if an audit is involved. Provide the context: why the feature was used and what risk it poses (e.g., “Using Tuning Pack without license could cost us $x in licenses plus back support.”). Gaining approval for remediation actions is easier when everyone understands the exposure.
8. Remediate and Monitor: Implement the chosen fix (license purchase or feature disablement). If purchasing, ensure the new entitlements are documented and added to your license inventory. If disabling, verify via another run of the feature usage queries that usage has stopped (e.g., run DBA_FEATURE_USAGE_STATISTICS again after a period to see that “currently_used” is now FALSE for that feature on that DB). You might also consider scheduling periodic internal audits to catch if it ever turns on again.
9. Prepare an Explanation (if audit scenario): If this is in the context of an upcoming or ongoing Oracle audit, prepare how you will address this with Oracle. Honesty and a clear plan help. For example: “We discovered Partitioning was enabled on one instance by mistake. It has since been disabled, and the tables have been unpartitioned as of last month. We have ceased all use. In the future, we will ensure it remains off.” Oracle may still require you to purchase licenses for the period it was used (they sometimes push for back licenses and support), but demonstrating prompt corrective action can sometimes lead to a more favorable settlement. If you’ve purchased licenses post-discovery, present that as a resolution (Oracle will still note the timing, but it resolves future use).
10. Learn and Educate: Finally, treat this as a learning opportunity. Update your internal policies to prevent similar issues: educate DBAs about which features require extra licenses (many are surprised to learn that just querying certain performance views requires a pack license). You might restrict certain privileges or install options in databases to reduce risk. Also, update your SAM processes: perhaps include a quarterly check of feature usage on all Oracle DBs, so you catch these things early, not just at audit time.

Following these steps transforms an “unexpected usage” discovery from a panic moment into a managed action plan. The key is speed and thoroughness – address it quickly, document it, and resolve it either by removal or licensing.

Oracle audits can be unforgiving with historical usage, but if you proactively fix issues, you’ll be in a much better position to negotiate or explain when the time comes.

Best Practices for Reviewing and Organizing LMS Output

Handling LMS script outputs can be overwhelming due to the data volume and the high compliance stakes. Adopting some best practices will ensure your SAM team stays organized and audit-ready:

• Perform Internal Reviews Before Official Audits: Always review the LMS output internally (or with a trusted consultant) before handing it over to Oracle. This lets you find and fix issues proactively. Treat an internal review with the same diligence as an actual audit. Some companies even run the scripts periodically (e.g., annually) to catch compliance gaps in advance.
• Use a Structured Analysis Template: Develop a checklist or spreadsheet for analyzing LMS output. For each database instance, list its details (name, edition, cores, etc.), then columns for each major option/pack with a place to mark “Used? Y/N” and “Licensed? Y/N”. Also include lines for user counts vs. NUP licenses and any notes. This structured approach ensures you don’t overlook something and makes it easy to summarize the findings. It essentially becomes your internal audit report.
• Leverage SAM Tools if Available: Some SAM tools and services (e.g., Snow License Manager, Flexera, Licenseware, etc.) can import Oracle LMS output and provide a more digestible report or compliance position. If you can access such tools, use them to cross-validate your manual analysis. However, do not rely blindly on tools – always sanity check results because misclassification can happen. Oracle also has an official license auditing tool (LMS) – which you are using – but remember, it’s not an “official license position” until Oracle says so; your job is to interpret it correctly.
• Keep Historical Records: Maintain a repository of past LMS outputs and analyses. This helps you track trends and document that you are managing compliance. For example, if last year’s partitioning wasn’t used and this year it is, something changed – investigate it. Also, if Oracle questions something, having the historical data (with timestamps) can demonstrate due diligence or show that an issue was a one-time event.
• Organize Output Files Clearly: Once you receive the ZIP of output files, save it in a secure location with a clear name (e.g., “OracleLMS_output_<date>_ServerABC.zip”). Extract the files and convert CSVs to Excel for easier filtering/sorting. Add filters and highlight important columns (like any “TRUE” for options). It sounds simple, but good file management prevents confusion – you don’t want to mix up outputs from different servers or dates.
• Segment by Environment: If the script was run on multiple servers (production, test, etc.), organize the results by environment. It may be useful to handle non-prod separately since licensing rules (like counting users or licensing every install) still apply. Still, sometimes there are different policies (e.g., customers have separate dev/test licenses or discounts). Label each analysis clearly as PROD or DEV/TEST, etc., to avoid mistakenly combining them.
• Cross-Reference with CMDB/Inventory: Use your Configuration Management Database (CMDB) or IT asset inventory to ensure the LMS output covers all servers. Verify that every Oracle database server in your environment had the script run and produced output. Oracle’s script doesn’t auto-discover servers you didn’t run it on, so completeness is key. If a server was missed, you should run the script there too – leaving a server out, intentionally or accidentally, could be disastrous if Oracle finds it via other means. A best practice is to maintain an updated inventory of all Oracle installations and ensure each one’s data is accounted for in the LMS outputs.
• Understand Oracle’s View of the Data: Train your SAM team (and relevant IT staff) on how Oracle interprets these outputs. For instance, Oracle will treat any “Currently Used = TRUE” or usage count > 0 as needing a license – even if it’s just once. By understanding that perspective, your team can prioritize issues accordingly. It can be helpful to go through Oracle’s licensing guide or training or consult with Oracle licensing experts who know how auditors read LMS data.
• Stay updated on LMS Script Changes: Oracle updates its LMS scripts periodically (a few times a year). Newer versions might collect additional data (for example, a new option introduced in Oracle 19c or changes to Oracle’s licensing rules like the Oracle 21c XE new features). Ensure you’re aware of what the latest script version collects. If you’re using an older output for internal checks, consider requesting the latest script from Oracle (even outside an audit) so your analysis is current. Similarly, stay informed about Oracle licensing policy changes (e.g., Oracle making certain options free or rebranding them – such changes could retroactively make a “red flag” harmless, but usually, Oracle announces these clearly).
• Prepare an Audit-Ready Packet: Once you’ve interpreted and organized the LMS data, prepare an audit-readiness package. This could include:
  • A summary report of your findings (e.g., “Out of 10 databases, 8 are fully licensed, and 2 have issues with partitioning usage, which we are addressing”).
  • A table mapping each DB to its licenses (to show you’ve done the homework).
  • Document any remediation steps underway for gaps (if any).
  • Copies of relevant license documents (so you can quickly show proof if asked).
  • This packet means if Oracle or management asks about compliance, you can confidently produce an organized explanation rather than scrambling with raw CSV files.
• Audit Trail and Communication: If you must submit data to Oracle or discuss it, maintain an audit trail of what you sent and when. Never edit the raw output files you will send to Oracle (that could be seen as tampering) – if something is truly wrong (e.g., a script error), discuss it with Oracle rather than changing it yourself. But for internal purposes, you can, of course, manipulate copies for analysis. Keep emails or portal upload confirmations as proof of the data provided. Internally, communicate the results to management in a digestible way – executives may not care about CSV details. Still, they will care about “are we compliant, and if not, what’s the exposure?” So translate the analysis into business terms for them.
• Educate and Implement Preventative Measures: Turn this exercise into preventative policy. Use the findings to educate technical teams: e.g., if you found three instances of unauthorized feature use, institute new checks (maybe DBAs must run DBA_FEATURE_USAGE_STATISTICS monthly and report any non-zero usages for unlicensed features to SAM). Consider implementing Oracle’s built-in license control features (like parameter settings that restrict usage of packs) to enforce compliance by configuration. This reduces the risk of future non-compliance creeping in.

By following these best practices, you’ll interpret the LMS script output effectively and maintain control over your Oracle licensing position. The goal is to avoid surprises for your organization and when dealing with Oracle.

A well-organized LMS output review process ensures that when the auditors come knocking, you are fully prepared, with data at your fingertips and a clear narrative of your Oracle software usage and compliance.

Conclusion

Interpreting Oracle’s LMS Database script output is a critical skill for SAM managers who oversee Oracle environments. By thoroughly understanding each output file—from high-level overviews of installations to granular feature usage logs—you can connect the technical data to licensing requirements.

This guide has shown you how to read key files (LMS_OPTIONS.csv, Installed_Products.txt, user listings, etc.), identify common compliance red flags (like unlicensed Partitioning or RAC usage), cross-reference everything with your contracts, and take corrective action well before Oracle’s auditors surprise you.

The overarching theme is proactivity: Use the LMS output as an audit tool and a regular compliance health check. When integrated into your SAM practices, these scripts become a powerful resource to ensure you only use what you’ve paid for—and pay for what you use.

Doing so will protect your organization from costly compliance gaps, avoid last-minute firefights during audits, and build trust with stakeholders that your Oracle licensing is under control.

You turn the complex raw output into actionable intelligence by organizing the data, training your team, and addressing any issues head-on. Oracle licensing may be complex and sometimes intimidating, but with the expert interpretation of LMS script results, you can navigate it confidently and maintain audit readiness. Always remember: every line in those output files tells a story about your Oracle usage – make sure you know the story and have the ending written in your favor.

Do you want to know more about our Oracle Analysis Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit