What is Oracle feature usage data?
Oracle feature usage data is the database's own record of which features and options have been exercised, captured in the DBA feature usage views and surfaced by the collection scripts during an audit. For each feature, the views hold a first usage date, a last usage date and a detected usage count, which together form the evidence an audit uses to claim that a licensable option was in use. The data is factual as far as it goes, but it answers only one question, whether a feature was ever touched, and not the question that matters for licensing, whether it was put to genuine productive use. The wider data discipline sits in the Oracle Audit Defense Guide.
Why does feature usage data flag options you never used?
Feature usage data flags options you never used because many database options install by default and a single click in Enterprise Manager can register a management pack such as Diagnostics Pack or Tuning Pack. The view records the event, and from that moment the feature shows a usage date and a detected count, regardless of whether anyone relied on it for daily work. This is the mechanism behind one of the classic audit findings, options enabled accidentally, and it is why a usage flag is the start of a question rather than the end of one.
Read every flag in context. A first and last usage date that are the same, with a detected count of one, points to an accidental click, not a feature your business depends on. Document that distinction for each flagged item.
How should a DBA read feature usage before an audit?
A DBA should read feature usage by working through each flagged feature and recording the first usage date, the last usage date, the detected count and the operational context, then reconciling that against the entitlements and the contract. The dates tell you whether usage was a one off or a pattern. The count tells you whether the feature ran once or ran constantly. The context tells you whether a dependent workload exists. Together they let you classify every flag as genuine use, accidental activation or test only, which is the classification that drives the negotiation.
| What the view shows | What it suggests | How to read it |
|---|---|---|
| First date equals last date | A single event | Likely accidental, document it |
| Low detected count | Rare or one off use | Check for a dependent workload |
| Usage only in test | Non production activity | Separate test from production |
| Sustained high count | Genuine reliance | Confirm entitlement coverage |
Why does context change the licensing position?
Context changes the licensing position because the licence question is about productive use, not about whether a flag exists, and only context distinguishes the two. A feature that was clicked once during a routine administrative task and never touched again is a very different fact from a feature woven into nightly processing. Oracle reads the flag, you read the context, and the difference between those readings is where a finding shrinks. This is the same discipline that drives the wider line by line review, which typically reduces a claim by 60 to 80 percent. See how the options argument is built in disputing options enabled but never used and how the cores are counted in counting processors correctly with core factors.
What is the next step?
The next step is to have your feature usage data read by someone who knows the difference between a flag and a finding before any of it reaches Oracle. The views are precise about what was touched and silent about what it means, and the meaning is where the money is. Book a strategy call and we will read your feature usage views with you and classify every flag before it becomes a number.
Have feature usage flags to interpret? Book a Strategy Call and we will classify every one, or read the full method in the Oracle Audit Defense Guide.