Oracle's auditors do not guess what options you use — they query a view called DBA_FEATURE_USAGE_STATISTICS, which the database populates automatically. You can run the same query today. A feature-usage self-audit reads exactly what LMS will read, surfaces accidental activations while you still have time to remediate, and turns an audit into a confirmation exercise. This sub-guide of the Oracle Database options guide shows what to query, how to read it, and how to avoid the common false positives.
It is a self-run query of the data dictionary views that Oracle's LMS team uses to detect option and management-pack use — chiefly DBA_FEATURE_USAGE_STATISTICS and DBA_HIGH_WATER_MARK_STATISTICS. The database samples feature use roughly weekly and writes a row for each detected feature, with first- and last-usage dates and a count of detections. Running these queries yourself, on every instance, on a quarterly cadence, is the single most effective Oracle compliance control there is — because it gives you the same picture as the auditor, months earlier.
Start with the feature-usage view. This returns every feature the database has recorded, whether it is currently used, when it was first and last seen, and how many times it was detected:
For count-metered options such as Multitenant, also read the high-water-mark view, which records the peak count Oracle measured:
Run both against every instance — production, test, development, and DR — because feature use on any of them creates a licence question. A single consolidated extract across the estate is what an LMS engagement assembles; building it yourself first is the whole point. The full per-feature trigger list is in options & management packs, and engineered systems add the wrinkles covered in the Exadata guide.
We run the LMS-equivalent scripts across the whole estate and interpret every row.
Each field answers a different licensing question. Read them together — a feature with detected use but CURRENTLY_USED = FALSE and an old last-usage date is a far weaker claim than one in continuous use.
| Field | Question it answers | What to look for |
|---|---|---|
| NAME | Which option/pack? | Map to the licensable feature, not the marketing name |
| DETECTED_USAGES | How many times detected? | 1 is enough to open a claim; high counts imply continuous use |
| CURRENTLY_USED | In use now? | FALSE + old date = remediation candidate |
| FIRST_USAGE_DATE | When did it start? | Sets the earliest claim boundary |
| LAST_USAGE_DATE | When did it last occur? | Recent = live deployment; old = historical accident |
| HIGHWATER (HWM view) | Peak count? | Drives Multitenant and session-metered options |
This is where a self-audit earns its keep. The view over-reports: it flags features that are technically detected but not licensably "used," and Oracle's auditors will happily count them if you do not contest them. Knowing the common false positives is the difference between a clean position and an inflated claim.
| Reported feature | Why it can be a false positive | Action |
|---|---|---|
| Advanced Compression | Basic table compression and some backup compression are free; the view can over-flag | Confirm the compression type actually used |
| Partitioning | Sample data, Oracle-supplied schemas, or dropped tables may linger in history | Distinguish live partitioned objects from historical rows |
| Real Application Testing | Some SQL Performance Analyzer paths are detected even when not licensably used | Verify the specific feature invoked |
| Spatial | Core Spatial is free since 19c; old rows may predate that | Check version and the exact feature path |
| Diagnostic Pack (sample) | A single automated sample is not the same as ongoing operational use | Weigh detected_usages and dates together |
None of these mean "ignore the row." They mean investigate before conceding. The discipline mirrors what we apply in Oracle audit defence: every line in an LMS finding is a claim to be tested, not an entitlement to be paid.
The full query set, the false-positive reference table, and the quarterly self-audit checklist.
Quarterly, at minimum, plus after any major change — a database upgrade, a consolidation project, a new tool rollout, or an OEM patch. The reason is that the view accumulates: once a row is written it persists, so the only way to catch an accidental activation while remediation is still cheap is to look before it ages into "continuous use." Customers who run this every quarter remediate accidents in days; customers who run it once, under audit, are negotiating from a record they have never seen.
| Trigger | Why re-run | Window |
|---|---|---|
| Routine cadence | Catch slow accumulation | Every quarter |
| Database upgrade | Free-tier limits and defaults change between releases | Before and after |
| Consolidation / Multitenant | PDB high-water mark moves | At cutover |
| New monitoring/tooling | Tools silently invoke packs and options | At rollout |
| Audit notice received | Match Oracle's extract before you respond | Immediately |
A dated, estate-wide extract of feature usage; a licence-or-remediate decision recorded against every flagged feature; evidence for every false positive you have contested; and the configuration controls (such as CONTROL_MANAGEMENT_PACK_ACCESS) that prevent recurrence. That package is both your internal compliance position and your opening response if an audit letter ever arrives — and it is exactly what an LMS team cannot improve on, because it is the same data, read first.
Our Oracle practice runs the LMS-equivalent extract across your estate, contests the false positives, and builds the remediation plan — before any audit letter lands. Our Oracle audit defense team holds that line if a letter does arrive. $1.8B+ documented savings · 68% average audit-claim reduction · buyer-side only since 2016.
Weekly compliance intelligence for IT leaders.
