IBM LPAR is one of the few partitioning technologies Oracle accepts as hard partitioning — but only when it is configured exactly the way Oracle's policy requires. Get the configuration right and you license only the capped capacity assigned to Oracle; get it wrong, or fail to evidence it, and Oracle's auditors will argue for the full physical core count of the frame. This is a recurring battleground in Oracle audit defence on IBM Power estates.
Why LPAR can limit licensing
On IBM Power systems, PowerVM allows a physical frame to be carved into logical partitions (LPARs). Oracle's Partitioning Policy lists dynamic LPAR (DLPAR) with capped configurations among approved hard-partitioning methods. In practice this means a properly capped LPAR — where the maximum processors available to the partition are bounded — lets you license the capped core count rather than every core in the frame. This is materially different from Oracle's treatment of VMware, which Oracle classifies as soft partitioning and refuses to accept as a limiting boundary. See the contrast in our VMware soft-partitioning analysis.
Capped versus uncapped, and the shared pool
The configuration detail that decides the licence count is whether the LPAR is capped and how it draws from the shared processor pool. An uncapped micro-partition can consume processing capacity above its entitlement up to the size of the shared pool — which Oracle reads as the licensable maximum. A capped partition cannot exceed its entitled capacity, so the cap defines the boundary. Where Oracle is run inside a shared processor pool, the maximum number of processors the partition can use — not the entitled average — is the figure Oracle expects to be licensed.
| LPAR configuration | Licensable processor basis (typical) | Audit risk |
|---|---|---|
| Dedicated processors | The dedicated cores assigned to the LPAR | Low — clear boundary |
| Capped micro-partition | The cap (maximum entitled processing units, rounded up) | Low–moderate if cap is evidenced |
| Uncapped micro-partition | Maximum cores in the shared pool the LPAR can reach | High — can equal the whole pool |
| Multiple shared pools | Maximum of the pool hosting Oracle | Moderate — depends on pool sizing |
Don't forget the Oracle Processor Core Factor
Once the licensable core count is fixed, IBM Power cores are multiplied by Oracle's Processor Core Factor from Oracle's Core Factor Table to reach Processor licences. IBM Power cores have historically carried a higher core factor than commodity x86 cores, so the per-core multiplier is a real cost driver on Power. Buyers modelling a migration between x86 and Power should price the core-factor difference explicitly, because it can offset the consolidation benefit of larger Power cores.
Buyer takeaway: LPAR is a legitimate way to cap Oracle licensing on IBM Power — but only capped configurations qualify, and only if you can evidence the cap and the shared-pool design at the time of the audit. The expensive failures are uncapped partitions and undocumented pool changes that let Oracle argue for the whole frame. Keep configuration history; it is your proof. Our audit defence service reconstructs Power partition history as part of position-building.
Evidence to retain
For each Oracle LPAR, retain HMC configuration showing capped status and entitled/maximum processing units, the shared-pool definition, and a history of any DLPAR changes. If a partition was uncapped even briefly, document when and why, because Oracle may argue the uncapped window defines the licence requirement. Treating partition configuration as auditable evidence — not just operational settings — is what makes the hard-partitioning boundary defensible.
Related: reading LMS output and DR licensing. Anchor: Oracle audit defence.
LPAR in a consolidation or migration decision
Because LPAR is accepted as hard partitioning while VMware is not, IBM Power can be the platform that makes a capped Oracle footprint defensible where x86 virtualisation would invite a full-estate argument. That advantage has to be weighed against the higher Oracle Core Factor on Power cores and the operational cost of the platform. The honest comparison models three numbers side by side: the licensable cores under each platform's partitioning treatment, the core-factor multiplier applied to each, and the support stream that follows from the resulting licence count. For some estates the capped-LPAR boundary saves more than the core factor costs; for others the opposite is true. The decision should be made on that arithmetic, not on a general preference for one platform.
Common questions
Does Oracle accept all LPAR configurations as hard partitioning?
No. Only capped configurations qualify under Oracle's policy. Uncapped micro-partitions are treated as able to consume the shared pool, so Oracle expects the pool maximum to be licensed.
What single document most protects an LPAR position?
HMC configuration evidence showing the partition is capped, with entitled and maximum processing units and the shared-pool definition, retained over time so you can prove the cap was in place throughout the audited period.