Oracle License Compliance Scripts: A Practical Guide for SAM Teams

Oracle’s License Compliance Scripts – often called LMS scripts (from Oracle’s License Management Services) – are Oracle’s official tools for collecting software usage data across Oracle products​.

These scripts are typically provided as a bundle of SQL queries, shell scripts, and utilities that run on your servers to inventory the Oracle software installed and how it is being used.

While Oracle primarily uses LMS scripts during audits to uncover any unlicensed usage, Software Asset Management (SAM) teams can run these scripts internally to proactively manage compliance.

This guide explains what LMS scripts are, which Oracle products they are used with, the data they collect, how to run them, and how to interpret the results for internal compliance management.

It also covers best practices and common pitfalls, focusing on practical compliance management rather than audit defense or sales tactics for Oracle.

What Are Oracle License Compliance (LMS) Scripts?

Oracle’s LMS scripts, also known as the Oracle LMS Collection Tool or license compliance scripts, are diagnostic scripts developed by Oracle to automatically gather detailed information about your Oracle software deployments.

Key points include:

• Purpose: They provide a detailed snapshot of Oracle software usage in your environment. Oracle uses them in audits to find any usage beyond what you’ve licensed. Internally, you can use them to see exactly what Oracle would see in an audit and catch compliance issues early​.
• Scope: LMS scripts cover a wide range of Oracle product families, not just databases. Oracle has script modules for Oracle Database, Oracle Fusion Middleware (including WebLogic and related servers), Oracle Applications (such as E-Business Suite and PeopleSoft), Java SE, and more. Each module is tailored to capture data relevant to that product (for example, a database script checks database options usage, while a WebLogic script gathers application server configuration)​
• Output: The scripts produce output files (usually in text or CSV format) containing the raw data collected, such as lists of installed software, feature usage status, hardware details, user accounts, and more. Oracle “trusts” this data as it comes from their tools, and uses it to assess your license needs​​ (Important: The scripts do not automatically decide compliance – they just gather data. Interpretation against your contracts is the next step.)

In essence, Oracle’s LMS scripts are like an X-ray of your Oracle environment, revealing all the Oracle components in use and any features that have been enabled.

SAM managers can leverage this to ensure internal records match reality and to avoid surprises in a formal audit.

Oracle Products with LMS Compliance Scripts

Oracle provides LMS collection scripts for many of its software products. The major categories include:

• Oracle Database: Scripts for all editions (Standard, Enterprise, etc.) of Oracle Database. These collect information about database options and management pack usage, hardware and CPU configuration, and database user counts. The database LMS script (often called “Review Lite”) is one of the most commonly used in audits​.
• Oracle Fusion Middleware: Scripts covering WebLogic Server and related middleware components. Oracle’s LMS tooling inventories WebLogic domains and servers (Basic, Standard, and Enterprise editions), Oracle application servers (OAS/iAS), SOA Suite components, Oracle Business Intelligence installations, Oracle WebCenter, Oracle Forms and Reports, Oracle Tuxedo, and more. In short, most products under the Fusion Middleware portfolio have script coverage to capture configuration and usage.
• Oracle Java SE: Oracle’s scripts can also detect Java SE installations on servers​Since Oracle changed Java licensing (now requiring subscriptions for commercial use in many cases), LMS scripts will flag installed Oracle Java versions and patch levels – e.g. identifying an Oracle Java SE 1.8.0 update and its last update date​This helps determine if Java is deployed in a way that needs a paid license (for example, Java SE running on a server post-2019 without a subscription).
• Oracle Applications (ERP/CRM): There are LMS scripts for Oracle’s enterprise applications, including Oracle E-Business Suite (EBS), PeopleSoft, JD Edwards, and Siebel, among others. These focus on application-level usage, such as counting application users and their roles in each module​ . For instance, the EBS script extracts all user accounts, their responsibilities (or roles), and maps them to modules to determine how many users have access to each licensed module. Similar scripts exist for other Oracle applications to gather metrics relevant to their licensing (e.g., number of users of a PeopleSoft module, or usage of Siebel components).

Summary: Virtually any licensable Oracle software has an associated LMS script or module. Databases, middleware servers, Java installations, and on-premise Oracle applications are all within scope​.

The script package you receive will contain different components to target each of these, and you run the ones relevant to the Oracle products you use.

What Data Do the LMS Scripts Collect?

Each LMS script gathers a wealth of data to paint a complete picture of usage and configuration.

Below are the typical data points collected for each major product area:

• Oracle Database: The script runs hundreds of queries against your databases​ and outputs multiple files with details such as:
  • Installed Database Edition and Version – e.g., Oracle Database 19c Enterprise Edition, or Standard Edition, including patch levels​. The edition is critical since features and licensing rules differ between Standard and Enterprise.
  • Database Options and Features Usage – A list of optional database features (Partitioning, Advanced Security, Advanced Compression, OLAP, Real Application Clusters, etc.) and whether each has ever been used. For each option or pack, you’ll see if it’s installed, if it’s used (TRUE/FALSE), how many times it was used, and the last usage date​. For example, the output might show that Partitioning is “TRUE” (used) with five detected uses, the last use being on 2024-07-15. ​Management packs, such as Diagnostic Pack and Tuning Pack, are reported similarly. Any “Used: TRUE” means that feature was activated at least once, which, under Oracle’s policies, triggers a license requirement for that option​.
  • Hardware and CPU Info – The number of processors or cores the database is running on, CPU architecture, and sometimes environmental information like whether it’s a virtual machine. For example, it might show Server: dbserver01; Cores: 16 (Intel Xeon) and even note Virtualization: VMware cluster “CorpCluster01”​ This tells you how many CPU licenses are needed (Oracle will apply its core factor to the core count for Enterprise Edition) and flags if it’s on a virtualized platform (which can have licensing implications beyond the script’s data).
  • Database Instance Configuration – A summary of each instance: instance name (SID), whether it’s part of a RAC cluster, and perhaps if Data Guard (standby) or Multitenant features are in use. For example, the script might list two instances, ORCL1 and ORCL2, on a server and note “RAC: Enabled” if they form a RAC cluster​. It may also note if Multitenant (Pluggable Databases) are present (since more than one PDB in a container requires the Multitenant license)​
  • Database Users – A count of Named Users in each database, often with a file listing all usernames and statuses. For instance, it might report “150 named users (120 active, 30 locked/inactive)” in a database.​ This is crucial for environments licensed by Named User Plus (NUP) rather than by processor. Oracle’s script essentially pulls the list of database accounts. Auditors will exclude Oracle-supplied accounts but count all real application or human accounts. The output helps you check if you meet Oracle’s user minimums (usually 25 NUP per processor for Enterprise Edition) and if your actual active user count exceeds your licensed NUP count.
  • Installed Database Components – A text inventory of all Oracle products/components installed on that server (e.g., Oracle Database software, Oracle client, options binaries, etc.)​This ensures you’re aware of any Oracle software present, even if it’s not actively used in the instance.
