Oracle Partitioning Policy: The Impact on Licensing

Oracle Partitioning Policy

Virtualization is widely used to reduce IT costs and improve flexibility. However, when it comes to Oracle software licensing, virtualization can introduce hidden risks. Oracle’s licensing rules around “partitioning” – the way hardware resources are divided for virtualization – have created potential licensing time bombs that can wipe out the expected savings​.

This is especially true for Oracle Database and other Oracle programs, due to Oracle’s strict definitions of what counts as an acceptable partitioning method. Failing to understand Oracle’s partitioning policy can lead to non-compliance and costly surprises during audits.

In this article, we’ll explain the difference between Soft Partitioning and Hard Partitioning as defined by Oracle, why soft partitioning is not accepted to limit license requirements, which hard partitioning methods are approved (with examples), and what all this means for licensing Oracle Database and other Oracle software.

We’ll also share real-world examples (such as Oracle’s stance on VMware clusters), clarify the non-contractual nature of Oracle’s policy (despite its enforcement in audits), and demonstrate how proper hard partitioning can save customers significant costs compared to over-licensing.

Finally, we’ll provide actionable recommendations for Software Asset Management (SAM) teams, IT architects, and Oracle licensing professionals to avoid common traps and optimize compliance.

Soft Partitioning (Non-Approved Virtualization)

Soft partitioning refers to virtualization or partitioning technologies that allocate system resources flexibly or dynamically but do not physically restrict Oracle software to a fixed subset of hardware. In Oracle’s terms, soft partitioning typically uses OS-level resource managers or hypervisors to divide resources, and these allocations can be changed easily (for example, adjusting CPU shares or moving a virtual machine to a different host). Oracle explicitly states that:

“…soft partitioning…is not permitted as a means to determine or limit the number of software licenses required for any given server or cluster of servers.”​

In simpler terms, if you use a soft partitioning technology, Oracle will not accept it as a way to reduce the number of licenses; you must license the full physical capacity of the server (or even the cluster) where the software is running.

Soft partitioning methods, including popular virtualization platforms and OS control features, are often assumed to limit licensing, but Oracle does not recognize them for license reduction purposes.

Common examples of soft partitioning technologies are:

• VMware ESXi/vSphere – Oracle considers VMware a soft partitioning technology. Even if an Oracle Database is running in a VM with only a fraction of the server’s CPUs, or even if you use VMware’s affinity rules to tie the VM to a specific host, Oracle’s policy still insists that every physical host in the cluster must be fully licensed. (We’ll discuss the implications of this in audits shortly.)
• Oracle VM (without hard pinning) – By default, Oracle’s hypervisor (OVM) is treated as soft partitioning unless configured otherwise. Simply running Oracle on Oracle VM does not automatically reduce licensing unless you follow Oracle’s hard partitioning requirements, such as CPU pinning. Otherwise, Oracle VM is just as ineligible as VMware for sub-capacity licensing​.
• Microsoft Hyper-V – Although not always explicitly named in Oracle’s documentation, Hyper-V is similar to VMware in concept. Oracle has not approved Hyper-V for sub-capacity licensing, so it falls under soft partitioning, meaning the full host or cluster must be licensed.
• OS resource managers and CPU affinity tools – Technologies such as Solaris Resource Containers (without capping), IBM AIX Workload Manager (WLM), HP Process Resource Manager (PRM), or setting CPU affinity at the OS level are all considered forms of soft partitioning. They can limit where Oracle runs in theory, but Oracle doesn’t accept these software-imposed limits for licensing purposes​.
• Dynamic hardware partitioning – If a hardware platform allows dynamic reconfiguration of CPUs (for example, adding/removing CPU resources on the fly), using it fluidly is effectively “soft” in Oracle’s view unless it’s locked down. For instance, an IBM Power server in an uncapped LPAR mode (where the partition can use additional CPU from a shared pool) would be treated as soft partitioning – Oracle would require licensing the entire physical machine unless the LPAR is capped (fixed).

The key characteristic of soft partitioning is that the boundaries of the Oracle workload are not firmly fixed. The Oracle programs could potentially use more CPU or move to another CPU/host, and Oracle’s stance is that you must license all processors where the software could run if you’re using these methods.

