Oracle Partitioning Policy – Do You Need Follow It?

Oracle Partitioning Policy Document

• Outlines licensing requirements for physical processor cores in certain virtualization environments.
• Applies to all Oracle products, including “soft partitioning” technologies like VMware.
• It is not explicitly part of Oracle’s license agreements or referenced in the Master Agreement.
• Aggressively enforced by Oracle’s License Management Services during audits.
• Companies should work with legal counsel to resist unsupported audit findings and ensure compliance.

Oracle Partitioning Policy

Oracle’s Partitioning Policy is a set of rules that dramatically impact how you must license Oracle software in virtualized, on-premises environments.

In essence, Oracle distinguishes between soft partitioning (flexible virtualization that does not limit licensing requirements) and hard partitioning (Oracle-approved methods that can reduce license needs).

Understanding these rules is critical: misuse of virtualization can lead to non-compliance and multi-million dollar licensing exposure, whereas proper partitioning strategies can save costs and avoid audit surprises.

Soft Partitioning: Why It Doesn’t Reduce Oracle License Requirements

“Soft partitioning” refers to virtualization techniques or OS resource controls that do not physically bind software to specific hardware resources.

This includes the most common hypervisors and software-based CPU limits. Oracle’s policy explicitly states that soft partitioning is not accepted to limit software licenses.

In practical terms, if you run an Oracle database on a VM in a soft-partitioned environment, Oracle will treat it as if it could use all the physical cores in that server or cluster.

Key points about soft partitioning:

• Flexible Resource Allocation: Soft partitioning enables the dynamic adjustment of CPU/RAM resources to VMs or processes (e.g., VMware vSphere, Microsoft Hyper-V, Linux cgroups). While efficient for IT operations, these flexible allocations are ignored by Oracle licensing.
• License Full Physical Capacity: Oracle requires you to license every physical processor core in the server or cluster where Oracle software could run. Even if an Oracle VM is limited to 2 vCPUs on a host with 20 cores, Oracle’s stance is that all 20 cores must be licensed because the VM could be reconfigured or moved.
• Examples – VMware & Others: Oracle considers VMware a soft partitioning technology. This means in a VMware ESXi cluster, every host in the cluster must be fully licensed for Oracle if any host runs (or could run) an Oracle workload. Setting VMware affinity rules or DRS constraints to pin a VM to one host is not recognized by Oracle. Similarly, other hypervisors like Hyper-V, Citrix XenServer, or unapproved cloud setups are treated as soft partitions – you cannot just license a subset of cores based on a VM setting. The only way to be compliant in these scenarios is to license the entire environment or isolate Oracle to its licensed hardware.
• Common Misconception: Many IT teams assume that limiting a VM’s CPU count or using OS CPU affinity will reduce Oracle licensing needs. Oracle’s policy rejects this. Unless the partitioning method is Oracle-approved (hard partitioning), you must license full hardware capacity. This misunderstanding has led companies to significantly under-license Oracle deployments in virtual environments, only to face substantial compliance penalties later.

In short, soft partitioning offers no relief for Oracle licensing. Any virtualization method that is not explicitly certified by Oracle for sub-capacity licensing is treated as if no partitioning were in place.

This conservative stance is unique to Oracle, and it’s the source of many unwelcome surprises in Oracle audits.

Hard Partitioning: Oracle-Approved Methods to Limit Licensing

“Hard partitioning” involves segmenting a server’s resources in a fixed, physical way so that an Oracle program is confined to a specific subset of CPU cores.

Oracle permits certain hard partitioning technologies as a legitimate means to reduce the number of licenses required.

In a hard-partitioned setup, you only need to license the cores assigned to the Oracle partition, not the whole server.

Key aspects of hard partitioning include:

