What is the Oracle server worksheet?
The Oracle server worksheet is the workbook that consolidates the collection script output into a per server view of processors, cores, options, packs, and usage, and it becomes the raw material for the audit finding. GLAS provides measurement scripts, you run them or decline to, and their output is organised into a worksheet that lists each server with the data Oracle will price. Because the finding is built directly from this worksheet, every error in it flows straight into the number. The worksheet is not a neutral inventory. It is the document that decides how large the opening position will be.
That makes the worksheet the single most important artifact to review before anything leaves your building. Running Oracle's collection scripts at all is a decision, not an obligation, and the scripts can overcount, especially across virtualization layers. Whatever you submit, the worksheet should be checked first, because correcting it before submission is far easier than disputing a finding that has already been built on top of it.
What errors appear in the worksheet?
The common errors are cluster wide virtualization counts, default installed options read as in use, wrong core factors, and missing entitlements, and each one inflates the finding in a predictable way. These are not exotic edge cases. They are the same handful of mistakes that recur from audit to audit, because they come from the way the scripts gather data and the way the worksheet aggregates it. Knowing the pattern lets you check the right rows first.
| Error | What it inflates |
|---|---|
| Cluster wide counts | Processors counted across a whole cluster, not the hosts Oracle ran on |
| Default installed options | Packs read as in use because they install or register by default |
| Wrong core factor | Processor counts raised by a misapplied factor from the table |
| Missing entitlements | Shortfall enlarged because owned licenses are not subtracted |
How do cluster wide counts get into the worksheet?
Cluster wide counts get in because Oracle policy does not recognise VMware, Hyper V, or KVM as hard partitioning, so the worksheet can attribute a database to every core in a cluster rather than the host it ran on. A single database that lived on two cores can appear as licensable across the entire cluster, multiplying the processor count many times over. The correction is to map usage to the hosts where Oracle genuinely ran, using your own placement, vMotion, and migration records, and to hold the claim to your contract rather than the partitioning policy paper. The policy document is not the contract, and where the contract is silent or more favourable, contract language beats policy. For the full treatment, see the Oracle virtualization licensing guide.
Why do default installed options appear as in use?
Default installed options appear as in use because many Oracle Database options and management packs install by default, and a single click in Enterprise Manager can register Diagnostics Pack or Tuning Pack. The worksheet records that an option is present or has registered usage, but presence is not the same as production reliance. A feature that registered once during routine administration is materially different from a feature your business depends on. The correction separates genuine production use from incidental activation, row by row, with evidence. This is detailed work, and it reclaims a large share of an options heavy worksheet.
The worksheet is the starting point, not the verdict. Running the scripts is a decision, the output can overcount, and reviewing the worksheet before submission is the cheapest reduction available in the whole audit.
How do core factor mistakes inflate the worksheet?
Core factor mistakes inflate the worksheet when the processor calculation ignores or misapplies the factor from Oracle's published core factor table. The Processor metric multiplies physical cores by the core factor for that processor type, so applying a factor of one where a lower factor belongs, or ignoring the table entirely, raises the count before usage is even considered. The correction is to apply the correct factor for each processor type on each server. It is arithmetic, but it is arithmetic that compounds across a large estate. For the detail, read the core factor table explained.
What is the buyer move?
The buyer move is to treat the worksheet as a draft to be corrected, not a record to be submitted, and to review every row before it leaves your building. Map virtualization to the hosts Oracle ran on. Separate production option use from incidental activation. Apply the correct core factor for each processor. Subtract every entitlement you own. The corrected worksheet is the foundation of a validated position, and a line by line review built on it typically cuts the claim 60 to 80 percent. For the next steps, read detecting accidentally enabled options and counting Named User Plus correctly.
The Oracle Audit Defense Handbook includes the worksheet review checklist and the questions to ask before any script output is submitted. Free behind a work email.
FAQ
What is the Oracle server worksheet? It is the workbook that consolidates Oracle's collection script output into a per server view of processors, cores, options, and usage. It becomes the raw material for the finding, so its errors flow straight into the number.
What errors appear in it? Cluster wide virtualization counts, default installed options read as in use, wrong core factors, and missing entitlements. Each inflates the finding, and the scripts can overcount across virtualization layers.
Should I review it before submitting? Yes. Running the scripts is a decision, not an obligation, and the worksheet should be reviewed before submission so overcounts are corrected before they become the starting point for the finding.