Oracle / Audit Defense
The Oracle LMS script. What it really reads.
Oracle's data collection script reads installed options, feature usage history, and user counts. Knowing what it reports, before you submit, decides the claim.
Oracle's data collection script reads installed options, feature usage history, and user counts. Knowing what it reports, before you submit, decides the claim.
The Oracle data collection script reads your databases in detail. It captures installed options, feature usage history, and user counts. Knowing exactly what it reports, before you submit it, is the difference between a clean result and a six figure surprise.
Oracle License Management Services ships a set of measurement scripts during an audit. For databases this is a SQL collection that queries internal views and writes a result file. The auditor then interprets that file against your entitlements.
The script is accurate at what it does. The risk is interpretation. A flag is not proof of licensable use, but Oracle treats it as a starting claim. Your job is to read the same data first.
The script standardizes measurement. Instead of trusting your inventory, Oracle reads the databases directly.
It produces a consistent, machine generated picture of what is installed and what has been used. Oracle prefers script output to self declaration because it removes ambiguity in their favor.
For Oracle Database it is a SQL script run with elevated privileges that queries data dictionary and feature usage views. The output is a structured file you return to the auditor.
The script measures. It does not license. Whether a flagged feature requires a paid option depends on your contract and the Oracle Database option documentation, not on the flag alone.
The collection is broad. It spans installed components, usage history, and user metrics.
The dictionary records that a feature ran, with a first and last used date, but not the business context. A feature triggered by a default maintenance job reads identically to deliberate production use.
Counts feed straight into the metric. Processor based licensing uses the Oracle processor core factor table to convert cores to licenses, so configuration accuracy matters as much as option flags.
Common script flags and what they mean
| Flag | What Oracle claims | Common true cause |
|---|---|---|
| Partitioning used | Partitioning option owed | Default partitioned dictionary objects |
| Diagnostics Pack used | Pack license owed | AWR running by default |
| Tuning Pack used | Pack license owed | SQL tuning advisor invoked once |
| Advanced Compression used | Option owed | Default secure file compression |
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
A few options account for most surprise findings. Knowing them lets you check the right places first.
Diagnostics Pack and Tuning Pack are enabled by default on Enterprise Edition. Unless control parameters are set to none, normal operation records usage that Oracle reads as licensable.
Partitioning shows usage even when only Oracle managed dictionary objects are partitioned. The Oracle partitioning policy document matters here, but the script does not distinguish your intent from a default.
Advanced Compression and Advanced Security can flag from default behaviors. Each requires a separate option and each is a frequent false positive.
The common advice is that the script is neutral and objective, so you should run it and return the file unchanged. We disagree. In the outputs we reviewed, a large share of flagged usage was a default behavior, not a deliberate deployment, yet the raw file presents both the same way. Returning it unannotated concedes claims you could defend. The buyer side move is to read every flag, separate default and incidental usage from real use, and submit the output with a written interpretation. The script is a measurement tool. The compliance conclusion is an argument, and you are entitled to make yours.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The script does not lie. It just does not know the difference between a feature you chose and one Oracle turned on for you. That difference is the whole negotiation.
A disciplined review turns raw output into a defensible submission. It runs in a few clear steps.
Screenshots, parameter settings, and job histories support your interpretation. Evidence you gather now is far stronger than an argument made after the claim lands.
If the output flags multiple priced options or a large user base, an independent reviewer pays for itself. The reading of feature usage is specialized and Oracle does it for a living.
It measures installed options, feature usage history, named user counts, and database configuration. It reads internal data dictionary and feature usage views and writes a structured output file. It records what ran, not why it ran.
Not on its own. A flag shows a feature was used, but whether that use requires a paid option depends on your contract and on whether the use was deliberate. Many flags trace to default jobs or one off tests and are defensible.
Diagnostics Pack and Tuning Pack lead, because they are enabled by default on Enterprise Edition. Partitioning, Advanced Compression, and Advanced Security follow. Each requires a separate license and each commonly appears as a false positive.
Yes, and you should. Run it internally, keep a private copy, and review every flag before submission. You are entitled to understand and annotate your own data rather than hand over raw output unexamined.
Their management features, including the automatic workload repository, run by default unless control parameters are explicitly set to none. Normal operation then records usage that Oracle reads as licensable, even when no one consciously used the pack.
In our experience two to three weeks is typical for a mid size estate. The time is spent tracing flags to their cause and gathering supporting evidence. That review consistently lowers the initial claim by a meaningful margin.
Yes. Processor based licensing uses the core factor table to convert physical cores to license counts. If the configuration data is wrong, the calculated requirement is wrong, so verify processor and core details alongside option flags.
If you do not license Diagnostics or Tuning Pack, set the control parameters to prevent their use going forward and document the change. This stops future flags. Do it deliberately and record the date, since it affects later measurements.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Never let Oracle read your databases before you have read them yourself. The script output is the first draft of the claim, and you should write the second.