In Oracle’s own words, soft partitioning technologies “cannot bind Oracle software strictly to a set of physical processors or cores”​ – therefore, Oracle ignores any such partitioning when counting licenses.

Why Soft Partitioning Doesn’t Limit License Requirements

Oracle does not accept soft partitioning to reduce licenses primarily because these methods are seen as too easily changed or bypassed. Since soft partitions are implemented in software, the resource limits are considered artificial from a licensing perspective – an admin could increase a VM’s CPU allocation or vMotion it to a larger host at any time.

Oracle’s policy treats this flexibility as a risk that the software might use any available resource. As a result, Oracle’s Partitioning Policy states that unless a partitioning method is explicitly approved (hard partitioning), “you cannot use soft partitioning to limit the number of Oracle licenses required” – you must license all processors on all physical hosts in the environment​.

This is why features like VMware’s DRS rules or affinity settings (which tie a VM to a specific host) do not reduce your licensing obligation in Oracle’s eyes. From Oracle’s standpoint, as long as the cluster or virtualization pool exists, the Oracle software could run on any host in that pool.

For example, if you run an Oracle database on a VMware ESXi cluster of 10 hosts, Oracle will require licensing for every host in that cluster, regardless of the size of the virtual machine (VM) or the host on which it currently runs. This can be shocking to unsuspecting customers: you might run a tiny Oracle instance on a two-vCPU VM, but Oracle will ask you to license perhaps dozens of physical CPUs across the entire cluster.

Real-world audit results have proven this to be true. Many companies have been caught off guard by this rule – they limited Oracle to a small VM, thinking they were compliant, only to find in an audit that Oracle’s License Management Services (LMS) required licenses for the full cluster. Oracle’s auditors often apply the policy aggressively, leading to crippling, multi-million dollar license compliance claims.

One Oracle licensing expert notes that Oracle LMS has made audit settlement demands in the tens of millions of dollars by insisting that customers license entire VMware environments. In effect, the cost savings of virtualization can be completely erased or even reversed if Oracle’s rules are not followed.

Common Misinterpretations (Licensing Traps): A few misconceptions frequently lead to compliance exposure:

• “We only need to license the VMs’ vCPUs.” – This is false in Oracle’s case. Unlike some vendors that allow sub-capacity licensing on VMs, Oracle does not allow counting only the virtual CPUs for products licensed by the processor. Even a 2-vCPU Oracle VM on a 32-core host requires licensing the host (or cluster) as if Oracle could use all 32 cores. Oracle explicitly states that VMware virtualization is considered soft partitioning, and any restriction of Oracle to a subset of CPUs via VMware is not acknowledged – you still need to license the entire environment.
• “We pinned the Oracle VM to one host, so we only license that host.” – Unfortunately, Oracle’s official position disregards even manual host affinity rules. Unless you completely isolate that host (e.g., it’s not part of a larger vCenter where VMs can move) or use an approved hard partitioning method, Oracle will argue that all hosts in the cluster (or vCenter) need to be licensed. In practice, some companies isolate Oracle workloads on dedicated clusters to contain the scope, but this must be a true physical segregation. Suppose there is any possibility of VM migration (and with newer VMware versions, VMs can be moved across clusters and vCenters). In that case, Oracle’s view is to license everything that could run the Oracle software.
• “Using cloud or containers bypasses this.” Placing Oracle in a container (e.g., Docker) on a host does not help with licensing unless the host itself is partitioned using an approved method. Containers are not on Oracle’s approved list, so they are treated like soft partitions – you’d need to license the full host or cluster. Public cloud has its own rules: Oracle has special policies for AWS, Azure, etc., which allow counting vCPUs, but those are separate from the on-premises Partitioning Policy. Always check Oracle’s cloud licensing policy if deploying in the public cloud, as it defines how many cloud vCPUs equal an Oracle processor license.

The takeaway is simple: if your Oracle deployment is on a platform or using a method not explicitly approved by Oracle’s Partitioning Policy, you must assume that all physical cores where the software exists or could require licensing.

Soft partitioning will not limit your license requirements, regardless of how you configure it. This sets the stage for why Oracle differentiates it from “hard partitioning.”

