The two sample-date columns in DBA_FEATURE_USAGE_STATISTICS are the single best evidence a buyer has that an option fired during a patch rather than ran in production. This is how to read them, and how to turn the dates into a defense narrative before Oracle does the arithmetic.
The two sample-date columns in DBA_FEATURE_USAGE_STATISTICS are the single best evidence a buyer has that an option fired during a patch rather than ran in production. This is how to read them, and how to turn the dates into a defense narrative before Oracle does the arithmetic.
When Oracle's LMS script (the tool now branded as the Global Licensing and Advisory Services collection) lands on your database, the first thing it harvests is DBA_FEATURE_USAGE_STATISTICS. If a row for Partitioning, Advanced Compression, or Diagnostics Pack shows DETECTED_USAGES > 0, Oracle treats that as a license requirement and starts calculating back charges. In 25 years of arguing these positions I have watched the same fight repeat: Oracle reads any detection as deployment, and the buyer has one narrow window to prove otherwise. That window is the pair of date columns, FIRST_USAGE_DATE and LAST_USAGE_DATE.
The distinction matters in dollars. A single Partitioning enablement on a 16-core server can create a six-figure gap because the option is licensed across the whole database on core count, not on how many partitioned tables you actually run. The difference between a feature that was touched once and a feature that was deployed is the difference between a documented defense and a settlement check. This page shows how to read the dates, where the false positives hide, and what to write down before the auditor arrives.
The view samples feature usage on a schedule and stamps two timestamps. FIRST_USAGE_DATE is the first sample interval in which the system detected the feature. LAST_USAGE_DATE is the most recent sample interval in which it detected the feature. Neither column records the literal moment a feature ran. Both record the sample window that caught it. That sampling behavior is the entire basis of the argument you are about to build.
By default the view refreshes about once per week. So the dates are not continuous. They are snapshots taken roughly every seven days. Two more columns complete the picture. DETECTED_USAGES is the number of sample windows in which usage was found, and TOTAL_SAMPLES is the number of times the sampling job woke up and checked at all. CURRENTLY_USED reflects only the most recent sample. Our companion analysis of DETECTED_USAGES versus CURRENTLY_USED covers why auditors weigh those two very differently.
| Column | What it records | Why it matters to defense |
|---|---|---|
| FIRST_USAGE_DATE | First sample window that detected the feature | Sets the start date Oracle back-charges from |
| LAST_USAGE_DATE | Most recent sample window that detected it | Shows whether use is ongoing or stopped |
| DETECTED_USAGES | Count of sample windows with a hit | 1 hit = single trigger candidate |
| TOTAL_SAMPLES | Count of times the job checked at all | Denominator for the ratio argument |
| CURRENTLY_USED | True/false for the last sample only | Proves current non-use if false |
The underlying data lives in three base tables the view joins: wri$_dbu_usage_sample, wri$_dbu_feature_usage, and wri$_dbu_feature_metadata. You do not need to query those directly, but knowing they exist tells you the record is durable. Once an enabled feature is used, Oracle keeps a permanent record, and there is no runtime warning when you cross into unlicensed territory. Nothing stops the trigger, and nothing tells the DBA it happened.
Here is the pattern that wins arguments. A row where DETECTED_USAGES = 1, and FIRST_USAGE_DATE equals or is within one weekly sample of LAST_USAGE_DATE, points to a one-time trigger rather than sustained production use. If the feature had been running in production, the weekly sampler would have caught it repeatedly, and DETECTED_USAGES would climb week after week while the two dates spread apart. A single detection with coincident dates is the mathematical fingerprint of an accidental fire during an install, a patch, or a one-off DBA action.
One detection, two matching dates, and a patch window that lines up. That is not deployment. That is a fingerprint, and it belongs in your evidence file before Oracle ever queries the view.
Oracle's own defensive practitioners have said publicly that the deficiencies customers actually pay for involve usage that persists longer than roughly one month. The implication cuts your way. Usage confined to a single sample window, or to the days surrounding an upgrade, is materially more defensible than usage that shows a sustained curve. When you can put the trigger date beside the change ticket for a patch or a database creation script, you have converted a raw detection into a narrative Oracle has to answer.
Do not treat these columns as trivia. FIRST_USAGE_DATE is the number Oracle plugs into its claim. It tells the auditor how far back the usage goes, and Oracle calculates back-support charges from that date. If a feature first appears three years ago, Oracle's opening claim covers three years of license fees plus three years of support at 22 percent. Move the effective start date, and you move the size of the check.
Quantify what one row can cost. At 2026 list, Partitioning is $11,500 per processor, Advanced Compression $11,500 per processor ($230 per NUP), Multitenant $17,500 per processor ($350 per NUP), and the broader option band (Diagnostics Pack, Tuning Pack, RAC, In-Memory, Advanced Security, Real Application Testing, GoldenGate, Active Data Guard) runs $7,500 to $23,000 per processor. On a 16-core Intel server (a factor of 0.5, so 8 processor licenses), a single Partitioning row lists at roughly $92,000 in license plus about $20,240 in annual support, before the back-support multiplier. For a full pillar view of how a detection turns into a bill, see how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill.
| Option (2026 list) | Per processor | 16-core server (8 proc) | Annual support (22%) |
|---|---|---|---|
| Partitioning | $11,500 | $92,000 | $20,240 |
| Advanced Compression | $11,500 | $92,000 | $20,240 |
| Multitenant | $17,500 | $140,000 | $30,800 |
| Diagnostics Pack (mid-band) | ~$7,500 | $60,000 | $13,200 |
| RAC | $23,000 | $184,000 | $40,480 |
These are list figures, not entitlements. The report Oracle runs is explicitly informational and does not represent your license requirement (per My Oracle Support Doc ID 1317265.1). That disclaimer is your opening: a detection is a question, not a verdict, and the date columns are how you answer it.
Before you concede a single row, test it for known defects. Oracle's own options_packs_usage_statistics.sql carries 14 documented bugs (My Oracle Support Doc ID 1309070.1) plus undocumented ones. The report also warns that usage data may show false positives from sample schemas (HR, PM, SH) or from system and internal activity. Two examples recur in practice:
For each disputed row, ask three questions: does a documented bug explain it, does the owning schema make it a false positive, and is the sample data even current. Any one of those can knock a row out entirely, and it does so before you ever have to argue about deployment versus trigger. Our note on the sampling gap explains why the same weekly cadence that helps you here can also hide real usage, and why that cuts both ways.
Raw dates do not defend you. A documented story does. The accidental-enablement defense is recognized practice: where an option was enabled by accident, you disable it and document that it was never intentionally used. Oracle may still count it in its opening position, but you have a story to tell, and stories move settlements when leverage is otherwise thin. Assemble the file in this order:
Oracle keeps a permanent record with no runtime warning. If you do not preserve your own dated snapshot the day the audit letter arrives, you are arguing against Oracle's numbers with none of your own.
Two cautions on the narrative. First, non-production does not automatically clear you. If a feature fired only in a dev or test instance, Oracle may still bill unless your contract carries an explicit non-production exclusion. Check the agreement before you lean on that argument. Second, run the report yourself first. You want to know every detected row and its dates before Oracle's script does, so you are never surprised in a live audit. Our guidance on running the feature usage report before the LMS script walks through that discipline.
Defense is reconstruction. Prevention is control. For Diagnostics and Tuning Pack specifically, the packs fire the moment someone opens an AWR report, ADDM, ASH, or the SQL Tuning Advisor, and Oracle's LMS query targets exactly those feature names. Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE to stop those findings going forward, as covered in our piece on suppressing Diagnostic and Tuning Pack access. It closes the most common accidental-enablement path with a single parameter.
For the harder options, remember that some detections stick even after remediation. Partitioning famously continues to show as used after you drop the partitioned tables, which is why the date columns matter so much: they let you prove the objects existed only briefly. Read why Partitioning usage stays after objects are removed for that specific trap. And know which pack rows actually carry a price before you panic over any single line; our breakdown of which management pack rows cost you separates the billable signatures from the noise.
If a letter has already arrived, sequence matters more than argument. Preserve evidence, control scope, and refuse to run Oracle's scripts on their timeline. Our Oracle audit response playbook and the first 48 hours after an audit letter set out the containment steps. The date columns are one lever inside a larger negotiation, not a magic exoneration.
Do not wait for the letter. Query the view now, export every row with a non-zero detection, and file the dated evidence with your change records while the tickets are still fresh. Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on any instance without a Diagnostics or Tuning Pack entitlement. Test each detected row against the documented bug list and the sample-schema exclusions before you accept it as real. Confirm your contract's non-production language. When you can walk into an audit with a one-page memo per feature (single detection, matching dates, patch ticket attached, remediation confirmed), you have moved the argument from Oracle's arithmetic to your evidence, and that is where buyer leverage lives.
No. It is strong evidence of a single trigger rather than production deployment, but Oracle may still include the row in its opening claim. The dates plus a matching change ticket and a documented remediation give you a defensible narrative, which is what moves the settlement, not an automatic exoneration.
By default the view updates about once per week. You can force a refresh with EXEC DBMS_FEATURE_USAGE_INTERNAL.exec_db_usage_sampling(SYSDATE). Forcing a refresh after you disable a feature lets you capture CURRENTLY_USED as false, which documents current non-use for your evidence file.
Yes. Oracle calculates back license fees and back support at 22 percent from FIRST_USAGE_DATE. If the feature first appears three years ago, the opening claim covers three years of both. This is why the date column is the number to scrutinize and, where a false positive or stale sample applies, to challenge.
Yes. Oracle's own usage script has 14 documented bugs (Doc ID 1309070.1). A classic case is Bug 16088534, where RMAN default BZIP2 backup compression is reported as Advanced Compression even though it is free with Enterprise Edition. Sample schemas (HR, PM, SH) and stale LAST_SAMPLE_DATE values also produce misleading rows.
Not automatically. Oracle may still bill for non-production use unless your contract includes explicit non-production exclusions. Check the agreement language before relying on this argument, and preserve the dated evidence either way.
Yes. Running the feature usage report yourself surfaces every detected row and its dates before the LMS script does, so nothing surprises you in a live audit. It also gives you time to remediate, document trigger events, and preserve dated snapshots while change records are still current.
The separately-licensed options and packs that ship enabled by default, get switched on with a single click, and become the single largest line item in most Oracle audit findings.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
