Oracle Soft Partitioning Licensing Rules
Soft partitioning is any technology Oracle does not accept as a way to cap the cores a database can run on. Under Oracle's partitioning policy, soft partitioning never reduces the licence requirement, so a database on a VMware cluster, KVM host, or Solaris resource pool must be licensed for every physical core it could run on, not the cores assigned to it.
Soft partitioning is the single largest source of accidental Oracle overexposure in a virtualised estate. The rule is short, the cost is large, and the gap between what an infrastructure team assumes and what Oracle requires is where audit findings are born. This article explains what soft partitioning is, why Oracle treats it the way it does, and how a buyer side estate contains the exposure. It sits directly under the database licensing pillar and pairs with the database on VMware deep dive.
What is Oracle soft partitioning?
Soft partitioning is Oracle's term for any technology that limits the processors available to its software in a way Oracle does not contractually accept for licensing. The defining characteristic is that the limit is enforced by software configuration rather than by a physical or firmware boundary Oracle recognises. Because the configuration can in principle be changed, Oracle declines to treat it as a binding cap on the cores that must be licensed.
The label matters because it decides the counting boundary. With soft partitioning, the boundary is the physical hardware, not the virtual machine. A database assigned two virtual CPUs on a host with 32 physical cores is licensed for the host, not the two vCPUs. Where the host belongs to a cluster that can migrate the workload, the boundary can extend to the whole cluster.
The partitioning policy and its status
Oracle's position on partitioning is set out in a policy document rather than in the master agreement itself. This is a critical distinction. The policy is not generally a contractual document, which means its statements are Oracle's interpretation rather than terms the customer has signed. The licence grant in the Oracle Master Agreement and the ordering document is what binds; the partitioning policy describes how Oracle would like the grant applied to virtualised environments.
The practical consequence is that the policy is a negotiating and audit position, not an automatic contractual obligation. A buyer side estate reads the actual licence grant and definitions first, then treats the policy as Oracle's claim to be tested against the contract. This contractual anchoring is the same discipline applied to the core factor table, which is also a policy document rather than a signed term.
Hard partitioning versus soft partitioning
Oracle divides partitioning into two categories. Hard partitioning is a short list of technologies Oracle accepts as binding limits on the cores that must be licensed. Soft partitioning is everything else. The distinction is binary in Oracle's policy: a technology is either on the accepted hard partitioning list or it is soft partitioning, with no middle ground.
| Category | Examples Oracle cites | Counting boundary | Reduces licences? |
|---|---|---|---|
| Hard partitioning | Physical domains, certain Oracle approved capping methods | The capped cores | Yes |
| Soft partitioning | VMware, KVM, Hyper-V, Solaris resource pools | All physical cores reachable | No |
| Oracle approved capping on OCI | OCPU shapes | Per OCPU | Cloud counting model |
The reason hard partitioning works and soft partitioning does not, in Oracle's view, is permanence. Hard partitioning methods enforce the core limit at a level Oracle treats as fixed. Soft partitioning enforces it through configuration that an administrator could change, so Oracle counts the full hardware regardless of the current setting.
Which technologies count as soft partitioning
The technologies Oracle classifies as soft partitioning include all versions of VMware vSphere, KVM, Microsoft Hyper-V, and operating system resource management features such as Solaris resource pools and processor sets when used for capping. The list is broad by design. Any mainstream x86 hypervisor falls into the soft partitioning category, which is why the typical enterprise virtualisation platform offers no licence relief for Oracle software on its own.
The most consequential of these is VMware, because it is the default platform in most enterprises and because Oracle's reading of vMotion and cluster mobility can extend the licensable boundary well beyond a single host. The detailed mechanics of that exposure, including the cluster versus host argument and the role of vCenter boundaries, are covered in the database on VMware article.
What soft partitioning costs in practice
The cost of soft partitioning is the difference between the cores assigned to a database and the cores it could reach. On a single 32 core host, a database using four cores is still licensed for 32. On a six host cluster of 32 core servers where the workload can migrate, the exposure can be 192 cores. Applying the core factor of 0.5 turns that into 96 processor licences for a workload that needs a handful of cores.
This is why a single Oracle virtual machine dropped onto a shared general purpose cluster can generate a seven figure exposure. The infrastructure team sees a small workload; Oracle sees the whole cluster. The gap is the soft partitioning rule, and it is invisible until an audit or a renewal surfaces it.
Key findings
- 1Soft partitioning never reduces the licence count. It only determines which physical cores fall inside the boundary.
- 2The partitioning policy is Oracle's interpretation, not a signed contract term. The licence grant governs.
- 3Shared virtualisation clusters create the largest exposure because workload mobility expands the boundary.
- 4Isolation, not configuration, is the lever. Dedicated hosts or clusters contain the count.
How to contain the exposure
The containment strategy is isolation rather than configuration. Because Oracle ignores soft partitioning caps, the only reliable way to limit the licensable cores is to physically restrict where the software can run. The standard approaches are a dedicated cluster reserved for Oracle workloads, dedicated hosts within a larger environment with affinity rules that Oracle accepts, or migration to a platform with an accepted hard partitioning method or to Oracle Cloud where per OCPU counting applies.
Each approach trades flexibility for cost certainty. A dedicated Oracle cluster caps the boundary at that cluster's cores but reduces consolidation. The right answer depends on the size of the estate, the consolidation pressure, and the appetite for an Oracle specific island in the data centre. Modelling the licence delta of each option before committing is the work the database licensing service brings to virtualisation decisions, and it should happen before the platform is chosen, not after the audit.
The buyer side view
The buyer side discipline on soft partitioning is to separate the contract from the policy, then engineer the environment so the licensable boundary is as small as the business will allow. Read the licence grant to establish what is actually owed, treat the partitioning policy as a claim rather than a rule, and isolate Oracle workloads so the boundary is a dedicated host or cluster rather than the whole virtual estate. Done in advance, this converts a latent seven figure exposure into a contained, defensible position. To model your own estate, see the database pillar, the database licensing white paper, or request a consultation.
Why soft partitioning drives audit findings
Soft partitioning is a favourite audit lever because the gap between assigned cores and reachable cores is almost always undocumented. When Oracle's scripts run across a virtual estate, they report the physical hardware, and the resulting count reflects every host the database could reach. The customer's records, built on assigned vCPUs, show a fraction of that. The difference becomes the audit finding, and it is large precisely because soft partitioning was assumed to cap the count when it does not.
Defending the finding is a contractual exercise rather than a technical one. The licence grant and definitions are read against Oracle's cluster boundary claim, and the actual mobility configuration is documented to limit how far the boundary can credibly extend. This is core to the audit defence practice, and it is far cheaper to prepare the documentation in advance than to assemble it under audit pressure.
Common soft partitioning mistakes
The first mistake is assuming a vCPU cap limits the licence count. It does not; only physical isolation does. The second is placing a single Oracle workload on a large shared cluster for convenience, which silently exposes every host in that cluster. The third is relying on the partitioning policy as if it were a contract term, which concedes Oracle's interpretation before it has been tested against the actual grant.
The fourth is failing to document the mobility boundary, which leaves the customer unable to argue against the widest possible reading in an audit. Avoiding these is mostly a matter of treating every Oracle placement decision as a licensing decision, isolating workloads onto a defined boundary, and keeping the configuration evidence current so the licensable count can be defended. The same discipline feeds the RAC licensing analysis, where clustered cores raise a parallel counting question.
Where the cluster boundary really sits
The fiercest soft partitioning dispute is not whether the rule applies but how far it reaches. Oracle's audit position on a mobile virtualisation platform is that any host the workload could migrate to falls inside the boundary. Where live migration is enabled across a vCenter, that reading can pull every host under management into scope, even hosts in separate clusters, if the configuration does not prevent migration between them.
The customer's counter position rests on the actual, demonstrable mobility limits. If affinity rules, separate clusters, or network and storage segregation make migration to a given host impossible, those hosts are arguably outside the boundary. The argument is only as strong as the evidence, which is why documenting the mobility configuration in advance is decisive. An estate that can show, with current configuration exports, that Oracle workloads cannot reach a given host has a defensible smaller boundary; an estate that cannot is exposed to the widest reading. This evidentiary discipline is the same one applied to the VMware scenario.
The cloud and hard partition alternatives
Two structural alternatives sidestep the soft partitioning problem rather than managing it. The first is moving the workload to Oracle Cloud Infrastructure, where capacity is counted per OCPU and the soft partitioning rule does not apply at all. A small workload that would be exposed to a whole cluster on premise is counted only on its OCPU shape in the cloud, which can transform the economics for lightly used databases.
The second is adopting a hard partitioning method Oracle accepts, which caps the licensable cores at a boundary Oracle treats as binding. This is viable on platforms that support an approved capping technology, and it converts the soft partitioning exposure into a fixed, defensible count. Both alternatives trade some flexibility or platform choice for cost certainty, and the right one depends on the estate's cloud strategy and hardware. Modelling them against the on premise soft partitioning exposure is part of the database licensing service, and it should precede any large virtualisation consolidation.
The counterpart to these rules is the bounded approach set out in the guide to hard partitioning and approved technologies, which is the only way to limit the licensable cores on a partitioned server.
Common questions.
What is Oracle soft partitioning?
Soft partitioning is any virtualisation or resource management technology that Oracle does not recognise as a way to limit the processors available to its software. Examples include VMware, KVM, Microsoft Hyper-V, and Solaris resource pools. Under the policy, soft partitioning does not reduce the licence requirement, so the database must be licensed for all physical cores it could run on.
Does soft partitioning reduce Oracle licence cost?
No. Soft partitioning never reduces the licence requirement. Oracle requires every physical core in the server or cluster where the software could run to be licensed, regardless of how few cores are assigned to the virtual machine. Only hard partitioning, which Oracle lists explicitly, can cap the count.
Is VMware soft partitioning?
Yes. Oracle treats all versions of VMware as soft partitioning. The practical consequence is that Oracle's published position requires licensing of every host the virtual machine could run on, and in many readings every host in the vCenter or cluster, which is why VMware deployments are a frequent audit target.
How do I license a database under soft partitioning?
Count every physical core in the server or cluster where the database could execute, apply the core factor, and license that total. To reduce the count, isolate Oracle workloads onto dedicated hosts or clusters, or use a hard partitioning method Oracle accepts, so the licensable boundary is contained rather than the whole virtual estate.