• Oracle Middleware (WebLogic and others): The middleware script collects configuration and usage data from application server environments:
  • WebLogic Domain Inventory – Identifies all WebLogic Server installations and domains on each host​. It uses the WebLogic Scripting Tool (WLST) to query each domain’s configuration​. The output will list domain names, the WebLogic version and edition, the number of servers in the domain, cluster configuration, and deployed applications. For example, it might show: Domain “ProductionDomain”: WebLogic Server 12.2.1 with 1 admin server + 4 managed servers in cluster “ProdCluster”​ . From this, you can deduce the edition in use (a clustered domain implies WebLogic Enterprise Edition or Suite, since clustering isn’t included in the basic license)​
  • Installed Middleware Products – Lists of other Oracle middleware components found, such as Oracle SOA Suite, Oracle Business Intelligence components, WebCenter, Forms/Reports, etc.​​The script checks the Oracle Middleware inventory (registry.xml) and the file system for installed products. For instance, it might report that Oracle SOA Suite 12c is installed on the server (which would require SOA licenses if used) or that Oracle HTTP Server is present.
  • Configuration and Feature Usage – The script may capture key configuration files (such as config.xml for each WebLogic domain) to determine which features or services are in use. It flags things like JMS persistence, Oracle Coherence caching, or other Enterprise features that might indicate a higher edition of WebLogic is being used. It also often notes if a WebLogic installation is “restricted-use” (e.g., if it came bundled for use only with Oracle EBS or a database), which is important because running a restricted-use WebLogic outside its allowed purpose would be non-compliant.
  • Hardware and Runtime Info – Similar to the DB script, it can record host details (CPU cores, OS) and even scan running processes to check if WebLogic or other middleware is actively running. This helps distinguish installed but unused software from active usage (which is what matters for licensing).
  • Java SE usage: Since WebLogic and other middleware run on Java, the middleware script will also note if Oracle Java is being used to run them, including the Java version, to flag if a separate Java SE license might be needed​(Oracle often audits Java separately, but the LMS tool can highlight Java usage on servers as part of the middleware scan).
• Oracle Applications (EBS, etc.): For enterprise applications, the LMS scripts target application user and usage data rather than infrastructure:
  • User Accounts and Status: A dump of all user accounts in the application (for E-Business Suite, the FND_USER table) including creation date, last login, and whether the account is active or end-dated. This tells you how many total users exist and how many are currently active (eligible to use the system)​ . Licensing is typically per Named User or Application User, so this is the baseline for compliance checks.Roles/Responsibilities: All defined responsibilities or roles in the application (e.g., in EBS the responsibilities from FND_RESPONSIBILITY) and which module or functional area each corresponds to For example, a responsibility “General Ledger Superuser” maps to the Oracle Financials GL module. The script often provides a mapping or at least data for you to map responsibilities to the actual product modules​. User-Role Assignments: Which users have which responsibilities. Essentially, who has access to what modules. From this, you can derive how many users are using each Oracle module – e.g., 25 users have the “Accounts Payable” responsibility (hence 25 users of Oracle Payables module). This is critical because EBS and other apps are licensed by module usage (X users licensed for Module Y). The output lets you calculate active users per module by filtering out inactive users and counting active assignments​.Installed Modules: The script also lists which application modules are installed or enabled in the system (for EBS, from FND_PRODUCT_INSTALLATIONS)​This shows the scope of what could be used. For instance, if Oracle Payroll is installed, it’s in scope even if no users are currently assigned to it – you’d still want to ensure you’re licensed if it’s being used.
  Using the EBS example: After running the script, you might find 500 total user accounts, with 300 active. Of those, for example, 50 have Payables roles, 40 have Purchasing roles, and so on. If you only have 30 Payables user licenses but 50 active users with access, you have a compliance gap. The LMS output gives you the raw numbers to make that determination. (It also might highlight if inactive accounts are not end-dated – a common issue where de-provisioned users still count toward licenses until properly removed or end-dated.)
• Other Data: The LMS scripts also often gather environment metadata, including OS type and version, hostnames, cluster names, and certain configuration parameters. For example, for databases, it might capture if Archive Log mode is on (related to Data Guard usage), or for WebLogic, the presence of specific domain settings. This context can help interpret the results correctly. Importantly, historical usage is captured especially for databases – Oracle’s script pulls from views DBA_FEATURE_USAGE_STATISTICS to find first use and last use dates of features​, meaning it can show evidence of options that were used in the past but perhaps not currently enabled. This historical trail is crucial for compliance (and a reason SAM teams must be aware that turning off a feature today won’t erase past usage records​).

In summary, Oracle’s LMS scripts gather everything needed to calculate licenses: how many databases or instances you have, what edition, what optional features have been used (even once), how many users, and what hardware those systems run on​ For middleware and apps, they similarly collect the installations, configurations, and user counts.

No stone is left unturned – if a licensable component was installed or toggled on, the scripts are designed to find it​.

How to Run Oracle’s LMS Scripts

Running the Oracle LMS compliance scripts requires careful preparation. Oracle usually provides these scripts as a compressed archive with a set of instructions.

Here are general steps and considerations for running each type of script:

