By the time data is collected in an audit, the number is largely written. Collection captures the state of your estate as it stands, and if that estate carries options enabled by accident, virtualization configured loosely, and entitlements no one has reconciled in years, the data will faithfully report all of it as usage. Cleaning house is the work of correcting those things before they are measured, so the picture Oracle builds from reflects what you actually run rather than what accumulated by neglect.
What does cleaning house before data collection mean?
Cleaning house before data collection means reviewing and correcting your estate so the measured data reflects real deployment rather than accidental usage. It is the difference between submitting a true picture of your environment and submitting an inflated one assembled from defaults and forgotten clicks. The goal is honesty in both directions: you remove what was never genuinely used, you document what remains, and you arrive at collection with an estate that tells an accurate story.
This is housekeeping, not concealment. You are not hiding deployment. You are ensuring that things which were enabled accidentally and never operationally used do not get priced at list as though they were in production. Every correction is recorded, with its usage history kept, so the position you reach is documented and defensible rather than merely smaller.
Why does the state of the estate at collection time matter?
The state of the estate at collection time matters because the data captures that state directly, and that data fixes the baseline for the whole negotiation. Oracle's collection scripts report what they detect. They cannot tell the difference between a management pack carrying real production load and one that installed by default and was never touched. Both appear as detected usage, and the preliminary finding prices both at list.
An independent line by line review later can take such items back out, but it is far easier and far cleaner to correct the estate before measurement than to dispute the data after. A finding built on a clean estate starts small. A finding built on an uncorrected estate starts large and then has to be argued down, with every disputed line costing time and friction. The reduction is the same arithmetic either way, but the path is far smoother when the housekeeping comes first.
What should you correct before collection?
You should correct, before collection, the items that most commonly inflate a finding without reflecting real use, and each correction should be documented as you make it. The work falls into a few clear areas.
- Options and management packs: identify features enabled accidentally and never meaningfully used, disable them, and keep the usage history. A single Enterprise Manager click can register Diagnostics Pack or Tuning Pack usage, and many options install by default.
- Virtualization configuration: bound Oracle workloads to defined hosts and document the architecture, so usage is measured against what genuinely runs Oracle rather than across an entire cluster.
- Disaster recovery and failover: reconcile failover usage against the 10 day rule, which allows up to 10 separate days of running Oracle on an unlicensed failover node in a calendar year, and is contract dependent.
- Entitlement reconciliation: match deployment against the licences you actually hold, by product and metric, so the data is read against a clean inventory.
- Decommissioned and orphaned installs: remove Oracle software on systems no longer in use, so retired deployment does not count as live usage.
Ahead of a compliance review, an estate audits its own databases and finds Tuning Pack and Diagnostics Pack flagged on a dozen instances, all enabled by default and none used operationally. The team disables them, records the usage history showing no real use, and reconciles three retired servers still carrying Oracle installs. When collection runs, those items simply are not present as live usage. The opening finding never includes them, saving the slow work of disputing each one later and keeping the baseline honest from the start.
Is cleaning house legitimate?
Cleaning house is legitimate when it corrects your estate to reflect real deployment and the changes are documented honestly, because that is accuracy, not avoidance. Disabling an option that was never genuinely used, and keeping the record that shows it was never used, presents your environment truthfully. Removing Oracle software from a decommissioned server reflects the fact that it is decommissioned. None of this hides production usage, and none of it should. The line is clear: correcting what misrepresents real use is housekeeping, while concealing genuine deployment is not, and a documented, honest cleanup stays firmly on the right side of it.
When is the right time to clean house?
The right time to clean house is before any audit, as a standing practice, because an estate kept clean shows a defensible position whenever it is measured. The strongest version of this work is not a scramble during the response window but a routine: a regular internal review that disables accidental options, keeps virtualization bounded, reconciles entitlements, and removes orphaned installs as a matter of course. An estate maintained that way is ready for an audit at any moment, because its data already tells an accurate story.
Doing it during the response window still helps, and it should always be done. But the earlier the housekeeping, the stronger the record, and the less of the defensible reduction is left to argue after the fact. This is why standing compliance and audit defense reinforce each other. The rest of the data cluster builds on the same discipline: see should you run Oracle's collection tool and verified third party tooling and when it helps. The full method sits in the Oracle audit defense guide.