Implementing Oracle-Approved Hard Partitioning: A Practical Guide to Cut License Costs

The Foundation: Oracle's Partitioning Policy Explained

Oracle's licensing policy for partitioned environments is governed by Oracle's Partitioning Policy document, originally published in 2009 and maintained as a binding reference alongside Oracle's standard licence agreement. The policy establishes two categories of partitioning: hard partitioning (approved for sub-capacity licensing) and soft partitioning (not approved for sub-capacity licensing).

Sub-capacity licensing means that an organisation needs to licence only the processor cores allocated to Oracle software within a partitioned environment — not every core in the physical server. This distinction is commercially significant. A physical server with 32 cores running Oracle Database Enterprise Edition at Oracle's list price of $47,500 per processor would require approximately 32 × $47,500 × 0.5 (Intel/AMD core factor) = $760,000 in licence fees at full server licensing. A hard-partitioned environment containing 4 cores would require 4 × $47,500 × 0.5 = $95,000 — a saving of approximately $665,000 on a single server.

This is not a loophole. Oracle explicitly created and maintains the hard partitioning provision. Oracle benefits commercially from selling Oracle VM, Oracle Linux, and SPARC hardware, which are among the approved technologies. The policy is real, the savings are real, and the implementation requirements are precise. Organisations that implement hard partitioning correctly can realise licence cost savings that compound through Oracle's 8% annual support escalation cycle — reducing not just current licence fees but the escalating support cost base over many years.

Hard Partitioning vs Soft Partitioning — Why the Distinction Matters

Oracle defines hard partitioning as the use of hardware or firmware mechanisms that enforce an absolute boundary on processor core access for a given virtual or logical environment. The defining characteristic is that the boundary cannot be crossed at runtime without administrative reconfiguration. The Oracle software inside the partition physically cannot access processing resources outside its allocated cores, regardless of system load or other software activity on the host.