• Physical or Static Limits: Hard partitions are typically implemented through hardware or low-level software settings that divide a server into smaller, independent systems. Each partition behaves like a distinct machine with dedicated CPUs and memory that cannot be changed on the fly by normal users. Because the limits are static or enforceable at the hardware level, Oracle “trusts” that the Oracle software truly cannot use more cores than allocated.
• Oracle-Approved Technologies: Oracle maintains a specific list of approved hard partitioning methods. Examples include IBM’s LPAR (with static/capped configurations), IBM PowerVM with static partitions (live mobility is not allowed without full licensing), Oracle Solaris Zones (configured as capped zones/containers), HP nPar and vPar (with fixed resources), and legacy technologies such as Fujitsu PPAR. Notably, Oracle’s virtualization solutions can qualify: Oracle VM Server (OVM) and Oracle Linux KVM can be used for hard partitioning only if CPU pinning is configured according to Oracle’s guidelines. In those cases, you bind VMs or domains to specific cores, essentially creating a fixed partition. Oracle even labels such setups on certain approved hardware as “Oracle Trusted Partitions.”
• Oracle Trusted Partitions: This is a special category for Oracle’s Engineered Systems (like Oracle Exadata, Exalogic, Private Cloud Appliance, etc.). On these systems, if you use Oracle’s hypervisor (OVM) or Oracle Linux KVM with Oracle Enterprise Manager control, Oracle allows sub-capacity licensing with some unique rules. For example, on an Engineered System, Oracle might count 2 vCPUs as one licensed core (a specific concession under the Trusted Partition policy). Trusted Partitions are essentially Oracle saying, “We will trust these particular configurations to license less than full capacity.” However, this is limited to Oracle’s high-end gear and comes with strict monitoring requirements.
• Must Follow the Rules: Using an approved hard partitioning technology does not automatically reduce the license – you must configure it as Oracle requires. This often means setting a hard cap on CPU usage for the partition and documenting it. For instance, simply running Oracle on Oracle VM Server doesn’t save licenses unless you have pinned the VM’s vCPUs to certain physical cores and ensured it can’t float to others. The same applies to IBM Power systems – you must use capped LPARs (with no dynamic expansion) if you want Oracle to accept them. Oracle provides technical whitepapers on how to configure these correctly. If you deviate (e.g., uncap an LPAR or allow a pinned VM to migrate), Oracle will treat the environment as soft partitioned and require full licensing.
• Limited List: It’s essential to note that no other partitioning methods are accepted beyond those explicitly named by Oracle. For example, carving up a server with a non-Oracle virtualization or using container technologies like Docker/Kubernetes to limit CPU isn’t recognized. Oracle’s list is very static and changes only occasionally when Oracle chooses to add a technology. Always refer to the latest Oracle Partitioning Policy document for the current approved list. If it’s not on the list, assume it’s not a valid hard partition in Oracle’s eyes.

By utilizing hard partitioning, organizations can achieve significant cost savings.

Hard partitioning enables “sub-capacity” licensing, where users pay only for the portion of the machine that Oracle uses.

This is the only Oracle-endorsed way to avoid licensing every core in a large server or cluster.

However, because the approved methods are limited, many enterprises find it hard to partition restrictive options (e.g., you might need to use Oracle’s hypervisor or specific hardware platforms).

Deciding whether to adopt an Oracle-approved partitioning method often involves weighing the operational trade-offs against potential license cost savings.

Virtualization on VMware & Other Platforms: Real-World Implications

The vast majority of enterprise virtualization today is done on platforms that Oracle deems “soft partitioning.” VMware vSphere is a prime example and is widely used for on-premises data centers.

Oracle’s Partitioning Policy has significant implications for anyone running Oracle products on VMware, Hyper-V, or similar hypervisors:

• All Hosts in a Cluster Must Be Licensed: Oracle’s auditors typically consider an entire VMware cluster as the environment that “could” run Oracle. Even if you pin an Oracle VM to a single ESXi host, if that host is part of a cluster with, say, 10 hosts, Oracle will insist that you need to license every host’s cores in that cluster. The rationale: features like vMotion mean the Oracle VM could be moved to any host, so all are potential Oracle hosts. From a compliance standpoint, unless you physically break the cluster or disable VM mobility in a way Oracle accepts (which is hard to prove), you are on the hook for the whole cluster’s worth of licenses.
• Real-World Example – The VMware “License Tax”: Imagine you have an Oracle Database VM using four vCPUs on a vSphere cluster of 10 physical servers. If each server has 16 physical cores (resulting in a total of 160 cores in the cluster), Oracle will require licensing for all 160 cores for that single database VM. With Oracle Database Enterprise Edition’s list price of roughly $47,500 per processor license (which covers two physical cores on x86, due to the core factor), this scenario would theoretically cost about $3.8 million in licenses, just to run a small database on a large VM farm. Had that database been on a dedicated 16-core server (hard partitioned to 4 cores), the licenses would cost closer to $190,000. This stark contrast is why Oracle virtualization can become a financial “time bomb.” Many organizations have been caught off guard in audits, faced with unbudgeted bills in the millions for software running on VMware clusters.
• Other Virtualization Platforms: The story is similar for Microsoft Hyper-V, Nutanix AHV, Red Hat Virtualization, or any cloud-like on-prem environments. Unless explicitly approved by Oracle, these are soft partitions. For example, running Oracle on Hyper-V means you should license all physical cores of the Hyper-V host/cluster where that VM resides. Oracle doesn’t publish an exhaustive list of every disallowed platform; instead, it lists the few allowed ones. Therefore, assume that anything not on the hard partition list (which includes none of the common third-party hypervisors) is treated similarly to VMware.
• Standard Edition Considerations: Oracle Standard Edition (SE2) employs a distinct licensing metric (per socket, with server and cluster size limits), which inherently restricts certain virtualization capabilities. For instance, SE2 is only permitted on servers with a maximum of 2 CPU sockets and cannot be deployed on a cluster of more than 2 servers for RAC. If you attempt to run SE2 in a large VMware cluster, you’d violate those terms outright. While Standard Edition’s rules are slightly different, you still cannot use soft partitioning to run SE2 on only part of a big server – the socket limitation and cluster restrictions apply. In practice, Standard Edition is better suited for smaller, non-virtualized or lightly virtualized setups. Companies sometimes use SE2 on small dedicated hosts as a way to avoid the virtualization licensing trap (taking advantage of its lower cost per socket), but this only works for applications that can tolerate the lesser features and performance of SE2.
• Enterprise Products Beyond Database: It’s not just Oracle Database. Any Oracle software licensed by Processor metric (such as WebLogic Server, Oracle Middleware, and Oracle E-Business Suite middleware components) is subject to the same partitioning rule. VMware clusters hosting Oracle middleware will face the same “license all cores” requirement. Oracle Applications (such as EBS, PeopleSoft) often use Named User or Application-Specific licensing, but their underlying technical components (database, WebLogic) also fall under these rules. Always check the licensing basis of each Oracle product when planning virtualization.

The bottom line: If you run Oracle on a virtualization platform that Oracle doesn’t explicitly approve for sub-capacity, plan for full capacity licensing.

Many enterprises mitigate this by segregating Oracle workloads: for example, maintaining a separate VMware cluster solely for Oracle databases, fully licensing that small cluster, and keeping Oracle VMs from ever moving into other clusters.

Some go as far as using dedicated vCenter Servers or physical network segmentation to ensure Oracle VMs cannot drift into unlicensed hardware.

These containment strategies can limit the scope of required licenses. However, they require strict operational discipline. One mistake (like vMotioning an Oracle VM to an unlicensed host even briefly) can theoretically put you out of compliance.

In summary, on-prem virtualization offers great flexibility but collides with Oracle’s licensing rules.

Organizations must proactively design their virtual environments with Oracle’s partitioning policy in mind, or face potentially massive cost and compliance consequences.

Cost Impact Example: Partitioning vs. Full-Capacity Licensing

To illustrate how the partitioning strategy affects costs, consider a simple scenario.

We compare three ways to deploy an Oracle Database on-premises:

1. Dedicated Physical Server (no virtualization) – e.g., one 4-core server for the database.
2. Virtualized on a Large Cluster (soft partitioning) – e.g., a VMware cluster with four hosts, each with 10 cores (40 total cores), where the DB runs as a VM.
3. Virtualized with Hard Partitioning – e.g., the same 4-host cluster (40 cores total) but using an Oracle-approved partitioning method to limit the DB to 4 cores.

For Oracle Database Enterprise Edition, assume a list price of ~$47,500 per processor license (approximately covering two physical cores on x86). The table below compares the licensing requirements and approximate costs:

Notes: This simplified example uses list pricing for illustration. In the VMware cluster scenario, all 40 physical cores require licensing, as Oracle doesn’t recognize the VM’s 4-core limit.

