The policy that drives the exposure
The Oracle soft partitioning audit problem starts with a single published document: Oracle's partitioning policy. That document divides every method of subdividing a server into two categories. Hard partitioning is accepted as a way to limit the number of processor cores that must be licensed. Soft partitioning is not. Software that runs on a soft partitioned environment must, in Oracle's reading, be licensed for all of the physical cores in the server, and in a virtualized cluster that boundary can extend to every host the software could conceivably run on.
The financial consequence is enormous and asymmetric. A customer who assigns a database four virtual CPUs on a large cluster believes it has a four core deployment. Oracle, applying the soft partitioning rule, can count the entire cluster, which might be hundreds of cores after the relevant core factor is applied. The gap between those two numbers, multiplied by list price and back support, is where soft partitioning findings reach into the millions. The customer never deployed more software; the policy simply counts more cores.
Crucially, this exposure is invisible until it is measured. The feature usage and configuration data collected during measurement reveals the virtualization topology, and from that topology Oracle constructs the cluster wide count. That is why the partitioning question is not separable from the broader audit defence posture: the architecture decisions made years before the audit determine the size of the claim, and the audit simply reads them back.
Soft versus hard partitioning
The distinction Oracle draws is technical in form and commercial in effect. Hard partitioning, in Oracle's definition, physically binds the software to a fixed, electrically or firmware enforced subset of a machine's processors, such that the software genuinely cannot run beyond that subset. Soft partitioning, by contrast, uses software to allocate resources in a way that Oracle considers reconfigurable, and therefore not a real limit. The argument is that if an administrator could in principle move or expand the allocation, the software could run on more cores, so all the cores must be licensed.
Oracle does not license the cores you use. It licenses the cores the software could reach, and the partitioning policy decides where that reach ends.
This is why the same logical limit, four cores, is binding under one technology and worthless under another. The number assigned is identical; what differs is whether Oracle accepts the mechanism as a genuine ceiling. The result catches out customers who reasonably assume that capping a virtual machine caps the licence, and it is the single most common source of surprise in a virtualization heavy estate. Understanding the boundary in advance is the difference between an architecture that defends itself and one that hands Oracle a cluster wide claim, a theme that runs alongside the user counting exposure covered in the Named User Plus audit guide.
What counts as hard partitioning to Oracle?
Oracle's policy lists the technologies it accepts as hard partitioning, and the list is narrow. It typically includes physical hardware partitioning on certain enterprise server platforms, specific firmware level partitioning, and capped configurations on a small set of platforms where the cap is enforced below the operating system. The defining quality is that the limit is enforced at a level the customer cannot trivially reconfigure, so the software is genuinely confined.
Almost everything in the mainstream virtualization world falls outside that list. General purpose hypervisors, including the most widely deployed ones, are treated as soft partitioning, as are most container and operating system level isolation methods unless paired with an accepted capping mechanism. The practical implication is that the consolidation strategy most enterprises pursued, running many workloads on a flexible virtual estate, is precisely the strategy Oracle's policy penalises, and the larger and more flexible the cluster, the larger the potential claim. The dedicated VMware audit guide works through the most contested case in detail, including the cluster boundary arguments Oracle raises and the responses available to a customer.
It is worth stating plainly that the policy is not contractual. Oracle publishes it as guidance and states it is not binding, which means a soft partitioning claim rests on a document outside the signed agreement. That gap is the foundation of many successful challenges, because the contract, not the policy, defines what the customer actually agreed to license. Whether to lean on that argument is a judgement to make with counsel, but it is a real and frequently decisive lever.
Partitioning technologies and audit treatment
The table summarises how common technologies are typically treated. Treatment can vary with configuration and platform, so each environment should be assessed on its specifics rather than assumed from the category.
| Technology | Oracle classification | Audit counting effect |
|---|---|---|
| VMware vSphere | Soft partitioning | Claim can span the cluster or vCenter |
| General hypervisor VMs | Soft partitioning | All physical cores on reachable hosts |
| OS containers, uncapped | Soft partitioning | All cores on the host |
| Accepted firmware partitioning | Hard partitioning | Only the bound cores need licensing |
| Physically isolated hosts | Effectively limited | Only the dedicated hosts are in scope |
Defending a soft partitioned estate
Defence has two layers, architectural and contractual, and the strongest position uses both. Architecturally, the cleanest answer is segregation: place Oracle workloads on dedicated hosts or clusters that are physically separated from the rest of the estate, so the boundary of the Oracle environment is a matter of hardware fact rather than software configuration. A documented, evidenced boundary, established before any audit, converts a cluster wide argument into a host count argument and removes most of the exposure at source.
Where segregation is not feasible, the next layer is evidence and architecture documentation. If the environment uses an accepted hard partitioning method, the configuration must be documented so it can be shown to be in place and enforced. If it relies on capping or isolation that Oracle may dispute, the customer needs a clear, dated record of how the environment is built and constrained, prepared with the data discipline set out in the audit defence service. The configuration data Oracle collects will reveal the topology; the customer's own documentation is what frames it.
The contractual layer is the partitioning policy's lack of contractual force. Because the policy sits outside the signed agreement, a soft partitioning claim can be challenged as resting on guidance the customer never agreed to be bound by. This is a legal argument as much as a licensing one, best raised through counsel and aligned with the broader findings challenge, but it is frequently the lever that moves a cluster wide claim down to a defensible number. The combined effect of architecture, documentation, and the contractual challenge is what keeps a soft partitioning finding from defining the entire settlement, exactly the approach the database options audit guide applies to the parallel exposure from priced options.
Timing changes which of these layers is available. The architectural layer is strongest before an audit, because segregating Oracle onto dedicated hosts after a notice arrives looks like remediation rather than design and does not undo the historical configuration the measurement will capture. The contractual layer is available at any time, since the policy's lack of binding force does not expire. The documentation layer is strongest when it is contemporaneous, built as the environment is built rather than reconstructed under pressure. This is why the partitioning decision belongs in the architecture review, not the audit response: the cheapest defence is the cluster that was never shared, and every layer added later is working against facts already set in the configuration data.
The buyer side view
Soft partitioning is the clearest example of a rule that costs nothing in deployment and everything in counting. The customer who consolidates onto a flexible virtual estate for sound operational reasons can find that the same flexibility hands Oracle a claim spanning hundreds of cores it never used. The defence is decided years before the audit, in the architecture, and reinforced at audit time through documentation and the contractual weakness of the policy itself.
Segregate where you can, document where you cannot, and challenge the policy where the claim outruns the contract. Build the foundation with the audit defence pillar, work the most contested case through the VMware audit guide, and pair partitioning discipline with the option and user exposure covered across the database options and Named User Plus guides.
Oracle soft partitioning audit: frequently asked questions
Does VMware count as soft partitioning to Oracle?
Yes. Oracle classifies VMware as soft partitioning, which means it does not accept VMware resource limits as a way to reduce the number of cores that must be licensed. In an audit Oracle can argue that every host the virtual machine could run on, up to the boundary of the management cluster or vCenter, must be licensed.
Is the Oracle partitioning policy contractual?
No. The partitioning policy is a published document, not a clause in the standard licence agreement, and Oracle itself states it is for educational purposes and not contractually binding. That distinction is the basis on which many soft partitioning claims are contested, because a policy document does not have the force of the signed contract.
How do I limit Oracle licensing on a virtual estate?
Use a recognised hard partitioning method, physically segregate Oracle onto dedicated hosts, or architect the environment so the software demonstrably cannot run beyond a defined, evidenced boundary. Each approach must be documented before an audit so the limiting configuration is a matter of record rather than an after the fact assertion.