• Obtain the Official Scripts: Always use the authentic scripts from Oracle. If you’re undergoing an official audit, Oracle (the LMS/GLAS team) will send you the script package, often via a secure link. If you are doing a self-assessment, you can request the latest LMS scripts from Oracle Support or your Oracle account manager. Do not use unofficial or outdated versions – ensure you have the exact scripts Oracle expects, as they update them periodically​. (For example, as of 2025, Oracle’s LMS script version 20+ might be in use; using an old version 17 might miss newer features.) Verify checksums if provided, to ensure integrity​.
• Preparation and Permissions: Coordinate with your IT teams before running anything​. Inform the DBAs, system administrators, and application admins about the plan, so they can assist and aren’t caught off guard by heavy scripts running. Typically:
  • For Database LMS scripts, you’ll need a database user with DBA privileges (often SYS or another account with access to all data dictionary views. The script may be a SQL file or a PL/SQL package that you execute using SQL*Plus. Ensure you have credentials and the environment (ORACLE_HOME, etc.) set up to connect to each database instance​.
  • For Middleware/Java collection, the script is usually run at the OS level on each server where middleware is installed. This often requires administrator/root access to the server to execute shell scripts and WLST commands that inspect the system​. You might have a master script like runLMS.sh (for Unix) or runLMS.bat (for Windows) that needs to be run as root/Administrator, which in turn calls subscripts for WebLogic, etc. Oracle’s instructions will specify if any environment variables (like JAVA_HOME or specific paths) need to be set.
  • For Oracle EBS/Application scripts, an application DBA typically runs a provided SQL script against the application’s database using the application’s schema (e.g., APPS schema for EBS). This script might produce output files of user and responsibility data. Again, the account used must have privileges to read the application tables. In EBS, the APPS user has this access.
  • For Hardware/CPU data, Oracle may include a separate processor measurement script (historically. cpuqry.sh / cpuqry.cmd) that is run on each physical server or VM host to capture CPU details​. In modern versions, the main scripts often gather CPU information themselves, but be prepared to run a small OS script or command to capture any details the DB script couldn’t (especially if virtualization is involved).
• Execution: Plan to run the scripts during a low-usage maintenance window if possible​. The scripts are read-only (they do not change configurations or data)​, but they can be intensive – for example, querying DBA_FEATURE_USAGE_STATISTICS on a huge database or scanning a large file system for installations might take some time and CPU. Running in off-peak hours minimizes any performance impact. It’s also wise to test the script on a non-production environment first​. For example, run it on a test database server to estimate how long it runs and ensure it doesn’t error out. This dry run can reveal if any permissions are missing or if adjustments are needed before touching production.
• Following Instructions: Oracle’s package will include a README or user guide. Follow it exactly​. This means running all required components of the tool on all relevant systems. If the instructions say to run on every server where Oracle software is installed, ensure that none are skipped. It’s a common mistake to run the DB part but forget the host-level script, or to run on primary servers but overlook standby or development servers. For completeness, run it on every environment in scope (production and any non-production environments that might require licensing). Also, use the specified user accounts. For instance, Oracle might instruct to run the DB script as SYSDBA and the OS script as root – do so to ensure the script can collect everything​. Running with lower privileges could result in incomplete data, such as missing option usage or installed software directories.
• Collecting the Output: The scripts will output files, usually into a directory or zip archive. Oracle’s instructions may have you run a final step to package all results, often generating a zip file of all outputs. Ensure you capture all output files from each server. Keep these in a secure location. Tip: Also, keep note of which server and instance each output corresponds to. The filenames often include the hostname or SID, but if not, organize them in a clear way (e.g., in separate folders per server). This will help later in the analysis.
• Verification and Logging: As you run the scripts, monitor their progress. If running manually, watch the console for any errors if something fails (such as a connection issue to a database or a permission denied error on a config file). Fix the issue and rerun that part. It’s good practice to log the execution – record the date, time, and who executed each script on each system. If there are any deviations (for example, if you had to rerun on a server due to an error), note them. This internal log can be useful for accountability and in case anyone, including Oracle auditors later, has questions about how the data was collected. Remember not to modify the Oracle-provided scripts or their outputs; even internally, you want the raw data to be accurate. Trust the process and address any concerning findings through analysis, rather than trying to omit them. Hiding or tweaking data is both unethical and risky – Oracle can detect inconsistencies if the output is altered​.

After running everything, you should end up with a set of files (often CSVs and TXTs, or a large zip file) that contain all the discovery data. Now, the key task for a SAM manager is to interpret those results and compare them to your licenses.

Interpreting Script Output and Understanding the Results

The LMS script outputs can be voluminous. They are essentially raw data dumps of your Oracle usage.

Here’s how to make sense of the results, with examples:

• Database Script Output: The Oracle Database LMS script typically produces files like LMS_OVERVIEW.csv, LMS_OPTIONS.csv, LMS_DBA_USERS.csv, and Installed_Products.txt​ Each serves a purpose:
  • Overview (Instances and CPUs): LMS_OVERVIEW.csv summarizes each database instance – host name, instance name, Oracle version and edition, number of CPUs/cores, and any cluster info​​ Use this to ensure all expected databases are listed and to note which are Enterprise vs Standard Edition (an unexpected Enterprise Edition where you thought it was Standard is a red flag). Also, check the core counts against your processor licenses. Example: An overview line might show Host: dbserver01 | DB Name: ORCL | Version: 19.3.0.0 EE | Cores: 16 (Intel) | Cluster: 2-node RAC.​This tells us ORCL is an Enterprise Edition database on a 16-core server and part of a RAC cluster. If we have Enterprise Edition licenses for only 8 cores, or if we haven’t licensed the RAC option, that’s immediately evident from this one line.
  • Options and Packs Usage: LMS_OPTIONS.csv is one of the most critical outputs. It lists every optional database feature and pack, along with whether it has been used on each instance. Look for any “TRUE” or “YES” under the usage column for options you have not purchased. Each line typically shows the Option Name, a usage indicator, the usage count, and the last used date. For example, an excerpt might be: textCopyOption | 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 Interpretation: Here Partitioning was used (TRUE) 5 times, last on 15-Jul-2024, Diagnostics Pack used once, last on 01-Jun-2024, whereas Advanced Compression was never used (FALSE)​ If your organization did not license Partitioning or Diagnostics Pack, these entries indicate compliance gaps – Partitioning in particular is a serious issue (used 5 times without a license) and would need attention. Advanced Compression being false means no license is needed for that, since it wasn’t used.Go line by line: every feature showing used = TRUE should correspond to a license entitlement you hold; if not, mark it for remediation​. Also note the last usage dates – they indicate how recently the usage occurred. Historical use counts mean even if the feature is off now, it was on in the past​. Oracle will typically consider any past usage as requiring a license during that period. As a SAM manager, you should investigate each unexpected usage. Was it enabled by mistake? Is it something that can be turned off to stop further usage? Document these findings.
  • Database Users: LMS_DBA_USERS.csv lists the database user accounts on each instance. Focus on the number of active (unlocked) users versus your Named User Plus licenses. For example, if it shows 80 active users on a certain database and you have 50 NUP licenses for it, you are underlicensed by 30 users. Also, check Oracle’s minimum NUP requirement: e.g., Enterprise Edition requires 25 NUP per processor. So, even a DB with five actual users on a 2-processor server would need 50 NUP licenses (the minimum). Use the user list to identify service accounts or duplicates that might be excluded, but be cautious – any active non-Oracle account could also be counted. If you see many generic accounts, note that Oracle’s policy is each named account counts as a user unless it’s truly a duplicate or only used for batch processing with no human users behind Bottom line: ensure the active user count per DB is <= your NUP entitlement for that DB (or meets the minimums if higher)​If not, you either need to reduce users or convert to processor licensing.
  • Installed Products: Check the Installed_Products.txt or similar inventory output. It might list all Oracle components found on the server, including database software, client, options, etc.​ This helps verify that no Oracle product is installed without being known. For example, if it lists the Oracle Advanced Security option as installed, even if it’s not used, you might decide to uninstall it to prevent accidental use. It’s also useful for identifying if any other Oracle software (maybe a separate Oracle product like GoldenGate or Middleware pieces) is present that should be accounted for.
• WebLogic/Middleware Script Output: After running the middleware scripts, you’ll have outputs like domain listings and configuration files. Key things to interpret:
  • Identify WebLogic Edition: Oracle WebLogic is available in various editions (Basic, Standard, Enterprise, and Suite) with different features. The LMS output will often indirectly tell you the edition by the features in use. For instance, if the domain configuration in the output shows a cluster with multiple managed servers, you know this is beyond “Basic” (which doesn’t allow clustering)​If JMS messaging and persistent stores are in use, that could indicate Enterprise features. Some outputs may explicitly list an edition or licensed features. Check for any mention of “WebLogic Basic” or restricted-use licenses. If WebLogic was provided as part of another product, such as a database license, its use may be limited to that scope​.
  • Check Installed Middleware Components: The output might include a list of middleware products found (for example, “Oracle SOA Suite: installed”, “Oracle BI Publisher: installed”). Any product you’re using that is listed should be licensed. If you see SOA Suite installed and in use, ensure you have SOA Suite licenses. If not using it, consider uninstalling or at least note that it’s present but unused (so you don’t accidentally start using it).
  • Domain Configurations: Review the domain details. Note the number of WebLogic instances and on which servers they are running. WebLogic licensing is often based on the number of processors (cores) on the machines where it’s running. So if the output says WebLogic domain “ProdDomain” on host appserver01 (8 cores) and appserver02 (8 cores), and you use WebLogic Enterprise, you’d need to license those cores. If you only licensed one server and the output shows two, that’s an issue. Also, watch for WebLogic Suite features (such as Oracle Coherence or InfiniBand optimizations) – although less common, any such usage would require the higher WebLogic Suite license.
  • Java SE: If the middleware output explicitly notes Java versions, treat that as you would the Java-specific output – i.e., if it finds Oracle Java 1.8 or 11 on those servers, verify you have Java SE subscriptions or plan to address that. Oracle may audit Java separately, but internally, you should consider it in your compliance considerations if it is detected.
• E-Business Suite/Application Output: The application script will produce user and usage files (often CSVs named after tables like FND_USER.csv, FND_USER_RESP.csv, etc., in the case of EBS). To interpret:
  • Determine the number of active users for each application. For EBS, open the user CSV file and filter to active users (those without an end date and a status of Active). This is your count of users consuming licenses.
  • Using the responsibility assignment data, map each user to their corresponding modules. Often, there is documentation (or you may need to manually map) that shows which responsibility corresponds to which module. The EBS LMS output might not directly say “Module X has Y users”, but you can derive it. For example, count how many active users have a “General Ledger” responsibility, how many have an “HRMS” responsibility, etc. Those counts need to be compared to your license entitlements for each module. If you licensed 50 HRMS users and the output shows 70 active users with HRMS-related responsibilities, you have a problem.
  • Check for inactive accounts that are still assigned roles. If users leave the company but their accounts aren’t end-dated, they may still show as active, artificially inflating your usage. It’s best practice to periodically purge or end-date such accounts. Oracle will typically count any enabled account as a licensed user, so cleaning up dormant accounts can legitimately reduce your license requirement.
  • Look for users with access to unlicensed modules: Sometimes, an organization may not have licensed a particular module, but an admin may have accidentally given some users access to it. The script data would show those users and their responsibilities for that module. That’s a red flag – you either need to remove that access or procure a license for that module.
  • In PeopleSoft or other apps, the concept is similar: you’d get a list of users, perhaps several records (employees, etc., if licensing is based on employees), and module usage. Always tie the usage numbers back to how those apps are licensed in your contract. Some PeopleSoft modules are licensed by the number of employees or transactions, rather than users, in which case the LMS script might capture a different metric.
• Java SE Output: If you ran a dedicated Java LMS script or as part of the other scripts, the key output is typically an inventory of all Oracle Java installations on each server. For each Java installation, it may report the version (e.g., Java SE 8 Update 271), the installation path, and possibly last update or usage information. Interpretation is straightforward: any Oracle Java SE installation in use (especially versions eight and above after public updates ended) likely requires a Java SE Subscription license unless you have an older license or it’s an allowed usage (like embedded in another product). So, list all Java installations found and ensure you have subscription coverage for them. If not, plan to migrate them to OpenJDK or other alternatives to avoid licensing costs.

Tip: The raw outputs are not always nicely formatted for presentation, so it helps to import CSV files into Excel or a database to filter and pivot the data. For example, pivoting the EBS user-responsibility data by module or summarizing the LMS_OPTIONS.csv file by counting the number of databases that use each option with TRUE can give a clearer picture.

Oracle won’t do this summarization for you (in an audit, Oracle’s analysts do it behind the scenes), but for internal purposes, processing the raw data into a human-friendly summary is immensely helpful.

In general, interpreting LMS script results is about connecting the dots: each line of output is a clue about potential license needs.

Once you interpret what each finding means (e.g., Partitioning used on DB X means Partitioning option license needed for that DB’s servers), you then compare it to what you own and see if there’s a mismatch.

Using LMS Script Outputs for License Compliance Management

Running the scripts is only half the battle – the real value comes from using the data to ensure compliance.

Here’s how SAM teams can use the LMS script outputs for internal license validation and optimization:

1. Cross-Reference with Entitlements: Take every piece of usage data from the script and map it to your current licenses. Create a table or matrix: list each Oracle product/feature on one side and whether the script found it being used, then list the licenses you have for it on the other. For example: Database Instances vs. DB licenses, Options used vs. Option licenses, number of users vs. NUP licenses, WebLogic cores vs. WebLogic licenses, EBS module users vs. module licenses, etc. Identify any gaps: if the script shows usage of something with zero corresponding licenses, that’s non-compliance. If it shows more usage than you have licenses for (e.g., 120 users but 100 NUP licenses), it is also non-compliant. These are your risk areas to address. On the other hand, if you find you have licenses for features not used, that might be an optimization opportunity (perhaps you’re paying for a pack nobody uses). Organize the findings in a report or spreadsheet for clarity​.
2. Investigate and Remediate Issues: For each compliance gap identified, decide on an action plan. The beauty of doing this internally is you have the chance to fix issues before Oracle finds them. Common remediation steps include:
   • Disable or turn off unlicensed features: If an option was enabled by mistake (e.g., Partitioning or a management pack), you can configure the database to stop using it; for example, you can drop partitioned tables or disable the pack. Note the date you did this and try to ensure it’s no longer used going forward.Uninstall unused software: If LMS found an installed product you aren’t using (say, WebLogic on a server that doesn’t need it), uninstall it to avoid accidental use and remove it from future audits.True-up your licenses: If a feature is heavily used and critical (for example, you are actively using Advanced Compression but never bought licenses), you might plan to purchase the license to cover it. It’s better to approach Oracle proactively about buying needed licenses (perhaps in a renewal or negotiation context) than to be caught in an audit owing back fees.Tidy up user accounts: If you found more database or application users than expected, work with admins to lock or remove accounts that are no longer needed. This can legitimately bring your usage count down. Make sure, however, to comply with Oracle’s rules (e.g., you can’t circumvent licensing by using one generic account for multiple users – Oracle counts distinct individuals). But cleaning up dormant accounts is fair game and recommended.Document Exceptions: If you spot something odd, like a feature usage that you believe shouldn’t count (maybe a false positive or a misunderstanding), document why. For instance, Oracle’s script might flag “Data Guard” used because a standby DB exists. If your license entitlements allow a standby under certain conditions (e.g., if it’s truly passive), note that context. Internally, you might still count it as usage, but you’ll be prepared to justify it.
   Essentially, treat each finding as an actionable item: either resolve the non-compliance or mitigate it. A real-world example: an LMS script revealed an admin had enabled Transparent Data Encryption (TDE) in a database (requires Advanced Security option license), which the company didn’t have. Upon discovery, the SAM team worked with the DBA to disable TDE (since it was a test) and avoided a potential $ 100,000 exposure if Oracle had audited them during that period.
3. Feed Data into SAM Tools: If you have a SAM tool or ITAM system, use the LMS output to update its records. Many organizations import the results into tools like FlexNet Manager, Snow, ServiceNow, etc. Some SAM tools have specific Oracle license management modules that can interpret LMS data. By doing this, you maintain a continuous license position. The LMS data is valuable because it’s the “ground truth” according to Oracle’s measurements, adding credibility to your SAM records​. For instance, if your SAM tool shows you are compliant but an LMS script indicates otherwise, the LMS script data should take precedence for investigation. Note: Some SAM tools are even Oracle-verified to use LMS queries (meaning Oracle will accept their data collection instead of running the script themselves). Even with these, it’s good to compare the tool’s interpretation with your manual interpretation to ensure nothing is misinterpreted.
4. Continuous Monitoring: Don’t treat this as a one-time exercise. Use the LMS script output as a baseline, and consider running the scripts regularly (more on frequency in Best Practices below). By comparing outputs over time, you can detect if new features have been enabled or if new servers have come online that need licenses. For example, if six months ago you had no “Tuning Pack” usage and now it appears as used, something changed – investigate it. Regular internal audits using the scripts keep you in control of your Oracle usage.
5. Educate Stakeholders: Sometimes, the script reveals that IT teams are unknowingly using features that incur license costs. Use these findings to educate your database administrators (DBAs) and application administrators (app admins). For instance, show them the excerpt that “Diagnostics Pack = TRUE” and explain that running an AWR report or turning on monitoring in Enterprise Manager without the Diagnostic Pack license triggers this. Education can prevent future accidental usage. It also demonstrates to management the importance of governance, e.g., restricting who can enable certain features or install Oracle software.

By using the outputs in this way, SAM professionals essentially conduct an internal audit of compliance. You’re ensuring that for every piece of usage data, either a license exists or an action is in progress to address the gap.

This greatly reduces the risk of a nasty surprise in an Oracle official audit and helps avoid panic because you’ve already identified and handled major issues proactively.

Oracle LMS Scripts vs Third-Party SAM Tools Data

Many SAM managers use third-party license management tools to track Oracle software. It’s important to understand how these tools differ from (and in some cases integrate with) Oracle’s own LMS scripts:

• Data Collection vs Interpretation: Oracle’s LMS scripts are considered the gold standard for data collection – they run Oracle’s queries and thus gather exactly what Oracle wants to see. Some third-party SAM tools have their discovery methods, which might not be as thorough or aligned with Oracle’s metrics. In recent years, Oracle has had a program to “verify” certain SAM tools, essentially certifying that the tool can execute Oracle’s LMS scripts and produce the same raw output Oracle would​. If your SAM tool is Oracle-verified (for example, Flexera or ServiceNow may be verified for Oracle Databases), it means the tool can automatically gather LMS script data. However, Oracle’s verification only covers data gathering, not license analysis​. The tool’s interpretation of that data is not guaranteed to match Oracle’s interpretation​. Oracle explicitly states that the output still needs to be analyzed by Oracle’s team in an audit, and Oracle may interpret the rules differently than the tool does.
• Coverage of Products: Historically, many SAM tools have focused on Oracle Database compliance because it is a significant area of risk. They might have weaker support for other products, such as middleware or Java. Oracle’s LMS scripts, on the other hand, cover all product areas. Oracle has also been extending verification to Fusion Middleware tools. However, if your tool isn’t verified for a specific product, it may not capture everything. For example, a SAM tool might inventory WebLogic installations, but might not capture details like cluster configurations or restricted-use status that Oracle’s script would. Be cautious: if you rely on a SAM tool, ensure it covers all Oracle software you use. If not, supplement it with manual runs of the LMS scripts in those areas.
• Accuracy and Granularity: Third-party tools may sometimes simplify or omit historical data. For instance, a SAM tool might report “Partitioning currently enabled: No” and conclude that no license is needed, whereas Oracle’s LMS script would show “Partitioning used 5 times historically,” which indicates a license need. This difference can lead to false confidence if you only trust the SAM tool. Always cross-check critical details, such as feature usage and user counts, with Oracle’s script output. SAM tools often have to implement Oracle’s complex licensing rules, and not all do it perfectly. One tool might flag a certain condition as requiring a license while another might not, but Oracle’s policy will ultimately decide it. For example, some SAM tools might count any use of performance pack features as usage, while others might require a specific threshold. Oracle’s analysis might be stricter.
• Oracle’s Acceptance: In an audit, Oracle accepts data from certain verified SAM tools instead of running its scripts, but this means Oracle trusts the raw data. They will still apply their interpretations of the license to that data. This is crucial: if your SAM tool says “compliant,” that doesn’t guarantee Oracle would agree if they analyze the same data differently. As an internal team, use SAM tools for convenience, but keep an eye on alignment with Oracle’s view. Some organizations treat the LMS script output as the final authority and adjust the SAM tool data accordingly, essentially feeding the LMS output into the tool, as mentioned.
• Virtualization Data: One area of difference is how VM or cloud environments are handled. Oracle’s scripts might not automatically capture the full picture of a VMware cluster (they’ll see the DB is on a VM with X vCPUs, but Oracle requires knowing the whole cluster’s physical cores due to soft partitioning rules). Some SAM tools try to account for this by linking vCenter data, among other things. But remember, Oracle’s script output by itself might not declare a license requirement for the whole cluster – that comes from Oracle’s policy. A SAM tool might try to enforce that policy in its calculations, which is an interpretation layer. In any case, ensure that data like “running on VMware” appears in the script output​. is flagged for special attention, because Oracle will use it to potentially expand scope (a SAM tool might or might not automatically flag that nuance).

Bottom line: Oracle’s LMS scripts and SAM tools are complementary. Use the SAM tool for ongoing tracking and, if necessary, running the scripts. However, always validate the results against the actual script outputs for Oracle. If discrepancies arise, trust the LMS script data first.

Many SAM teams use the LMS scripts as a “second opinion” to double-check the figures from the SAM tool. This way, you get the efficiency of a tool with the accuracy of Oracle’s data. And if your tool is Oracle-verified, leverage it – it can automate collection, but be aware of its limitations in interpretation.

Best Practices for Using LMS Scripts in SAM

To maximize the benefits and minimize risks, consider these best practices when working with Oracle’s license compliance scripts:

• Run the Scripts Regularly (Not Just During Audits): Don’t wait for an official audit notice to run LMS scripts. Make it a routine part of your SAM process​. Many organizations run the database LMS scripts semi-annually or quarterly on key systems. A regular cadence (e.g., every 6 months) helps catch licensing “drift” early, such as new features being enabled or new servers being added, so you can respond before it becomes a big problem. It also keeps your team familiar with the process, so if an audit happens, you aren’t scrambling to figure out how to run the scripts under pressure. Integrate these runs with your change management or internal audit calendar.
• Analyze and document findings every time: treat each internal script run as a mini-audit. Form an internal review team (e.g., SAM manager, DBA lead) to review the output and identify any compliance issues. Write an internal report or at least a checklist of what was found – e.g., “Q1 run: Found 2 databases using Partitioning without licenses, 1 WebLogic instance on an unlicensed server, 10 new users added in EBS AR module exceeding license count.”​ Then track the remediation of each issue​. By maintaining this documentation, you create a record of your compliance posture and the actions taken. If something repeats in the next run, you know it wasn’t fully fixed and may need to be escalated. This disciplined approach means if Oracle ever audits you, you already have an understanding of issues and possibly solutions in progress.
• Keep Up with Oracle Licensing Policy Changes: Oracle’s rules and product licensing can change, which can affect how you interpret script results. Stay informed about any changes through Oracle’s official communications or by consulting with licensing experts. For example, Oracle made Oracle Spatial (a database option) free in late 2019. If your script flags Spatial usage now, it might no longer require a license, depending on the versions and timing. Oracle also changed Java SE licensing in 2019 and again in 2023​ . So, maintain a licensing update log: when Oracle announces something like “Feature X is now included with base license” or “Product Y now requires subscription,” note the date and details. When reviewing LMS data, apply the current rules to current usage, but also be aware that audits might examine past usage under old rules. If a feature was licensable during the period it was used, Oracle could claim back licensing, but if it was later made free, you have some leeway to argue. In any case, knowing the context behind the raw data (the policy environment at the time of use) is key. Always use the most up-to-date script version, too, as it will incorporate the latest product list and checks.
• Remediate proactively and Consider Optimization: use the findings to not only fix compliance gaps but also optimize your Oracle deployments. For each item the scripts highlight, ask if there’s an opportunity to reduce cost or risk. Example: If an LMS script shows that a certain expensive option was used only once, the team may be able to live without it – disable it permanently to avoid needing a license, rather than buying one. Or if the scripts show dozens of lightly used databases, consider consolidating them to use fewer licenses. Some companies have saved significantly by rightsizing their environments after seeing the holistic view from LMS data​. Essentially, treat the script output as a roadmap for both compliance and efficiency: every compliance risk resolved might also yield a cost-saving or simplification. And if additional licenses are truly needed, you can plan and budget for them in advance, possibly negotiating better deals without the pressure of an audit.
• Maintain Internal Controls and Communication: When using LMS scripts, especially outside of audits, handle the outputs with care. They contain sensitive information (like user counts and system details). Keep the data confidential and share internally on a need-to-know basis. If you ever need to share results with Oracle (for example, in a voluntary compliance discussion), have a single point of contact, such as your SAM lead or legal team, and communicate with Oracle. You don’t want different people giving different data points to Oracle. Internally, ensure that everyone understands the purpose of running these scripts is to improve compliance, not to point fingers. Foster cooperation with technical teams by showing that the goal is to avoid surprises and unbudgeted fees.
• Use Oracle’s guidance, but verify: Oracle’s LMS team may offer to help interpret script results, especially during a formal review. While their input can be valuable, remember that their goal is to find compliance issues (they are not truly independent). It’s good to get expert help – either internal licensing experts or third-party consultants – to double-check Oracle’s conclusions. Internally, build expertise by learning from each run. Over time, you’ll get a feel for common gotchas (like which features always trigger even if used briefly). There are also community forums and knowledge bases where SAM professionals share insights on Oracle LMS findings. Leverage those to improve your process.

By following these best practices, running LMS scripts becomes a routine, controlled activity in your SAM program – not a scary event. You transform the Oracle scripts from an audit weapon into a management tool for your benefit.

Common Pitfalls to Avoid with LMS Scripts

While LMS scripts are powerful, there are several pitfalls and misunderstandings to watch out for:

• Incomplete Coverage: A frequent mistake is not running the scripts everywhere they are applicable. For example, only running the DB script on production databases and forgetting test or development instances. If those dev instances are installed on servers that need licensing, they count too. Similarly, ensure that you run the OS/hardware collection part on all servers, including those hosting only Oracle middleware or Java. Skipping a server will give you an incomplete picture and could mean a license liability lurking out of sight​. Always double-check that the script output has entries for every Oracle installation you know of – if something’s missing, you might have missed running it on a box.
• Insufficient Privileges or Execution Errors: If the script is not run with the correct permissions, it may silently fail to collect some data. For example, running the DB script without SYSDBA privileges might mean it cannot query certain views, so it may not list all option usage. Or running the middleware script as a non-root user might skip certain config files due to permission issues. These scenarios could lead to a false sense of compliance, as the output shows “not used” simply because there is no data. Always run with the recommended privileges and check the log or output for any “permission denied” errors. If in doubt, rerun with correct rights. Also, use the latest script version – older scripts might not capture new cloud configurations or recently licensable features.
• Misinterpreting “Usage”: A classic pitfall is thinking that if you turn something off before running the script, you’re safe. Oracle’s scripts capture historical usage from the database’s internal tables. So, do not assume that disabling an option the day before means the script won’t show it. Similarly, “Used = FALSE” in the output means the feature wasn’t used at all, not just “not currently in use.” Conversely, some DB options can be enabled by default but not used – the script might still flag them as installed, even though they are not truly used. Understanding Oracle’s definitions is key: e.g. “installed=TRUE” doesn’t require a license if “used=FALSE,” but it’s a risk because anyone could use it accidentally. Ensure you interpret the “Used?” column correctly – it usually reflects whether any usage was detected over the life of the instance. When in doubt, look at the detected use count and last used date for clarity.
• Ignoring Oracle’s License Rules Nuances: The script provides data, but you must apply Oracle’s licensing rules to that data. A common mistake is to count users or processors one way when Oracle counts them another. For instance, counting actual named users versus Oracle’s requirement of a minimum per processor (the script won’t tell you about this minimum rule; that’s something you must know and apply). Another example: in VMware environments, the script might only show the VM’s allocated CPUs, but Oracle’s policy might require licensing the entire cluster – if you ignore that, you’d under-count. Don’t let the script output lull you into a false sense of compliance – always overlay Oracle’s licensing policies on top. This is where having a licensing specialist involved helps; they can properly interpret “4 cores on VMware” (likely meaning more licenses are needed beyond just those 4).
• Overlooking Indirect Usage: Some Oracle features get triggered indirectly. For example, a developer might enable a feature like Advanced Compression by creating a compressed table, unaware that it requires a license. Or an admin might turn on Diagnostic Pack by using an OEM performance page. These indirect uses will appear in the script, but the pitfall is failing to identify why they were included. If you find an unexpected usage, investigate its cause. It could be a one-off action that can be prevented in the future with better controls. If you just ignore it (“Oh, it was just one time, not a big deal”), you risk it happening again. Put measures in place, for example, by restricting who can run AWR reports (to control Diagnostic Pack usage) or educating DBAs not to use partitioning unless approved.
• Relying Solely on LMS Scripts (or Solely on Tools): Some think running LMS scripts once means you’re done with Oracle license management. In reality, the scripts are a diagnostic; ongoing management is needed. Likewise, just trusting a SAM tool without validating it can be dangerous. The pitfall is a lack of verification. Best practice is to use both: run the scripts and use tools, then cross-verify. If your SAM tool says everything is good, but the LMS script finds an issue, or vice versa, investigate the discrepancy. Often it’s due to a nuance in interpretation.
• Panicking or Overreacting: It’s easy to see the script output and get alarmed (Oracle’s auditors often intend that). For internal use, approach the data calmly and systematically. Not every “TRUE” means a huge liability – sometimes a feature was enabled but for a trivial reason, or is no longer used. While you must take it seriously, you also have time on your side when doing this internally. Don’t rush out to buy licenses for everything flagged without analysis. Determine if the usage is ongoing, if it was an error, or if it can be addressed in another way. Conversely, don’t underreact – a common pitfall is to dismiss something as “probably an error.” Validate each item with DBAs or admins. Maybe that one “Partitioning used” was indeed a small test, but verify it and ensure it’s resolved. Balanced analysis is key.
• Not Retaining Evidence: If you fix something (for example, removing an unauthorized installation or locking 50 user accounts to get back in compliance), document it and, ideally, keep evidence (such as screenshots or scripts of the change). Why? In the event of a future audit, if Oracle’s script still detects historical use, you can demonstrate that you identified it and remedied it on a specific date. This can sometimes help during audit negotiations to show good faith and possibly limit back-dated charges. A pitfall is not keeping these records – then it’s just your word versus the data. Maintain a folder with notes or tickets for each compliance fix.
• Forgetting the Human Element: Finally, a subtle pitfall is treating this purely as a technical exercise. Compliance is also about governance and the people involved. Make sure your IT staff understands why you are running these scripts (not to blame, but to help the company stay compliant). If people fear that LMS scripts are “spying” or will get them in trouble, they might be uncooperative or, worse, try to hide things. Be transparent internally: explain that this is to avoid surprises from Oracle and to manage licenses properly. Build a culture where reporting a licensing issue is seen as responsible behavior, not something to cover up. This will encourage teams to inform SAM if, for instance, they want to try a new Oracle feature (so you can evaluate the license impact before they do).

Avoiding these pitfalls will help ensure that your use of Oracle’s LMS scripts is effective and that the data you get leads to correct conclusions and actions.

In short: run the scripts correctly, interpret the data carefully with context, and follow through on what the data is telling you.

Recommendations

For SAM managers and Oracle licensing professionals looking to effectively use Oracle LMS compliance scripts, here are actionable recommendations:

• Integrate Regular LMS Script Audits: Make Oracle LMS script execution a routine part of your SAM compliance checks. Schedule internal runs at least annually, or better yet, semiannually. Regular checks will catch compliance issues early and keep your team fluent in running and interpreting the scripts.
• Cover All Relevant Systems and Products: Each time you run the scripts, ensure that you include every Oracle product in use, including databases, middleware servers, Java installations, and application instances. Don’t overlook non-production environments if they are installed on hardware that requires licensing. It’s better to have comprehensive data than to miss a system that could become an audit liability.
• Coordinate and Prepare in Advance: Before running the scripts, inform and involve your database administrators (DBAs), system administrators, and application administrators. Schedule the execution at an appropriate time, such as a maintenance window, and test it on a subset if possible. Verify you have the needed access (DB credentials, OS permissions) ahead of time. Proper preparation helps avoid errors and ensures complete data collection.
• Use Official Tools and Follow Guidance: Obtain the scripts from Oracle or verified sources and use the latest version. Follow Oracle’s provided instructions step by step – this includes running all components (DB, OS, etc.) with the recommended privileges. Skipping steps can lead to missing data, so adhere to the guidelines exactly as given.
• Thoroughly Analyze Outputs Against Licenses: After running the scripts, conduct a detailed analysis, mapping the script findings to your license entitlements one by one. Identify any feature showing “used” without a corresponding license, any user counts over limits, any deployments on unlicensed servers, etc. Create a clear list of compliance gaps and address each one systematically, either by acquiring licenses or modifying configurations. Keep an internal log or report of these findings and decisions for future reference​.
• Remediate and Monitor: Act promptly on the insights. Disable unused or unauthorized features to prevent further usage, clean up user accounts, and consider consolidating or rearchitecting to reduce license needs, if possible. If additional licenses are needed for legitimate usage, plan for that – it’s better to budget and purchase properly than risk an audit penalty. After remediation, monitor those areas in subsequent script runs to ensure the issue doesn’t recur.
• Leverage Data for Optimization: Don’t just play defense – use the LMS data to optimize costs. If the scripts show that certain paid options aren’t used, you can remove them or stop paying for support on them (if the contract allows). If you discover that you’re underutilizing some licenses and overutilizing others, you can rebalance. Treat each finding as an opportunity to ask, “Do we really need this, or can we save money/avoid risk here?” and then act accordingly​.
• Document Everything: Maintain documentation of what was run, when, and by whom, as well as the outputs and the internal analysis done. Document any remediation steps (with dates). Not only does this help in audits (showing proactive compliance efforts), but it also builds internal knowledge. Over time, you’ll have a playbook for Oracle compliance specific to your environment.
• Stay Educated on Oracle Licensing: Assign someone on the team to keep track of Oracle licensing updates, including product notices, support blogs, and licensing rule changes. When a change occurs (e.g., Oracle reclassifies a feature as free or changes the licensing of Java), update your internal compliance criteria accordingly. Regular training or reading on Oracle licensing for the SAM team is highly recommended – the rules are complex and evolving.
• Use SAM Tools Wisely – Validate with LMS Data: If you use third-party SAM tools, continue to use them for day-to-day tracking, but feed them with Oracle LMS data when available. Trust but verify: if the tool is Oracle-verified, utilize that capability; if not, be sure to manually input or compare with script outputs. Never rely solely on a tool’s compliance report without cross-checking against what Oracle’s scripts show​. This dual approach provides both efficiency and accuracy.
• Be Audit-Ready (No Surprises): By following the above steps regularly, you should reach a state of confidence where an Oracle audit doesn’t induce panic. Keep a “license evidence file” with your LMS outputs and remediation records. If an audit notice comes, you already know your likely exposure (if any) and have a narrative for it (“Yes, we used Partitioning on these three servers, but we addressed it by licensing/turning it off on X date”). This preparation can significantly ease the audit process. In other words, use Oracle’s scripts to stay one step ahead of Oracle – when they come with questions, you’ll have the answers.

By adhering to these recommendations, global SAM teams can turn Oracle’s license compliance scripts into a proactive asset. You’ll maintain control over your Oracle deployments, ensure compliance continuously, and mitigate the risk of unexpected fees.

Remember, effective Oracle license management is an ongoing process – but with the right practices, the LMS scripts become powerful allies in that effort rather than dreaded audit tools.

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

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit