Somewhere in the audit request is an instruction to run a set of scripts and return the output. It is presented as routine, the procedural heart of the audit, the thing you simply do. It is in fact one of the most consequential decisions in the whole process, because what those scripts report becomes the factual basis for everything Oracle claims. Treating the data step as a formality is how defensible estates end up with indefensible findings.
Do you have to run Oracle's collection tool?
You do not automatically have to run Oracle's collection tool, because running Oracle's scripts at all is a decision, not an obligation. The audit clause in the Oracle Master Agreement governs what you are required to provide, and it generally speaks to giving Oracle reasonable access to verify usage. It does not usually compel you to execute Oracle's own tooling and submit the raw results unreviewed. The specifics are contract dependent, so the starting point is to read your own agreement and understand what it actually requires rather than what the audit letter assumes.
This does not mean refusing to cooperate. It means understanding that the method of data collection is open for discussion, and that you have a legitimate interest in how usage is measured. The scripts are one method. They are not the only method, and they are not automatically the right one for your environment.
Why does the script output matter so much?
The script output matters so much because what you submit frames the entire negotiation, fixing the factual baseline that every later argument has to work from. Once a number is in Oracle's hands as measured usage, moving it requires evidence and effort. A clean, reviewed submission starts the negotiation from solid ground. A raw, unreviewed one can hand Oracle inflated figures that you then spend the rest of the audit trying to walk back.
Preliminary findings already arrive inflated at list price. If the underlying data is also inflated, the opening number compounds two problems at once. The data step is your first and best chance to keep the baseline honest, and it is far easier to get the submission right than to dispute it after the fact.
How do Oracle's scripts overcount?
Oracle's scripts overcount mainly across virtualization layers and through options that were enabled accidentally, because the tooling reports what it detects without the context that explains it. In a virtualized estate, collection run at the wrong layer can attribute Oracle usage across hosts that never ran the workload, feeding the cluster wide claims that Oracle's partitioning policy already encourages. The result is a count far larger than the cores genuinely running Oracle.
Options and management packs are the other common overcount. A single click in Enterprise Manager can register usage of Diagnostics Pack or Tuning Pack, and many options install by default. The scripts faithfully report that detected usage, and the finding prices it at list as though it were in production. The tooling cannot tell the difference between a feature relied upon and a feature touched once by accident. Only review can.
Raw script output reports option usage on a database that, on review, was triggered by a single Enterprise Manager click during a routine check and never used again. Submitted unreviewed, it would have added a list price option line to the finding. Documented and disabled, with the usage history attached to the evidence file, it drops out of the claim entirely. The difference was one review pass before submission.
What should you do before submitting?
Before submitting, you should review every result against your entitlements, strip the double counts, and document anything that misrepresents real deployment, because the output is raw data and not a verdict. Treat the scripts as producing a draft that you verify, not a final answer you forward. The review has a clear sequence.
- Reconcile the reported usage against the licences you actually hold, product by product and metric by metric.
- Identify and remove overcounts across virtualization layers, bounding usage to the hosts that genuinely run Oracle.
- Test every detected option and pack against real usage, and document features that were enabled accidentally and never meaningfully used.
- Check failover and standby results against the disaster recovery 10 day rule, which is contract dependent.
- Record what you corrected and why, so the submission is supported by an evidence trail.
What is the buyer move on data collection?
The buyer move on data collection is to control the method, review the output, and submit only what you can stand behind, because the submission is the foundation the whole negotiation rests on. Decide deliberately whether and how Oracle's scripts are run. Review their output as carefully as you would read a contract. And submit a verified position rather than a raw export. None of this is adversarial toward Oracle. It is simply refusing to let an unreviewed tool write your opening position for you.
The next steps in the data cluster build on this discipline. See verified third party tooling and when it helps for alternatives to Oracle's own scripts, and cleaning house before data collection for the preparation that makes any submission cleaner. The full method sits in the Oracle audit defense guide.