Oracle Partitioning Policy: Sub-Capacity Licensing, Hard Partitioning, and Your Rights

What Is Oracle Partitioning Policy?

Oracle's Partitioning Policy is a published technical document that defines Oracle's position on how database processor licenses must be counted when databases run in virtualized environments, on partitioned systems, or with CPU resource limits applied. It is fundamentally a document about measuring processor usage for licensing purposes, not about the Oracle Database Partitioning feature that partitions data within a database.

The policy distinguishes between soft partitioning (software-defined resource limits) and hard partitioning (Oracle-approved physical or logical hardware partitioning methods). Oracle's core assertion is that soft partitioning does not reduce the number of licenses required. Only hard partitioning via approved technologies allows customers to count and license only the processors where Oracle can actually run.

Critical Context: It Is Not a Contract Provision

Oracle's own Partitioning Policy document states explicitly that it is published "for educational purposes only" and does not form part of any customer contract. This legal status is important. Your Oracle licensing agreement (OMA, OLA) does not reference the Partitioning Policy. Instead, it references Oracle's interpretation of what constitutes a "Processor" for licensing purposes.

However, Oracle LMS (License Management Services) auditors treat the Partitioning Policy as the audit standard. When Oracle conducts a compliance audit, they apply the Partitioning Policy. Courts have not upheld Oracle's position solely on the strength of the policy document itself; Oracle has settled every major case that relied primarily on the policy, often accepting compromise positions that customers had proposed.

Soft Partitioning: Why Oracle Rejects It

Soft partitioning means using software—typically your hypervisor—to limit the CPU cores available to a virtual machine or database instance. The underlying hardware has more cores, but the hypervisor restricts what the database can access.

Examples of Soft Partitioning (Oracle Does NOT Accept)

• VMware ESXi vSphere: Setting vCPU limits on a virtual machine. If a physical server has 32 cores and ESXi limits the Oracle VM to 8 vCPUs, Oracle counts 32 cores (all physical cores on the host where Oracle CAN run).
• Microsoft Hyper-V: Virtual processor reservations and caps. Hyper-V-imposed CPU limits do not reduce Oracle's licensed processor count.
• Citrix XenServer: vCPU assignments to guest VMs. Oracle counts all physical cores on the host.
• Solaris Containers (Uncapped): Solaris Zones without hard CPU caps applied at the kernel level count as soft partitioning.

Oracle's rationale is straightforward: software-based limits can be modified or bypassed by the hypervisor administrator without changing the database code. Therefore, Oracle considers the entire physical server as available for license calculation, even if vCPU limits are temporarily in place.

The VMware Challenge

VMware is the most common soft-partitioning platform. Organisations with Oracle databases on VMware clusters face a significant licensing challenge: if you place even a single Oracle database on a 32-core host in a VMware cluster, you must licence all 32 cores, even if the database only uses 4 vCPUs. If the cluster has 10 such hosts, you must licence 320 cores, not 40.

This is why many enterprises either build dedicated Oracle-only VMware clusters or migrate to Oracle Linux KVM with CPU pinning, which Oracle accepts as hard partitioning.

Hard Partitioning: Approved Methods

Hard partitioning uses Oracle-approved methods to physically or logically partition hardware at a level that Oracle trusts. Only cores assigned to a partition are counted for licensing. Oracle recognises eight categories of hard partitioning:

Approved Hard Partitioning Technologies

• Oracle VM Server for x86 (OVM): Oracle's own hypervisor. CPU pinning (mapping virtual CPUs to specific physical cores) is required. This is Oracle's preferred virtualisation platform for processor licensing reduction.
• Oracle Linux KVM with CPU Affinity: Kernel Virtual Machine on Oracle Linux, with CPU affinity configured to bind vCPU threads to specific physical cores. This must run on Oracle Linux (not other Linux distributions). Oracle accepts this for sub-capacity licensing.
• IBM LPAR (Power Systems): Logical Partitions on POWER architecture systems. Partitions must be capped (minimum vCPU requirement: 1). Each partition is licensed independently for only the cores assigned to it.
• IBM Micro-Partitions: On POWER systems, shared CPU pools with micro-partitions. Must be capped at a minimum of 1 vCPU. Only cores assigned to the pool are counted.
• Solaris Zones (Capped): Solaris containers with explicit CPU caps applied at the kernel level. Requires configuration via zonecfg and kernel enforcement. Only capped cores are counted.
• Physical Domains (PDomains) on SPARC: SPARC T-Series systems with physical domain partitioning. Each domain is isolated at the hardware level and licensed independently.
• HP vPar (capped): Virtual Partitions on HP UX systems, with CPU capping. Only capped cores are counted.
• HP nPar: Hardware-level partitions on HP systems. Each partition is completely isolated and licensed separately.
• Fujitsu PPAR (capped): Fujitsu Server Partitions with explicit CPU caps. Only the capped CPU count is licensed.