Hard Partitioning (Oracle-Approved Methods)

Hard partitioning refers to methods of partitioning or segregating a server’s resources such that the allocation of CPUs to the Oracle software is fixed and cannot be changed dynamically.

In other words, hard partitioning means physically segmenting a server into distinct smaller systems, each acting as an independent server​. Oracle does recognize certain hard partitioning technologies as legitimate ways to limit the number of licenses required.

If you use an approved hard partitioning method to confine Oracle to a subset of a machine, you only need to license the CPUs in that subset, not the whole server or cluster.

In Oracle’s description, hard partitioning involves configuring a server so that Oracle programs are restricted to a specific number of CPU cores or processors. For example, if a server has 16 cores, you might create a hard partition of 4 cores and run Oracle within that partition.

Oracle would then accept licensing based on four cores, assuming the partitioning method is on their approved list. The key is that the partition is enforced at a low level (hardware or hypervisor) and cannot be altered on the fly without deliberate reconfiguration. This provides Oracle with confidence that the Oracle software cannot use more cores than licensed.

Oracle’s Partitioning Policy document explicitly lists the technologies it accepts as hard partitioning for license purposes. The currently approved hard partitioning methods include​:

• Physical Domains – Also known as PDomains, Dynamic System Domains, or similar. These are hardware partitions (common on high-end Unix servers, such as Oracle/Sun SPARC M-series or Fujitsu M-series) where boards or CPUs are split into separate, electrically isolated domains.
• Oracle Solaris Zones (with capped CPU allocation) – Solaris Zones/Containers can be hard partitioned only if configured as “capped zones”, meaning a fixed number of cores is dedicated to the zone​. Uncapped Solaris Zones (the default, which can use any available CPU) are not considered hard partitioning. With capped zones, Oracle will license only the capped CPU amount.
• IBM’s LPAR on Power Systems (with static capacity) – IBM Logical Partitions (LPARs) on AIX can qualify if set to a fixed maximum CPU capacity. Oracle allows hard partitioning on Power if the LPAR is capped to a specific number of processor cores​. (Dynamic LPAR that can grow/shrink is considered soft unless you always license to the peak.) IBM’s older terms like DLPAR (Dynamic LPAR) are supported only to the extent that you don’t exceed the licensed core count – if you do, you must adjust licensing accordingly.
• IBM Micro-Partitions (capped) – Similarly, IBM PowerVM supports micro-partitions, which involve sub-CPU allocation. Oracle recognizes these only if capped – i.e., if an LPAR is set to use a maximum of n processing units and not exceed it​.
• HPE vPar and nPar – On HPE Integrity servers (running HP-UX on Itanium) or older HPE Superdome systems, vPars (virtual partitions) and nPars (node partitions) are accepted as hard partitions. An nPar is a hardware partition, similar to a cell-based division of a server, and is inherently a hard partition. vPars (software partitions on Integrity) can be hard partitions if configured with fixed CPUs​.
• HPE Integrity Virtual Machine (IVM) – capped – Integrity VM is an HP-UX virtualization feature; Oracle allows it for sub-capacity licensing only if the virtual machine’s CPUs are capped​.
• Fujitsu PPAR – Fujitsu’s Partitioning (used in Fujitsu PrimePower/SPARC systems) is on Oracle’s list of hard partitioning technologies​.
• Secure Resource Partitions (Oracle Solaris or others) – Oracle mentions “Secure Resource Partitions” (an old Oracle Solaris 10 feature) as approved if configured with caps.
• Oracle VM Server (Oracle’s hypervisor) – with proper configuration, Oracle VM Server (for x86 or SPARC) can be used as a hard partitioning technology, but only if configured according to Oracle’s hard partitioning requirements​. Specifically, this usually means using CPU pinning or “processor capping” so that a specific VM is assigned to a certain set of CPU cores. For Oracle VM Server for SPARC (also known as LDoms), you must assign an entire core to a domain to count as a hard partition. For Oracle VM Server for x86, Oracle required a technique to bind virtual CPUs to physical cores, which, as of Oracle VM 3, was achieved through hard partitioning configurations in Oracle VM Manager. In short, Oracle VM qualifies as hard partitioning only if you dedicate CPUs to it and do not allow them to float freely. Oracle’s Partitioning Policy notes that the rules for OVM are precise, and you should thoroughly understand them before relying on OVM for license reduction​. (If OVM is used in default mode with live migration and no CPU pinning, it would be treated as soft partitioning.)
• Oracle Linux KVM – with CPU pinning – In 2019, Oracle added Oracle Linux KVM (Kernel-based Virtual Machine) to the approved list, provided that you use a specific process to pin vCPUs to physical CPU cores using Oracle Linux Virtualization Manager. Essentially, Oracle Linux KVM supports hard partitioning by preventing a VM’s vCPUs from running on any cores beyond a designated set. Oracle published a “Hard Partitioning with Oracle Linux KVM” paper describing how to configure CPU pinning to meet the requirements. A crucial caveat: if you pin VMs to cores in KVM for licensing purposes, you are not allowed to live-migrate those VMs to other hosts, as this would break the partitioning guarantees​. (If you did live-migrate, Oracle’s policy says you then must license the equivalent number of physical hosts as VMs using Oracle software, up to the whole cluster​ – effectively eliminating the sub-capacity benefit.)

