Running Oracle LMS scripts during a certification is usually a choice, not an obligation. The scripts produce detailed data that can support a count, but the same data can surface things you did not intend to share. The decision deserves analysis, and you should control your own measurement.
Oracle Licence Management Services scripts collect detailed configuration and usage data from your environments. During a ULA certification you generally do not have to run them, unless your contract says otherwise, and you can produce a defensible count through your own discovery instead. The right answer depends on your estate and your contract, but the principle is constant: you should control your own measurement and understand the output before anyone else sees it.
In most agreements, running Oracle LMS or audit scripts is a choice rather than a contractual requirement at certification. What you owe is a defensible declaration of the deployed quantity, supported by evidence. How you arrive at that evidence is usually open to you, and there is more than one credible method. A small number of agreements do specify a measurement approach, so the first step is always to read your contract rather than assume. Where the contract is silent on method, you are free to gather your evidence in the way that produces the most accurate and the most controlled result, which is rarely the same as handing the vendor a free measurement of your estate.
The scripts are thorough. They collect configuration, version, and usage data across the Oracle environments they touch, including which database options and management packs have been used. That depth is exactly why they are double edged. On one hand, the output can substantiate a count with precise detail. On the other, it can surface usage of separately licensed options or packs that were switched on inadvertently, in environments inside or outside your ULA scope. Database options such as partitioning or diagnostics, and management packs, are licensed separately from the database itself, and their accidental use is a classic source of exposure. Once the script output exists, the information is on the record, and you cannot put it back. That is why the decision to run is a decision to make deliberately, with eyes open to what the data might show.
Measure on your own terms first. Whatever tool you use, review the output, reconcile it to your contract, and control what is shared and when. Never let raw measurement reach the vendor before you understand what it says.
There are situations where running the scripts, on your own initiative and under your own control, makes sense. They produce a consistent, recognised dataset, and a count built on that dataset can be straightforward to present. If your estate is clean, your options usage is well understood, and you want output in a format Oracle is familiar with, the scripts can be an efficient way to evidence the count. The key word is control. Running the scripts yourself, reviewing the results, and deciding what to do with them is very different from running them at Oracle's request and forwarding the raw output unread.
Independent discovery gives you the same goal, a defensible count, while keeping you in command of the process. You inventory the estate, measure the cores and products in use, establish install dates against the deployment cutoff, and assemble an evidence file that maps each number to your contract. This approach lets you find and address inadvertent options usage before it becomes a problem, scope the measurement to what your ULA actually covers, and present a count you fully understand. For estates with virtualization complexity, scattered non production environments, or any uncertainty about options usage, independent discovery usually gives a cleaner and safer result.
The table sets the two paths against the factors that should drive the choice. In every case the controlling principle is that you see and understand the data first.
| Factor | Lean to LMS scripts | Lean to own discovery |
|---|---|---|
| Options and packs usage | Well understood and clean | Uncertain or likely inadvertent |
| Virtualization | Simple, well isolated | Complex VMware estate |
| Non production sprawl | Inventoried and contained | Scattered and informal |
| Control of output | You run and review first | You need full control end to end |
Not without reviewing it first. Whatever measurement you run, the sequence matters: gather the data, understand it, reconcile it to your contract, and only then decide what to share and when. Handing raw script output to the vendor before you know what it contains surrenders the initiative at the most important moment of the engagement. A buyer side approach treats your usage data as your data, shared on a considered basis as part of a position you control, not as a file forwarded on request. This is one more place where independence pays, because the party that measures and the party that audits should not be the same.
The script decision sits inside the wider counting question. Read counting production, test, and DR instances for what your measurement needs to capture, and the overcount risk and its cost for keeping a maximized count defensible. For the full mechanics, the Oracle ULA certification guide sets out how evidence supports the certification.
Running Oracle LMS or audit scripts is generally a choice during a ULA certification, not a contractual obligation, unless your specific agreement requires it. You need to produce a defensible count supported by evidence, and there is usually more than one way to gather that evidence. Check your contract, because a few agreements do specify a measurement method.
The scripts collect detailed configuration and usage data from your Oracle environments, including options and management packs in use. That detail can support a count, but it can also surface usage of separately licensed features you did not intend to deploy. Once the output exists, you cannot unsee it, so the decision to run deserves analysis.
Not without reviewing it first. Whatever measurement you run, you should understand the output, reconcile it to your contract, and control what is shared and when. A buyer side approach keeps you in command of your own data rather than handing raw output to the vendor before you know what it says.
Book a confidential assessment and we will run independent discovery, review every result against your contract, and keep you in control of what is shared.