Detecting Option Usage Before Oracle Does

Why should you detect option usage before Oracle does?

You should detect option usage before Oracle does because the same feature usage data that an audit script reports is visible to you at any time, and finding it first turns a surprise finding into a managed position. When Oracle reads your feature usage and presents a list at list price, you are reacting. When you read it first, you decide what to disable, what to document, and what to license deliberately, on your own timeline rather than under audit pressure.

The asymmetry matters because options findings arrive inflated and assume the worst. A flagged option is priced as if you relied on it across the estate, when often a feature was touched once and never depended upon. By the time an auditor presents the list, the moment to disable an unneeded option has passed and the usage is on the record. Detecting early preserves your choices, and it is the practical core of the options discipline set out in the Oracle database licensing guide.

Which feature usage views reveal option usage?

The feature usage views that reveal option usage are the database internal views that record when a feature was first and last used and how often, the same source Oracle's collection scripts query. These views track each separately licensable option and management pack, noting the dates of use and a usage count, so a single read tells you which options have ever been exercised on a given database. The data lives inside the database and updates as features are used.

Reading these views across every database in the estate gives you the complete options picture before anyone outside sees it. The detail of which views matter and how to interpret their columns is covered in feature usage data, the DBA views that matter. The important point is that this is your data, queryable today, and it is the foundation of an honest options position.

Why do options show as used when no one chose them?

Options show as used when no one chose them because many Oracle options install by default with the Enterprise Edition binary and a single click in Enterprise Manager can enable a management pack such as Diagnostics or Tuning Pack. The capability is present and active without a purchasing decision, so ordinary administration can register usage. A DBA exploring a performance screen can trip the Tuning Pack flag, and a default configuration can register an option no one intended to use.

This is why an options finding is so often disproportionate to intent. The usage is real in the sense that the feature was exercised, but it does not reflect a deliberate reliance on a paid option. Recognising that the database enables these capabilities by default, and that exercising them is easy and silent, is the context for every options dispute. The mechanics of accidental enablement are covered in detecting accidentally enabled options.

How do you separate genuine reliance from incidental flags?

You separate genuine reliance from incidental flags by reading the usage count and dates together, so a feature used once two years ago is treated differently from one used continuously across production. Reliance shows as sustained, recent, repeated usage tied to a real workload. An incidental flag shows as a single touch, an old date, or a usage pattern that matches a one off administrative action rather than an operational dependency.

This distinction is the heart of the defense, because Oracle prices a flag as full reliance at list price. Establishing that usage was incidental, when and how it occurred, and that nothing depended on it, converts an inflated claim into a small or disputable one. Where an option was genuinely never relied upon, the case is set out in disputing options enabled but never used. The work is evidentiary, and it depends on reading your own data carefully before anyone else does.

• Pull first used, last used, and usage count for every option on every database
• Flag options with sustained, recent, repeated usage as genuine reliance
• Flag single touches and old isolated dates as candidates for dispute
• Tie each genuine reliance to the workload that depends on it
• Document the circumstances of each incidental flag while the trail is fresh

How do you build an option detection routine?

You build an option detection routine by querying the feature usage views across every database on a regular schedule, recording the results, and reviewing changes so new usage is caught the day it appears rather than the day an audit lands. The routine turns a one time scramble into a standing control, and it gives you a dated record of your own position that supports any later dispute. Running it quarterly, or after any major change, keeps the picture current.

The routine also informs deliberate decisions. When detection shows an option you genuinely need, you can license it on your terms in a planned purchase rather than a settlement. When it shows an option you do not need, you can disable it cleanly and document the date. Either way you are acting from knowledge. This proactive stance is what separates a compliance program from a reaction, and it pairs with the inventory work in building your own deployment inventory. Remember that running Oracle's own collection scripts is a decision, not an obligation, so your internal detection can stay internal until you choose otherwise.

A worked example

Consider an anonymized manufacturer with thirty Enterprise Edition databases. A self run detection pass found Tuning Pack and Diagnostics Pack flagged on twelve of them, most from a single Enterprise Manager session during a past performance investigation.

The manufacturer found the usage first, disabled the packs where they were not needed, documented the incidental flags, and licensed the two databases that genuinely relied on Diagnostics Pack. Acting before any audit cut the realistic exposure by roughly 80 percent, the upper end of the 60 to 80 percent range a line by line review typically achieves, and removed the audit pressure entirely. This example is illustrative and anonymized, and outcomes depend on your estate, your contract and your evidence.

Your next step

Detecting your own option usage is the single most cost effective compliance control available, and it is most powerful before an audit rather than during one. A buyer side review can run the detection, interpret the flags, and build you a defensible options position. Our advisors work on a Fixed Fee or Gainshare basis with no risk to you, and we reduce your Oracle exposure or we reimburse our service fee.