IBM Power LPAR is one of the few technologies Oracle accepts as hard partitioning. That makes it a powerful way to limit Oracle licensing, but only when the LPAR is configured the way Oracle's policy requires.
IBM Power LPAR is Oracle approved hard partitioning, which lets you license a capped subset of cores. The capped versus uncapped setting decides everything, and an uncapped Oracle LPAR exposes the whole pool.
IBM Power LPAR is one of the few virtualization technologies Oracle accepts as hard partitioning. That makes it a powerful way to limit Oracle licensing, but only if the LPAR is configured the way Oracle's policy requires.
This guide covers what Oracle approves, the capped versus uncapped distinction, and what it really costs.
Oracle's partitioning policy lists IBM LPAR among approved hard partitioning methods. A correctly capped LPAR lets you license only the cores assigned to it, not the whole frame.
A logical partition carves an IBM Power server into isolated environments, each with its own processor allocation. Oracle accepts the allocation as a licensing boundary when it is hard capped, consistent with the Database Licensing Information manual.
IBM PowerVM micro partitioning assigns fractional cores. Oracle requires you to license to the cap, rounded up to whole cores, so the cap setting directly drives the bill.
This is the distinction that decides everything. An uncapped LPAR can borrow cores from the shared pool, so Oracle treats it as able to use the whole pool.
Capped versus uncapped LPAR for Oracle
| Setting | What Oracle licenses | Cost effect | Buyer note |
|---|---|---|---|
| Capped | The cap, rounded up | Lowest, predictable | Required for hard partition benefit |
| Uncapped | The whole shared pool | Highest | Defeats the purpose |
| Dedicated cores | The assigned cores | Low, simple | Cleanest position |
An uncapped LPAR can exceed its entitlement by drawing on the shared pool. Oracle then argues you must license the entire pool the LPAR can reach, citing its contract and audit terms. Keep Oracle LPARs capped.
Retain the HMC configuration showing the cap. In an audit, the configuration evidence is what holds the line on the smaller core count.
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
The cost depends almost entirely on the cap, and on getting the cap small enough to match real demand without throttling the workload.
IBM Power cores carry a core factor of 1.0 in Oracle's core factor table, higher than x86. That makes cap discipline more important, because every Power core counts fully.
The standard advice is that IBM LPAR is automatically safe because Oracle approves it, so you can run Oracle anywhere on the frame. We disagree. In roughly three out of five IBM Power estates we have reviewed, the LPARs running Oracle were uncapped or the caps were set far above real demand, which handed Oracle a claim on the whole shared pool or a needlessly large core count. The buyer side move is to hard cap every Oracle LPAR, set the cap to measured peak plus modest headroom, and keep the HMC evidence. Approved hard partitioning only protects you when it is configured the way the policy actually requires.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
IBM LPAR is hard partitioning only when it is capped. An uncapped Oracle LPAR is a soft partition wearing a hard partition badge.
The moves all come back to the cap and the evidence behind it.
Set a hard cap on every LPAR that runs Oracle. Size it to measured peak plus modest headroom, not to the frame.
Archive the HMC output that proves the cap. Evidence is what converts the policy approval into a defended core count.
Yes. Oracle's partitioning policy lists IBM LPAR among approved hard partitioning methods. A correctly capped LPAR lets you license only the cores assigned to it, not the whole Power frame.
A capped LPAR is limited to its assigned cores, which Oracle licenses. An uncapped LPAR can borrow cores from the shared pool, so Oracle argues you must license the entire pool it can reach.
Oracle requires you to license to the cap rounded up to whole cores. A cap of 3.5 cores licenses as 4. The cap setting therefore directly drives the licensable count.
IBM Power cores carry a core factor of 1.0 in Oracle's core factor table, higher than the 0.5 typical for x86. Every Power core counts fully, which makes cap discipline more important.
An uncapped LPAR can exceed its entitlement by drawing on the shared pool. Oracle then claims you must license the whole pool the LPAR can reach, which defeats the purpose of using LPAR as a hard partition.
Retain the HMC configuration output showing the hard cap. In an audit this configuration evidence is what holds the line on the smaller, capped core count against any broader Oracle claim.
Hard cap every Oracle LPAR, size the cap to measured peak plus modest headroom rather than the frame, apply the Power core factor, and review the caps at each renewal against actual demand.
Only by licensing the whole shared processor pool the partition can reach, which is expensive. To gain the hard partitioning benefit you must keep the Oracle LPAR capped and evidenced.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