Soft partitioning, by contrast, uses software-layer mechanisms to attempt to constrain processor use. Oracle explicitly identifies the following as soft partitioning technologies that do NOT qualify for sub-capacity licensing: VMware vSphere (including vSphere's CPU affinity settings), Microsoft Hyper-V, KVM on non-Oracle Linux distributions, Docker containers, LXC containers, Kubernetes resource limits, Solaris Resource Manager, HP-UX nPars software partitions, and any technology that uses CPU scheduling rather than CPU assignment to constrain Oracle's access to processing resources.

The consequences of misclassifying a soft partitioning environment as hard partitioning are severe. Oracle's LMS audit teams specifically test partitioning configurations during audits. A VMware environment with CPU affinity settings is one of the most common audit findings in Oracle database deployments. Customers who believed their VMware-hosted Oracle databases were sub-capacity licensed on four cores are frequently presented with back-billing claims for the full physical host's core count — retrospectively, across years of deployment.

The Complete List of Oracle-Approved Hard Partitioning Technologies

Oracle's partitioning policy document identifies the following technologies as qualifying for hard partitioning, subject to correct implementation:

• Oracle VM (Oracle VM Server for x86) — with CPU pinning enabled
• Oracle Linux KVM — with CPU pinning and affinity configured correctly
• Oracle VM Server for SPARC (Logical Domains / LDoms) — with whole-core allocation
• Solaris Capped Zones (non-global zones with CPU caps configured)
• IBM LPAR — in capped mode, not uncapped mode
• IBM System p Micro-Partitioning — in capped mode only
• HP Integrity Virtual Machines (HP-UX) — with CPU entitlement caps
• HPE nPars (hard partitions) — physical hardware-enforced partitioning
• Fujitsu M10/M12 Physical Partitions (PPAR)
• SPARC Physical Domains (PDoms)

Each of these technologies has specific configuration requirements that must be met for the partitioning to be valid under Oracle's policy. Meeting the general category requirement is not sufficient — the implementation must conform to Oracle's specific technical conditions for each technology. The sections below cover the most commonly deployed technologies in detail.

Oracle VM for x86 — CPU Pinning Step by Step

Oracle VM Server for x86 is Oracle's Type-1 hypervisor based on the Xen architecture. It is one of the most widely used approved hard partitioning technologies for Oracle database workloads on x86 hardware. When properly configured, Oracle VM allows Oracle software to be limited to a specific set of physical CPU cores via CPU pinning — Oracle's term for binding a virtual machine's virtual CPUs to specific physical CPUs on the host.

What CPU pinning means in the Oracle VM context

CPU pinning in Oracle VM means that the virtual CPUs assigned to an Oracle VM guest domain are permanently and exclusively bound to specific physical CPU cores on the hypervisor host. The pinned virtual CPUs cannot float to other physical cores, cannot burst onto unlicensed capacity during peak load, and cannot migrate to other physical hosts without reconfiguration. This is enforced at the hypervisor level — not by a scheduler policy that might be overridden under load.

To configure CPU pinning in Oracle VM, the administrator must explicitly pin each virtual CPU to a specific physical core using Oracle VM Manager or the OVM command-line interface. Oracle's documentation specifies that CPU pinning is configured at the guest level, and that once pinned, the hypervisor prevents the virtual machine from using any physical CPU resource outside its pinned set.

Critical requirements for valid Oracle VM hard partitioning

For Oracle VM CPU pinning to qualify as hard partitioning under Oracle's policy, the following conditions must all be true simultaneously:

• CPU pinning must be explicitly enabled in Oracle VM Manager, not left to the default scheduler.
• The number of virtual CPUs pinned must correspond to the number of physical cores being licensed.
• The pinned virtual CPUs must be bound to specific physical cores — not "up to X cores" on the host.
• Live migration of the Oracle VM guest to another Oracle VM Server host is not permitted under the hard partitioning model. If live migration is required for availability, the destination host's full core count must also be licensed.
• Oracle VM Server must be running on the physical host — Oracle VM's hard partitioning provisions do not extend to nested virtualisation environments.
• The Oracle VM configuration must be documented and reproducible — Oracle's auditors will verify the pinning configuration through OVM Manager API queries.

Oracle Linux KVM with CPU pinning

Oracle Linux KVM is increasingly deployed as the hard partitioning technology of choice for Oracle database environments. Oracle has published specific guidance confirming that Oracle Linux KVM qualifies for hard partitioning when CPU pinning is correctly implemented using the vcpupin configuration in libvirt/virsh and CPU affinity is set to bind virtual CPUs to specific physical core identifiers.

The KVM implementation requires that the vcpupin element in the VM's libvirt XML configuration explicitly assigns each virtual CPU to a specific physical CPU ID. Simply setting cpuset at the domain level may not satisfy Oracle's requirement for explicit per-vCPU pinning in all audit scenarios. Always use explicit vcpupin elements and retain configuration exports as audit evidence.

Oracle VM Server for SPARC — Hard Partitioning with LDoms

Oracle VM Server for SPARC (formerly Sun Logical Domains, commonly called LDoms) provides the hard partitioning mechanism for Oracle SPARC hardware platforms including the T-Series, M-Series, and S-Series systems. SPARC-based Oracle database deployments can leverage LDoms to achieve sub-capacity licensing, with Oracle supporting this as a fully approved hard partitioning method.

Whole-core allocation requirement

Oracle VM Server for SPARC hard partitioning is based on whole-core allocation. Beginning with Oracle VM Server for SPARC 2.0, domains must be allocated CPU in whole cores (not individual threads) for the partitioning to qualify as hard partitioning. This is an important distinction from earlier LDom implementations that could allocate individual CPU threads to guest domains.

On SPARC T-Series processors, each physical chip contains multiple CPU cores, each with multiple hardware threads (strands). Oracle's hard partitioning policy for SPARC requires that a domain receives all hardware threads in each allocated core — you cannot allocate a single thread from a multi-threaded core and claim sub-capacity licensing for that fraction of the core.

The Oracle Core Factor Table assigns SPARC T-Series processors a core factor of 0.25 per core. This means that an LDom with 4 dedicated SPARC cores requires 4 × 0.25 = 1.0 processor licence for Oracle Database Enterprise Edition — enabling significant licence reduction compared to licensing the full physical server.

SPARC Physical Domains (PDoms)

On Oracle SPARC M-Series systems, Physical Domains (PDoms) provide hardware-enforced partitioning at the chip level. A PDom is a distinct partition with its own processors, memory, and I/O completely isolated from other PDoms on the same chassis. PDoms are the most aggressive form of SPARC hard partitioning — the isolation is enforced in hardware, not firmware or software, making it unambiguously compliant with Oracle's hard partitioning requirements.

Solaris Capped Zones

Oracle Solaris Zones (specifically capped zones with CPU resource controls configured) qualify as an Oracle-approved hard partitioning technology. An uncapped Solaris Zone, which allows the zone to burst onto additional processors during high load, does not qualify for sub-capacity licensing. Only zones with explicit CPU caps that prevent the zone from accessing more than the allocated processor capacity are approved.

To configure a capped Solaris Zone for hard partitioning purposes, the zone must have its cpu-shares and capped-cpu ncpus properties set explicitly in the zone configuration. The capped-cpu resource limits the total CPU time the zone can consume, expressed as a fraction of a CPU (e.g., ncpus=4.0 limits the zone to the equivalent of 4 CPUs). Oracle's auditors will examine the zone configuration export during an audit to verify these settings are in place and have not been modified.

Solaris Zones hard partitioning is particularly common in organisations running Oracle Database on Solaris SPARC systems, where the combination of PDoms or LDoms for hardware-level partitioning with Solaris Zones for application-level workload isolation provides multiple layers of cost management and compliance control.

IBM LPAR in Capped Mode

IBM LPAR (Logical Partition) technology on IBM Power Systems qualifies as Oracle-approved hard partitioning when configured in capped mode. An IBM LPAR in uncapped mode can burst beyond its allocated processor entitlement using spare processor capacity on the physical server — this disqualifies it from sub-capacity Oracle licensing. Capped mode strictly enforces the processor entitlement ceiling, preventing the LPAR from consuming more than its allocated virtual CPU capacity regardless of available spare capacity on the host.

IBM's documentation distinguishes between "dedicated" and "shared" processor LPARs. Oracle's hard partitioning approval extends to both dedicated LPARs and shared-processor LPARs, provided the shared-processor LPAR is in capped mode. A dedicated LPAR allocates specific physical processor cores exclusively to that partition — equivalent to Oracle VM CPU pinning. A shared-processor capped LPAR allocates a specified processor entitlement from a shared pool with a hard cap enforced by the IBM POWER Hypervisor.

For Oracle licensing purposes under IBM LPAR, the number of processors to licence is calculated from the LPAR's processor entitlement. Oracle's Core Factor Table includes the IBM POWER core factor relevant to the specific processor generation, which is applied to the number of active cores in the capped LPAR.

Cost Savings Calculator and Real-World Examples

The financial case for hard partitioning implementation is strongest when Oracle Database Enterprise Edition or other expensive Oracle products are running on modern high-core-count servers. Oracle's core factor for Intel and AMD processors is 0.5 (each core requires 0.5 processor licences). Oracle Database Enterprise Edition lists at $47,500 per processor. Annual support on Oracle database licences is approximately 22% of net licence value — and escalates at 8% per year.

Example 1: x86 server with 32 cores, 4 cores allocated to Oracle

Without hard partitioning, a 32-core Intel server running Oracle Database EE would require 32 × 0.5 = 16 processor licences. Licence cost: 16 × $47,500 = $760,000. First-year support at 22%: $167,200. In year five, after four years of 8% annual escalation, the annual support cost becomes approximately $227,000.

With Oracle VM hard partitioning, the same workload confined to a 4-core pinned partition requires 4 × 0.5 = 2 processor licences. Licence cost: 2 × $47,500 = $95,000. First-year support: $20,900. Total first-year saving from hard partitioning: $665,000 in licence fees plus $146,300 in first-year support — a combined saving exceeding $800,000 on a single server. The licensing saving compounds through the 8% annual support escalation over the life of the infrastructure.

Example 2: SPARC T8 server with 8 SPARC cores, 2 cores in a licenced LDom

A SPARC T8-2 system has 2 sockets, each containing 32 cores. Without LDom hard partitioning, fully licensing Oracle Database EE would require 64 × 0.25 (SPARC core factor) = 16 processor licences. With an LDom allocated 2 whole cores, the licence requirement is 2 × 0.25 = 0.5 processor licences — Oracle rounds this to 1 processor licence minimum. Licence cost: 1 × $47,500 = $47,500. Saving vs full server: $712,500 in licence fees alone.

Long-term compounding effect of the 8% support escalation

This is the element most organisations fail to model correctly. The 8% annual Oracle support escalation means that every dollar saved on initial licence fees translates to $1.47 in support savings over five years (at 22% annual support compounding at 8%). The true five-year benefit of hard partitioning implementation is substantially larger than the one-year licence saving alone. For a $665,000 licence saving, the five-year total benefit — including compounding support savings — exceeds $1.5 million on a single server, before accounting for the licence savings on the initial purchase.

Documentation Requirements for Audit Survival

Hard partitioning is auditable. Oracle's LMS team specifically tests partitioning configurations during Oracle database licence audits. Organisations that implement hard partitioning correctly but cannot demonstrate that configuration to an auditor's satisfaction may face the same outcome as those who implement it incorrectly: back-billing for full server core counts.

What Oracle's auditors will request

In a hard partitioning audit scenario, Oracle's LMS team will typically request the following evidence for each server where sub-capacity licensing is claimed:

• Oracle VM Manager export showing the virtual machine configuration, including explicit CPU pinning assignments per virtual CPU, for each period of Oracle software operation.
• For Oracle Linux KVM: the libvirt XML configuration file(s) showing vcpupin assignments, plus evidence that these configurations were in effect at the time of Oracle software deployment.
• For SPARC LDoms: the LDom configuration export from Oracle VM Server for SPARC Manager, showing whole-core assignments to each domain.
• For Solaris Zones: zonecfg export output for each zone, confirming capped-cpu ncpus values.
• For IBM LPAR: the LPAR configuration profile from HMC, confirming capped mode and processor entitlement.
• Configuration change history: evidence that the configuration has been continuously maintained — not created retrospectively for the audit.
• Change management records (ITSM tickets, CMDB entries) showing when partitions were created, modified, or decommissioned.

Configuration management is evidence management

The most common documentation failure in hard partitioning audits is retrospective configuration. Organisations that have been running unlicensed or mis-configured environments sometimes attempt to implement hard partitioning correctly just before or during an audit, then present the current configuration as historical evidence. Oracle's auditors are experienced at identifying this pattern through configuration change logs, hypervisor host change histories, and cross-referencing with Oracle software installation dates from CMDB records.

Documentation must be contemporaneous. If hard partitioning was implemented on a specific date, that date must be documented — and Oracle licence compliance is only claimed from that date forward. Historic non-compliance must be acknowledged and addressed separately. Attempting to present current configurations as historical evidence in an audit is not only ineffective — it damages your credibility for the entire audit scope.

Best practice is to integrate hard partition configuration exports into your CMDB or configuration management platform as a scheduled automated task. Export Oracle VM Manager configurations weekly, retain them for at least seven years, and tag exports with timestamps. For Oracle Linux KVM environments, automate libvirt XML exports and store them in version-controlled storage. This creates an irrefutable, independently verifiable configuration history.

The Ten Audit Risks That Invalidate Hard Partitioning

In our experience reviewing Oracle hard partitioning deployments prior to audits, the following ten configuration and process failures are the most common causes of hard partitioning being invalidated — resulting in full-server core-count back-billing:

1. Using VMware with CPU affinity settings and claiming it as hard partitioning. VMware is explicitly excluded from Oracle's hard partitioning approvals. No VMware configuration qualifies, including vSphere CPU affinity, vSphere reservations, or DRS anti-affinity rules.
2. Enabling live migration without licensing the destination host. If a hard-partitioned Oracle VM guest migrates to another physical host — for any reason, including emergency failover — the destination host's full core count must be licensed for the period of operation, or the destination host must itself have an equivalent hard partition in place.
3. Configuring IBM LPAR in uncapped mode. Uncapped LPARs can burst beyond their entitlement and do not qualify for sub-capacity Oracle licensing.
4. Using Solaris uncapped zones. A zone without explicit capped-cpu configuration can consume all available processors on the global zone host.
5. Implementing CPU pinning at the scheduler level rather than the hypervisor level. CPU sets defined in the guest OS (e.g., via taskset in Linux) do not enforce partitioning at the hypervisor level and do not qualify.
6. Allocating virtual CPUs to a range rather than specific physical cores. CPU pinning must bind virtual CPUs to specific physical core IDs. Pinning to "any 4 of the 16 available cores" does not satisfy Oracle's requirement for explicit, reproducible assignment.
7. Failing to document the pinning configuration contemporaneously. Retrospective documentation is not accepted as evidence of historic sub-capacity compliance.
8. Using overcommitted Oracle VM environments. If Oracle VM Server hosts have more virtual CPU cores mapped to Oracle VM guests than there are physical cores, the overcommitted physical cores must all be licensed.
9. Running Oracle software in containers on an unlicensed partitioned host. Docker containers, LXC containers, and Kubernetes pods are not Oracle-approved hard partitioning technologies. Oracle software in containers requires licensing based on the physical host's core count (or the hard-partitioned partition if the container host is itself within a valid hard partition).
10. Applying hard partitioning to middleware without applying it to the database tier. All Oracle products running on a server are subject to Oracle's partitioning policy. If Oracle Database is fully licensed at hard-partition scope but Oracle WebLogic Server runs outside the partition, WebLogic requires full-server licensing independently.

Implementation Roadmap for Hard Partitioning Projects

Implementing hard partitioning for Oracle licence cost reduction is a structured project, not an ad-hoc configuration change. The following roadmap reflects best practice for enterprise-scale implementations.

Phase 1: Current-state licence position assessment (2–4 weeks)

Conduct a comprehensive internal Oracle licence position review covering all servers running Oracle database products. Document the current deployment architecture, identify servers where Oracle software is running on environments that do not currently qualify as hard partitions, and calculate the potential licence saving available if hard partitioning were correctly implemented. This phase should be completed independently — without Oracle's involvement — to protect commercial confidentiality.

Phase 2: Technology and architecture selection (2–3 weeks)

Select the appropriate approved hard partitioning technology for each environment based on the existing hardware platform, operating system, and Oracle product stack. For new server procurements, consider building the hard partitioning strategy into the hardware specification — SPARC systems with LDoms, Oracle VM Server for x86 on certified x86 hardware, or IBM POWER with capped LPARs. Engage your virtualisation and server teams to confirm they can support the selected technologies and implement the required configuration standards.

Phase 3: Configuration implementation and testing (4–8 weeks)

Implement hard partitioning configurations in a controlled, staged manner — starting with development and test environments before production. Each configuration must be peer-reviewed by a colleague who understands Oracle's requirements, tested to confirm that the Oracle software cannot access resources outside the partition under any operational scenario (including peak load), and documented in your CMDB with configuration exports at the point of implementation.

Phase 4: Documentation framework and audit readiness (ongoing)

Establish automated, scheduled configuration exports for all hard-partitioned Oracle environments. Integrate configuration management for partitioned environments into your standard ITSM change management process so that all future changes to partition configurations are formally tracked and authorised. Brief your Oracle account team on the hard partitioning implementation once it is complete and stable — proactive communication is preferable to Oracle discovering the sub-capacity licensing position during an unannounced audit review.

Summary and Expert Guidance

Oracle-approved hard partitioning is one of the most powerful and legitimate tools available for reducing Oracle processor licence costs. The savings can be substantial — from tens of thousands to millions of dollars per server, depending on the Oracle product, server core count, and the number of cores allocated to Oracle in the partitioned environment. These savings compound through Oracle's 8% annual support escalation over the lifetime of the infrastructure investment.

The technology is real. The savings are real. The implementation requirements are precise. And the audit risks for incorrect implementation are significant — back-billing claims at full physical server core counts for years of operation, plus Oracle's 8% annual support escalation applied to the back-billing amount. The difference between hard partitioning done correctly and hard partitioning done incorrectly is not a matter of effort — it is a matter of knowing exactly which configuration parameters Oracle's policy requires and documenting them in a form that survives an audit.

For organisations running Oracle Database Enterprise Edition, Oracle WebLogic Server, or other high-value Oracle products on modern multi-core servers, a hard partitioning assessment should be a standard component of Oracle licence governance. The investment in a proper implementation and documentation framework delivers measurable, auditable, sustained cost reduction. For expert guidance on hard partitioning assessment, implementation planning, or audit defence, contact Redress Compliance or visit our Oracle Knowledge Hub for additional Oracle licensing resources.