The common thread across approved hard partitioning: the partition boundary is enforced at the hardware or firmware level, not by software that can be reconfigured without system restart and administrative privilege escalation.

The Legal and Commercial Status of the Policy

Oracle's Partitioning Policy has been tested in court multiple times. Courts have examined whether Oracle can unilaterally enforce a non-contractual policy document. The outcome is instructive.

What Court Cases Show

Oracle has litigated Partitioning Policy disputes in multiple jurisdictions. Notably, Oracle has not won a judgment based purely on the Partitioning Policy itself. When courts have examined the question directly, they have questioned whether a non-contractual, unilaterally published document can override contract terms or force customers to pay for unused capacity.

Instead, Oracle has settled cases by accepting compromise positions. For example, in several disputes, Oracle has agreed to count only the cores actually assigned to a partition, rather than all cores on the physical host, even when the hypervisor was soft partitioning. These settlements indicate Oracle's practical vulnerability to expert testimony and customer pushback.

Why Oracle Cannot Contract Around This

Oracle's master agreements (OMA, OLA) define "Processor" but do not explicitly invoke the Partitioning Policy or state that soft partitioning requires full host licensing. This gap is deliberate on Oracle's part—it allows Oracle to apply the policy more broadly than the contract text strictly requires—but it also creates a defence for customers who argue that their contract does not mandate the policy's application.

Customer obligations under OMA/OLA clauses like "Products are licensed by the number of Processors on which they are installed" can be interpreted flexibly. A lawyer might argue that "installed" means "actually executable" or "actually capable of using the software," which is narrower than Oracle's interpretation that it means "potentially installable."

Cloud and BYOL Environments

Oracle Partitioning Policy applies differently in cloud environments.

Oracle Cloud Infrastructure (OCI)

OCI uses OCPU (Oracle Compute Unit) licensing, not traditional processor licensing. Partitioning Policy does not apply in the same way. You licence OCPUs consumed by your database instance, not underlying server cores. This is one reason customers with existing Oracle BYOL contracts may find it advantageous to use OCI for new workloads: there is no partitioning ambiguity.

AWS and Microsoft Azure (BYOL)

If you bring your own Oracle licenses to AWS EC2 or Azure VMs, Oracle Partitioning Policy applies to your dedicated host assignment. Placing an Oracle database on a Dedicated Host does not fully resolve the issue. Oracle may still argue that because the Dedicated Host has more capacity than you are using, you must licence the full host, unless you have explicitly negotiated otherwise.

AWS and Azure Dedicated Hosts provide hardware isolation, which is valuable, but they do not constitute Oracle-approved hard partitioning in the Partitioning Policy sense. Negotiating a supplementary letter of usage rights specific to your Dedicated Host configuration is essential.

Customer Rights and Negotiation Strategies

What rights do you have if Oracle cites the Partitioning Policy in an audit and demands licensing for unused capacity? Several strategies have proven effective.

1. Challenge the Non-Contractual Status

Argue that because the Partitioning Policy is explicitly published as "for educational purposes only" and is not incorporated into your OMA or OLA, Oracle cannot unilaterally enforce it. Your contract defines licensing obligations; the policy is Oracle's interpretation, not a legal requirement.

2. Obtain Expert Opinion

Commission an independent expert opinion from a licensing architect or consultant with no Oracle or customer affiliation. The expert should opine on whether your partitioning method qualifies as reasonable sub-capacity licensing under industry-standard definitions. Several customers have used expert opinions successfully in settlement negotiations.

3. Cite Contract Language Ambiguity

The OMA/OLA language "Products are licensed by the number of Processors on which they are installed" is ambiguous. A customer can argue that "installed" refers to processors where the database is actually installed and can execute, not to processors that exist on a shared physical host.

4. Propose a Capping Strategy

If you are currently on VMware soft partitioning, propose migrating to Oracle Linux KVM with CPU affinity or building a dedicated Oracle-only cluster. Oracle accepts both as hard partitioning. The cost of migration may be less than the incremental licensing Oracle is demanding. Use this proposal as leverage in settlement discussions.