Oracle’s approved list may evolve slightly over time, but it is typically limited to the technologies mentioned above. Notably absent from the list are general-purpose hypervisors, such as VMware and Hyper-V, or container platforms, which reinforce that these are not accepted for limiting licenses.

Oracle sometimes uses the term “Trusted Partition” for certain situations: a Trusted Partition is an arrangement where Oracle permits subset licensing without the usual restrictions on live migration, but this is only available on Oracle’s own engineered systems (like Oracle Exadata, Oracle ODA, etc.) with Oracle-approved virtualization like OVM configured under Oracle’s supervision​.

For most customers, Trusted Partitions are not applicable unless you invest in Oracle’s specialized hardware and get Oracle’s agreement.

The general rule for a technology to be hard partitioning is that it physically or logically prevents Oracle from using more than a fixed number of CPU cores. All approved methods must have a capped allocation of CPUs​. If a partition can grow or share CPUs beyond its limit, it won’t qualify.

When configured correctly, these hard partitioning methods allow you to use “sub-capacity” licensing – i.e., license only the portion of the hardware allocated to Oracle, not the entire system. This can be a powerful cost-saving strategy, as we’ll see later, but it must be done in strict accordance with Oracle’s policy.

For easy reference, Table 1 below summarizes examples of soft vs. hard partitioning technologies and whether Oracle accepts them for limiting license counts:

(Table 1: Examples of partitioning technologies and Oracle’s classification for licensing purposes.)

As shown above, unless your environment’s partitioning method appears in the “Yes” category (and is configured properly), Oracle will consider it a soft partitioning scenario and will not limit license requirements based on the virtual or partitioned boundaries.

In those cases, you have to count all the physical cores in the server or cluster when determining how many licenses you need.

Licensing Implications and Real-World Examples

The practical implication of Oracle’s policy is stark. If you are not using an Oracle-approved hard partitioning method, you must license every physical processor that could run the Oracle software.

This typically means licensing the entire server on which Oracle is installed, or even an entire cluster of servers if the virtualization allows VMs to move between hosts.

To illustrate, consider a common scenario: an organization runs an Oracle Database on a VMware vSphere cluster. They allocate the DB a VM with four vCPUs on a single host that has, say, 32 physical CPU cores (across two sockets). The team might initially think only those 4 vCPUs (or the one host) need licensing.

Oracle’s view, however, is very different. According to Oracle’s partitioning policy, VMware is soft partitioning, so the Oracle database is essentially considered “installed” on the entire cluster. If the cluster has 10 hosts, each with 32 cores, Oracle expects the customer to license all 320 cores (minus any multi-core factor) for the database, even if it mostly runs on just one host.

Oracle LMS has indeed required customers to license “all physical processor cores on all hosts in certain virtualization environments where Oracle software is present​.” In our example, that could turn a requirement of a couple of licenses into dozens of licenses, potentially a compliance gap worth millions of dollars in license fees.

VMware and Oracle Audits: VMware is the most cited real-world example of this policy in action. Oracle often requires customers running Oracle on VMware to license every host that is part of the VMware cluster (or vCenter) where the Oracle VM resides.

