Almost every Oracle options finding traces back to the same root cause: a priced option was switched on, nobody noticed, and time passed. The capability did its work, the licence was never bought, and the usage sat in the feature usage views accumulating into a liability that only became visible when an audit read those same views. The entire problem is one of timing. The information was always there. Nobody was looking at it. A quarterly options review is the discipline that closes that gap.
How often should you review Oracle options usage?
You should review Oracle options usage at least quarterly, reading the feature usage views across every database in the estate, because a quarterly cadence catches an unintended option within weeks of it appearing, while the context is fresh and the fix is free. The options install enabled by default, so any change, a new application, a tool, a database administrator solving a problem, a vendor patch, can quietly switch one on. Quarterly is frequent enough to catch that drift before it hardens into a standing position, and infrequent enough to be sustainable as a routine.
The cadence matters because remediation cost rises with time. An option found weeks after it was enabled can usually be turned off, the offending object rebuilt, and a clean position documented, all at no licensing cost. The same option found years later in an audit has been used continuously across that whole period, and Oracle prices the standing usage at list. Frequency is not bureaucracy here. It is the single largest lever on what an option finding eventually costs.
What does an Oracle options review check?
An Oracle options review checks the feature usage statistics for every separately licensed option and management pack, compares what is recorded as used against what the contract actually licenses, and flags any gap for investigation. The feature usage views are the authoritative source, the same data an auditor relies on, and they record each option with first and last used dates and a usage count. Reading them yourself, on every host, gives you the audit's own picture before the audit happens.
The review should cover the full priced set, not only the obvious ones. Diagnostics and Tuning Pack, where a single Enterprise Manager click can trigger usage, belong in scope alongside Partitioning, Advanced Compression, Database In Memory, Advanced Security, Real Application Clusters, and the quiet options such as Spatial. For each flagged option, the review asks three questions: is it genuinely needed, is it licensed, and if neither, can it be removed cleanly. Documenting the answers builds an entitlement record that holds up later.
An estate adopts a quarterly options review. In the first cycle it finds Tuning Pack flagged on three databases, switched on when a database administrator opened a performance screen in Enterprise Manager, and Advanced Compression on one host from a storage initiative. None were licensed. Because the usage is weeks old, the packs are disabled in Enterprise Manager, the compression is reverted to the included basic type, and each change is documented with a date and an owner. No licence is owed. Found two years later in an audit, the same four items would have been priced at list across every processor on those hosts.
How do you run the review in practice?
You run the review in practice by collecting the feature usage views from every database on a fixed quarterly date, consolidating them into one estate wide view, and triaging every priced option flag against your entitlements. Use a consistent script or process so each cycle is comparable with the last, which lets you see new usage appear rather than re examining everything from scratch. Keep the output and the decisions in a durable record, because that record is both your management tool and your evidence file if an audit ever comes.
Triage each flag into one of three buckets. Licensed and needed, where you simply confirm the entitlement covers it. Unlicensed but removable, where you remediate and document. Unlicensed and genuinely needed, where you make a deliberate decision to license it through negotiation rather than discover it through an audit. That third bucket is rare when the review runs regularly, because most accidental usage falls into the second. The discipline turns option licensing from a recurring shock into a managed line in the budget.
Why is a quarterly review cheaper than an audit?
A quarterly review is cheaper than an audit because it lets you remove an unintended option while it is still removable, so the remediation cost is zero, whereas an audit prices the same usage at list across every processor it ran on. The arithmetic is stark. An option caught early costs the time to turn it off. The identical option caught late costs a per processor licence plus back support, and arrives as an opening position you then have to negotiate down. An independent line by line review of Oracle findings typically cuts a claim 60 to 80 percent, but the cleanest reduction of all is the finding that never forms because you caught the usage first.
The review also changes the dynamic of any audit that does come. An organisation that already reads its own feature usage views meets an audit with a documented position rather than a scramble, can answer findings with records rather than guesses, and negotiates from knowledge rather than fear. The quarterly habit is both prevention and preparation at once.
The review is the standing version of the detection and dispute work an audit forces in a hurry. See detecting accidentally enabled options and disputing options enabled but never used for the deeper mechanics, and the full method in the Oracle database licensing guide.