The hard partitioning scenario assumes you configured an approved method (such as OVM with CPU pinning or a capped LPAR) to restrict Oracle to 4 cores on that cluster; thus, only four cores are licensed.

The cost difference is enormous: approximately $1.9 million versus $ 190,000 in this example.

Even after factoring in typical annual support (22% of the license cost, which would add hundreds of thousands of dollars per year in the full-capacity case), the savings of a hard partitioning approach are clear.

Of course, achieving those savings means accepting some limitations.

Using hard partitioning might require specific technology choices or reduced flexibility in moving VMs. Some organizations find it more cost-effective to simply buy the extra licenses for agility’s sake, especially if they have Enterprise Agreements or discounts.

Others take a hybrid approach: license a certain number of hosts fully for Oracle use (essentially treating them as an “Oracle zone”) and keep Oracle off other hosts.

The key is to consciously evaluate the trade-offs and not inadvertently assume a cost reduction that Oracle will later disallow.

Also note the risk of non-compliance costs: The table above shows planned licensing costs, but if you wrongly assumed you only needed four cores licensed when Oracle’s policy says 40, the “savings” evaporate into a huge liability.

Oracle License Management Services (LMS) can audit and back-charge for unlicensed use, often with additional support fees and penalties.

Those unbudgeted costs can far exceed the costs of doing it right upfront.

In one real-world case, a company encountered a compliance gap on dozens of VMware hosts, leading to an unexpected settlement of tens of millions of dollars.

This underscores that cost impact isn’t only about list prices, but also about avoiding worst-case financial exposure.

Compliance Risks and Contract Considerations

Oracle’s Partitioning Policy introduces not only cost implications but also serious compliance risks.

A unique twist here is the policy vs. contract dilemma: Oracle’s partitioning guidelines are published on its website and in policy documents, but they are not explicitly part of the license agreement you sign.

This has several implications:

• Policy Is Not a Contractual Term: If you comb through Oracle’s Master Agreement (OMA/OLSAs) and ordering documents, you won’t find a clause that directly references the Partitioning Policy. Oracle license terms define “Processor” as all processors where the software is installed and/or running, but they don’t explicitly mention how virtualization is handled. The Partitioning Policy is a public document stating Oracle’s interpretation of those definitions. Oracle even labels the policy as educational, non-binding, and subject to change. In a legal sense, this means customers might argue that they are only bound by the contract, not a website policy.
• Oracle’s Enforcement via Audits: Despite the above, Oracle will enforce the Partitioning Policy in audits as if it were binding. Oracle auditors from LMS routinely apply the “all hosts in the cluster” rule when assessing usage. If you try to contest it during an audit by saying “it’s not in the contract,” you may face an uphill battle. Oracle’s stance is that the policy reflects the proper interpretation of the contract’s terms (specifically the definition of Processor and counting rules). In practice, most customers end up negotiating based on Oracle’s policy, unless they’re prepared for a legal fight.
• Legal Pushback is Rare: A few organizations have pushed back legally, as the policy isn’t included in the contract. While there’s merit to the argument, the uncertainty and potential damage to relationships from fighting Oracle in court often deters customers from pursuing this path. Oracle could threaten to revoke discounts or support if a customer is being non-cooperative (though they must be careful not to violate contractual rights). Generally, customers seek a settlement or purchase additional licenses at a discount rather than litigate the definition of “installed and/or running.” However, awareness of the contractual gap can be a negotiation point – some companies have successfully negotiated custom contract clauses or LMS waivers that acknowledge specific virtualization setups.
• Changing Policies: Oracle can update the Partitioning Policy at any time. For example, Oracle recently added Oracle Linux KVM to the list of approved hard partitioning methods (when properly configured). If you rely on a particular method to limit licenses, keep an eye on policy updates to ensure compliance. Oracle typically doesn’t retroactively enforce new rules on existing deployments, but during audits, it will apply the latest policy stance. It’s the customer’s responsibility to stay informed. Regularly check Oracle’s official policy page for changes or consult licensing specialists who track these changes.
• Audit Readiness and Documentation: Given the high stakes, companies should document their virtualization environment as if an audit is inevitable. This means keeping architecture diagrams that show where Oracle workloads run, records of how those environments are configured (e.g., “Oracle VM Server with hard partitioning enabled on Hosts A and B – only these hosts have Oracle, each pinned to 4 cores”), and even screenshots or logs that prove Oracle VMs haven’t drifted to unlicensed hardware. If Oracle comes knocking, the burden of proof often falls on you to demonstrate compliance. Without clear evidence, Oracle will assume non-compliance with its policy.