Oracle’s reasoning: with features like VMware vMotion and DRS, any host in the cluster (or even linked clusters) could run the Oracle workload, so all those hosts count as “where the program is installed and/or running.” One legal analysis summarized Oracle’s stance: a cluster of virtualization hosts within a VMware vCenter must be fully licensed for any Oracle product running on any host in that cluster, even if affinity rules limit the VM to a single host.

During audits, Oracle has adhered to this interpretation, leading to scenarios where companies face substantial back-licensing claims. For instance, Company X might have only two Oracle database instances, each on a small VM, but if those VMs are part of a large vSphere farm, Oracle may claim that the entire farm (dozens of servers) should have been licensed.

Many companies only discover this after an LMS audit, finding themselves owing Oracle for perhaps 20 or 30 additional processor licenses. As Certero (an Oracle SAM tool provider) noted, “we have come across many sites that made this mistake, and it is usually only picked up during Oracle audits, leading to large true-up costs.”​

A common real-world example: Oracle on VMware vSphere 6. In vSphere 6 and later, VMware made it possible to vMotion VMs across different clusters and even vCenters, with Cross-vCenter vMotion.

Oracle, correspondingly, has taken the position that if Oracle software is present anywhere in a vCenter, all hosts under that vCenter could potentially run it and thus must be licensed. This can extend the scope to hundreds of servers if not controlled.

To avoid this, many Oracle customers have started isolating Oracle workloads into dedicated vCenters or clusters that are not connected to non-Oracle servers. Isolation can be a mitigating strategy – for example, keep a small 2-host cluster just for Oracle – but one must be very careful that there is no shared vMotion or shared storage that could blur the boundaries in Oracle’s eyes.

Oracle will interpret any technical possibility of movement as a reason to include hardware in licensing. So, the safest approach with VMware (if you want sub-capacity) is often physical segregation of Oracle environments or using an approved hard partitioning within VMware hosts.

Although VMware’s hypervisor is not approved, you could theoretically run something like Oracle Linux KVM nested or use BIOS partitioning – but these are uncommon options.

The more practical approach is either to license the whole cluster (budget for it upfront) or contain Oracle to a smaller cluster that you can afford to license entirely.

Other Virtualization Examples: Oracle’s policy has similarly caught customers off-guard on other platforms:

• AIX/PowerVM users sometimes assumed they could use uncapped LPARs for flexibility and only license average usage. Still, Oracle will demand that the highest possible CPU usage (the full box if uncapped) be licensed. Only static (capped) LPARs avoid this. If an audit finds Oracle in an uncapped LPAR, Oracle can insist that the entire physical server’s cores be licensed, because the partition wasn’t a hard wall.
• Solaris admins might run Oracle in non-capped zones, thinking they separated workloads. In an audit, Oracle would treat it as if it were installed on the entire server (since an uncapped zone can use any core). The fix would have been to cap the zone and document it; otherwise, reverting to licensing all cores is likely.
• Even with Oracle’s virtualization, mistakes happen: if an Oracle VM Server for x86 weren’t set up with hard partitioning (CPU pinning), an auditor would count the full host. Or if someone pinned CPUs but then used live migration for convenience, they might unknowingly void the hard partitioning, again making all hosts count.

Policy vs. Contract – A Crucial Distinction: It’s important to note that Oracle’s Partitioning Policy is a policy document, not a contractual term. Nowhere in Oracle’s standard license agreements, such as the Oracle Master Agreement (OMA), is this Partitioning Policy explicitly incorporated.

The contracts usually define the Processor metric as “all processors where Oracle Programs are installed and/or running​.” Oracle interprets this broadly with the help of the policy, effectively saying “installed and/or running” includes any host where it could run under a soft partitioning scenario.

However, legally, customers could challenge Oracle on the basis that the software was never actually installed or running on those other hosts. The Partitioning Policy itself states that it is for educational purposes and not part of the agreement.

In practice, though, Oracle enforces the policy during audits as if it were binding. They expect customers to adhere to the policy’s definitions. One law firm commented that Oracle’s aggressive use of the policy often “surprises” customers, but since the policy is not in the contract, the customers theoretically could push back​.

