Oracle Licensing on IBM LPAR — A Simplified Guide

1. Understanding IBM LPAR and Oracle Licensing Basics

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. However, Oracle's licensing is tied to physical processor cores — meaning you must licence every core where Oracle software is installed and/or running.

In a virtualised LPAR setup, this becomes complex because Oracle will require you to account for all CPU cores that an Oracle instance could potentially use if not properly restricted. For more context on Oracle in virtual environments, see Oracle Licensing in Virtual Environments.

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 method as "hard."	Capped/dedicated LPARs can dramatically reduce licence counts. This is the goal.
Oracle Core Factor	IBM POWER processors (POWER7–10) 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. The same workload on 8-core Intel would require only 4. See Oracle Core Factor Table.
Named User Plus (NUP)	Oracle enforces a minimum of 25 NUP per processor core for Enterprise Edition, even if fewer users exist.	A 2-core LPAR requires minimum 50 NUP licences. NUP is rarely economical in production IBM environments.
Processor Licensing	Per-core licensing — the most common method for enterprise environments on IBM LPAR due to large user counts.	Directly tied to core count × core factor. Every additional vCPU or entitlement increases cost.

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 — half the cost. Hardware choice directly impacts Oracle licensing spend. For the full pricing picture, see Oracle Technology Price List — How to Calculate Pricing.

2. Oracle's Partitioning Policy: Hard vs Soft Partitions

Oracle distinguishes hard partitioning vs 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 (not shared). Cores are reserved exclusively for that partition.	Oracle accepts this as hard partition. You only need to licence the cores assigned to that LPAR.
Capped Micro-Partition (Hard ✅)	Shared-CPU LPAR with a strict entitled capacity cap. No uncapped mode. LPM disabled.	Oracle allows licensing based on the capped entitlement (rounded up to whole cores) rather than the whole server.
Uncapped LPAR (Soft ❌)	LPAR can dynamically grow CPU usage beyond its entitlement. TurboCore or uncapped mode enabled.	Oracle treats this as soft partitioning. You must licence all physical cores in the server.
LPAR with LPM Enabled (Soft ❌)	Live Partition Mobility is enabled — LPAR can migrate across physical hosts.	Oracle considers the environment fluid. You must licence all cores on all servers the LPAR can move to.

Oracle's Requirements for IBM LPAR as Hard Partition

To qualify, the LPAR must have a defined resource cap on CPU (entitled capacity that limits max cores), Live Partition Mobility must be disabled, and the LPAR must not be in uncapped mode that would let it use additional capacity beyond its 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. Oracle uses it in audit situations, so it's wise to follow it. However, 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.

Capped LPAR Cost Saving

A company runs Oracle Database EE on an IBM Power10 server with 16 cores total. Instead of licensing all 16 cores (16 × $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 × $47,500 = $95,000 — an 87% reduction in licence cost for the same workload.

Unsure About Your IBM LPAR Licence Position?

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.

Oracle License Management Services → Book a Consultation

3. Counting Licences on IBM LPAR

The fundamental formula is: 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 × 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 × 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)

Named User Plus (NUP) on LPAR

Oracle's rule for Database EE: minimum 25 NUP per processor core. A 2-core LPAR requires at least 50 NUP licences, even if only 10 users access the database. In most production scenarios with hundreds of users, processor licensing is safer and more predictable.

Core Factor Table — Key Values for IBM LPAR

Processor Family	Core Factor	Impact on 8-Core Server
IBM POWER10	1.0	8 × 1.0 = 8 licences ($380,000)
IBM POWER9	1.0	8 × 1.0 = 8 licences ($380,000)
IBM POWER8	1.0	8 × 1.0 = 8 licences ($380,000)
IBM POWER7/7+	1.0	8 × 1.0 = 8 licences ($380,000)
IBM Z Series (z15, z14, z13)	1.0	8 × 1.0 = 8 licences ($380,000)
Intel Xeon (all modern)	0.5	8 × 0.5 = 4 licences ($190,000)
AMD EPYC (all generations)	0.5	8 × 0.5 = 4 licences ($190,000)
SPARC T4/T5/M5/M6/M7/M8/S7	0.5	8 × 0.5 = 4 licences ($190,000)
SPARC T3 / UltraSPARC T1 (1.0–1.2 GHz)	0.25	8 × 0.25 = 2 licences ($95,000)
Ampere Altra / AltraMax / AmpereOne	0.25	8 × 0.25 = 2 licences ($95,000)
All other multicore chips	1.0	8 × 1.0 = 8 licences ($380,000)

🧮 Oracle LPAR Licence Calculator

Calculate your Oracle processor licence requirements and estimated costs for IBM LPAR environments. Uses Oracle's official Core Factor Table values.

Processor Family

LPAR Configuration

Total Physical Cores (LPAR or Server) For dedicated LPAR: enter cores assigned to the LPAR

Oracle Product

Licensing Metric

—

Processor Licences Required

—

One-Time Licence Cost (List)

—

Annual Support (~22%)

—

3-Year TCO (List)

⚠️ These are list-price estimates for planning purposes only. Actual prices depend on negotiated discounts, existing agreements, and Oracle's current pricing. Standard Edition 2 uses socket-based licensing — the Core Factor Table does not apply. Always verify with Oracle's official documentation. This calculator uses Oracle's published Core Factor Table values as of January 2026.

