Oracle's auditors cite DBA_FEATURE_USAGE_STATISTICS as if a nonzero count proves ongoing use, but the two key columns say different things and most of the money hides in the gap. This page shows you how to read the columns line by line, when CURRENTLY_USED=FALSE defeats a claim, and how to build a timeline that separates a one-time trigger from a live deployment.
What the two columns actually say
Per Oracle's own Database Reference, DETECTED_USAGES is the number of times the system has detected usage of a feature, and CURRENTLY_USED indicates whether usage was detected the last time the system checked (TRUE) or not (FALSE). Those are two different measurements, and Oracle auditors routinely treat them as one. DETECTED_USAGES is a cumulative counter that never decreases. CURRENTLY_USED is a snapshot of the most recent sample only. A row can show DETECTED_USAGES of 40 and CURRENTLY_USED=FALSE, which in plain terms means Oracle saw the feature at some point but did not see it at the last check.
The mechanics matter because they determine what you can prove. The view also carries TOTAL_SAMPLES (how many times the system woke up and checked), FIRST_USAGE_DATE and LAST_USAGE_DATE (the first and last sample times a hit was recorded), and two detail columns: AUX_COUNT (feature-specific numeric data such as session or user counts) and FEATURE_INFO (the same in CLOB text). The last two are where you find the configuration context that separates real use from an incidental trigger, and Oracle's preliminary findings almost never quote them. If you want the wider picture of how this view becomes a bill, start with our pillar on how DBA_FEATURE_USAGE_STATISTICS becomes an audit bill.
One structural fact carries most of the defense. Reverse-engineering the view definition shows CURRENTLY_USED is not a stored flag; it is computed by comparing LAST_USAGE_DATE against LAST_SAMPLE_DATE (berxblog, November 2015). It reads TRUE only when the most recent detection coincides with the most recent sample. That single line of logic is why a stale trigger reads FALSE, and it is the hook you use to argue that a nonzero count is history, not a live liability.
DETECTED_USAGES counts every time Oracle ever saw the feature. CURRENTLY_USED only reports the last sample. Auditors quote the first and hope you never ask about the second.
The sampling interval: why the count lies about frequency
The internal collection job runs once per week, typically on a Saturday (House of Brick, March 2026). The default SAMPLE_INTERVAL is 604,800 seconds, exactly seven days (berxx DBA_FEATURE_USAGE_STATISTICS deck, December 2019). This has two consequences that both cut in the buyer's favor when you argue them correctly.
First, a feature used heavily for six days between samples registers as a single detected usage, and a feature touched once in the sample window registers identically. DETECTED_USAGES therefore measures how many weekly samples caught the feature on, not how intensively you used it. Second, manual refreshes distort the number entirely. If a DBA forces the view to update with the DBMS_FEATURE_USAGE_INTERNAL package (Oracle-Base), the count climbs without any new real use. berxblog documented that manual refresh methods can produce a higher DETECTED_USAGES than the number of weeks between FIRST_USAGE_DATE and LAST_USAGE_DATE. When you see that arithmetic impossibility, the count is an artifact, and you say so on the record. Our note on the sampling gap and why it cuts both ways works through the missed-sample scenarios in detail.
How Oracle auditors read these columns in LMS output
In the LMS collection output, the fields the auditor works from are NAME, CURRENTLY_USED, DETECTED_USAGES, LAST_USAGE_DATE, and AUX_COUNT. The commercial danger sits precisely here: independent commentary calls DBA_FEATURE_USAGE_STATISTICS the most commercially dangerous element of the USMM output because it records every feature invoked with a first use date, last use date, and usage count (Oracle Licensing Experts, March 2026). Usage history is effectively permanent and portable. An AWR report run three years ago stays visible indefinitely, cloned test-to-prod usage migrates with the data, and Oracle uses that history to assert a compliance requirement for the entire period of detected usage (Redress Compliance, August 2025).
Two principles frame every rebuttal. Usage recorded does not always equal a license obligation, and the raw output does not declare compliance, it is data (Oracle Licensing Experts, 2025 and 2026). Oracle's opening position is a maximalist reading. From our engagement work we have seen preliminary LMS findings routinely overstate actual liability by 30 to 60 percent through double-counting, aggressive entitlement attribution, and Oracle-favorable metric interpretation. That range is our field experience across audits, not a published Oracle figure, and we flag it as such. For a broader walkthrough of the same skill applied to the whole script, see reading Oracle LMS script output line by line.
When CURRENTLY_USED=FALSE with a nonzero count is defensible
A FALSE flag against a positive count is defensible in several documented situations, and knowing which one applies changes your negotiating posture. Below are the categories we test first.
1. System-generated triggers, not user use
Oracle's feature usage statistics do a poor job of filtering false positives. Oracle Enterprise Manager triggers usage of the Partitioning Option because its own repository partitions tables, which is not the customer's responsibility to license (House of Brick, March 2026). The view often distinguishes this: a row reading Partitioning (System) reflects internal AWR use requiring no license, while Partitioning (user) implicates a license. Only the user-attributed lines support a claim. If the auditor's line item does not separate the two, it is not yet a finding. Partitioning that persists after you drop the tables is a whole category of its own, covered in why partitioning still shows as used after you drop the partitioned tables.
2. Known Oracle bugs producing permanent false flags
Bug 23734270 is the classic example. On a freshly created 12c database, DBA_FEATURE_USAGE_STATISTICS shows usage of Real-Time SQL Monitoring even if no reports have been run, because SQL Monitor reports are auto-generated and saved in AWR but should be considered system usage (dbi-services, per MOS Bug 23734270). This behavior is identical across all 12c releases and is absent in 11.2. That version boundary is a precise, checkable defensibility point: if the flagged database is 12c and the pattern matches the bug signature, the row is Oracle's defect, not your deployment.
Oracle's own report script states the output is to be used for informational purposes only and does not represent your license entitlement or requirement (MOS Doc ID 1317265.1). You quote Oracle's disclaimer back to Oracle. A tool the vendor labels informational cannot simultaneously be the sole evidence of a contractual breach.
| Signal |
One-time trigger |
Ongoing deployment |
| CURRENTLY_USED | FALSE | TRUE |
| FIRST vs LAST usage date | Same or near-same date | Spread across weeks or months |
| DETECTED_USAGES | Low, often 1 | High and consistent with the week span |
| AUX_COUNT / FEATURE_INFO | Zero or system-only detail | User sessions, real object counts |
| System vs user tag | (System) | (user) |
| Defensibility | Strong | Weak, remediate and negotiate |
A row where FIRST_USAGE_DATE equals LAST_USAGE_DATE and CURRENTLY_USED is FALSE is not a deployment. It is a fingerprint from a single event, and the dates prove it.
Building the one-time-trigger vs ongoing-use timeline
The core distinction is simple once you pair the columns. A nonzero DETECTED_USAGES tied to a single date where FIRST_USAGE_DATE equals LAST_USAGE_DATE, with CURRENTLY_USED=FALSE, points to a one-time trigger. Ongoing use shows a spread between FIRST_USAGE_DATE and LAST_USAGE_DATE plus CURRENTLY_USED=TRUE. LAST_USAGE_DATE shows when the feature was last triggered, and CURRENTLY_USED is the boolean flag for active usage (Oracle Reporting). Pairing the two is how you separate a stale trigger from live use, and it is the single most productive analysis you can run before Oracle does. The date pair method is worked through in using FIRST_USAGE_DATE and LAST_USAGE_DATE to prove a feature was touched once, not deployed.
Your timeline document should establish four things per flagged row: the date range from FIRST_USAGE_DATE to LAST_USAGE_DATE, the DETECTED_USAGES count checked against the number of weeks in that range (to expose refresh artifacts), the AUX_COUNT and FEATURE_INFO detail (to show whether any real sessions existed), and the system-versus-user tag. Where the count exceeds the available weekly samples, you state on the record that the number reflects manual refreshes, not repeated use. Where AUX_COUNT is zero or reflects only AWR internals, you state the feature was never user-deployed.
Remediation belongs on the timeline too, with dates. Disabling a feature stops CURRENTLY_USED going TRUE going forward but does not erase historical DETECTED_USAGES, so your narrative must document the remediation date explicitly. The cleanest control is CONTROL_MANAGEMENT_PACK_ACCESS, which prevents new Diagnostic and Tuning Pack findings from that date forward, covered in setting CONTROL_MANAGEMENT_PACK_ACCESS to stop pack findings going forward. Be aware that audit response windows are short, typically 30 days to resolve Oracle's findings (Spinnaker Support, February 2025), so interpreting and actioning quickly is an advantage, and running your own internal review buys time for remediation.
The money behind each flagged line
You interpret these columns carefully because the stakes per line are large. Under the 2026 list, Oracle Database Enterprise Edition is $47,500 per processor or $950 per Named User Plus (Reveal Compliance, June 2026); SE2 is $17,500 per processor or $350 per NUP (Oracle Licensing Experts, March 2026). The two most commonly flagged packs are Diagnostics at roughly $7,500 per processor ($150 per NUP) and Tuning at roughly $5,000 per processor ($100 per NUP), each carrying the standard 22 percent annual support uplift (Oracle Licensing Experts, April 2026).
- Tuning Pack requires Diagnostics Pack as a prerequisite (Atonement Licensing, May 2026), so a single Tuning line usually pulls in both, combining to roughly $12,500 per processor per year before support.
- A combined Diagnostics plus Tuning back-license claim across a 50-processor estate can reach $5.94M in licenses before three years of back support at 22 percent (Oracle Licensing Experts, April 2025).
- Independent reviews find a median $1.6M in unlicensed Diagnostics, Tuning, and Partitioning usage that LMS audits target as routine findings (Atonement Licensing, May 2026).
Because Diagnostics and Tuning drive the pack findings, know which rows in the view actually implicate them before you concede anything. The AWR and ADDM signatures that map to a real Diagnostic Pack obligation are itemized in which management pack rows actually cost you. Treat every pack row as unproven until you have paired the columns and checked the detail fields against it.
What to do before Oracle runs the script
The reader action is direct: run the feature usage query yourself first, on your own schedule, and build the timeline before an auditor imposes theirs. Extract NAME, CURRENTLY_USED, DETECTED_USAGES, TOTAL_SAMPLES, FIRST_USAGE_DATE, LAST_USAGE_DATE, AUX_COUNT, and FEATURE_INFO for every flaggable feature. Classify each row as one-time trigger, system-only, known bug, or genuine ongoing use. Apply CONTROL_MANAGEMENT_PACK_ACCESS where appropriate and record the date. Then, and only then, decide what if anything is a real obligation. The self-assessment discipline is set out in running the feature usage report yourself before Oracle's LMS script does.
The negotiating principle to hold onto: DETECTED_USAGES is a count Oracle inflates, CURRENTLY_USED is the check Oracle omits, and the date pair is the evidence Oracle hopes you never assemble. When you present the timeline, the informational-only disclaimer, and the system-versus-user distinction together, the 30 to 60 percent overstatement we see in the field collapses back toward the small number of rows that genuinely reflect user deployment. That is where the settlement should land, not at the opening figure.
Related advisory: the full topic guide.
Frequently asked questions
Does a nonzero DETECTED_USAGES mean I owe a license?
No. DETECTED_USAGES is a cumulative count of every sample that caught the feature on, including one-time triggers, system internal use, and known bugs. Usage recorded does not equal a license obligation. You have to pair it with CURRENTLY_USED, the date range, and the detail columns before it becomes a real finding.
What does CURRENTLY_USED=FALSE actually prove?
CURRENTLY_USED is computed by comparing LAST_USAGE_DATE against the most recent sample date. FALSE means the feature was not detected at the last weekly check. Combined with a FIRST_USAGE_DATE that equals LAST_USAGE_DATE, it strongly indicates a one-time trigger rather than an ongoing deployment.
How often does Oracle sample feature usage?
The internal collection job runs once per week, typically on a Saturday, with a default sample interval of 604,800 seconds (seven days). This means DETECTED_USAGES counts weekly samples that caught the feature on, not how intensively you used it, and it cannot distinguish a single week of heavy use from a single incidental touch.
Can DETECTED_USAGES be higher than the number of weeks a feature was in use?
Yes, and that is a red flag for the auditor's claim, not yours. Manual refreshes using DBMS_FEATURE_USAGE_INTERNAL can push DETECTED_USAGES above the number of weeks between FIRST_USAGE_DATE and LAST_USAGE_DATE. When the arithmetic is impossible, the count is an artifact of refreshes, and you should say so on the record.
Is the feature usage report admissible evidence in an Oracle audit?
Oracle's own script disclaims it. MOS Doc ID 1317265.1 states the report is for informational purposes only and does not represent your license entitlement or requirement. Quote that disclaimer back to Oracle. The output is raw data and an opening position, not a compliance verdict.
Does disabling a feature remove the historical usage?
No. Disabling a feature or setting CONTROL_MANAGEMENT_PACK_ACCESS stops CURRENTLY_USED going TRUE from that point forward, but it does not erase historical DETECTED_USAGES. Your defense must document the remediation date explicitly so the timeline shows use stopped, even though the historical count remains visible.