The challenge is that mounting a legal fight against Oracle’s audit findings can be an uphill battle – it may involve costly litigation or strained negotiations. Oracle’s audit team will usually stand firm on requiring licenses according to the Partitioning Policy, leaving the customer to either negotiate a settlement (often with a discount or the addition of other products) or escalate the dispute.

For SAM managers and IT architects, the pragmatic approach is to treat Oracle’s partitioning policy as the de facto rule when planning deployments, even if it is not explicitly part of the contract.

As one Oracle licensing advisor puts it, you can reference the policy in discussions, but “since it is not legally binding, your actual contract terms hold greater importance during an audit​.”

In other words, you should design your environment so that it would satisfy both the contract language and Oracle’s policy interpretation, to avoid even getting into a conflict. Relying on the argument that “the policy isn’t in my contract” might be a last resort defense, but by then, Oracle might already have hit you with a non-compliance bill. It’s usually better to avoid the scenario altogether by being proactive.

Cost Impact: Hard Partitioning vs. Full-Capacity Licensing

Oracle software, especially enterprise products like Oracle Database and WebLogic, is notoriously expensive, typically licensed per processor. The difference between licensing a full server and a portion of a server can be dramatic in terms of cost.

Let’s quantify the savings potential with an example:

Scenario: You have a physical server with 8 CPU cores (modern x86 processors), and you want to run Oracle Database Enterprise Edition on it. Oracle’s price for Enterprise Edition is $47,500 per processor license (list price)​ , and Oracle defines a processor for licensing as a core multiplied by a factor (common Intel/AMD x86 cores have a 0.5 factor)​. This means each core effectively costs $23,750 in licenses (because two cores = one license at 0.5 factor each). Additionally, annual support is about 22% of the license fee (around $10,450 per license per year at list)​.

Now compare the two approaches:

• No Partitioning (License Full Server): All eight cores are available to Oracle, so with a
• 0.5 core factor, which counts as 4 Oracle licenses. At $47,500 each, that’s $190,000 in licenses required, plus about $41,800 per year in support fees.
• Approved Hard Partitioning to 2 Cores: Suppose we use hard partitioning (say, we create a capped zone or a pinned VM) to limit Oracle to 2 cores on that server. 2 cores × 0.5 factor = 1 Oracle processor license needed. At $47,500, that’s only $47,500 in licenses, and $10,450 per year in support. We are effectively only paying for 1/4 of the server’s capacity.

The difference in this example is $142,500 in upfront license savings, and about $31,350 less in annual support costs (support is calculated as 22% of the license, so it scales down similarly). Over a few years, these savings multiply, freeing budget for other needs. Table 2 summarizes this comparison:

(Table 2: Example cost comparison for Oracle Database EE on an 8-core server vs. limiting to 2 cores via hard partitioning. List prices used; actual prices may vary with discounts.)

In this simple scenario, using hard partitioning to license only two cores yields a 75% reduction in license count and cost. The savings would be even larger in environments with more cores or more servers. Consider a larger example: a VMware cluster with four hosts, each with 16 cores, for a total of 64 cores.

If treated as soft partitioning, Oracle might require 32 licenses (64 cores × 0.5) for the cluster. Using per-processor list pricing, that’s roughly $1.52 million in licenses. If the Oracle workload could be constrained to one host with eight cores using an approved method, it would require 4 licenses ($190,000).

The savings in that case would be well over $1 million. Of course, not everyone can limit Oracle to such a small footprint – performance requirements matter – but the point is that understanding partitioning options can prevent unnecessary over-licensing.

Many Oracle customers have substantially over-provisioned licenses to stay compliant with Oracle’s policy (for instance, licensing a whole 10-host cluster when their Oracle VM only needed two cores).

By re-architecting with hard partitioning, they could potentially free up licenses or reduce support costs. Given Oracle’s support fees accumulate year after year with increases, optimizing license counts can have long-term TCO benefits.

It’s also worth noting the difference with Oracle Standard Edition (SE) products: Standard Edition 2 is licensed per socket (up to a certain number of sockets) rather than per core, at a lower price ($17,500 per processor or socket). The Standard Edition has its restrictions (e.g., it can only run on servers with a maximum of 2 sockets and cannot use certain partitioning methods to exceed that limit).