Vendor / Processor	Core Factor	Notes
IBM POWER10	1.0	Current generation
IBM POWER9	1.0
IBM POWER8	1.0
IBM POWER7 / POWER7+	1.0
IBM POWER6 / POWER5	1.0	Legacy systems
IBM Z Series (z15, z14, z13, z(EC)12, z196, z11)	1.0	Mainframe
Intel Xeon — all modern series (Platinum, Gold, Silver, Bronze, E-series, Scalable)	0.5	Most common enterprise x86
Intel Itanium 95XX+	1.0	Changed from 0.5 in Dec 2010
AMD EPYC — all generations (7xx1, 7xx2, 7xx3, 9xx4, 9xx5)	0.5	Updated May 2025
AMD Opteron (all models)	0.5	Legacy
SPARC T4 / T5 / M5 / M6 / M7 / M8 / S7	0.5	Oracle SPARC — modern
SPARC64 VII+ / X / X+ / XII	0.5	Fujitsu SPARC
SPARC T3	0.25
UltraSPARC T1 (1.0–1.2 GHz)	0.25	Named servers only
UltraSPARC T1 (1.4 GHz) / T2 / T2+	0.5
Ampere Altra / AltraMax / AmpereOne	0.25	ARM — added June 2023
All other ARM processors	1.0	Non-Ampere ARM
All other multicore chips	1.0	Default if not listed

📊 Need help with accurate Oracle licence calculations on IBM LPAR?

Oracle License Management →

Need Expert Oracle Licensing Guidance?

Redress Compliance provides independent Oracle licensing advisory services — fixed-fee, no vendor affiliations. Our specialists have helped enterprises save millions through strategic license optimization, audit defense, and contract negotiation.

Explore Oracle Advisory Services →

4. Handling Dynamic LPARs (Mobility and Pools)

IBM PowerVM allows moving and sharing resources via multiple processor pools and Live Partition Mobility (LPM). However, 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 that both source and target servers (all their 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).

Treat an Oracle LPAR as fixed as possible. The more freedom it has to use additional CPUs or move across systems, the more licences you will ultimately 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.

📄

Oracle Licensing White Papers

Independent research on Oracle licensing, partitioning policies, audit defence, ULA strategies, Java compliance, and cost optimisation. Written by former Oracle insiders.

Browse White Papers →

📊 Free Assessment Tool

Running Oracle on IBM LPAR and unsure if your partitioning qualifies? Our free audit risk assessment checks your LPAR configuration against Oracle's requirements.

Take the Free Assessment →

5. Cost Implications and Optimisation Strategies

Oracle Database licences are notoriously expensive. 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
No partitioning (full 16-core server)	16 licences	~$760,000	—
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%)

💡 Key Optimisation Strategies

1. Constrain Core Allocation — Only allocate the CPU cores the workload truly needs. Right-size the LPAR's 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 (e.g., 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.

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.

Oracle Audit Concerns on IBM LPAR?

Oracle licence audits are notoriously strict — a single misconfigured LPAR can result in demands for hundreds of thousands of dollars in back-licensed software and support. Our independent advisory helps enterprises validate LPAR configurations, close compliance gaps, and prepare defensible audit positions.

Oracle Audit Defense Service → Oracle Negotiation Service

6. Common Pitfalls and Compliance Risks

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. Don't 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 × the number of cores, regardless of actual user count.
Assuming IBM's 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 can't 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.

7. Recommendations and Checklist

💡 10 Expert Recommendations

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. An IBM Power10 might have different implications than a Power8.

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. Don't wait for an audit to discover issues.

Checklist: 5 Actions to Take

Inventory your Oracle LPARs. Identify all IBM LPARs running Oracle software across your enterprise. Note host servers, configurations, and CPU allocations.
Verify partitioning settings. For each Oracle LPAR, check if it's dedicated or shared. If shared, confirm it has a capped entitled capacity and LPM is disabled. Document these settings.
Calculate required licences. Count cores (dedicated or entitled), apply core factors. If using NUP, count users and ensure minimums are met. Compile a compliance report.
Reconfigure to optimise. For any non-compliant LPARs (uncapped, mobile), plan adjustments. Cap them, segregate Oracle workloads to smaller pools, or acquire additional licences to cover gaps.
Monitor and govern. Implement governance ensuring any LPAR changes are reviewed by ITAM. Maintain an audit trail and prepare evidence for Oracle audit readiness.

8. Frequently Asked Questions

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 don't 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're trying to limit licensing to a subset. If LPM is enabled and you move an Oracle LPAR, you'll need to licence both hosts (or all hosts it can migrate to). Many companies simply 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 licences, 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. In practice, Oracle auditors use it to assess compliance. Follow it closely, or negotiate a custom contract amendment if you have a unique setup. 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 the Oracle Core Factor Table for the complete reference.

Fredrik Filipsson

Co-Founder @ Redress Compliance

20+ years in enterprise software licensing. Former IBM, SAP, and Oracle. 11 years as an independent consultant advising hundreds of Fortune 500 companies on Oracle, Microsoft, SAP, IBM, Salesforce, and ServiceNow licensing, contract negotiations, and cost optimisation.

LinkedIn · View All Posts

Explore More Licensing Hubs

Oracle Licensing Hub Microsoft Licensing Hub SAP Licensing Hub IBM Licensing Hub Salesforce Licensing Hub ServiceNow Licensing Hub

Ready to Take Control of Your Software Licensing?

Book a free consultation with our licensing specialists. No obligations, no vendor ties — just independent advice tailored to your situation.

Book Your Free Consultation →