What do Oracle audit scripts actually collect?
Oracle audit scripts are the data collection mechanism at the heart of the measurement phase. When an audit moves past scope and into measurement, Oracle provides a set of scripts, usually a database SQL collection and a set of operating system commands, and asks you to run them against the servers in scope and return the output. Those output files are the raw evidence from which every line of the eventual finding is built, which is why the scripts deserve far more scrutiny than they usually get.
The database scripts query internal data dictionary and dynamic performance views. The most consequential of these is the feature usage tracking data, which records whether priced options and management packs such as partitioning, advanced compression, diagnostics pack, or tuning pack have ever been used, even once, even by an administrator testing a feature. The scripts also enumerate installed options, database versions and editions, instance counts, and user accounts that feed Named User Plus counting. Operating system commands capture processor counts, core counts, socket configuration, and virtualization details that drive the processor metric calculation explained in the audit defence pillar.
The important point is that these scripts are designed to be comprehensive, not minimal. They collect everything that could conceivably be relevant, and they make no distinction between a feature deliberately deployed and a feature accidentally touched. The interpretation of that raw data, separating genuine use from incidental traces, is a human judgement that happens after collection, and it is a judgement the customer should participate in rather than delegate entirely to Oracle.
Why feature usage statistics drive most findings
Of everything the scripts collect, feature usage statistics produce the largest and most contested findings. The database records a flag the first time a separately licensed feature is invoked, and it never clears that flag. A database administrator who enabled partitioning to test a migration three years ago, or who let a monitoring tool quietly use the diagnostics pack, leaves a permanent record that the script will faithfully report. Oracle then treats that single recorded use as evidence that the option requires a licence on every processor of that database.
This is where review before transmission matters most. Many recorded uses are incidental, reversible, or attributable to default tool behaviour rather than deliberate deployment, and the contractual and factual significance of each one needs to be assessed before it becomes a conceded finding. The data minimisation guide sets out the principle that you provide what the contract requires and nothing more, and feature usage data is the clearest case for examining each entry rather than forwarding the file wholesale.
| Captured data point | Oracle's default reading | The question to ask first |
|---|---|---|
| Option feature flag set | Option is in use and licensable | Was it deliberate use, a test, or default tool behaviour? |
| Management pack accessed | Pack requires licensing on all processors | Did a bundled tool trigger it without intent? |
| High core count on host | All cores licensable for the database | Is the database pinned or partitioned to fewer cores? |
| Large user account list | All accounts are Named User Plus | Are these human users, or service and batch accounts? |
Reviewing script output before transmission
The single most valuable discipline in the measurement phase is to run the scripts yourself, in a controlled environment, and review every output file before any of it reaches Oracle. This is not about altering data, which would be both wrong and detectable; it is about understanding what you are about to hand over and being ready to explain it. A customer who reads the output first can identify incidental feature flags, recognise misconfigurations that overstate deployment, and prepare the factual context that turns a raw flag into a defensible position.
The customer who reads the script output first controls the narrative. The customer who forwards it unread lets Oracle interpret silence as agreement.
Review also surfaces scope problems. Scripts are sometimes run against servers that are outside the agreed scope, or they capture data about products the audit was never supposed to reach. Reading the output against the agreed perimeter, the boundary set during the scope control phase, lets you withhold or query anything collected beyond what was agreed. The mechanics of running and interpreting the collection are part of the broader sequence covered in the LMS audit process guide.
Controlling where and how the scripts run
Control begins with who runs the scripts. The customer should always run them, never Oracle directly on customer systems, and the customer should run them on the defined in scope estate only. Running in a controlled window, with the output captured to files the customer holds first, preserves the opportunity to review before transmission. It also protects production systems, because some collection commands carry a performance cost that should be scheduled rather than imposed mid business day.
Control continues with documentation. Recording which scripts were run, against which hosts, on which date, and what version of the collection was used, creates a defensible record of exactly what was provided. If a later finding rests on data the customer never actually submitted, or on a server outside scope, that record is the evidence that resolves the dispute. For organisations that prefer this run by specialists, the Oracle audit defence service operates the collection end to end, and the audit defence white paper documents the full method.
Common mistakes when running the scripts
The most damaging mistake is the most common one: forwarding the raw output the moment the scripts finish, before anyone has read it. The collection is designed to be run and returned quickly, and an unprepared customer treats that workflow as an instruction rather than a choice. The output then arrives at Oracle complete with every incidental flag and overcounted core, and the customer first learns what it contained when the findings report quotes it back.
A second mistake is running the scripts more broadly than scope requires, sweeping in servers, instances, or environments that were never agreed to be in scope. Each extra host adds data Oracle did not need and the contract did not require, expanding exposure for no reason. Running the collection only against the perimeter agreed during the scope phase keeps the data set tight and defensible.
A third is letting different teams run different versions of the collection on different days with no record of what was done, producing an inconsistent picture that Oracle can exploit and the customer cannot reconstruct. A single coordinated run, documented host by host, removes that ambiguity. The fourth mistake is panic remediation: disabling options or deleting accounts after the notification in the hope of improving the picture, which alters evidence, looks like concealment, and rarely helps, since historical usage flags persist regardless.
Avoiding all four comes down to the same principle that governs the rest of the measurement phase, which is deliberate control rather than reflexive compliance. The customer decides what to run, where, when, and what to review before anything is sent, exactly the posture the audit defence service imposes by default.
The buyer side view
The scripts themselves are neutral; the risk lies in treating their output as a verdict rather than as raw material. Customers who settle small are the ones who ran the collection themselves, read every file, understood each feature flag and core count before it left their building, and entered the measurement conversation with context already prepared. Customers who settle large are the ones who forwarded the output unread and then spent the rest of the audit arguing against their own data.
Run the scripts, hold the output, read it line by line, and provide only what scope requires. Build the foundation with the audit defence pillar, apply the discipline in the data minimisation guide, and see how collection fits the sequence in the LMS audit process guide.
Oracle audit scripts: frequently asked questions
Should I let Oracle run audit scripts on my servers?
No. The customer should run the scripts on the in scope estate and capture the output first, never granting Oracle direct access to systems. Running the collection yourself preserves the ability to review every output file before it is transmitted and keeps the data inside the agreed scope.
Can Oracle audit scripts modify my database?
The standard measurement scripts are read only data collection, querying data dictionary and dynamic views rather than changing data. You should still review any script before running it, run it in a controlled window, and confirm it only reads the information the audit scope requires.
What is the most dangerous data the scripts collect?
Feature usage statistics. The database permanently records the first use of separately licensed options and management packs, so a single incidental or test use can appear as evidence that the option must be licensed on every processor. Each flag should be assessed for context before it is conceded.