Partitioning policy still matters for SE in that if you run SE in a virtualization environment that spans big hardware, Oracle could claim you exceed the socket limits. Hard partitioning could conceivably be used to confine Standard Edition to allowable sizes as well. The savings with SE are different due to the metric, but the principle of not licensing more hardware than necessary still applies.

In summary, proper use of Oracle-approved hard partitioning is one of the few ways to achieve sub-capacity licensing with Oracle and avoid paying for idle or unused CPU capacity.

The potential cost savings are significant, but they will only be realized if you strictly adhere to Oracle’s policies and document your configurations.

Otherwise, you might end up either inadvertently non-compliant (owing a large true-up) or over-compliant (buying way more licenses than you use). The next section provides recommendations on how to navigate these issues effectively.

Recommendations for SAM Teams and Oracle Licensing Professionals

To manage Oracle licensing in virtualized environments and avoid costly mistakes, consider the following best practices:

• 1. Always Identify the Partitioning Method: For every environment where Oracle software is deployed, determine the partitioning or virtualization technology in use. Classify it as soft or hard partitioning per Oracle’s definitions. This should be a standard step in architectural design and during any license review. If it’s a technology not explicitly on Oracle’s hard partitioning list, assume it will not limit your licensing requirements. Treat such environments as if all physical resources count toward Oracle licensing.
• 2. Use Oracle-approved hard partitioning to Contain License Needs: If you want to limit Oracle licenses, choose technologies that Oracle accepts. For example, on IBM Power systems, use capped LPARs for Oracle workloads. On Solaris, use capped Zones for Oracle. If you are considering virtualization on x86 for Oracle, evaluate using Oracle Linux KVM with CPU pinning or Oracle VM Server with hard partitioning mode for those workloads​. These can give you VM flexibility while staying compliant with sub-capacity rules. Document the configurations thoroughly (which cores are allocated, how it’s enforced) so you can show auditors that you followed Oracle’s hard partitioning requirements. Remember that any change to these configurations (such as uncapping an LPAR or enabling vMotion on a pinned VM) can void sub-capacity eligibility, so manage changes carefully.
• 3. Avoid Mixed Oracle and Non-Oracle Workloads in Uncontrolled Virtual Environments: A common licensing trap is running Oracle in the same VMware or Hyper-V cluster as other workloads. While technically it works, licensing-wise it entangles the whole cluster. Segregate Oracle workloads to dedicated clusters or hosts if using non-approved virtualization. Many companies maintain a separate VMware cluster just for Oracle databases, which they fully license, so that other clusters are not in scope. If segregation at the cluster level is not possible, at least use strict vCenter rules or separate vCenter instances to contain where Oracle VMs can run. This may add some infrastructure cost (having dedicated hosts for Oracle), but it can save a fortune in licenses by reducing the number of hosts you need to license.
• 4. Do Not Rely on Soft Partitioning or Unofficial Capabilities for Compliance: Sometimes, IT staff might think, “We set a limit in the hypervisor/OS, so we’re compliant.” For Oracle, that is not a safe assumption. Train your virtualization and cloud teams about Oracle’s rules. Ensure everyone understands that features like DRS rules, affinity, or cgroups are not license-reducing measures for Oracle. This awareness can prevent well-intentioned but risky configurations. If a limit is not one of Oracle’s approved hard partitions, it doesn’t count in Oracle’s eyes – period​.
• 5. Factor Oracle’s Policy into Project Planning: When planning new deployments or migrating Oracle software, include licensing impact as a criterion for platform selection. For instance, if you plan to deploy a new Oracle WebLogic Server cluster, you might decide to use Oracle Linux KVM with CPU pinning instead of an existing VMware farm, solely to take advantage of sub-capacity licensing. The licensing savings might justify that design choice. Always run the numbers: sometimes buying an extra physical server to isolate Oracle or using a specific partitioning technology is far cheaper than licensing Oracle on an entire large cluster.
• 6. Keep Contracts and Policies on Hand: Maintain copies of Oracle’s Partitioning Policy document and your Oracle contract (OMA or OLSA). While the policy isn’t part of the contract, it’s the reference Oracle will use in audits. Knowing the exact wording (e.g., the definition of ‘Processor’ and examples of approved partitioning) helps in internal discussions and audit defense preparation. If Oracle updates its policy (it occasionally revises the list of approved technologies), ensure you get the latest version. As of the latest update, technologies like Oracle KVM have been added (which may not have been available years ago), so staying current can open up new options for you.
• 7. Proactively Engage with Oracle or Experts if Unsure: If you have a complex environment, such as a hybrid cloud or a large virtual infrastructure, and it’s unclear how Oracle will view it, consider reaching out to Oracle (or a third-party licensing expert) before deploying Oracle software there. While Oracle Sales might push for full licensing, you can sometimes get clarity on what they consider compliant. Independent licensing advisors can also help simulate an audit and identify non-compliant setups before Oracle does. It’s better to discover and fix a partitioning or licensing issue early than under the pressure of an actual audit.
• 8. Monitor and Document Hard Partition Configurations: If you do implement hard partitioning (e.g., a capped zone or pinned VM), continuously monitor that those settings remain in place. Changes in personnel or updates to systems can accidentally remove caps or allow migrations. Keep a record (such as screenshots, configuration files, VMware host settings, etc.) that shows the partitioning configuration at regular intervals. In an audit, being able to demonstrate that “Oracle was always confined to X cores on this server, here is the proof” can make your case much easier. If possible, use tooling to alert if an Oracle VM is moved to an unlicensed host or if someone increases its CPU count beyond the licensed limit – catch it before it becomes a compliance issue.
• 9. Consider License Editions and Options: Sometimes the best way to reduce Oracle licensing cost is to reduce usage or use a different edition, rather than partitioning. For example, Oracle Standard Edition 2 might be sufficient for certain databases and has different licensing rules (per socket) that could be more favorable on smaller servers. The Standard Edition cannot be run on large multi-socket machines or large clusters, which incidentally avoids the partitioning issue because it is not allowed in those setups. While this goes beyond partitioning, it’s part of a holistic strategy: use the right Oracle edition for the right workload, and you might avoid the need for complex partitioning tricks altogether. Similarly, assess whether you need the Oracle product on a virtual platform. If an Oracle database is for a small app, running it on a dedicated, small physical server (with licenses for just 2 cores, for example) may be simpler and cheaper than placing it on a large hypervisor cluster.
• 10. Be Prepared for Audits: Even with your best efforts, Oracle may still audit your environment. If you have followed the recommendations – segregated Oracle deployments, used hard partitioning where possible, and licensed any soft partitions fully – you should be in a strong position. Keep an audit readiness kit with documentation of your partitioning setups, proofs of usage, and your interpretation of the license requirements. If Oracle’s auditors challenge your use of partitioning, calmly present the evidence of what you have done in line with their policy. If you have, for example, pinned an Oracle Linux KVM VM to 4 cores and not migrated it, show them the configuration and Oracle’s hard partitioning guide. While the auditors might still try to find fault, having thorough documentation usually short-circuits protracted arguments. And if it comes to a dispute (e.g., Oracle claims a host should be licensed but you disagree based on contract language), involve legal counsel or licensing specialists – do not simply concede to a huge compliance bill without reviewing your contractual rights.

In conclusion, Oracle’s Partitioning Policy has a significant impact on how you must license Oracle Database and other Oracle software in virtualized or partitioned environments. Soft partitioning will not reduce your license requirements – ignoring this fact has led many companies into compliance trouble.

On the other hand, hard partitioning, when done correctly, is a valuable tool for limiting license exposure and optimizing costs, essentially allowing Oracle sub-capacity licensing in a controlled manner. SAM managers and IT architects should design Oracle deployments with these constraints in mind to avoid “license traps.”

Always remember that Oracle’s policy, while not legally binding on its own, is effectively enforced in practice, so it’s wise to align with it in your operations. By leveraging approved partitioning techniques, keeping Oracle workloads appropriately isolated, and staying vigilant about compliance, you can achieve a balance: meet Oracle’s requirements and minimize your license and support spend.

The result will be a more predictable Oracle licensing position, less risk during audits, and potentially significant savings that can be redirected to other IT initiatives.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit