The collection scripts sample your database roughly once a week and write the result to CSV. Here is what each column proves, what it only suggests, and the errors to find before it leaves the building.
Oracle's collection scripts read a small number of data dictionary views and write them to CSV. This guide reads those views column by column, explains what each field actually proves, and lists the error classes a SAM manager should find before the output leaves the building.
Oracle's collection scripts are read only SQL. They query a handful of views, write the results to text, and prove considerably less than the formatting suggests.
The gap between what the output records and what a finding asserts is where a SAM manager earns their salary. Closing that gap is a reading exercise before it is a negotiation.
A defined set of data dictionary and dynamic performance views, plus host facts, exported as delimited text. Nothing is installed, nothing is modified, and nothing about your contracts is read.
Oracle's licensing function is described on its license management services page. The technical definitions of every view below are published in the Oracle Database Reference.
Oracle publishes a database options and management packs usage reporting script through My Oracle Support under Doc ID 1317265.1, available from Oracle Support with a valid support identifier.
It queries the same views but applies Oracle's own exclusion logic for known benign detections. Running it yourself, before an audit, tells you what Oracle's own filtering considers reportable rather than what a raw view dump shows.
Where the filtered report and the raw dump disagree, the difference is the argument. Document it at the time, because it is far harder to reconstruct once a finding has been drafted.
Read it as a sampling record, not a usage log. Every column in DBA_FEATURE_USAGE_STATISTICS is a statement about samples, and misreading that one fact accounts for most inflated findings.
DBA_FEATURE_USAGE_STATISTICS, field by field
| Column | What it holds | What it proves | What it does not prove |
|---|---|---|---|
| DBID | Database identifier | Which database the row belongs to | That the database is not a copy of another one |
| NAME | Oracle's internal feature name | Which feature the sampler detected | Which licensable product that feature maps to |
| VERSION | Database version at sample time | The release the detection occurred under | That usage continued after an upgrade |
| DETECTED_USAGES | Count of samples in which usage was seen | How many sample windows contained a detection | How often, how long, or how much the feature ran |
| TOTAL_SAMPLES | Samples taken for that feature and version | The denominator for the detection rate | That every sample was equally representative |
| CURRENTLY_USED | TRUE or FALSE for the most recent sample | Whether the last sample saw the feature | Anything about the rest of the audit period |
| FIRST_USAGE_DATE | Date of the first sample with a detection | The earliest window in which it was seen | The moment the feature was first used |
| LAST_USAGE_DATE | Date of the last sample with a detection | The most recent window with a detection | That use stopped on that date |
| LAST_SAMPLE_DATE | When the feature was last sampled | That sampling is current | That a detection occurred |
| SAMPLE_INTERVAL | Seconds between samples, default 604800 | The resolution of every date in the row | Any finer timing than one week |
| AUX_COUNT | Feature specific auxiliary count | A secondary measure where the feature sets one | A licensable quantity on its own |
| FEATURE_INFO | Feature specific detail, held as a CLOB | Scale: object counts, compression types, modes | Nothing, if you never open it. Most people do not |
A background process samples feature usage on a fixed interval, by default once a week. Each sample asks whether the feature has been exercised, and records a yes or a no.
So DETECTED_USAGES is a count of weeks, not a count of events. One accidental second inside a week and seven days of continuous production load both produce exactly the same value.
That single fact reframes most option findings. The view cannot distinguish intensity, and no amount of formatting in a report changes what the underlying counter measured.
Take a row for a licensable option with DETECTED_USAGES of 1, TOTAL_SAMPLES of 260, CURRENTLY_USED of FALSE, and FIRST_USAGE_DATE equal to LAST_USAGE_DATE.
That is the signature of a single touch: one detection in five years of weekly sampling, never repeated, not present now. It is a very different fact from a row showing 260 detections out of 260 samples.
Both rows can appear in a finding at the same price. Only one of them describes a deployed capability, and the distinction is visible in the raw data before anyone argues about it.
CURRENTLY_USED reports the most recent sample only. Oracle's own options and packs report renders the same underlying state as a verdict of current usage or past usage.
Past usage is not automatically free. If a license was required at the time the use occurred, the obligation existed then, and pretending otherwise is not a defensible position.
What past usage does change is the shape of the conversation. A historical detection on a known date, on a known host, is a bounded event to be priced, not a permanent capability to be licensed across the estate in perpetuity.
Rows exist per database, per feature, and per VERSION. An upgrade starts a new set of rows and leaves the old ones in place, so usage under 11.2.0.4 with none under 19c means it has not been seen since the upgrade.
On multitenant databases the same applies per container. Root and pluggable database rows both exist in CDB_FEATURE_USAGE_STATISTICS, and adding them together counts the same activity twice.
Summing naively across versions and containers is one of the most mechanical over counts in the entire process, and it is also one of the easiest to demonstrate.
It proves a peak was once reached. It does not say when, for how long, or why, and that missing context is where the largest single numbers come from.
DBA_HIGH_WATER_MARK_STATISTICS carries a NAME, a HIGHWATER value, and a LAST_VALUE. The first is the all time maximum observed, the second is the value at the most recent sample.
V$LICENSE tells a similar story with SESSIONS_HIGHWATER and the CPU count, core count, and socket count high water columns. On a virtualized host that has since been resized, those columns are the memory of what the instance once saw.
Pair every high water value with your own change records. A peak that coincides with a documented migration window, a hardware fault, or a one time load test is a fact with an explanation attached.
This is context, not evasion. If the peak coincides with two years of production, say so and price it. The point is that the view supplies a number and you supply the only available account of what produced it.
Because V$OPTION reports what is linked into the Oracle binary, not what you licensed or used. On a default Enterprise Edition installation most separately licensable options read TRUE straight out of the installer.
It is an installation fact. Treating it as a usage fact, or as a licensing fact, produces findings for options that have never touched a single object in the database.
A claim built on the first without the third is not a claim about use. Ask, in writing, which view a given line was derived from.
The chopt utility shipped with the database can unlink certain options from the binary, including Partitioning, OLAP, Real Application Testing, and Advanced Analytics on 12c and 19c. After unlinking, V$OPTION reports FALSE and the code path is physically unavailable.
Before relying on that argument, read your own agreement. A small number of Oracle contracts define exposure by reference to installation as well as use, and where that language exists the V$OPTION reading matters far more.
Edition entitlements decide the rest. Which features are included in your edition and which require a separate license is set out in the database licensing information manual, and it should be the first document open beside the output.
Ten classes cover almost everything we see. Work the list before submission, because each one is far cheaper to explain with evidence now than to dispute in a position paper later.
The ten error classes, their signature, and the evidence that settles them
| Error class | Signature in the output | Evidence that settles it |
|---|---|---|
| Default pack access | Diagnostics or Tuning Pack usage from database creation | CONTROL_MANAGEMENT_PACK_ACCESS set to DIAGNOSTIC+TUNING by default |
| Console touch | Very low DETECTED_USAGES on a pack, isolated date | Enterprise Manager access logs for the same window |
| Cloned history | Usage predating the host or the project | Clone or duplicate records, DBID, database creation date |
| Version stacking | Detections on an old VERSION, none on the current one | Upgrade date, and the per version row split |
| Container double counting | The same feature on root and on a pluggable database | CON_ID breakdown from the container level view |
| Basic versus advanced compression | A compression row with no type detail carried forward | FEATURE_INFO contents and the edition entitlement |
| Cluster wide reads | Per instance rows summed as if per database | Cluster topology and the GV$ view across instances |
| Standby and failover | Usage on a database that only ever ran as a target | Role transition records and failover dates |
| User account proxies | DBA_USERS counts presented as named user counts | Which accounts are service accounts and which map to people |
| Sample schemas and default jobs | Detections tied to demonstration schemas or maintenance windows | The job schedule and the template the database was built from |
On Enterprise Edition, CONTROL_MANAGEMENT_PACK_ACCESS defaults to DIAGNOSTIC+TUNING. Automatic Workload Repository snapshots then run without anyone enabling them, and Diagnostics Pack usage registers from the moment the database exists.
Setting the parameter to NONE stops that happening going forward, and it is the right control on any database where the packs are not licensed. It does not erase history, and it should not be presented as if it does.
For the past, the argument is factual rather than technical: the detection arose from a shipped default, on a date matching database creation, on hosts where no performance workflow ever existed. Say it plainly and show the parameter.
Oracle provides internal procedures that can refresh or clear feature usage data. Running anything that clears history before an audit submission is falsification, and it is not a grey area.
It also destroys your best evidence. The same rows that suggest a detection are the rows that show it happened once, five years ago, on a version you no longer run.
Forcing a fresh sample so the current period is up to date is a different act entirely and is legitimate. Keep the raw files unaltered, take a hash of each one, and record who produced it and when.
In three columns, per database, before anything is aggregated. Detected is what the sampler saw, reviewed is what survives an evidenced error class check, and entitled is what your ordering documents grant.
Only the gap between reviewed and entitled is worth a conversation. Aggregating across an estate before doing this at database level hides both the errors and the surplus.
A worked three column reconciliation for one database
| Line | Detected | Reviewed | Entitled | Basis for the review |
|---|---|---|---|---|
| Partitioning | Yes | Yes | Yes | Deliberate, in production, covered by an ordering document |
| Diagnostics Pack | Yes | No | No | Default parameter, usage dated to database creation |
| Tuning Pack | Yes | Historical only | No | One detection in 260 samples, dated, host identified |
| Advanced Compression | Yes | No | Included | FEATURE_INFO shows basic compression, included in the edition |
| Real Application Testing | Yes | No | No | Detections only on a version retired at the 19c upgrade |
| Active Data Guard | No | No | Yes | Surplus entitlement, offsets shortfall in the same family |
Note the final row. Surplus entitlement is as real as shortfall, it offsets within the same product family, and buyers almost never look for it because they are only searching for problems.
Counting rules live outside the output. The Oracle software investment guide sets out how Oracle expects deployments to be counted, and the processor core factor table converts cores into licensable processors.
Reconcile against those documents and your ordering documents, never against the dump. The dump has no opinion about your entitlement because it has never seen your contract.
With a reconciled position and documented exclusions, not with a refusal and not with the raw file. Acknowledge the collection, then answer from the reviewed column.
Write the response in that order. Concede the proven, evidence the suggested, and separate out the questions the data cannot reach.
The standard guidance is to treat the collection output as an authoritative license position and reconcile your purchases to it. We disagree. The output is a weekly sampling record, and its most important counter measures the presence of a detection in a window rather than any quantity of use. Treating it as truth hands Oracle a negotiation anchored at the worst available reading of every row. The buyer side move is to invert the burden: separate detected from reviewed from entitled, evidence each exclusion by error class, and answer only from the reviewed figure. The script is an input to a licensing conversation. It is not the conversation.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The script tells you what the database noticed. It does not tell you what you owe. Confusing the two is the most expensive reading error in an Oracle audit.
A finding is a claim, not an invoice, and it is quoted at list. The full end to end process sits in the Oracle license audit guide, and the wider library is in the Oracle knowledge hub.
It counts sample windows in which usage was detected, not individual uses. With the default weekly sampling interval, a value of 1 means the feature was noticed in exactly one week. A feature exercised once for a second and one running continuously for that week both produce the same value.
CURRENTLY_USED reports whether the feature was detected in the most recent sample only. It tells you about the last sampling window and nothing about the rest of the audit period. Oracle's own options and packs report translates the same state into a verdict of current usage or past usage.
Yes, if a license was required at the time the use occurred. Past usage is not automatically free, and arguing that it is will damage your credibility. What it does change is scope: a dated detection on an identified host is a bounded event to price, not a permanent estate wide capability.
V$OPTION reports which options are linked into the Oracle binary, not which were licensed or used. Most separately licensable options read TRUE on a default Enterprise Edition install. The chopt utility can unlink several of them, and feature usage data, not V$OPTION, is what evidences actual use.
Diagnostics and Tuning Pack usage arising from defaults. CONTROL_MANAGEMENT_PACK_ACCESS defaults to DIAGNOSTIC+TUNING on Enterprise Edition, so Automatic Workload Repository snapshots run without anyone enabling them and pack usage registers from database creation. A single console click produces the same effect.
Yes, routinely. Feature usage history lives in the data dictionary, so a database cloned or duplicated from production carries the source system's usage rows and original dates. A test database can show years of option usage that never happened on that host. Check creation dates against the earliest usage dates.
That a counter once reached a peak, with no date and no duration attached. A CPU count high water of 96 against a current value of 16 means the instance once saw a much larger host. Pair every peak with your change records so the number arrives with an explanation.
No. Clearing or resetting usage history before a submission is falsification, not defense. It also destroys the evidence that shows a detection was a single event years ago on a retired version. Keep the raw files unaltered, hash them, and record who produced each one.
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.
We sit on your side when you negotiate with the major software publishers. Independent, benchmarked, and built for the renewal in front of you.
Contact Us