5. Escalate Through Commercial Channels

Oracle's LMS organization applies the policy. But Oracle's sales, account management, and executive teams may take a more pragmatic stance, especially if you have a large contract up for renewal. Escalate the dispute beyond LMS to the sales organization and frame it as a commercial relationship question, not a technical one.

6. Address Multi-Vendor Contracting

If you have an Oracle Unlimited License Agreement (ULA) or PULA (Platform ULA), partitioning policy changes may not apply retroactively within the ULA term. Review your ULA terms carefully. If audited under a ULA, cite the ULA's terms as the governing agreement.

7. Negotiate a Supplementary License Schedule

Ask Oracle to execute a supplementary letter or schedule that explicitly defines your partitioning method and the corresponding licensed processor count. A written confirmation from Oracle acceptance of your configuration is far more defensible than relying on the unprompted application of an educational-purposes-only policy.

Oracle Support Fee Increases and Long-Term Costs

Regardless of partitioning method, your Oracle support and maintenance fees increase automatically each year. Oracle support fees increase at 8 percent per year. This applies to all Oracle products under maintenance, including Database, Fusion Applications, Java, and any others.

An 8 percent annual increase compounds significantly. A $1M annual support bill becomes $1.08M, then $1.166M, then $1.259M over four years. This is not negotiable within standard OMA or OLA terms. To address this, customers often:

• Negotiate multi-year pricing locks or caps on annual increases as part of broader EA renewals.
• Use cost reductions from partitioning improvements (migration to KVM, dedicated Oracle clusters) to offset the growth in support fees.
• Evaluate alternative databases and plan retirement timelines for Oracle workloads where possible.

Note: Oracle does not offer Enterprise Agreements (EA) in the traditional SAP or Microsoft sense. Oracle's commitment models are ULA (Unlimited License Agreements), PULA (Platform ULA), OCS (Oracle Cloud Services Subscription), and CSI (Cloud Services Infrastructure). Understand which model applies to your contract; each has different true-up, audit, and cost escalation terms.

Practical Decisions: VMware, KVM, or Dedicated Clusters?

If you are currently running Oracle on VMware and auditors are pushing for full-host licensing, you have three practical paths:

Option 1: License All VMware Hosts in the Cluster

If you have a 10-host VMware cluster and 3 of those hosts run Oracle, you must licence all cores on all 10 hosts (or all cores in the resource pool containing Oracle). This is the simplest compliance path but the most expensive. It avoids further disputes and simplifies future audits.

Option 2: Build a Dedicated Oracle-Only Cluster

Isolate Oracle databases onto a separate VMware cluster with no non-Oracle workloads. Then negotiate with Oracle to accept this configuration as single-tenancy soft partitioning (or close-enough for practical audit purposes). Some customers have successfully negotiated this compromise with Oracle.

Option 3: Migrate to Oracle Linux KVM with CPU Affinity

Migrate Oracle databases from VMware to Oracle Linux KVM, using CPU affinity to bind database instances to specific cores. This qualifies as approved hard partitioning. Initial migration costs are real, but the ongoing licensing benefit (paying for only the cores you actually use) often justifies the expense over 3-5 years.

Negotiation Steps and Audit Defence

When Oracle LMS opens an audit or issues a preliminary report citing Partitioning Policy violations, follow this sequence:

1. Do Not Admit Liability: Respond formally to acknowledge the audit but explicitly state that you dispute the policy's application to your environment.
2. Document Your Configuration: Gather detailed technical documentation of your partitioning method, vCPU assignments, hypervisor settings, and resource allocations.
3. Engage Independent Counsel: Retain an attorney experienced in Oracle licensing disputes. (Redress Compliance can introduce you to counsel if needed.)
4. Obtain an Expert Opinion: Commission a technical expert opinion on the licensing status of your partitioning method.
5. Propose Settlement Terms: Use the expert opinion to propose a settlement that acknowledges partial compliance and offers a reasonable compromise on disputed cores.
6. Escalate to Commercial Leadership: If LMS disputes your position, escalate to Oracle's account team and executive sponsor. Make clear that you wish to resolve this, but that the policy's legal basis is questionable.
7. Negotiate a Supplementary Letter: Whatever resolution you reach, insist on a supplementary letter or schedule explicitly confirming the number of licensed cores and the partitioning method Oracle is accepting.

This sequence has proven effective. Customers who push back thoughtfully and professionally, backed by expert opinion and sound legal reasoning, typically reach settlements that are significantly better than Oracle's initial audit position.