Five Oracle Database Audit Findings Every CIO Sees

Across hundreds of Oracle Database audits the findings are remarkably consistent, because the same handful of structural traps catch estate after estate. For a CIO, the value of knowing them in advance is that every one is preventable with a control that costs far less than the finding it avoids. This article walks through the five findings that appear in nearly every audit, why each happens, and how to close it before a notice arrives. It sits under the database licensing pillar and draws on the mechanics in the options audit guide.

Why the same findings recur

Oracle licensing rewards complexity with cost, and the five recurring findings all live at points where ordinary technical activity quietly crosses a commercial line. None of them requires negligence; they happen to well run estates because the licensing consequence of a routine action is invisible at the moment the action is taken. The auditor's advantage is that the database records the evidence whether or not anyone was watching.

Because the findings are structural rather than accidental, the defence is structural too: a set of standing controls that watch the specific places where these crossings happen. An estate that installs those controls converts the recurring findings into non events.

Finding one: unlicensed options and packs

The single most common finding is usage of priced options and management packs that were never bought. Partitioning enabled to manage a large table, the Diagnostics or Tuning packs accessed through a performance screen, Advanced Compression triggered by a backup setting, Advanced Security used for encryption: each is easy to switch on and each is licensed across the full core count of the database. The detection mechanism is the feature usage statistics views, which record every use permanently.

The control is continuous monitoring of those views against the entitlements actually held, so any new usage is caught and either licensed or stopped immediately rather than accumulating silently until an audit reads the same views. This is the heart of the options audit discipline.

Finding two: virtualisation overcounting

The largest findings by value come from virtualisation. Oracle's position is that its software must be licensed for every core it could run on, and on VMware that means every physical core across all hosts within reach of vMotion, not merely the cores where Oracle is currently running. A modest Oracle footprint on a large shared cluster can therefore be assessed against the entire cluster, as set out in the VMware licensing guide.

The control is hard isolation that Oracle accepts: dedicated clusters for Oracle workloads, or a partitioning approach Oracle recognises, so the countable boundary is small and defined. Mixing Oracle into a general purpose cluster without isolation is the configuration that produces the headline finding.

Finding three: Named User Plus shortfalls

Named User Plus carries a minimum of twenty five Named Users Plus per Processor for Enterprise Edition, so a database on a high core count must be licensed to that minimum however few people use it. Estates that pick the Named User Plus metric for a low user database, then license to the real user count, fall below the minimum and the gap is a finding. The arithmetic is set out in the Named User Plus minimums article.

The control is to compute the per Processor minimum for every Named User Plus database and license to whichever is higher, the real user count or the minimum, and to revisit the calculation whenever the core count changes through a hardware refresh.

Finding four: unlicensed standby databases

Disaster recovery standbys are routinely left unlicensed because estates treat the second copy as protected infrastructure rather than a running database. But a standby with Oracle installed and an instance applying redo is fully licensable for its cores, and the ten day failover rule does not cover a continuously running standby, only a genuine cold spare. The detail is in the Data Guard licensing guide.

The control is to license every running standby on its own cores from the outset and to keep standbys mounted rather than open unless Active Data Guard has been deliberately bought, so the disaster recovery footprint is fully and knowingly entitled.

Finding five: historical feature usage

The most frustrating finding is feature usage that no longer exists. The feature usage statistics views record first and last usage dates that survive after a feature is disabled, so a single use of an option two years ago still appears in the history and can support a claim for the period it ran. Switching the feature off stops accrual but does not erase the record.

The control is proactive: review the usage history on every database, document any historical usage with its context, and where a one off use occurred, establish the facts before an auditor frames them. Reconstructing this history under audit defence is far harder than recording it in advance.

The five findings at a glance

The buyer side view

The buyer side position is that audit findings are not bad luck but the predictable output of missing controls. Each of the five has a known cause and a known countermeasure, and installing those countermeasures as standing controls costs a fraction of any single finding. Monitor option usage, isolate Oracle from shared clusters, license to the Named User Plus minimum, entitle every standby, and review feature usage history before an auditor does. An estate that runs these controls meets an audit with nothing to find. Start with the database pillar, operationalise the controls with the database licensing service, and where a notice has already arrived engage a consultation. For a related scenario, see counting processor cores correctly.