Oracle's feature usage view is not a continuous log. It is a weekly sample, and that single design fact drives both your unexpected exposure and, when you know how to use it, your defense.
Oracle's feature usage view is not a continuous log. It is a weekly sample, and that single design fact drives both your unexpected exposure and, when you know how to use it, your defense.
Start with the fact that most buyers never learn until an audit: DBA_FEATURE_USAGE_STATISTICS (DBAFUS) is refreshed by a hidden internal job roughly once per week. It is not a real time monitor and it is not a transaction log. Oracle's own reference documentation defines the columns around a sampling model: TOTAL_SAMPLES is the number of times the system woke up and checked, DETECTED_USAGES is the number of samples in which usage was found, and CURRENTLY_USED reflects only the most recent sample. The FIRST_USAGE_DATE and LAST_USAGE_DATE fields are sample times, not event times.
That distinction is the whole article. Because the check happens weekly, anything that starts and ends inside a seven day window can be entirely invisible, and anything caught once in a sample stays in the permanent history forever. In 25 years across the table from this vendor, I have watched both sides of that coin land in the same negotiation: Oracle counting a feature it caught once, and a customer unable to prove a feature they used briefly was never deployed. The pillar page on how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill covers the mechanics end to end. This subpage isolates the sampling gap itself, because it is the least understood and the most exploitable part of the view.
The check happens weekly. Anything that starts and ends inside seven days can be invisible, and anything caught once stays in the history forever.
The exposure risk is not that the sample is too infrequent to catch you. It is that a single hit in a single sample creates a permanent, non zero DETECTED_USAGES row that Oracle treats as proof of deployment. Consider the classic drift scenario documented by advisory sources: a DBA enables Advanced Compression for a one time migration on a Tuesday and disables it Friday. Your own quarterly discovery script never sees it. But if the weekly internal job happened to wake up during that window, the feature reads as used, and it reads as used for the rest of the database's life.
Here is why that turns into six figures instead of an apology. Database options are licensed across the entire database, not just the cores that touched the feature. An option installed on a 16 processor database must be licensed for all 16 processors whether or not every core ever invoked it. So a single enable action on a large server, caught in one weekly sample, is not a small finding. It is Partitioning at $11,500 per processor times your full core count. On a 16 processor box that is $184,000 at list, plus 22 percent annual support, plus backdated support if Oracle argues historic use. Partitioning sits among the three most common audit findings for exactly this reason, alongside Diagnostics and Tuning Pack usage.
| Option | List price per processor (2026) | Exposure on a 16-proc DB (list) | Annual support at 22% |
|---|---|---|---|
| Partitioning | $11,500 | $184,000 | $40,480 |
| Advanced Compression | $11,500 | $184,000 | $40,480 |
| Advanced Security | $15,000 | $240,000 | $52,800 |
| Active Data Guard | $11,500 | $184,000 | $40,480 |
| Diagnostics Pack | $7,500 | $120,000 | $26,400 |
| Tuning Pack (requires Diagnostics) | $5,000 (+$7,500) | $200,000 combined | $44,000 |
| Multitenant | $17,500 | $280,000 | $61,600 |
| RAC | $23,000 | $368,000 | $80,960 |
Read the table as the price of one careless enable action caught in one weekly sample. The metric rule is strict: each option is priced on the same metric as the underlying Database Enterprise Edition license (currently $47,500 per processor). If Database is per processor, so is every option. The sampling gap does not reduce that math. It only decides whether the sample happened to catch the event.
Now the mirror image, and the part customers get dangerously wrong. Because CURRENTLY_USED reflects only the most recent sample, a feature that genuinely runs on a monthly cycle can read FALSE on the day you look. Buyers see FALSE, exhale, and assume they are clear. They are not. A FALSE value means the feature was not detected active at the precise moment the last sample ran. It says nothing about scope. Oracle calculates the compliance obligation on the entire period covered by non zero DETECTED_USAGES, not on the current flag. The full comparison of these two columns lives in the subpage on DETECTED_USAGES versus CURRENTLY_USED and why auditors weigh them differently.
The practical takeaway: never build a defense on CURRENTLY_USED. The history is the finding. A priced option invoked once, two years ago, still sits in the usage history with a non zero detected count, and Oracle's position holds regardless of what the current flag says. If you run your own report and see FALSE across the board, you have proven exactly one thing: nothing fired in the last sample window. That is not the same as clean.
Never build a defense on CURRENTLY_USED. A FALSE reading means one sample missed the feature, not that the feature is out of scope.
The sampling model also produces readings that overstate your liability, and this is where buyer-side leverage lives. Oracle's own options_packs_usage_statistics.sql carries an explicit disclaimer: the reports are informational only, do not represent your license entitlement, and may indicate false positives. That sentence is Oracle admitting, in writing, that its own detection is not authoritative. Use it.
The defensive posture is simple to state and hard for auditors to counter: the burden of proof for an option purchase sits with the vendor whose own tool disclaims accuracy and carries 14 known defects. When Oracle presents a finding, ask which specific trigger fired, whether that trigger is on the documented bug list, and whether the invocation is a licensable use or an included feature. Snapshot Standby is included; Far Sync requires Active Data Guard. Real Application Security is included; Real Application Testing is extra cost. Auditors count rows. Your job is to force them to prove each row is a licensable event, not a detected string.
There is a third category that neither party likes to discuss out loud. Certain feature triggers that invoke a licensable option or pack are not recorded in DBAFUS at all. So the view is neither complete nor infallible. This matters two ways. First, do not treat a clean view as a guarantee of compliance across your estate, because some licensable use never lands there. Second, and more useful in negotiation, it undermines any Oracle claim that the view is the authoritative single source of truth. It is a sample of a subset. That framing is worth rehearsing before any audit interview.
The most self-inflicted version of this is the Diagnostics Pack. Automatic Workload Repository (AWR) snapshots run by default, which silently activates the pack in more than 40 percent of enterprise databases per advisory data. Worse, the act of running an AWR or ASH report is itself a detectable event the LMS team can find. You can generate a six figure finding by troubleshooting a performance problem. The forward fix is a single parameter, covered in the guide on setting CONTROL_MANAGEMENT_PACK_ACCESS to stop Diagnostic and Tuning Pack findings going forward. Set it to NONE on any database you have not licensed for those packs, and set it before, not after, the audit notice arrives.
When TOTAL_SAMPLES is low or DETECTED_USAGES is one or two, you have the strongest possible fact pattern for a touch, not a deployment. This is where FIRST_USAGE_DATE and LAST_USAGE_DATE earn their keep. If both dates are the same, or a single sample apart, the feature was invoked once and not run as a production workload. The technique is set out in the subpage on using FIRST_USAGE_DATE and LAST_USAGE_DATE to prove a feature was touched once, not deployed. Auditors will still open with the full-price position because that is the anchor. Your response is the sample history: one detected usage, identical first and last dates, no continuity, likely a test or an accidental default.
Expect the standard auditor moves. They will argue that a single detection proves the option was installed and available, and that availability across the database is what triggers the license, not continuous use. That argument has force for options that are truly deployed. It has far less force for a one-time invocation, and it collapses entirely if the trigger is on the documented bug list. There is also a related but distinct trap: Partitioning shows as used even after you drop the partitioned tables, because the historic detection persists. When both the sparse-sample argument and the historic-persistence argument are on the table, the outcome is a negotiation, not an invoice. Treat it that way.
A single detected usage with identical first and last dates is a touch, not a deployment. Make Oracle prove otherwise, row by row.
Run the discovery yourself before Oracle does. There is no benefit to seeing your own data for the first time in an LMS draft finding. The mechanics of running it in advance are in the guide on running the feature usage report yourself before Oracle's LMS script does. Do this quarterly, not annually, because the weekly sample means drift accumulates silently between reviews.
CONTROL_MANAGEMENT_PACK_ACCESS to NONE on every database not licensed for Diagnostics or Tuning. This is the single highest-value preventive control and it costs nothing.CURRENTLY_USED alone, in either direction. TRUE is not your only exposure and FALSE is not your safe harbor.The broader context, including the six other findings that hide in the same view, is mapped in the overview of hidden Oracle audit risks. The sampling gap is the thread that runs through most of them. Understand that the view is a weekly sample of a subset, disclaimed by its own author and carrying 14 known defects, and you stop treating an Oracle finding as a fact and start treating it as an opening position. That shift is worth more in a negotiation than any script you can run.
By default, roughly once per week, driven by a hidden internal job. It is a sample, not a continuous log. You can force a refresh with the undocumented DBMS_FEATURE_USAGE_INTERNAL.EXEC_DB_USAGE_SAMPLING procedure referenced on My Oracle Support, but the standard cadence is weekly.
No. FALSE means the feature was not detected active in the most recent weekly sample. Oracle calculates the obligation on the entire period represented by non-zero DETECTED_USAGES, regardless of the current flag. A feature that runs monthly can read FALSE the day you look and still generate a finding.
Oracle's position is yes if the sample caught it, because a single detection creates a permanent non-zero DETECTED_USAGES row and options are licensed across the whole database. Your defense is FIRST_USAGE_DATE and LAST_USAGE_DATE: identical or near-identical dates indicate a touch, not a deployment, which is a negotiation, not an invoice.
Yes. Oracle's own LMS script disclaims accuracy and carries 14 documented bugs (My Oracle Support Doc ID 1309070.1). One recorded case showed over 700 false Advanced Compression usages from an unpublished bug, and RMAN default backup compression is misreported as a licensable option. Challenge every row that may be a documented false positive.
Set CONTROL_MANAGEMENT_PACK_ACCESS to NONE on any database you have not licensed for those packs. AWR snapshots run by default and silently activate the Diagnostics Pack in more than 40 percent of enterprise databases, and even running an AWR report is a detectable event. Set the parameter before an audit notice, not after.
At 2026 list prices, Partitioning or Advanced Compression at $11,500 per processor on a 16-processor database is $184,000, plus 22 percent annual support of about $40,480. Options are licensed for every core in the database, not just the cores that used the feature, so the sampling gap turns one weekly detection into a six-figure exposure.
Oracle prices Fusion ERP Cloud per employee, not per user, which inflates true cost. The buyer side guide to module economics and the modernization discount.
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.