Oracle LMS Scripts
Oracle LMS scripts – the Oracle LMSCollectionTool – are Oracle’s official scripts for collecting software usage data. They play a pivotal role in Oracle license audits and compliance reviews.
These scripts are designed to run on customers’ systems and capture detailed information about Oracle software installations and usage.
Understanding Oracle LMS scripts is crucial for IT asset managers, Oracle customers facing audits, procurement professionals, and consultants.
This guide provides an expert overview of LMS scripts, how they work during audits, what data they collect, the compliance risks involved, and the best practices for running them safely and accurately.
What Are Oracle LMS Scripts?
Oracle LMS (License Management Services) scripts are a set of diagnostic programs developed by Oracle to help assess software license compliance. Oracle sometimes refers to them as the Oracle Collection Tool, Oracle license compliance scripts, or LMS collection tools.
These scripts are provided by Oracle (often during an audit) and executed in the customer’s IT environment to gather data on Oracle software usage. Key points about Oracle LMS scripts:
- Origin and Purpose: Created by Oracle’s License Management Services (now part of Oracle Global Licensing and Advisory Services, GLAS) team, LMS scripts are the “fully automated analysis” tools Oracle uses to locate installed Oracle products and capture how they are used. The goal is to provide a detailed evaluation of the customer’s Oracle software usage. In other words, they inventory what Oracle software is deployed and how it’s configured and utilized.
- Use in Audits: Oracle employs these scripts during official license audits or “license reviews” to verify that customers comply with their license agreements. During an audit, Oracle will typically send the LMS script package to the customer and request it be run on all relevant systems. The output from the scripts is then returned to Oracle for analysis. An initial audit notification and kickoff meeting follow this standard audit process. (Oracle may also use LMS scripts for other compliance scenarios, like verifying usage at the end of an Unlimited License Agreement term or as part of a voluntary self-assessment.)
- Scope – Many Oracle Products: The LMS collection tools cover many Oracle products. While the most common use is for Oracle Database audits, there are script modules for Oracle Middleware (e.g., WebLogic Server), Applications (E-Business Suite, PeopleSoft, etc.), Java SE, and other Oracle software. Each script is tailored to gather data relevant to the Oracle product family. For example, a database LMS script targets database options and usage, whereas a WebLogic script would gather application server domain configuration and deployments.
Why Oracle Uses LMS Scripts: Oracle insists on using its LMS scripts in audits because they ensure consistent, accurate, and comprehensive data collection. Rather than relying on manual reporting or third-party tools (which might be incomplete), Oracle’s scripts are engineered to capture everything Oracle needs to assess compliance.
According to Oracle, the Collection Tool provides “a detailed evaluation of…software usage” and helps identify where Oracle products are deployed and in use. In practice, these scripts run hundreds of checks automatically – the database script alone executes hundreds of SQL queries to interrogate the system (one analysis noted 694 SELECT statements in a recent LMS script version).
This thoroughness gives Oracle confidence that no usage of a licensable feature or option is overlooked. From Oracle’s perspective, LMS scripts make audits efficient and reliable, standardizing the process across all customers.
How Oracle License Compliance Scripts Work During Audits
During an audit, the use of LMS scripts typically follows a structured process:
- Audit Notification: Oracle notifies the customer of the audit (usually with 45 days’ notice per contract) and specifies which Oracle products/environments are in scope. Oracle’s audit team (License Management Services, now GLAS) will be involved.
- Kickoff and Scoping: A kickoff meeting discusses the scope and procedures. Oracle will outline what data it needs. In nearly all cases, Oracle will request running the LMS scripts on the relevant servers to gather the required information.
- Providing the Scripts: Oracle provides the customer with the appropriate LMS script package for their environment. These are typically delivered as a ZIP or archive with scripts and instructions. (The scripts are not publicly downloadable; they are given out for audits or on special request.) Oracle regularly updates the scripts (typically a couple of times per year) to account for new Oracle product versions and features, so auditors will ensure you have the latest version.
- Running the Scripts: The customer executes the LMS scripts in their environment. Oracle does not run them remotely; your IT team runs the tools and gathers the output. Depending on the product, running the scripts might involve:
- Logging into each server (or database) with appropriate privileges. For database scripts, you usually run a provided SQL script or tool connecting as a DBA user (often with SYSDBA privileges) on each Oracle database instance. There may be shell scripts or commands to run for middleware or other products.
- Often, the script package includes an overarching shell script or batch file that must be run as an administrator (root) on the server. This script will execute various system commands and SQL queries automatically. For example, running as root allows it to gather hardware details from the OS and connect to Oracle databases to run internal queries for feature usage and configuration.
- The script execution is generally read-only and safe. It should not make changes to your system; it only collects information. Many organizations still choose to run it during a maintenance window or off-peak hours to avoid any performance impact. In most cases, performance impact is minimal – one Oracle customer noted that running the scripts took “one hour for each server and did not interfere with the team’s day-to-day activities.”
- As the script runs, it generates output files (often in HTML, CSV, or text format, sometimes zipped). These files contain the raw inventory and usage data gathered. Depending on the tool version, it might produce separate files per database or component or one consolidated output.
- Reviewing the Output Internally: Before sending anything to Oracle, it’s wise (though not required by Oracle) for the customer to review the script output. The data is typically quite technical and voluminous – it may include lists of installed software, feature usage metrics, user accounts, CPU details, etc. The output doesn’t declare whether you are compliant; it’s raw data. Oracle’s script output is often not easily interpretable without licensing expertise. Many organizations engage internal licensing specialists or third-party consultants to parse the results before submitting to Oracle. This internal review can reveal potential compliance gaps (for example, noticing that an optional database feature was used on a server that isn’t licensed for it) so the company isn’t caught off guard. We’ll discuss best practices for this later.
- Submitting Data to Oracle: The customer then provides the LMS script output files to Oracle’s audit team (often via a secure portal or email). Importantly, the LMS scripts do not automatically send data to Oracle – you remain in control of the results until you choose to share them. Oracle will usually request that you send the raw output without alteration.
- Oracle’s Analysis: Oracle’s LMS auditors import and analyze the script results. They compare the discovered deployments and usage data against your entitlements (your purchased licenses and contracts). Specifically, they look for any discrepancies such as software installations or options in use that are not fully licensed, usage beyond what your license metrics allow (e.g., using more cores or users than licensed), or use of features that require separate licenses. Oracle will reconcile installed and used programs vs. what you’ve paid for, flagging any unlicensed usage.
- Audit Report and Follow-Up: Oracle then issues a preliminary audit report outlining potential non-compliance findings. For each issue, they’ll detail the evidence (often derived from the LMS script data). For example, the report might say, “Database instance X on server Y is using Partitioning option without a license, and the server has eight cores requiring N processor licenses” – information directly drawn from the scripts (option usage flags and hardware CPU count). The customer can discuss or dispute these findings, especially if something seems inaccurate. Finally, the process moves to negotiating resolutions (typically purchasing required licenses or adjusting deployments).
Throughout this process, Oracle’s audit clause in the license agreement underpins its right to collect this data. Customers must “provide reasonable assistance and access to information” for the audit. The contract usually does not explicitly force you to run Oracle’s specific scripts.
Still, it’s difficult to gather “all relevant information” manually or via other tools to Oracle’s satisfaction. Thus, nearly all customers consent to using the LMS Collection Tool provided by Oracle, as it’s the most straightforward way to fulfill the audit requirements.
In summary, during an Oracle audit, the LMS scripts are the de facto method for data collection, trusted by Oracle and expected to be used.
What Data Does the Oracle LMSCollection Tool Collect?
Oracle LMS scripts are designed to capture a wide range of data points about your Oracle software environment. The exact data collected varies by product, but generally, the scripts aim to build a complete picture of:
- Installed Oracle Software: The scripts will inventory all Oracle products installed on the system. For databases, this means identifying every Oracle Database instance, its version (e.g., 19c, 21c), edition (Standard Edition vs Enterprise Edition), and installed database options or extensions. For application servers, it might list installed WebLogic Server instances or Java installations. Essentially, it locates the Oracle software present on each machine.
- Software Usage and Configuration: LMS scripts gather information on how the software is configured and used. For an Oracle Database, this includes which database options and features have been used. Oracle Database Enterprise Edition has numerous add-on options (Partitioning, Advanced Compression, Transparent Data Encryption, etc.) and management packs (Diagnostics Pack, Tuning Pack, etc.) that are licensed separately. The scripts query the database’s internal views to detect the usage of these options/packs. For example, the script will check if Partitioning is enabled, if any partitioned tables exist, if Advanced Security features were turned on, or if performance packs were accessed. It also checks features usage statistics – Oracle databases internally record feature usage metrics, and the LMS script harvests those to see if any chargeable feature was exercised (even historical usage is noted). Even if you tried a feature years ago without a license, the script may catch it. Oracle’s tools can uncover unlicensed usage dating back as far as 10 years in some casessince the database stores cumulative usage data. For middleware or other products, usage info might include things like number of Oracle WebLogic instances in a cluster (to see if Enterprise edition is needed), or which modules of an Oracle application are actively used.
- Hardware and System Configuration: A critical part of license compliance is understanding the hardware on which Oracle software runs because Oracle licenses (especially for databases and middleware) are often tied to the number of processors or cores. The LMS scripts, therefore, collect detailed hardware specs from each server. This includes the number of CPUs/cores, the CPU architecture (for core-factor calculations), physical vs virtual environment details, and partitioning/virtualization info. For instance, if a database runs on a VMware virtual machine, the script may gather the host cluster name and CPU info to determine the physical footprint. The script will capture if it’s running on a Unix server with hardware partitions (like Oracle Solaris Zones or IBM LPARs). CPU counts are explicitly captured so Oracle can compute how many processor licenses would be required on that machine. In short, any details about the server that affect licensing (processors, cores, memory in some cases, cluster nodes, etc.) are gathered.
- User Counts and Access: For products licensed by user (Named User Plus licensing, for example), the scripts will gather data about user accounts and usage. In an Oracle database, LMS queries might pull the number of distinct named users or schema accounts to check against Named User Plus minimums. It may not directly know which humans vs service accounts are, but it provides a count that Oracle can ask you to clarify. In applications (like E-Business Suite or Oracle Middleware), it might collect the configured users or access logs to estimate usage.
- Current and Historical Usage Patterns: The scripts look at the current configuration and often retrieve historical data points. For example, Oracle Database keeps track of each feature’s first usage date and last usage date. LMS output might include these timestamps (e.g., “Partitioning last used on 2024-07-15”). This helps Oracle identify if a feature was ever used without a license, even if it’s not in use at the exact time of the audit. Similarly, the script might look at installation history or past version usage for Java or other software.
- Environment Details: Expect the scripts to also capture environment metadata like the OS type and version, hostnames, instance names, cluster names, Oracle database SID names, etc. This info is useful for Oracle to cross-reference with their records or to ensure all instances have been reported.
To illustrate, consider a simple example of LMS script output for an Oracle Database: it might report that on server. dbserver01 An Oracle Database Enterprise Edition 19c is installed on 8 CPU cores (Intel x86) in a VMware virtual environment. It would list that database’s configured options – e.g., Partitioning = TRUE (used 5 times), Advanced Compression = FALSE (not used), Oracle Diagnostics Pack = TRUE (used), etc.- along with the dates or counts of usage.
It would also show the database name, the number of user accounts in that database, and perhaps that the database is part of a two-node cluster (Oracle RAC) if applicable.
All of this raw data would later be analyzed to determine, for instance, that the Partitioning option and Diagnostics Pack licenses are required and that eight processor licenses (after core factor) or a certain number of named users are needed for compliance.
Another example: for an Oracle WebLogic Server deployment, the LMS script might output the number of WebLogic instances, versions (say, WebLogic 12c), the edition (Basic vs Enterprise), whether they’re clustered (clustered WebLogic usually implies a higher edition or license requirement), what Java version is used (since Java SE now requires licensing in certain cases), and the host CPU details.
If WebLogic is part of an Oracle middleware suite, the script would similarly identify any optional components in use (like Oracle SOA Suite, if installed).
Overall, the data collected by LMS scripts is exhaustive – Oracle has engineered these tools to fetch everything relevant to licensing. One expert noted that an Oracle LMS database script checks all 18 chargeable database options and five management packs available for Oracle DB Enterprise Edition, performing hundreds of detailed queries to ensure nothing is missed.
The result is a comprehensive raw dataset of what Oracle software you have, how you’re using it, and on what infrastructure. This data is the foundation for Oracle’s compliance conclusions.
Compliance Risks and Oracle’s Rationale for Using LMS Scripts
Running Oracle’s LMS scripts can expose significant compliance risks if your organization has unlicensed or misconfigured Oracle deployments.
It’s important to understand these risks and also why Oracle strongly insists on using the scripts during audits:
- Exposure of Unlicensed Usage: The primary risk is that the scripts will uncover usage of Oracle software beyond what you have legally licensed. This could be something obvious, like an entirely unlicensed Oracle database installation that was never purchased, or something subtle, like an optional feature enabled on a licensed database without the corresponding option license. Because LMS scripts dig into historical and configuration data, they might reveal “unintentional” usage that staff weren’t even aware of. For example, a DBA might have enabled the Oracle Tuning Pack for a performance issue, not realizing it wasn’t licensed – the script will flag that usage, and Oracle will consider it a license violation. Even if the feature was turned on briefly years ago, if the usage data remains in the system, the script can find it. Such findings can result in hefty backdated license fees or require a purchase to resolve. In essence, any deviation from license terms is likely to be spotted. This is exactly why Oracle uses the scripts – to flush out non-compliance.
- Thoroughness (No Hiding): Oracle’s scripts are very thorough, meaning it’s difficult for a customer to hide or omit information (whether intentionally or accidentally). If an organization thought it could avoid scrutiny on a certain server by not running the script there, Oracle would question any gaps in data. Oracle’s audit teams often have a high-level view of your contracts and support records, so they might know which servers or applications to expect. Oracle insists on using LMS scripts because they close any loopholes – the scripts uniformly collect data from all systems, leaving little to “interpretation” by the customer. From Oracle’s standpoint, this consistency prevents customers from cherry-picking what to report.
- Standardization and Trust: Oracle trusts the data collected by its LMS scripts because they are Oracle’s tools. Suppose a customer were to provide data in another format or from a third-party tool. In that case, Oracle would likely still want to verify it with its scripts (unless that third-party tool is Oracle-verified, and even then, Oracle may run some of its queries to double-check). Oracle knows exactly what LMS scripts do, so they consider the output reliable evidence. This standardization can sometimes feel rigid to customers, but it’s part of Oracle’s audit methodology to reduce ambiguity.
- Legal and Contractual Position: The license agreements don’t force a specific tool but require full cooperation. Refusing to run the LMS scripts outright could be seen as a lack of cooperation. That could escalate the situation – Oracle might then pursue legal means to obtain the information or assume non-compliance by default. Thus, most customers comply and run the scripts to stay within the “reasonable assistance” clause. Oracle’s audit team might highlight that running the scripts is the quickest way to satisfy the audit requirements. In short, Oracle is insistent because they need complete info contractually, and practically, their tool is the surest way to get it.
- Data Accuracy and Completeness: Another risk on the customer side is inaccurate data if the scripts are not run correctly. If the script is executed improperly or not across all systems, it might produce incomplete results. Incomplete data can lead Oracle to assume worst-case scenarios. For instance, if a database’s output is missing, Oracle may assume that instance is unlicensed or that it’s using all features until proven otherwise. It’s in the customer’s interest to run the tools correctly to avoid false compliance issues. Oracle insists on proper execution to avoid debates over accuracy.
- Sensitive Information Considerations: By design, LMS scripts collect system and usage information, not business data – they shouldn’t expose application data or personal data. However, there’s a theoretical risk that some sensitive info could be swept up (for example, hostnames might include company or client names, or user account names could be personal identifiers). Oracle advises that customers review the data the scripts will collect. As a precaution, companies sometimes scrutinize the script (Oracle usually provides it in source form, especially SQL scripts, which can be reviewed by your DBAs) to ensure it’s only gathering relevant information. The audit clause also typically includes confidentiality provisions, meaning Oracle should treat any data collected as confidential. Still, it’s wise to know exactly what you’ll be sending to Oracle. Never modify the script to omit data without Oracle’s knowledge, as that could be seen as a breach of audit cooperation – instead, discuss any concerns with Oracle upfront if something seems beyond scope.
- Impact on Systems: Running any tool on production systems carries a risk, however small, of performance impact or instability. Oracle LMS scripts are generally safe and read-only, but if you have extremely sensitive environments, you might worry about the load of hundreds of queries. Oracle’s case studies indicate minimal impact, but a best practice is to schedule the execution in off-hours or during maintenance windows to mitigate this risk. Additionally, coordinate with system owners to ensure the timing is acceptable. From Oracle’s perspective, the scripts are necessary. They shouldn’t be delayed excessively but will usually accommodate reasonable scheduling (since the audit clause says not to “unreasonably interfere” with business operations). They insist on running the scripts, but not at the cost of crashing your system, so communicate any performance concerns and plan accordingly.
In summary, the compliance risks of running LMS scripts are essentially the flip side of their value: They will uncover any compliance gaps. Oracle’s rationale for requiring them is to leave no stone unturned in verifying license compliance.
As a customer, knowing what these scripts target helps you anticipate what Oracle might find.
The next section will provide some examples to concretize what information the scripts output, and then we will discuss how to manage the process through best practices.
Examples of Information Collected by LMS Scripts
To better understand the scope of Oracle LMS data collection, let’s walk through a couple of practical examples that illustrate typical findings:
- Oracle Database Example: An LMS script is run on a server hosting an Oracle Database. The output might include lines or sections like:
- Oracle Database Edition: Enterprise Edition 19.12.0.0.0 (indicating version 19c, patch level, Enterprise Edition).Installed Options: Partitioning [Installed/Used], Advanced Compression [Not Used], OLAP [Installed/Used], Data Guard Broker [Enabled]. This shows which optional components are present and whether they’ve been used. The script uses internal queries (against views like
V$OPTIONorDBA_FEATURE_USAGE_STATISTICS) to produce this list. If “Used” appears, it often includes a usage count or date. For example, Partitioning might show “Used 10 times, Last Used: 2024-11-01”.Management Packs Usage: Diagnostic Pack [Used], Tuning Pack [Used], Database Vault [Not Used]. Oracle databases track if features of these packs (like AWR reports for Diagnostics Pack) have been accessed. The script will flag those usages. Each “Used” implies a separate license may be required. Hardware Details: Server: dbserver01 (Linux x86_64); Cores: 16 (2 CPUs x 8 cores each); CPU Architecture: Intel Xeon; Virtualization: VMware (virtual machine running on host cluster “CorpCluster01”). This portion comes from the OS-level part of the script run as a root, capturing how many processors and cores the database runs on and the environment. Oracle would use this to calculate processor license needs – e.g., 16 cores with a core factor of 0.5 each would equate to 8 Licenses required, if not limited by virtualization policies. User Accounts: 150 named users in the database (of which 120 are active). If you license using Named User Plus, this is important. Oracle might compare that number to your license count to ensure you meet the minimums and have enough licenses for all users. Database Instances: The script would list each if the server had multiple Oracle instances. For example: Instance ORCL1 and ORCL2, both Enterprise Edition, with their respective option usage. It also identifies if these instances are part of an RAC cluster (Real Application Clusters). For instance, ORCL1 and ORCL2 might be two nodes of a RAC – the script output would note that RAC is enabled (which itself is an option requiring licensing).Other Findings: The script might also capture things like whether standby databases exist (Data Guard usage), or if features like Multitenant (Pluggable Databases) are in use (Multitenant is a licensable option in versions 12c and up if more than one pluggable DB is used in a container). For example, it might list “Multitenant Option: 3 PDBs (license required)” if applicable.
- Oracle Database Edition: Enterprise Edition 19.12.0.0.0 (indicating version 19c, patch level, Enterprise Edition).Installed Options: Partitioning [Installed/Used], Advanced Compression [Not Used], OLAP [Installed/Used], Data Guard Broker [Enabled]. This shows which optional components are present and whether they’ve been used. The script uses internal queries (against views like
- Oracle Middleware (WebLogic) Example: An LMS script run on servers using Oracle WebLogic might produce information such as:
- WebLogic Server Installations: WebLogic Server 12c (12.2.1) detected on host appserver01 and appserver02. The domain name is “ProductionDomain,” and it has 4 managed servers in a cluster. This tells Oracle you have a clustered deployment of WebLogic. Typically, clustering WebLogic requires the Enterprise Edition (as opposed to the free Basic version). The script would flag the edition or features in use (e.g., JMS clustering, transaction manager, etc. that indicate an Enterprise feature set).Java SE Usage: If the servers are running Java, the script might identify Oracle Java versions installed (particularly if Java SE is used in server environments, which since 2019 may require a subscription license for updates). For example: “Oracle Java SE 1.8.0_u271 installed, last updated Jan 2021”. This could alert Oracle to a Java licensing need. Oracle HTTP Server or Other Components: The script might find associated products like Oracle HTTP Server or Coherence caching if those are present, which have their licensing implications.Hardware: similar to the DB example, it lists the server CPU info (e.g., each app server has 8 cores, IBM Power architecture, etc., or notes if running in cloud instances).
These examples underscore how granular the LMS data collection is. It covers the high-level inventory down to specific feature toggles and usage counts. By reviewing such output internally, organizations can often predict what Oracle will say and prepare their explanations or remediation plans.
Best Practices for Running Oracle LMS Scripts Safely and Accurately
Running LMS scripts is a sensitive task that needs to be managed carefully. Below are best practices to ensure the process goes smoothly, your data is accurate, and risks are minimized:
- Obtain Scripts through Official Channels: Only use the exact scripts provided by Oracle for your audit or review. Do not download scripts from unofficial sources. Oracle typically provides the collection tool directly (via secure email or a support portal). Using the authentic package ensures you’re running the correct version that Oracle expects. Verify any checksums or digital signatures if provided, to confirm integrity.
- Involve the Right Teams: Coordinate internally with all relevant stakeholders – database administrators (DBAs), system administrators, middleware admins, IT asset managers, and security personnel. Make sure everyone understands what will be run and why. Your DBAs should review the script instructions; your security team might want to vet the script (they can inspect the script code to confirm it’s read-only and safe). Having the right experts involved ensures the script is executed with appropriate privileges and oversight.
- Run in a Controlled Manner: Plan the execution of the LMS scripts during a time that will least impact business operations. Schedule a maintenance window or an off-peak time to run the scripts, especially on production systems. While, as noted, the scripts usually don’t significantly affect performance, it’s prudent to be cautious. If possible, test-run the script on a non-production instance first to gauge its effect and to ensure you know the procedure. For example, run it on a test database that mirrors production to see how long it takes and what output is generated. This practice can uncover any issues (like needed permissions or script errors) before you run on critical systems.
- Follow Oracle’s Instructions Exactly: Oracle will usually supply a ReadMe or guide for running the LMS tool. Follow these steps precisely. That includes running all parts of the script on all systems in scope. If Oracle asks for the script to be run on every server where Oracle software is installed, ensure none are overlooked (don’t forget development or standby servers if they are in the audit scope). Run the scripts with the user privileges that Oracle recommends (often root for OS-level data and a DBA user for database-level data). Skipping a component or using lower privileges might result in incomplete data. Also, ensure any environment prerequisites are met (for example, for database scripts, setting ORACLE_HOME or ensuring the database listener is up if the script connects remotely).
- Minimize Interference and Log Everything: Monitor the systems for any unusual load while running the scripts. It’s uncommon to need to stop the script, but if something goes wrong (e.g., a script hangs), you should know. Keep logs of the execution: note the date/time each script was run, on which server, and by whom. If the script produces log files or screen output, save that as well. This record can be useful if Oracle has questions or if you need to demonstrate that you ran it properly.
- Do Not Tamper with the Script or Output: It may be tempting for some to modify the script to “skip” known compliance issues or to edit the output afterward. Avoid any such tampering. Oracle auditors are very familiar with their tools – altered scripts might fail internal checks or produce inconsistent results that raise flags. Similarly, Oracle can often detect incomplete or edited output (for example, missing sections). Providing manipulated data in an audit can lead to severe consequences, including legal action. Always run the tool as-is and provide the raw results. If you’re concerned about something in the output, handle it through analysis and discussion, not deletion. Transparency and honesty are important; you can always explain context to Oracle, but you can’t explain an attempt to conceal facts.
- Internal Review and Analysis: Once the scripts have run, you’ll have the output files. Take the time to analyze these internally before handing them to Oracle. This step is crucial. As noted earlier, non-experts do not easily interpret the raw data, so involve your software asset management team or an Oracle licensing expert. Look for surprises: Are there options listed as “Used” that you weren’t licensing? Are the hardware counts correct? (For example, if a virtual machine shows 64 cores because it pulled the whole host’s info, be ready to clarify the actual VM allocation.) Cross-check the discovered installations against your records: Perhaps you find an old Oracle instance that was thought decommissioned but is still up – now you know how to properly remove or address it. You can address many issues proactively by doing an internal audit with the LMS data. For instance, if you find a feature enabled that you don’t need, you might consider disabling it immediately (and documenting when you did so). While that historical usage may still appear, showing Oracle that it’s been turned off and was an oversight might help in negotiations. If interpreting the output is beyond your team’s expertise, consider hiring an independent Oracle license consultant to help translate the data. They can often predict exactly what Oracle will claim and help you formulate a response or remediation plan.
- Fix Easy Issues Before Submission: If your internal review uncovers clear mistakes that can be corrected quickly and legally, do so before sending data to Oracle. For example, you might realize you installed a database option (like Enterprise Manager packs) that you never actually needed – if it’s feasible, uninstall or disable it now. Note that this won’t erase the historical usage data, but it’s better to demonstrate that you’ve stopped any unlicensed use by the time Oracle reviews. Be cautious with this approach: never try to “quick-fix” by purchasing a license at the last minute and hoping Oracle won’t notice it was unlicensed. If the usage pre-dates the purchase, Oracle can still claim back licensing. Instead, focus on cleaning up things like redundant installations, shutting down unused servers, or ensuring all environments are properly tagged (e.g., if some instances are for DR only, make sure you have records to show that, as DR might not need separate licensing under certain clauses).
- Submit Data Securely and Keep Evidence: When providing the LMS script output to Oracle, use the secure method they require (usually an upload link or encrypted email). Keep a copy of exactly what you sent, and note when it was sent and to whom. This ensures you have evidence of the data provided, should any questions arise later. It also protects you if files get lost in transit – you can re-send the package you archived.
- Communicate and Clarify: After submission, maintain open communication with Oracle’s audit team. If there are any known oddities in your environment that the data might misrepresent, proactively inform them. For instance, if the scripts show 10 databases, but you know 2 are purely for backup/testing and you have a contractual clause excluding those, let Oracle know upfront. Or if the script shows a high user count because of some system accounts, provide that explanation. This can preempt misunderstandings. Everything you claim should be truthful and, ideally, documented. Oracle will ultimately use its interpretation of the data, but informed context from you can sometimes shape that interpretation.
- Understand Your Contractual Rights: While cooperating fully, also remember your rights. You have the right to understand what the script is doing – ask Oracle for documentation if something is unclear. You also have the right to confidentiality; audit results should not be shared beyond the audit. If you have any doubt about the legitimacy of a data request, consult your legal team. For example, Oracle should not demand access beyond the scope of the audit (e.g., unrelated systems). Usually, LMS scripts are designed for specific products, but if Oracle mistakenly asks you to run a script on a system with no Oracle software, you can question that. Such scenarios are rare in practice, but it’s good to be vigilant.
By following these best practices, you help ensure that running Oracle LMS scripts is smooth and controlled. You’ll also get an accurate view of your Oracle deployments and be prepared to address compliance issues.
Moreover, demonstrating diligence in running the scripts and handling the output can foster goodwill with Oracle’s auditors (showing that you take compliance seriously and are organized).
Conclusion and Key Takeaways
Oracle LMS scripts are integral to Oracle’s license compliance verification process. They are powerful data-gathering scripts that give Oracle a deep look into your software usage. For organizations, these scripts can seem daunting, but with the right approach, they become a useful diagnostic resource rather than just an audit threat.
Key points to remember:
- Oracle LMS scripts (the Oracle Collection Tool) are Oracle’s proprietary audit scripts used to collect information on installed Oracle products, feature/option usage, and the hardware environment. They are commonly deployed during audits and other compliance exercises.
- These scripts gather comprehensive data from software versions and installed options to CPU counts, user counts, and even historical usage logs. Oracle leverages this to identify any use of software beyond what’s licensed.
- Oracle requires or strongly encourages their use in audits to ensure accuracy and completeness. The audit contract obliges customers to provide information, and the LMS scripts are the proven method for doing so. In practice, most customers will run the scripts as requested since providing equivalent data by other means is extremely difficult.
- Running the scripts carries compliance risk in that they will spotlight any non-compliance—even inadvertent or historical usage. However, those risks exist regardless; the script just brings them to light so they can be addressed. Not running the scripts is not a viable way to avoid the issue and would conflict with audit obligations. Knowing your risks is better by seeing the script output (even running them internally before any official audit).
- Best practices include verifying that you have the authentic and up-to-date script, involving experts to run it, scheduling it appropriately, and reviewing the results carefully before submission. Never attempt to falsify the data. Instead, use the knowledge gained to fix what you can and prepare for any negotiations. Also remember that the raw output is complex—don’t hesitate to get expert help to interpret it.
- Oracle’s LMS (GLAS) team often portrays the process as helping customers optimize licenses (and indeed, some customers use the script results to better manage their licenses). From a customer viewpoint, treat the LMS scripts as a necessary diagnostic. They can benefit you by revealing inefficiencies (e.g., perhaps you find you have licenses for features you never use – information that could inform downgrading or terminating those licenses in the future).
- Finally, always maintain a professional and collaborative stance during the process. Oracle audits can be challenging, but being organized and informed about LMS scripts turns a potential vulnerability into an opportunity to demonstrate control over your Oracle estate.
By demystifying Oracle LMS scripts and following the guidelines above, IT asset managers and Oracle users can confidently navigate audits. Precision and preparation are your allies – know what the scripts do, anticipate what they will find, and manage the execution and outcomes diligently.
This transforms the LMS collection tool from a feared audit mechanism into a straightforward verification step, ensuring you and Oracle have a factual basis for discussing license compliance.