In summary, Oracle’s Partitioning Policy occupies a grey area between formal contract and practical enforcement.

From a risk management perspective, treat the policy as if it were part of your agreement, because operationally, Oracle will. That means architecting and licensing with those rules in mind to avoid nasty surprises.

If you believe your situation warrants an exception or different interpretation, engage Oracle (or legal counsel) proactively – preferably before an audit – to seek clarification or an amendment.

Don’t simply ignore the policy; the “ignorance defense” won’t get you far when an auditor uncovers an unlicensed cluster of Oracle workloads. Being informed and prepared is your best defense.

Recommendations

To navigate Oracle licensing in virtualized environments and minimize risk, consider these best practices:

• Identify Your Environments: Catalog all virtualization technologies in use where Oracle software runs. Classify each as soft or hard partitioning per Oracle’s definitions. If it’s not on Oracle’s hard-partitioning approved list, assume it requires full hardware licensing. This should be a standard step whenever you deploy Oracle on new infrastructure.
• Use Hard Partitioning Deliberately: Where possible, choose Oracle-approved hard partitioning to contain license costs. For example, on IBM Power servers, use capped LPARs for Oracle workloads. For Oracle deployments on Oracle’s hardware or x86, consider using Oracle Linux KVM with CPU pinning or Oracle VM Server (OVM) in hard partition mode. These allow you to pay for only the cores you allocate to Oracle. Be sure to follow Oracle’s technical guidelines to the letter and document the configuration. If you ever remove the cap or pin, update your records and licenses accordingly.
• Segregate Oracle Workloads: Avoid mixing Oracle and non-Oracle workloads in large, unfettered clusters. A common strategy is to create a dedicated cluster (or set of hosts) for Oracle software. For instance, you might have a small VMware cluster (fully licensed for Oracle) that handles all Oracle VMs, separate from your general VMware farms. This containment limits the scope of licensing. It may require additional hardware or reduced flexibility (you can’t vMotion an Oracle VM to a general cluster), but the license savings often justify the investment. If a separate cluster isn’t possible, use strict policies (such as separate vCenter environments or host affinity rules) to at least isolate where Oracle can run.
• Don’t Rely on Unapproved Limits: Ensure your IT staff understands that software-based limits (soft partitions) are not valid for Oracle compliance. For example, setting a CPU affinity or using VMware’s Distributed Resource Scheduler rules to keep an Oracle VM on one host does not reduce the need for licenses. Make this part of your architectural review and change management process: whenever someone plans to deploy or move Oracle software, the partitioning compliance must be evaluated. This awareness can prevent costly misconfigurations.
• Plan Licensing in Advance: Incorporate Oracle’s partitioning rules into your project planning and architecture decisions. If you’re considering a new virtualization platform for an Oracle-based application, evaluate the licensing impact before you build it. Sometimes the decision might be to avoid virtualization altogether for that system, or to use a specific technology just because it’s more license-friendly. For example, you might decide to use an Oracle Private Cloud Appliance (PCA) or smaller physical servers for an Oracle workload, rather than deploying it into a large VMware cluster, to explicitly control licensing. Always run the cost scenarios – a slightly less consolidated architecture might save millions in licenses.
• Keep Policies & Proof on File: Maintain a repository of Oracle licensing documents, especially the latest Oracle Partitioning Policy, along with your Oracle contracts. Although the policy isn’t in your contract, it serves as the benchmark that Oracle will use in audits. Knowing the exact wording can be crucial in internal discussions or negotiations. Additionally, keep evidence of your compliance measures, such as documents showing which cores are dedicated to Oracle, screenshots of virtualization settings, etc. In an audit, having ready proof that “Oracle has only ever run on these 8 cores, here is how we ensured that” can shorten the debate and demonstrate to auditors that you’re on top of it.
• Consult Experts When in Doubt: If you have a complex environment (e.g., a hybrid cloud or a very large virtual infrastructure) and you’re unsure how Oracle will view it, seek expert advice. This could involve consulting with Oracle representatives (with caution, as sales personnel may push for full licensing) or engaging an independent Oracle licensing consultant. They can help simulate an audit and flag non-compliance risks. It’s much better to discover and address an issue yourself than to have Oracle find it. Additionally, if necessary, experts can assist in crafting arguments or strategies for negotiating an exception with Oracle. Some customers have successfully negotiated contract addendums for specific virtualization technologies; however, this process requires careful handling.
• Monitor Your Environments: If you implement hard partitioning or dedicate certain hosts to Oracle, treat this configuration as sacrosanct. Monitor it continuously. Set up alerts if, say, an Oracle VM is accidentally moved to an unlicensed host or if someone increases a VM’s vCPUs beyond the agreed limit. Catching such a drift immediately allows you to correct course (or procure licenses quickly if needed) before it becomes a bigger problem. Regularly audit your environment: verify that Oracle remains confined to the proper servers/cores. This is part of being audit-ready.
• Consider License Alternatives: In some cases, the most effective way to optimize Oracle costs is to reduce reliance on partitioning altogether. Evaluate if your use of Oracle products is optimal. Could some workloads use Oracle Standard Edition 2 (with its per-socket licensing) on smaller servers to avoid the virtualization minefield? Are there cases where using a cloud service or even a non-Oracle technology could sidestep heavy licensing? While these go beyond the partitioning policy, a holistic approach to Oracle licensing might reveal that segmenting workloads or using different editions/features can save more money than trying to virtuously contain Enterprise Edition licenses on a hypervisor.
• Be Audit-Ready: Always operate under the assumption that an Oracle audit will happen at some point. By following the above recommendations – isolating Oracle deployments, leveraging hard partitioning where viable, and fully licensing any soft-partitioned setups – you will be in a defensible position. Maintain an “audit kit” with all relevant documentation (contracts, policy docs, internal diagrams, usage evidence). If auditors arrive, you can swiftly demonstrate what you’ve done to comply. And suppose there is a disagreement (for example, Oracle claiming a certain host should be licensed because of clustering, but you believe it’s not applicable due to a contract nuance). In that case, you’ll have the information needed to support your case or escalate appropriately. Never simply accept a massive compliance finding without scrutiny; use your data and rights to push back if justified.

Checklist: 5 Actions to Take on Oracle Partitioning

1. Inventory Your Oracle Deployments: List all servers, clusters, and virtualization platforms where Oracle software is running. Confirm whether each environment is using a soft or hard partitioning method. This inventory will highlight any Oracle instances running in unauthorized locations (e.g., a general VMware cluster).
2. Map Licenses to Hardware: For each Oracle deployment, map the physical hardware it can use. Ensure you have sufficient licenses to cover the worst-case scenario (e.g., the entire cluster core if it is soft-partitioned). Identify gaps where licenses are insufficient under Oracle’s rules.
3. Implement Isolation or Controls: Take action on any risky setups to ensure safety. For example, segregate an Oracle workload to a smaller cluster or dedicated hosts, or apply an Oracle-approved hard partitioning configuration. Clearly label and document these systems (internally) as “Oracle-restricted” environments to prevent accidental changes.
4. Document Partitioning Configurations: If you use hard partitioning, keep a record of its configuration. Create a brief dossier for each such system – e.g., “Oracle WebLogic on Solaris Zone capped at four cores, configuration file X, in effect since 2024.” Also, document any operational policies (like “Oracle VMs will not vMotion out of Cluster A”). This documentation will be invaluable for internal knowledge and during audits.
5. Review and Update Regularly: Set a schedule (e.g., quarterly or semi-annually) to review Oracle licensing compliance. Check if Oracle has updated its Partitioning Policy or if you’ve introduced new virtualization tech. Update your plans if, for example, you have added a new VMware cluster, to either license it or exclude Oracle from it. Regular reviews ensure that as your IT environment evolves, you stay compliant and optimized.

FAQ

Q1: Is Oracle’s Partitioning Policy legally binding if it’s not in my contract?
A: Technically, the partitioning policy is not a signed contract document. However, in practice, Oracle will enforce it during audits as if it were binding. Most Oracle agreements define licensing by processor count but don’t detail virtualization. Oracle uses the policy to interpret those terms. While you could challenge it legally, doing so is rare and difficult. It’s safest to assume the policy’s rules apply to you and plan your licensing accordingly, unless you have a negotiated exception in writing.

Q2: How does Oracle treat VMware or Hyper-V clusters for licensing?
A: Oracle considers VMware vSphere, Microsoft Hyper-V, and similar hypervisors as “soft partitioning.” This means Oracle requires you to license every physical core in every host of a cluster where an Oracle VM could potentially run. Even if an Oracle VM is on one host, if that host is part of a 10-node cluster, all 10 nodes’ cores need licensing (because features like live migration mean the Oracle VM isn’t tied down). In short, there is no official sub-capacity licensing on those platforms – you either isolate Oracle to a subset of hosts (and license all those cores) or pay for the whole cluster.

Q3: What are examples of approved hard partitioning methods?
A: Approved hard partitioning methods include technologies that physically or virtually segment a server. Some examples: Oracle VM Server (OVM) with hard partitioning (pinned vCPUs as per Oracle’s guide), Oracle Linux KVM (with specific CPU pinning configuration), IBM LPAR on Power Systems (configured as capped partitions with no dynamic CPU allocation), Oracle Solaris Zones (Solaris Containers configured as capped zones), HP nPar and vPar (hard partitions on Integrity servers), and a few others like Fujitsu PPAR. Oracle Engineered Systems can use “Trusted Partitions” via OVM/KVM with Oracle’s oversight. If your technology isn’t on Oracle’s list (for example, standard VMware ESXi or Docker containers), it’s not an approved hard partition, meaning you cannot use it to reduce licensing.

Q4: How can I reduce Oracle license costs in a virtual environment without violating policy?
A: There are a few approaches:

• Use Hard Partitioning: Leverage an Oracle-approved partitioning tech to confine Oracle to fewer cores. For instance, run your Oracle databases on an Oracle Linux KVM host where you’ve pinned the VM to 4 cores – then license just those four cores. This requires the use of specific technologies and configurations, but it’s the direct way to implement sub-capacity licensing legitimately.
• Dedicated Hardware/Clusters: Instead of mixing Oracle on a big shared virtual cluster, carve out dedicated smaller clusters or physical servers for Oracle. License those fully for Oracle and refrain from running Oracle elsewhere. This limits license scope and can be more cost-effective than licensing a huge environment.
• Optimize License Type/Edition: In some cases, using Oracle Standard Edition 2 on smaller machines (with socket-based licensing) can be cheaper, or using Named User Plus licenses if you have a small user population (keeping in mind Oracle’s minimums per core). Also, review if all your Oracle instances need to be Enterprise Edition or if some could be eliminated or replaced with less costly options. Reducing your Oracle footprint will naturally reduce licensing costs.
• Cloud or Oracle’s Own Cloud: While your question is on-prem focused, it’s worth noting that some organizations move workloads to Oracle’s cloud or authorized cloud environments where licensing works differently (Oracle has cloud policies allowing usage with BYOL more flexibly in some cases). This is a larger decision, but it can sidestep some on-prem virtualization issues.

Q5: What happens if we get audited and found non-compliant due to virtualization?
A: If Oracle audits you and determines that you haven’t licensed the full physical environment per the partitioning policy, they will present a compliance claim. This usually includes backdated license fees for all unlicensed processors (often at list price), plus back support maintenance for those licenses (22% per year, potentially for multiple past years), and sometimes penalties or interest. The result can be a shockingly high number. In many cases, Oracle will then offer to resolve the issue if you purchase a certain number of licenses or a Unlimited License Agreement (ULA) in the future. You do have some room to negotiate – for example, you might argue certain hosts never actually ran Oracle, or that you’ll immediately rectify the situation – but expect Oracle to be aggressive in applying their policy. The best course is to avoid getting into this situation: maintain compliance, and if an audit happens, you can confidently demonstrate that you followed Oracle’s rules. Suppose you genuinely believe Oracle’s assessment is wrong. In that case, you may need to involve legal counsel or licensing experts to dispute it, ideally leveraging the fact that the policy isn’t in the contract. However, that’s a last resort – most audits end in a settlement or purchase, not a courtroom.

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit