Implementing Oracle-Approved Hard Partitioning
Oracle-approved hard partitioning technologies enable enterprises to license only a portion of a server’s resources for Oracle software, a key factor in reducing costs in virtualized data centers.
This article serves as a practical guide for CIOs, IT architects, and SAM professionals to implement hard partitioning correctly.
We explain what hard partitioning is, list Oracle-approved methods (such as IBM LPAR, Oracle VM with CPU pinning, and Solaris Zones), and provide best practices for configuring these technologies to ensure Oracle recognizes them.
Real-world examples demonstrate how effective hard partitioning can yield substantial Oracle licensing savings while ensuring compliance.
Read Oracle Partitioning Policy Cost Impact: Real-World Scenarios of Soft vs. Hard Partitioning.
What Is Hard Partitioning and Why Does It Matter
Hard partitioning refers to physically segmenting a server’s resources (CPUs/cores) such that a defined subset is dedicated to specific software, in this case, Oracle products. Unlike “soft partitioning” (dynamic or software-based partitioning), hard partitioning creates fixed resource boundaries.
Oracle’s partitioning policy explicitly recognizes certain hard partitioning technologies as legitimate means to limit software licensing to a portion of a machine (often called sub-capacity licensing).
Why CIOs and CTOs care about hard partitioning:
- Cost Savings: By limiting Oracle to a smaller partition of hardware, you only need to buy licenses for that partition’s capacity instead of the entire server or cluster. In large environments, this can save hundreds of thousands in licensing and support fees.
- Compliance Assurance: Using an Oracle-approved method ensures a defensible configuration in the event of an audit. Oracle will (in theory) accept that you didn’t need to license the parts of the hardware outside the hard partition.
- Predictability: Hard partitions offer a stable and unchanging assignment of resources. This means your Oracle workload won’t unexpectedly use more cores than intended, which helps keep licensing needs predictable.
In summary, hard partitioning is about creating a win-win between performance and cost – you get to virtualize or divide your servers for efficiency, but without incurring Oracle’s wrath or an exorbitant licensing bill for every core in your data center.
Read Oracle Partitioning Policy vs. Contract Terms: How to Push Back on Licensing Demands.
Oracle-Approved Hard Partitioning Technologies
Oracle maintains a list of technologies it deems “hard partitioning” capable. It’s vital to use only the approved methods if you plan to rely on sub-capacity licensing.
Below are some of the primary Oracle-approved hard partitioning technologies and what they entail:
- Oracle VM (OVM) / Oracle Linux KVM with CPU Pinning: Oracle’s hypervisor (OVM) and Oracle Linux Kernel-based Virtual Machine can be configured such that specific CPUs are allocated to an Oracle VM, and that VM is pinned to those CPUs. If you pin an Oracle VM to, say, four cores on a host with 16 cores, Oracle accepts that only those four cores need licensing. The key is to set the CPU affinity or hard pinning so it remains fixed.
- IBM Logical Partition (LPAR) – Capped Mode: On IBM Power Systems, you can create LPARs (logical partitions). Oracle acknowledges LPARs with a hard cap on CPU usage as hard partitions. For example, an LPAR configured to never exceed two cores is considered a separate two-core partition for licensing purposes. (Uncapped LPARs, which can dynamically use more cores, do not count as hard partitioning.)
- Oracle Solaris Zones (capped zones/containers): The Solaris OS allows the creation of zones or containers. If a Solaris Zone is configured as a “capped zone” with a fixed number of CPUs assigned, Oracle treats that as a hard partition. A capped zone with 2 CPUs dedicated means you only license those 2 for Oracle in that zone.
- Physical Domains (PDoms) on certain hardware: Some high-end servers (like Oracle/Sun SPARC Enterprise M-series or Fujitsu servers) have physical domains or dynamic domains that effectively split the hardware into distinct physical partitions. Oracle accepts these PDoms as separate units for licensing. Each domain’s core count can be licensed independently.
- HPE nPartition (nPar): On HPE Integrity and some other HPE servers, nPars provide a hard partition at the hardware firmware level. Oracle recognizes nPars as hard partitions – each nPar is like a standalone server from a licensing view.
- Fujitsu PPAR (Processor Partitioning): Some Fujitsu systems allow processor partitioning (PPAR) where processors are isolated. Oracle’s policy has listed Fujitsu PPAR (with proper capping) as an approved method.
- Dynamic Hardware Partitioning (with strict limits): In certain environments, technologies such as Secure Resource Partitions or other vendor-specific hardware partitions are permitted, provided they are configured with an unchangeable limit on CPU resources.
It’s essential to consult the latest Oracle partitioning policy document for the precise list, as Oracle occasionally updates the approved technologies and versions.
Always ensure the version of technology you use is covered. For example, Oracle might approve IBM LPAR on AIX 7+ with certain settings – you’d want to match those conditions.
Best Practices for Configuring Hard Partitions
Simply using an approved technology isn’t enough; you must configure it correctly. Oracle will only honor the partitioning if specific guidelines are followed:
- Enable Hard Caps or Fixed Allocation: Ensure that any partition or VM is configured with a fixed maximum number of CPU cores that it cannot exceed. For instance, in VMware (which is not approved), you might set a CPU limit, but Oracle ignores it; in Oracle VM or LPAR (which are approved), you must actively set the cap. Always double-check that the setting for a cap is in place and cannot be auto-changed.
- Document the Configuration: Maintain official records of the partition’s setup. For example, if using OVM, document the OVM CPU pinning settings showing VM XYZ is pinned to cores 1-4 of Host A. For LPARs, save the system configuration screen or command outputs that show the partition’s processing units and capacity. This documentation will be your evidence in an audit that “Partition X = Y cores max.”
- Use Supported Versions: For example, Oracle might specify that Oracle VM 3.x with hard partitioning is accepted. If you’re running an extremely old or new version, verify that it’s covered. It’s safest to stick with mainstream, vendor-supported versions of these technologies as listed in Oracle’s policy.
- Avoid Mixing Partition Types on the Same Host: For clarity and safety, if you’re using hard partitions, try not to have ambiguous setups on that hardware. E.g., don’t run both a capped LPAR and an uncapped LPAR on the same server for Oracle and assume Oracle will only notice the capped one. They could argue that the presence of the uncapped means you could exceed the cap. Best practice is to dedicate a host or environment to the controlled partitions for Oracle.
- Test the Limits: After configuring, perform your test – attempt to exceed the resource allocation and ensure it’s truly not possible. For example, try starting additional Oracle processes or loading data to see if the partition restricts usage to the set limit. If the cap fails and Oracle software could utilize more CPU, then the configuration isn’t audit-proof.
- Consistency Across Reboots or Changes: Ensure that your hard partitioning settings persist. Some configurations might reset on reboot if not saved properly. Always implement partitions in a way that they automatically reapply after any system restart or maintenance, so you don’t accidentally run Oracle at full capacity after a power cycle.
Real-World Example: Hard Partitioning in Action
Consider a scenario at a financial services company: They have a powerful 32-core UNIX server hosting various applications, including an Oracle Database for a specific department.
Without partitioning, licensing the entire 32-core machine for Oracle Database Enterprise Edition would require 32 core factor licenses (with a core factor of 0.5 for that architecture, which is 16 licenses). At a list price of roughly $47,500 per processor license, that’s $760,000, plus about $167,000/year in support.
The company instead uses Oracle Solaris on that server and sets up Solaris Zones. They create a dedicated zone for Oracle DB and cap it to 8 cores (out of the 32). Oracle recognizes Solaris-capped Zones as hard partitions. Now, the Oracle zone only needs 8 cores worth of licenses (with a core factor of 0.5, that’s 4 licenses). The cost becomes 4 * $47,500 = $190,000, with $41,800/year in support – a 75% reduction in licensing costs for that server. Meanwhile, the other 24 cores on the machine run non-Oracle workloads or remain available for expansion, without incurring Oracle fees.
During an Oracle audit, the company provided documentation of the Solaris Zone configuration, showing the cap, as well as usage logs confirming that the Oracle DB never exceeded the 8-core limit.
The audit concluded with no findings for that server; Oracle accepted the partitioning since it met their policy criteria. This example highlights how adhering to the strict partitioning rules can legitimately save money and pass Oracle’s scrutiny.
Common Mistakes to Avoid
Even well-intentioned IT teams can make errors in partitioning that negate the benefits. Be mindful to avoid these pitfalls:
- Relying on Unapproved Methods: A classic mistake is assuming that a setting in an unapproved hypervisor (such as setting a vCPU limit in VMware) will count as hard partitioning – it won’t. Oracle ignores such settings in technologies it classifies as soft partitioning. Always stick to the Oracle-approved list.
- Uncapped “Hybrid” Partitions: Configuring an LPAR without capping it, or using Oracle VM without actually pinning CPUs, means you’re not in hard partition territory. Oracle will treat those as soft partitions and could demand full licensing. Double-check that every “partition” is truly restricted.
- Not Keeping Evidence: Years might pass between setting up a hard partition and an Oracle audit. If you don’t keep the config info, you might scramble to prove your setup later. Always archive configuration files and screenshots, or use a tool that periodically documents your environment.
- Assuming Oracle’s Memory or Socket Restrictions Count: Some admins think “I limited the VM’s memory” or “I allocated only one socket to the VM” is enough. Oracle’s policy specifically pertains to CPU cores for licensing purposes. Memory caps or other resource controls are irrelevant to Oracle’s licensing rules. Only CPU restrictions in approved forms count.
- Partial Compliance in a Cluster: If you have a cluster of servers (say multiple hosts for high availability), be careful. Hard partitioning often applies per host. If you live-migrate an Oracle VM from a pinned host to another host that isn’t partitioned, you break compliance. For example, Oracle VM with CPU pinning on Host A is fine, but if that VM can move to Host B, where it’s not pinned, Oracle could suddenly argue that Host B’s full capacity counts. The solution is to similarly partition Host B or restrict VM mobility strictly to configured hosts.
Demonstrating and Maintaining Compliance
Hard partitioning isn’t a “set and forget” from a compliance perspective.
CIOs should institute processes to continuously maintain and demonstrate compliance:
- Regular Audits and Snapshots: Schedule periodic internal audits of Oracle deployments to ensure optimal performance and security. Verify that partitions are still in place and that no one has altered configurations (for instance, increasing a cap to address a performance issue without considering the compliance impact). Taking snapshots of configurations every quarter can help track any changes.
- Change Management Discipline: Tie any modification of virtualization or partition settings into your change management process. For example, if an administrator wants to allocate more CPU resources to an Oracle VM for improved performance, that should trigger a review of the licensing impact. Perhaps the request is denied, or you plan to purchase additional licenses before approving it. Avoid “shadow changes.”
- License Tracking: Maintain a close connection between your CMDB (Configuration Management Database) and your license management system. If an Oracle partition is created with four cores and you have purchased four licenses for it, ensure that you don’t change it to 8 cores unless you also true-up the license counts. A good Software Asset Management (SAM) tool or process can help flag if deployed configurations drift beyond licensed limits.
- Stay Updated on Oracle Policy: Although the policy isn’t contractually binding, it’s still advisable to stay updated on it, as you choose to comply with it to save money. If Oracle were to update the list (say, by removing support for a certain partitioning technology in a future policy version), you would need to know. Usually, Oracle won’t retroactively penalize you if you followed the policy version in effect at the time; however, it’s a gray area. It’s best to align with the latest accepted practices or be prepared to defend using the terms of an older policy.
By actively managing your hard partitioning approach, you ensure that the cost benefits are preserved and your compliance position remains solid over time.
Recommendations
- Choose the Right Technology: Select a hard partitioning method that suits your environment (e.g., OVM, LPAR, Zones) and verify it’s on Oracle’s approved list. Standardize on that technology for Oracle workloads to simplify compliance.
- Engage Expertise for Setup: When first configuring hard partitions, involve experts – whether internal infrastructure architects or external consultants – who have experience with Oracle’s requirements. A correctly set partition from day one will prevent costly rework later.
- Explicitly Document Configurations: Create a “license binder” for each Oracle deployment that relies on partitioning. Include configuration screenshots, partition definitions, hostnames, and the exact CPU allocations. Update this documentation whenever something changes.
- Lock Down Settings: Use administrative controls to prevent unauthorized changes. For example, restrict hypervisor admin access to only a few trusted individuals if those changes could affect partitioning. Implement alerts in your virtualization management console to notify you if someone modifies CPU allocation on critical Oracle VMs.
- Test Audit Your Setup: Periodically simulate an Oracle audit internally. Have your team present the partitioning evidence and see if it justifies the licensing. This drill can identify gaps (e.g., “we lost the config file for that LPAR”) while there’s time to fix them.
- Balance Performance and Cost: When deciding how many cores to allocate in a hard partition, find a balance. Don’t starve the Oracle system (which could tempt admins to break the partition out of necessity), but also don’t allocate so many cores that you lose the cost benefit. Monitor Oracle workload performance to ensure the partitioned resources are sufficient.
- Plan for Growth: If you anticipate needing more Oracle capacity, plan how you’ll scale within the hard partitioning framework. For instance, you might add another hard-partitioned server rather than converting a 4-core partition to an 8-core (triggering more licenses). Incremental scaling with additional partitions can sometimes be more license-efficient than expanding an existing one.
- Keep Communication Open with Oracle (Carefully): If you are unsure whether your planned partitioning setup will be accepted, consider asking Oracle (or a third-party licensing advisor) for their opinion. Be cautious in how you ask (don’t imply you’ve deployed non-compliantly). Phrasing like “We intend to deploy Oracle on Solaris Zones capped at X cores – can Oracle confirm this aligns with its partitioning policy?” can sometimes get you a written statement from Oracle you can file away.
FAQ
Q1: What are the main Oracle-approved hard partitioning methods we should consider?
A: Some of the most common ones include Oracle VM/Oracle Linux KVM with CPU pinning, IBM LPAR in capped mode, Solaris Zones (capped), HPE nPars, and Physical Domains on supported hardware. These methods physically or statistically segment resources. Always check Oracle’s latest policy for the definitive list and any specifics (for example, Oracle might list particular versions or configurations required for acceptance).
Q2: Is VMware ever considered hard partitioning by Oracle?
A: No, Oracle treats VMware (all versions, including vSphere 7.x and 8.x) as soft partitioning. Regardless of how you configure VMware (such as setting CPU affinity or using host/DSR rules), Oracle will not consider it an approved hard partitioning method. The only partial exception is Oracle’s virtualization (OVM or Oracle Linux KVM), where Oracle naturally trusts its technology when configured correctly.
Q3: How can I prove to Oracle that I’ve configured a hard partition correctly?
A: Provide evidence like configuration files, screenshots from management consoles, or output from system commands that show the CPU allocation. For example, on an IBM Power system, the lparstat HMC screen can show an LPAR’s processing units and capacity. For Oracle VM, the OVM Manager interface can show a VM’s pinned CPUs. During an audit, presenting these along with a clear explanation should demonstrate compliance. It’s also wise to maintain a narrative document explaining your partitioning setup for each relevant environment.
Q4: If I use hard partitioning, do I need fewer Oracle licenses?
A: Exactly – that’s the point. You need licenses only for the cores you allocate to the Oracle partition, not the whole system. If your partition has four cores (on hardware with a 0.5 core factor), that’s two processor licenses required, regardless if the machine has 32 cores in total. Ensure that no Oracle usage occurs outside the partition, and the partition can’t grow beyond 4.
Q5: What happens if we temporarily change a partition (e.g., to add more CPU for a heavy workload) and then reduce it back?
A: Technically, during the time it was higher, you would have been out of compliance if you didn’t have licenses for those extra cores. Oracle audits often examine past usage, not just current usage. If you increase a cap or break a partition even briefly, it creates risk. It’s safer to avoid such changes or, if needed, consider them permanent and purchase additional licenses. A short-term change might fly under the radar, but if Oracle audited and found evidence (logs, configs) that for 2 months you had eight cores instead of 4, they could claim you needed licenses for that period. Consistency is key.
Q6: Are there performance downsides to hard partitioning?
A: The main limitation is that you’ve capped resources. If your Oracle workload suddenly needs more CPU than the partition allows, performance will suffer unless you adjust the partition (which, as discussed, has licensing implications). Hard partitioning trades some flexibility for cost control. However, many enterprise workloads can be sized appropriately. Another consideration is that using certain technologies (like older OVM or specific hardware partitions) might not be as feature-rich or as familiar to your team as, say, VMware. There could be an operational learning curve.
Q7: Can we mix hard-partitioned Oracle environments with other virtualization?
A: Yes, but carefully. For example, you might have a dedicated Oracle server using hard partitions for your databases, and the rest of your environment runs on VMware for non-Oracle apps. That’s fine. What you should avoid is intermixing them in a way that confuses boundaries – e.g., do not connect an Oracle hard-partitioned server to a VMware cluster via live migration or similar methods. Keep Oracle hard partitions isolated to ensure clarity of what needs to be licensed.
Q8: Does using hard partitioning affect Oracle support or compatibility?
A: Generally, no – if you’re using Oracle-approved methods, Oracle fully supports their software running in those environments. For instance, Oracle will support the Database on IBM AIX LPAR or Oracle VM. Just be sure to follow any support notes or configuration requirements (Oracle may have documentation on how to configure their database on those platforms optimally). In contrast, if you run in an unapproved environment (such as VMware), Oracle’s support will still assist you; however, if they suspect an issue is due to the environment, they may ask you to reproduce it on a physical or approved setup.
Q9: Are cloud environments considered hard partitioning?
A: Public cloud (AWS, Azure, etc.) is a different animal. Oracle has a policy for cloud licensing that lets you count virtual CPUs, but it’s not part of the partitioning policy. Oracle Cloud Infrastructure (OCI) allows you to choose the number of OCPUs for an instance – effectively sub-capacity – but again, that’s governed by cloud-specific terms (and because it’s Oracle’s cloud). If we focus on on-premises, think of hard partitioning as your on-prem cloud strategy for Oracle. For cloud, consult Oracle’s cloud licensing rules, which are generally more favorable than on-premises soft partitioning, but this is separate from what we’re discussing here.
Q10: If Oracle updates its partitioning policy and removes a technology we use, are we at risk?
A: This is a tricky situation. Suppose Oracle were to stop recognizing a certain partitioning method in a future policy version (although it’s rare, it’s hypothetically possible). If you implemented it in good faith under the older policy, you have a strong argument to Oracle that you followed their guidance at the time. Oracle cannot retroactively change your contract, and you could argue estoppel (i.e., you relied on their representation). However, Oracle might still challenge it. In practice, Oracle’s list of approved hard partition technologies hasn’t shrunk; it has mostly expanded or clarified over time. If such a change occurs, you may preemptively engage with Oracle or adjust your strategy (e.g., move to another approved method). It underscores why staying current on Oracle’s communications matters, even if they’re not binding.
