Hard partitioning is the only Oracle-approved method to licence a subset of a server cores instead of the entire machine. This guide covers every approved technology, configuration requirements, common mistakes that invalidate compliance, audit evidence standards, and real-world examples of enterprises saving hundreds of thousands in Oracle licensing.
This article is part of the Oracle Licensing in Virtualised Environments pillar series. Related guides include Hard vs. Soft Partitioning Cost Impact, Oracle Licensing on Hyper-V, and Partitioning Policy vs. Contract Terms.
Hard partitioning physically segments a server CPU resources so that a defined, fixed subset is dedicated to Oracle software. Unlike soft partitioning, where virtualisation technologies can dynamically redistribute resources, hard partitioning creates immovable boundaries that Oracle accepts as the licensing scope. You licence only the cores inside the partition, not the entire physical server.
For enterprises running Oracle on large multi-core servers, the financial impact is enormous. Without hard partitioning, Oracle requires licensing every core in the physical server or cluster where Oracle is installed, even if Oracle uses only a fraction of those cores. Hard partitioning is the only Oracle-recognised method to avoid this full-server licensing requirement in virtualised or partitioned environments.
Licence only the cores in the partition, not the full server. On a 32-core server with an 8-core partition, you licence 8 cores instead of 32. That is a 75% reduction.
Oracle-approved hard partitioning creates a defensible licensing position. During audits, documented partition configurations serve as evidence of compliance.
Hard partitions are static. Oracle workloads cannot accidentally consume more cores than allocated, keeping licence requirements predictable and stable.
VMware is classified as soft partitioning regardless of configuration. No VMware CPU affinity, reservation, or limit setting is accepted by Oracle as hard partitioning.
"The difference between hard partitioning and soft partitioning is not a technicality. It is the difference between licensing 8 cores and licensing 128 cores on the same server. In every major Oracle audit we have supported, the partitioning classification of virtualised environments is the single largest source of compliance exposure and unexpected cost."
Redress Compliance Oracle Advisory Team
Oracle maintains an explicit list of technologies it classifies as hard partitioning. Only these methods allow sub-capacity licensing. Using any technology not on this list, regardless of how restrictively you configure it, means Oracle will require licensing of the entire physical server or cluster.
| Technology | Platform | Key Configuration Requirement | Accepted |
|---|---|---|---|
| Oracle VM (OVM) with CPU Pinning | x86 (Oracle Linux) | VMs must be pinned to specific physical cores. CPU affinity must be fixed and persistent. | Approved |
| Oracle Linux KVM with CPU Pinning | x86 (Oracle Linux) | vCPUs must be pinned to specific host cores using libvirt/virsh configuration. | Approved |
| IBM LPAR (Capped Mode) | IBM Power (AIX, Linux) | LPAR must be configured with a hard cap on processing units. Uncapped LPARs are NOT accepted. | Approved |
| Solaris Zones (Capped) | Oracle Solaris (SPARC, x86) | Zone must be configured as capped-cpu with a fixed number of dedicated CPUs. | Approved |
| Physical Domains (PDoms) | SPARC (T-series, M-series) | Hardware-level domain isolation. Each domain operates as an independent physical partition. | Approved |
| HPE nPartition (nPar) | HPE Integrity / Superdome | Firmware-level partition. Each nPar is electrically isolated at the cell board level. | Approved |
| Fujitsu PPAR | Fujitsu SPARC / PRIMEQUEST | Processor partitioning with hardware isolation and capped CPU allocation. | Approved |
| VMware vSphere (all versions) | x86 | No configuration is accepted. CPU affinity, reservations, limits, and resource pools are all classified as soft partitioning. | NOT Approved |
Critical distinction. Oracle partitioning policy is a unilateral policy document, not a contractual term. It is not part of your licence agreement. However, Oracle LMS enforces it during audits, and most enterprises comply with it to maintain a defensible position. If you believe your contract terms differ from the policy, consult independent licensing advisers. See our guide on Partitioning Policy vs. Contract Terms.
Using an approved technology is necessary but not sufficient. Oracle will only accept the partitioning if the configuration meets specific criteria. A poorly configured approved technology is treated the same as an unapproved technology: full server licensing.
Every partition must have a fixed maximum number of CPU cores that cannot be exceeded under any circumstances. For IBM LPARs, this means capped mode with maximum processing units defined. For OVM, this means CPU pinning to specific physical cores. Soft limits, resource pools, and priority settings are not sufficient. The partition must be physically or logically incapable of exceeding the defined core count.
Partition settings must survive server restarts, firmware updates, and maintenance windows. If a reboot resets the CPU pinning or uncaps an LPAR, the server runs at full capacity until the configuration is restored, and Oracle can claim you needed full licensing for that period. Automate configuration enforcement and validate settings after every restart event.
If you use Oracle VM with CPU pinning, the VM must not migrate to a host where it is not identically pinned. Live migration to an unpinned host invalidates the hard partitioning for the entire period the VM ran unpinned. Disable live migration for Oracle VMs, or ensure every potential target host has identical pinning configurations.
Maintain a licence evidence binder for every Oracle deployment that relies on hard partitioning. Include configuration screenshots from the management console, command-line output showing CPU allocation (lparstat for IBM, virsh vcpupin for KVM), hostnames, partition names, core counts, and timestamps. Update this documentation after every change.
Restrict the ability to modify partition settings to a small number of authorised personnel. If an operations administrator increases an LPAR CPU cap to resolve a performance issue, even temporarily, the licensing position changes immediately. Implement role-based access controls and change management approvals for any modification to Oracle-related partition configurations.
Situation. A financial services company ran Oracle Database Enterprise Edition on a 32-core SPARC server (core factor 0.5). Without partitioning, the full server required 16 Processor licences at $47,500 each, totalling $760,000 in licences plus $167,000 per year in support.
Implementation. The company configured a capped Solaris Zone dedicated to Oracle, limited to 8 physical cores. The remaining 24 cores ran non-Oracle workloads. Oracle core factor of 0.5 applied to the 8-core zone, requiring only 4 Processor licences.
Result. Licence cost: 4 x $47,500 = $190,000. Annual support: $41,800. Total savings: $570,000 in licences plus $125,200 per year in ongoing support. A 75% reduction.
Audit outcome. During a subsequent Oracle audit, the company provided Solaris Zone configuration documentation showing the capped CPU allocation and usage logs confirming Oracle never exceeded the 8-core boundary. Oracle accepted the partitioning with no findings.
A healthcare organisation ran Oracle Database EE on an IBM Power9 server with 32 cores (core factor 1.0 for Power architecture). Full-server licensing would require 32 Processor licences totalling $1,520,000. By creating a capped LPAR limited to 12 cores, the organisation licensed only 12 Processors at $570,000, saving $950,000 in licence cost. The capped LPAR was documented via HMC (Hardware Management Console) screenshots and lparstat -i output showing the entitled capacity ceiling. At audit, Oracle accepted the configuration without challenge.
Even well-intentioned implementations can fail Oracle scrutiny. These are the most frequent errors that negate the licensing benefit of hard partitioning.
Critical Mistake: Using VMware as Hard Partitioning. No VMware configuration is accepted by Oracle as hard partitioning. This is the single most common and most expensive audit finding. Enterprises running Oracle on VMware must licence every core in the VMware cluster, not just the cores assigned to Oracle VMs.
Critical Mistake: Uncapped IBM LPARs. An IBM LPAR configured in uncapped mode can dynamically borrow additional processing capacity. Oracle treats uncapped LPARs as soft partitioning, requiring licensing of the entire physical server. Always verify that Oracle-hosting LPARs are in capped mode with a hard maximum.
Costly Mistake: Temporary Cap Removal. Increasing a partition CPU allocation, even briefly for performance troubleshooting, creates compliance exposure for the entire period the cap was removed. Oracle audits examine historical configurations, not just the current state.
Additional pitfalls include: failing to pin CPUs on Oracle VM (configuring the VM without CPU affinity renders it soft-partitioned), allowing Oracle VMs to live-migrate to unpinned hosts, assuming memory or socket restrictions satisfy Oracle requirements (only CPU core restrictions count), and neglecting to maintain documentation after the initial setup.
Oracle LMS will examine your partitioning configuration in detail during an audit. The burden of proof is on you. Oracle assumes full-server licensing unless you demonstrate otherwise.
Confirm the partitioning technology is on Oracle approved list with version number.
Management console views showing partition definitions, CPU allocations, and cap settings.
Output from system commands confirming CPU boundaries (lparstat, virsh vcpupin, zonecfg info).
Timestamped records showing partition configuration consistent over the audit period. If changes occurred, document them with dates and reasons.
Evidence that partition modifications follow a controlled process with licensing impact assessment.
For OVM/KVM environments, documentation showing Oracle VMs are restricted from migrating to unpinned hosts.
CPU utilisation data confirming Oracle never exceeded the partition boundary.
Mapping between each partition and the specific Oracle licences allocated to cover it.
Pro tip. Present this evidence proactively at the start of the audit engagement, before Oracle LMS draws its own conclusions. A well-organised compliance package significantly reduces the likelihood of disputes and accelerates audit closure.
Hard partitioning is not a one-time configuration exercise. It requires ongoing governance to ensure the licensing benefit is preserved as infrastructure evolves.
Schedule internal reviews every quarter to verify all Oracle-related partitions remain correctly configured. Check for accidental cap changes, firmware updates that may have reset settings, and new servers added without proper partitioning.
Require that any change to a server hosting an Oracle partition triggers a licensing impact assessment.
Oracle periodically updates its partitioning policy. An update that modifies acceptance criteria for a technology you rely on could affect your compliance. Review updates with independent advisers.
Check the latest Oracle partitioning policy document for your specific technology and version. Only technologies on the approved list qualify.
Every Oracle partition must have a fixed, immovable CPU core maximum that cannot be exceeded. Soft limits are never sufficient.
Validate that partition settings survive restarts, firmware updates, and maintenance windows without resetting.
Disable live migration for Oracle VMs or ensure identical pinning on all potential target hosts in the cluster.
Maintain timestamped configuration evidence for every Oracle partition. Screenshots, command output, change logs. Update after every change.
Restrict partition modification rights to authorised personnel with change management approval required for any change.
No VMware configuration is accepted. If Oracle runs on VMware, you must licence the entire cluster.
Verify configurations, check for drift, and update documentation every quarter as a standard governance practice.
Require licensing impact assessment for any infrastructure change affecting Oracle partitions.
Pre-audit review by specialists ensures your evidence package meets Oracle LMS standards and your partitioning position is defensible.
No. Oracle classifies all VMware configurations as soft partitioning, including vSphere, ESXi, CPU affinity, reservations, limits, DRS host groups, and resource pools. Regardless of how restrictively you configure VMware, Oracle requires licensing of every core in the VMware cluster where Oracle is installed or could potentially run. The only way to reduce Oracle licensing on VMware is to isolate Oracle onto a dedicated VMware cluster with the minimum number of cores, then licence that entire cluster.
A capped LPAR has a fixed maximum number of processing units it cannot exceed. Oracle accepts this as hard partitioning. An uncapped LPAR can dynamically borrow additional processing capacity from other LPARs on the same server. Oracle treats this as soft partitioning and requires licensing of the entire physical server. Always verify that Oracle-hosting LPARs are configured in capped mode with a hard maximum defined in the HMC.
Yes. Any Oracle option or management pack enabled within the partition must be licensed for the partition core count. Check DBA_FEATURE_USAGE_STATISTICS within the partition to verify which options are active.
Any period during which the cap was increased creates compliance exposure for the higher core count. Oracle audits examine historical configurations, not just the current state. Implement strict change management controls to prevent unauthorised cap modifications, and log all configuration changes with timestamps.
Yes. Oracle VM (OVM) and Oracle Linux KVM with CPU pinning are approved hard partitioning technologies for x86 servers. The VM must be pinned to specific physical cores using the hypervisor CPU affinity settings, and the pinning must be fixed (not dynamic). The VM must not migrate to a host where it is not identically pinned.
No. Oracle partitioning policy is a unilateral policy document, not a term of your licence agreement. Your contract defines licensing based on the number of processors where Oracle is installed and/or running. In some cases, your contract language may support a different interpretation. Consult independent licensing advisers if you believe your contract provides broader sub-capacity rights.
If Oracle VMs can migrate between hosts in a cluster, every host in the migration domain must be licensed. To preserve the hard partitioning benefit, restrict Oracle VMs to a dedicated subset of identically partitioned hosts and disable migration outside that subset. Mixed configurations create the worst outcome: Oracle may claim full licensing on every host.
Need help with Oracle hard partitioning? Redress Compliance helps enterprises implement Oracle-approved hard partitioning, prepare audit-proof documentation, and defend partitioning positions during Oracle LMS reviews. Oracle Advisory Services | Book a Consultation