IBM's LPAR virtualisation can limit Oracle licence requirements if configured correctly. But missteps such as not capping CPU usage or allowing mobility can lead to licensing the entire server. This independent advisory outlines how Oracle's rules apply to IBM LPARs and provides best practices, cost scenarios, and compliance strategies for ITAM professionals.
IBM POWER's 1.0 core factor is the single biggest cost driver for Oracle on these platforms. An 8-core IBM POWER server requires 8 Oracle processor licences at $47,500 each = $380,000. The same workload on an 8-core Intel Xeon server (core factor 0.5) requires only 4 licences = $190,000. Hardware choice directly impacts Oracle licensing spend. For virtualisation rules, see Oracle Licensing in Virtualised Environments. For partitioning policy, see Oracle Partitioning Policy.
IBM LPAR is a virtualisation feature on IBM Power servers (commonly running AIX) that allows a physical server to be divided into multiple logical partitions. Each LPAR functions as an independent server, utilising a specific share of CPU resources. Oracle's licensing is tied to physical processor cores, meaning you must licence every core where Oracle software is installed or running.
In a virtualised LPAR setup, Oracle requires you to account for all CPU cores that an Oracle instance could potentially use if not properly restricted.
| Concept | How It Works | ITAM Impact |
|---|---|---|
| Full-capacity licensing | By default, Oracle expects licensing for the full capacity of the physical server. | Without proper LPAR configuration, you licence the entire frame, potentially dozens of cores. |
| Sub-capacity licensing | Licensing only a portion of the server. Possible if Oracle recognises the partitioning as "hard." | Capped/dedicated LPARs can dramatically reduce licence counts. This is the goal. |
| Oracle core factor | IBM POWER processors (POWER7 through POWER10) have a core factor of 1.0. Each core counts fully as one licence. Intel/AMD x86 = 0.5. | An 8-core LPAR on IBM POWER requires 8 licences. Same workload on 8-core Intel requires only 4. See Core Factor Table. |
| Named User Plus (NUP) | Oracle enforces minimum 25 NUP per processor core for Enterprise Edition, even if fewer users exist. | A 2-core LPAR requires minimum 50 NUP. NUP is rarely economical in production IBM environments. |
| Processor licensing | Per-core licensing. Most common method for enterprise environments on IBM LPAR due to large user counts. | Directly tied to core count x core factor. Every additional vCPU or entitlement increases cost. |
Oracle distinguishes hard partitioning from soft partitioning to determine if you can licence only part of a server. IBM LPAR can be an Oracle-approved hard partitioning method, but only if certain conditions are met. Oracle's public Partitioning Policy lists IBM LPAR as approved for sub-capacity licensing when configured as a hard partition.
| Partition Type | Configuration | Oracle Licensing Impact |
|---|---|---|
| Dedicated LPAR (Hard) | LPAR with dedicated physical cores. Cores reserved exclusively for that partition. | Oracle accepts this as hard partition. Licence only the cores assigned to that LPAR. |
| Capped micro-partition (Hard) | Shared-CPU LPAR with strict entitled capacity cap. No uncapped mode. LPM disabled. | Oracle allows licensing based on capped entitlement (rounded up to whole cores) rather than whole server. |
| Uncapped LPAR (Soft) | LPAR can dynamically grow CPU usage beyond entitlement. TurboCore or uncapped mode enabled. | Oracle treats as soft partitioning. Must licence all physical cores in the server. |
| LPAR with LPM enabled (Soft) | Live Partition Mobility enabled. LPAR can migrate across physical hosts. | Oracle considers environment fluid. Must licence all cores on all servers the LPAR can move to. |
To qualify, the LPAR must have a defined resource cap on CPU (entitled capacity that limits maximum cores), Live Partition Mobility must be disabled, and the LPAR must not be in uncapped mode that would allow additional capacity beyond entitlement. By adhering to these rules, you hard-bind Oracle to a fixed set of CPU resources. Oracle's Partitioning Policy is a guideline, not part of your contract by default. Consider negotiating terms in your contract to explicitly allow sub-capacity licensing on LPAR. Without contractual language, Oracle's interpretation could change. For implementation guidance, see Implementing Oracle-Approved Hard Partitioning.
A company runs Oracle Database EE on an IBM Power10 server with 16 cores total. Instead of licensing all 16 cores (16 x $47,500 = $760,000), they configure a capped micro-partition with 2.0 cores entitled capacity and LPM disabled. Oracle recognises this as a hard partition. Result: 2 processor licences x $47,500 = $95,000. An 87% reduction in licence cost for the same workload.
The fundamental formula: count the processor cores Oracle will run on, apply Oracle's core factor, and determine the number of licences required. With IBM LPAR, the challenge is identifying the correct number of cores to count.
| LPAR Type | How to Count | Example |
|---|---|---|
| Dedicated LPAR | Count the dedicated physical cores assigned to the LPAR. | 4 dedicated cores x 1.0 factor = 4 licences |
| Capped micro-partition | Count the entitled capacity, round up to the next whole core. | 1.4 cores entitlement = round up to 2 cores x 1.0 = 2 licences |
| Uncapped / floating | No firm limit. Oracle may require licensing the maximum cores the LPAR can utilise (entire pool or server). | Server with 16 cores = 16 licences (worst case) |
| Processor Family | Core Factor | Impact on 8-Core Server |
|---|---|---|
| IBM POWER10 | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
| IBM POWER9 | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
| IBM POWER8 | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
| IBM POWER7/7+ | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
| IBM Z Series (z15, z14, z13) | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
| Intel Xeon (all modern) | 0.5 | 8 x 0.5 = 4 licences ($190,000) |
| AMD EPYC (all generations) | 0.5 | 8 x 0.5 = 4 licences ($190,000) |
| SPARC T4/T5/M5/M6/M7/M8/S7 | 0.5 | 8 x 0.5 = 4 licences ($190,000) |
| SPARC T3 / UltraSPARC T1 (1.0-1.2 GHz) | 0.25 | 8 x 0.25 = 2 licences ($95,000) |
| Ampere Altra / AltraMax / AmpereOne | 0.25 | 8 x 0.25 = 2 licences ($95,000) |
| All other multicore chips | 1.0 | 8 x 1.0 = 8 licences ($380,000) |
NUP on LPAR: Oracle's rule for Database EE is minimum 25 NUP per processor core. A 2-core LPAR requires at least 50 NUP, even if only 10 users access the database. In most production scenarios with hundreds of users, processor licensing is safer and more predictable. See NUP vs Processor: Which to Choose.
IBM PowerVM allows moving and sharing resources via multiple processor pools and Live Partition Mobility. From an Oracle licensing standpoint, dynamic movement can dramatically increase your licence liability.
| Dynamic Feature | Oracle Licensing Risk | Mitigation |
|---|---|---|
| Multiple processor pools | If an Oracle LPAR switches pools or draws from both, Oracle insists you licence all cores in every pool it has ever run in. Moving between an 8-core and 12-core pool = 20 cores to licence. | Strictly contain Oracle LPARs in a single, dedicated pool. Document pool assignments. |
| Live Partition Mobility (LPM) | Oracle treats LPM like VMware vMotion. If enabled, Oracle may demand both source and target servers (all cores) be fully licensed. | Disable LPM for Oracle-containing LPARs. Consider Oracle RAC or cold failover instead. |
| Dynamic LPAR (DLPAR) | If CPUs can be dynamically added to an Oracle LPAR, the maximum possible CPU count becomes the licensing basis. | Set hard caps. Do not allow dynamic CPU additions without ITAM review. |
| Temporary moves (maintenance) | Even a temporary move to a different server or pool creates a licensing requirement on that new hardware. | Purchase buffer licences or use Oracle's limited 10-day rule for failover (specific and limited). |
The more freedom an Oracle LPAR has to use additional CPUs or move across systems, the more licences you will need. Many enterprises segregate Oracle environments to a subset of hardware specifically to contain costs. Pin Oracle LPARs to specific resources, disable mobility, and monitor any changes. For failover and DR rules, see Oracle Failover and DR Licensing.
At list price (~$47,500 per processor licence for Database Enterprise Edition), every core counts. Using a small LPAR instead of running on the full server can dramatically reduce licence counts.
| Scenario (IBM Power Server) | Oracle Licences Required | Licence Cost (List) | Savings vs Full Server |
|---|---|---|---|
| No partitioning (full 16-core server) | 16 licences | $760,000 | Baseline |
| Dedicated LPAR with 4 cores | 4 licences | $190,000 | $570,000 (75%) |
| Capped micro-LPAR, 1.5 cores (rounded to 2) | 2 licences | $95,000 | $665,000 (87%) |
1. Constrain core allocation. Only allocate the CPU cores the workload truly needs. Right-size the LPAR capacity. Every additional vCPU or entitlement increases your licence count.
2. Hard partition to save costs. Ensure the LPAR is configured as an Oracle-recognised hard partition (capped and/or dedicated). Capping at 25% of a large server = 75% licence reduction.
3. Leverage processor pools. Create separate pools for different Oracle workloads. Segment expensive add-on options (Partitioning, RAC) to small pools to avoid licensing them across all cores.
4. NUP for niche cases. If an LPAR serves a very limited user base (5 developers on a dev system), NUP licensing could be more cost-effective. But watch the 25-per-core minimum.
5. Consider Oracle ULA. If your Oracle footprint on IBM LPAR is large or growing, an Unlimited Licence Agreement provides cost certainty. But manage LPAR configs to avoid a licensing explosion when the ULA ends. See Oracle ULA Optimisation.
6. Retire unused instances. Regularly audit LPARs. If an Oracle installation is no longer needed, decommission it and save on support renewals or reassign licences elsewhere.
7. Evaluate hardware migration. Migrating from IBM POWER (factor 1.0) to Intel/AMD x86 (factor 0.5) instantly halves the core-based licence count. Weigh performance needs against licensing costs.
| Pitfall | Risk | Mitigation |
|---|---|---|
| Leaving LPARs uncapped | Oracle views uncapped LPARs as needing to licence the peak capacity or the entire server. | Always cap Oracle LPARs at a fixed entitlement to set an upper bound on licensable cores. |
| Enabling LPM | Live migration extends licence requirements to multiple systems. Both source and target servers must be fully licensed. | Disable LPM for Oracle workloads. Strictly limit which servers an Oracle LPAR can run on. |
| Mixed shared pools | Oracle and non-Oracle apps sharing a pool. Oracle's usage could float and Oracle claims the entire pool. | Dedicate pools or cores for Oracle. Do not let Oracle run in a large shared pool without proper capping. |
| Ignoring NUP minimums | Counting actual users and overlooking the "25 per processor" rule leads to under-licensing. | Ensure at least 25 NUP x the number of cores, regardless of actual user count. |
| Assuming IBM ILMT applies | IBM's sub-capacity licensing tool (ILMT) does not apply to Oracle. Oracle will not accept ILMT data. | Compliance depends on LPAR configuration, not usage tracking. Follow Oracle's own partitioning policy. |
| Lack of documentation | In an audit, Oracle may assume worst-case if you cannot prove LPAR settings. An undocumented 2-core cap = potential 16-core liability. | Maintain screenshots, HMC configs, and architectural diagrams. Update after every change. |
| Hardware upgrades without re-evaluation | Migrating to a newer Power server with more cores (or different core factor) changes licence requirements. | Treat any hardware change as a trigger to recalculate Oracle licensing. |
1. Hard partition every Oracle environment. Configure every Oracle LPAR as a hard partition (dedicated cores or properly capped with no mobility).
2. Isolate Oracle workloads. Group Oracle databases on specific IBM Power servers or dedicated pools. Avoid mixed-use superclusters.
3. Disable unneeded virtualisation features. Turn off LPM for Oracle LPARs. Avoid dynamic capacity boost features. Simplicity = clarity in licensing.
4. Use processor pools wisely. Create small pools for Oracle LPARs (e.g. 8-core pool) rather than letting them draw from a 32-core pool.
5. Audit configurations regularly. Schedule periodic reviews of all Oracle LPAR settings (caps, CPU allocations, mobility). Catch drift before it becomes a compliance issue.
6. Educate system administrators. Ensure IBM Power admins understand that changing an LPAR config or relocating it has licensing implications. ITAM must review changes.
7. Track Oracle core factors. Stay updated on Oracle's Core Factor Table, especially if you upgrade hardware.
8. Plan for growth. Assess cost implications before expanding Oracle capacity. Spin up new LPARs in a controlled way or negotiate a ULA.
9. Leverage enterprise agreements. For large Oracle estates, consider ULAs or enterprise agreements. Always have an exit plan for when the agreement ends.
10. Engage experts when in doubt. Oracle licensing on IBM platforms is intricate. Do not wait for an audit to discover issues.
Yes, if configured correctly. Oracle treats an LPAR as hard partition (and allows sub-capacity licensing) when you dedicate or cap the cores and disable live migration. A static dedicated LPAR or a capped shared LPAR (with no mobility) is recognised. If you do not meet those criteria, Oracle classifies it as soft partitioning and requires licensing all the server's cores. See Oracle Partitioning Policy for full details.
Yes, but only by constraining Oracle to that subset. Set up an LPAR limited to 4 cores (either dedicated or with capped entitlement of 4 cores). Oracle's rules allow licensing just those 4 cores instead of all 16. The remaining capacity must not be usable by the Oracle LPAR. If the software can potentially run on all 16, all 16 need licensing.
Strongly recommended. Oracle requires LPM to be off if you are trying to limit licensing to a subset. If LPM is enabled and you move an Oracle LPAR, you need to licence both hosts (or all hosts it can migrate to). Many companies turn off LPM for any LPAR running Oracle. For HA needs, consider Oracle's own clustering solutions (RAC) or accept the cost of licensing multiple hosts.
NUP licensing works but fits best for small-scale or non-production environments. You must meet Oracle's minimum of 25 NUP per processor core. A 2-core LPAR requires at least 50 NUP, even if only 10 users access Oracle. In enterprise production with hundreds of users, processor licensing is typically more practical. NUP is usually reserved for dev/test or very limited-user applications.
No. Oracle's Partitioning Policy is a public policy document, not a contractual term (unless you negotiate it in). Oracle's standard contracts say you must licence all processors where the software is installed or running. The policy is Oracle's interpretation of how certain technologies can limit where software runs. Oracle auditors use it to assess compliance. Follow it closely, or negotiate a custom contract amendment. For more detail, see Implementing Oracle-Approved Hard Partitioning.
All modern IBM POWER processors (POWER7, POWER7+, POWER8, POWER9, POWER10) have a core factor of 1.0. Each core counts fully as one Oracle processor licence. This is double the cost-per-core compared to Intel/AMD x86 (factor 0.5). The Core Factor Table is published by Oracle and updated periodically. See Oracle Core Factor Table for the complete reference.
An uncapped LPAR can dynamically grow CPU usage beyond its entitlement. Oracle treats uncapped LPARs as soft partitioning, which means you must licence all physical cores in the server, not just the LPAR's entitled capacity. On a 16-core server, that means 16 processor licences at $47,500 each = $760,000 instead of potentially 2 licences at $95,000. Always cap Oracle LPARs to set an upper bound on licensable cores.
It is worth evaluating. Migrating from IBM POWER (core factor 1.0) to Intel/AMD x86 (core factor 0.5) instantly halves the core-based licence count. An 8-core IBM POWER server requires 8 Oracle licences ($380,000). The same workload on 8-core Intel requires 4 licences ($190,000). Weigh performance requirements, application compatibility, and migration costs against the licensing savings. For many enterprises, the licensing cost difference over a 3-5 year period justifies the migration investment.
Oracle's partitioning rules, core factor calculations, and LPAR configuration requirements create significant compliance complexity. Our independent advisory helps ITAM teams audit IBM Power environments, validate LPAR configurations, calculate accurate licence requirements, and prepare for Oracle audits. Fixed-fee. Vendor-independent.
Oracle Advisory ServicesIndependent Oracle licensing advisory for IBM LPAR environments. LPAR configuration review, core factor analysis, partitioning compliance, audit defence. Fixed-fee. Vendor-independent.