Oracle / Audit Defense
The Oracle LMS script run. On your terms.
Oracle asks you to measure yourself and return the file. Which script arrives, what it touches, how to run it safely, and what to capture before you release anything.
Oracle asks you to measure yourself and return the file. Which script arrives, what it touches, how to run it safely, and what to capture before you release anything.
Oracle's data collection script is not a form. It is an evidence gathering event that runs inside your estate, on your privileges, on a date you choose, and it produces the file that becomes the audit. What you do in the two weeks around that run decides most of the claim.
Oracle License Management Services, now generally operating as Global Licensing and Advisory Services, does not audit by inspection. It audits by asking you to measure yourself and return the measurement.
That distinction matters more than anything else on this page. The collection is an event you control, and control is the only leverage you get before the finding letter.
Oracle asks for a package, not a script. A database collection normally arrives as three separate artifacts, and buyers routinely treat only the first one as the audit.
Only the first artifact is measurement. The other two are declaration, which means they are written by you and can be written badly.
Ask for the script by name and version before you agree to anything. Oracle's collection scripts change between releases and between database versions, and a script written for a 12c estate can behave differently on 19c or 23ai.
Record the exact filename, file size, and a SHA256 hash of what you received, plus who sent it and when. If a finding later fails to reconcile, that record is the only way to establish which code produced which number.
The three artifacts, and who is actually exposed by each
| Artifact | Nature | Where the money moves | Who should own it |
|---|---|---|---|
| SQL collection | Measured, objective | Option and pack usage rows | DBA, supervised |
| Host or hypervisor data | Mixed | Core counts and cluster reach | Infrastructure plus licensing |
| Server worksheet | Self declaration | Scope, environments, user counts | Licensing lead, never a DBA alone |
| Covering note | Your argument | Frames every ambiguous row | Licensing lead plus counsel |
Not every collection request arrives with the word audit in it. Oracle also runs license reviews, health checks, and advisory engagements that use the same scripts and feed the same analysis engine.
Treat a soft review exactly as you would treat a formal notice. The only reliable difference is the contractual clause being invoked, so read that first and see our Oracle audit letter triage guide for the first 30 days.
The database collection is read only against the data dictionary. It queries catalog views and dynamic performance views, and it does not read your application tables.
Our companion page on reading LMS script output column by column takes those views apart row by row. This page stops at what the run touches.
The collection does not read customer data, table contents, or business records. Arguing that it does will cost you standing with the auditor and with your own legal team.
What it does capture is worth naming precisely: database account names, schema names, hostnames, instance names, database link names, and directory paths. In some jurisdictions account names are personal data, and hostnames plus link names disclose architecture you may hold under other confidentiality obligations.
A single run against one instance is not a complete picture, and an incomplete picture is worse for you than a complete one. Oracle fills gaps by extrapolation, and extrapolation is not generous.
Run it yourself, once, under change control, after you have read the script. Every part of that sentence is a control that buyers regularly skip.
There is no situation in which Oracle needs database credentials to complete a collection. A DBA with SELECT_CATALOG_ROLE and read access to the relevant dynamic performance views produces byte identical output.
Granting an Oracle engineer interactive access converts a bounded measurement into an unbounded one. It also destroys your ability to say what was run and when.
The collection is plain SQL and can be read in an hour by any senior DBA. You are looking for four specific things.
Feature usage is not recorded continuously. A background process samples the database on an interval that defaults to roughly seven days, and each sample writes a dated row into the usage view.
This creates a trap in both directions. Forcing an on demand sample writes a new row dated today, and if anything is running at that moment you have just manufactured evidence inside the audit window.
If you find unlicensed option usage before Oracle asks, the right order is remediate, document, then let the estate settle. Turning off a feature does not erase history, but it stops the clock and it changes the currently used state on the next sample.
Once a formal notice is in hand the calculus changes. Remediation after notice is still worth doing for future periods, but you must disclose the change and its date, and you should expect the audited period to be measured as it was.
Capture everything that will let you rebuild the run without Oracle's cooperation. The auditor keeps their own copy of the output. If you do not keep yours, every later conversation happens on their evidence.
Write one row per instance, at the time of the run, in a file nobody edits afterwards. It takes a DBA about ten minutes per instance and it has settled disputes worth six figures.
Most defensible arguments rest on evidence that ages badly. Job histories roll over, ticket systems archive, and the consultant who ran a one time test in 2021 leaves the company.
Collect the supporting material in the same window as the run, not after the finding letter arrives.
The script is the only part of an Oracle audit that tells the truth by accident. Everything around it, including your own worksheet, is written by people with an interest in the answer.
Expect four or five, and expect most of them to be defensible. Knowing them in advance changes the run from a discovery exercise into a verification exercise.
Diagnostics Pack and Tuning Pack are the most common findings on Enterprise Edition, and the reason is a single initialization parameter. CONTROL_MANAGEMENT_PACK_ACCESS ships with a default that enables both.
Set to NONE, the database blocks the pack features and stops recording new usage. Set to DIAGNOSTIC, only the Diagnostics Pack is available. Left at the default, the automatic workload repository runs and records usage nobody consciously asked for.
Partitioning frequently shows usage on databases where no application table is partitioned, because Oracle managed dictionary objects are themselves partitioned. Oracle's own partitioning policy document is the reference, but the raw file does not distinguish your intent from a product default.
Advanced Compression behaves the same way. Basic table compression is included with Enterprise Edition, while advanced row compression is not, and the usage row does not always make that distinction obvious on its face.
Expected findings, and what you should have ready before the run
| Expected finding | Usual real cause | Evidence to have ready |
|---|---|---|
| Diagnostics Pack used | Pack access parameter left at default | Parameter history, AWR retention settings |
| Tuning Pack used | SQL tuning advisor invoked once, often by a script | Advisor task owner and date, change ticket |
| Partitioning used | Oracle managed dictionary objects | List of partitioned objects by owner |
| Advanced Compression used | Secure file or basic compression misread | Compression type by segment |
| Advanced Security used | Network encryption defaults on a patched release | Network configuration files with dates |
| Option present in V$OPTION | Linked into the binary, never used | Zero usage rows in the feature usage view |
Reading those rows properly is a separate discipline and we have written it up separately. Start with the run controls on this page, then move to the column by column interpretation guide once the file exists.
Findings are priced from Oracle's global price list, then multiplied by processor count, then loaded with backdated support. A single option on a modest cluster routinely lands as a seven figure opening claim.
The arithmetic and the prerequisite chains are set out in our page on Enterprise Edition options as a priced audit risk, which is the right place to model the bill before you run anything.
Source: Redress Compliance advisory engagement file
The common advice is to stall: delay the run, argue about scope, and give Oracle as little as possible for as long as possible. That advice is half right and it costs people money.
Delay is only leverage when you are using the time. Buyers who stall without preparing arrive at the same run three months later with the same unmeasured estate, a worse relationship, and a shorter runway to the renewal Oracle has been holding in reserve.
The stronger posture is the opposite. Agree a scope in writing, then run the collection early and completely on your own terms.
Hold the output for the two to three weeks it takes to reconcile it. You then arrive at the first finding meeting knowing the number better than the auditor does, and that is the only position from which a claim actually falls.
Treat release as a gate with named approvers, not as an email. Once the file leaves your network you cannot unsend it, and every later argument is uphill.
Send the output with a short written interpretation, not naked. Two pages is enough: scope statement, method, known defaults and their causes, points of disagreement, and the evidence index.
A covering note does not change the data. It changes who is arguing from a position and who is arguing from a spreadsheet. See our Oracle audit response letter guide for the wording that has held up.
Bring in independent help when the estate spans virtualization, when multiple priced options appear, or when the audit sits within twelve months of a renewal. Those three conditions are where the claim and the renewal become the same negotiation.
Usually not outright, because most Oracle agreements contain an audit clause that obliges reasonable cooperation. What you can do is negotiate the scope, the timing, the method, and who runs it. Refusing entirely tends to escalate; negotiating the terms of the run almost always succeeds.
Read access to catalog and dynamic performance views, which SELECT_CATALOG_ROLE normally provides. It does not need SYSDBA for the standard database collection, and it never needs an account created for Oracle. If someone asks for more, ask them to point at the specific view that requires it.
No. The output is identical when your own DBA runs it, and running it yourself preserves your record of what was executed, when, and against what. Handing over interactive access converts a bounded measurement into an open ended one you cannot reconstruct.
The standard read only collection does not, but related actions can. Forcing an on demand feature usage sample writes a new row dated today, and invoking a tuning advisor to investigate a finding can register Tuning Pack usage. Read the script and control what else runs that week.
No. Clearing or resetting the views is falsification of audit evidence and breaches the audit clause you are operating under. It also destroys your own defense, because those rows carry the dates that prove a feature was used once years ago and never since.
Letting a DBA complete the server worksheet alone. The SQL collection is measured and objective, but the worksheet is self declaration, and a well meaning engineer will happily declare an entire virtualization cluster that Oracle could never have discovered on its own.
Two to three weeks is realistic for a mid size estate. That time is spent tracing every ambiguous row to a cause, gathering evidence that is still retrievable, and reconciling counts against the Oracle processor core factor table. Agree that window with the auditor up front rather than missing a deadline.
If they are in scope under the agreement, yes, and omitting them is worse than including them because Oracle will extrapolate. Note that non production databases normally require full licensing under Oracle's standard terms, so a refreshed test copy carrying production usage history is a real exposure, not a technicality.
An Oracle audit is decided by two feature usage views the database has filled in since day one. What the GLAS and LMS scripts collect, and how to read them before Oracle does.
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.
