Reviewing Oracle Script Output Before Submission

You review Oracle script output before submission because the collection scripts can overcount across virtualization layers, and what you submit frames the whole audit, so reconciling it against your entitlements first protects the finding.

Why review the output at all?

You review the output because raw script results become the foundation of the preliminary finding, and the preliminary finding arrives inflated at list price. Once data leaves the building it is hard to walk back. Reviewing it first means the opening number is built on accurate, reconciled measurements rather than on the worst case the raw output would otherwise support.

Oracle audits run through GLAS, formerly LMS, under the audit clause in the Oracle Master Agreement, with a 30 to 45 day response window. The review of script output happens inside that window and is part of a controlled response, not an optional extra.

Where do the scripts overcount?

The scripts overcount most often across virtualization layers, where they can read an environment as if Oracle could run on every host in a cluster. Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, and that view can inflate processor counts dramatically. Options are another hot spot, because many install by default and a single Enterprise Manager click can flag Diagnostics or Tuning Pack as used when the business never relied on them.

Is running the scripts even required?

Running Oracle's scripts is a decision, not an obligation. You choose which hosts are measured, and you choose to review the results before anything is submitted. Treating the scripts as something that must be run everywhere on demand hands Oracle the broadest possible reading of your estate. Treating them as one input that you control keeps the measurement bounded to the agreed scope.

How do you reconcile the output?

You reconcile the output by mapping every measured program against your entitlements and your current estate. Decommissioned hosts come out. Cluster wide processor counts are reduced to the hosts Oracle actually runs on and tested against the contract. Option flags are checked against real usage. Named User Plus figures are recounted against the real population. The reconciled view is the one that supports a defensible number rather than an inflated one.

Why does submitted data frame the audit?

Submitted data frames the audit because the negotiation that follows is anchored to it. A reconciled submission gives Oracle an accurate starting point and gives you a documented basis to defend each line. A raw submission gives Oracle the largest defensible number and forces you to argue every figure back down from a worse position. The review is therefore where much of the eventual reduction is decided, before any line by line dispute begins.

A worked example

Consider an anonymized insurance firm asked to run scripts across a mixed VMware and physical estate. The raw output read the entire cluster as licensable and flagged two management packs. Before submission, the team mapped processors to the hosts Oracle actually ran on, removed decommissioned servers, and confirmed the packs had never been used. The reconciled submission was far smaller than the raw output, and the eventual finding started from that defensible base. No client names, sector level example only.

The buyer moves, in order

Reviewing script output before submission follows a clear order: decide which hosts are measured, run collection only within the agreed scope, reconcile every line against entitlements and the current estate, test virtualization counts against the contract, and submit only the reconciled view. Done in sequence, these moves keep the audit anchored to accurate data.

Where to go next

This piece links up to the Oracle Audit Defense Guide. Keep reading across the cluster: