Oracle licensing on IBM LPAR what it really costs.

Oracle accepts IBM Power LPAR as approved hard partitioning, but only when it is capped and documented. Get the configuration right and you license a fraction of the frame.

This guide is for infrastructure and license teams running Oracle Database on IBM Power. Read it with the Oracle partitioning policy and the approved hard partitioning guide.

IBM Power is one of the few platforms where Oracle accepts partitioning to limit licenses. The acceptance is conditional, and the conditions are where estates slip into exposure.

Does Oracle accept IBM LPAR as hard partitioning?

Oracle's partitioning policy names IBM dynamic LPARs as approved hard partitioning when they are capped. That acceptance is the basis for licensing fewer cores than the physical frame holds.

Why does the partition have to be capped?

The Oracle partitioning policy treats a capped LPAR as a hard boundary. An uncapped LPAR can borrow from the shared pool, so Oracle treats the whole pool as licensable.

• Capped LPAR: a fixed ceiling Oracle accepts as a boundary.
• Uncapped LPAR: can exceed entitlement, so the pool is exposed.
• Dedicated cores: the cleanest and most defensible configuration.

Is the partitioning policy contractual?

The partitioning document is policy, not a contract term. It guides Oracle's audit position but is not signed. That is why documentation of your configuration matters so much in a dispute.

How do you count Oracle cores on an IBM LPAR?

Once the partition is capped, you count the cores assigned to it and apply the IBM Power core factor. The frame may hold far more cores than you ever license.

Which core factor applies to IBM Power?

IBM Power processors carry a core factor of 1.0 in the Oracle table, higher than x86 at 0.5. The capped core count is multiplied by that factor to reach the Processor license requirement.

What does a worked example look like?

A frame with 48 cores running one capped LPAR of 8 cores licenses 8 cores at the Power factor of 1.0, so 8 Processor licenses. The other 40 cores are not licensable while the cap holds.

• Frame cores: 48 physical cores in the example.
• Capped LPAR: 8 cores assigned to Oracle.
• Licenses: 8 cores at factor 1.0 equals 8 Processor licenses.

Oracle's acceptance of LPAR is generous, but it evaporates the moment the cap or the documentation slips.

How do you prove the partition boundary to Oracle?

The boundary only protects you if you can show it held. IBM tooling produces the evidence, and keeping it current is the difference between a clean audit and a frame wide claim.

What evidence does Oracle accept?

HMC configuration exports, partition profiles, and capacity reports show the cap and the assigned cores. Capture them on a schedule so you can prove the boundary at any point in the year.

How does Live Partition Mobility create risk?

Live Partition Mobility can move an Oracle LPAR onto an unlicensed frame. If that frame is not licensed, the move creates exposure. Restrict mobility to licensed frames and log every migration.

What buyer side moves protect an IBM Power estate?

The moves are configuration discipline and evidence. Oracle's acceptance of LPAR is generous, but it evaporates the moment the cap or the documentation slips.

Why is cap discipline the core control?

An uncapped partition or a stray shared pool assignment can expose the whole frame. Reviewing partition profiles before each change keeps the licensable footprint where you intend it.

Where does consolidation help?

Concentrating Oracle workloads onto a small set of capped, licensed frames simplifies the evidence and shrinks the licensable core count. Spreading Oracle across many frames does the opposite.

Suggested reading

• Oracle partitioning policy explained. Cross vendor reading from the wider library.
• Approved hard partitioning guide. Cross vendor reading from the wider library.
• Oracle core factor table. Cross vendor reading from the wider library.

What to do next

1. Map every Oracle workload to its IBM frame and partition profile.
2. Confirm each Oracle LPAR is capped, not uncapped or borrowing from a pool.
3. Apply the IBM Power core factor to the capped core counts.
4. Schedule regular HMC configuration exports as audit evidence.
5. Restrict Live Partition Mobility to licensed frames and log every move.
6. Consolidate Oracle onto a small set of capped, licensed frames.
7. Review partition profiles before any infrastructure change.

Frequently asked questions

Does Oracle accept IBM LPAR as hard partitioning?

Yes, Oracle's partitioning policy recognizes capped IBM dynamic LPARs as approved hard partitioning. Only capped partitions qualify, because an uncapped LPAR can borrow from the shared pool and expose it.

What happens if the LPAR is uncapped?

An uncapped LPAR is treated as soft partitioning. Oracle then considers the entire shared processor pool licensable, which usually means licensing far more cores than the workload actually uses.

Which core factor applies to Oracle on IBM Power?

IBM Power processors carry a core factor of 1.0 in the Oracle table. You count the cores assigned to the capped partition and multiply by 1.0 to reach the Processor license requirement.

Is the Oracle partitioning policy contractual?

No, the partitioning document is policy rather than a signed contract term. It guides Oracle's audit position, which is why documenting your capped configuration is essential if a dispute arises.

Can Live Partition Mobility cause a compliance gap?

Yes, moving an Oracle LPAR to an unlicensed frame creates exposure on that frame. Restrict mobility to licensed frames and log every migration so you can prove where the workload ran.

How do I prove the partition boundary in an audit?

Capture HMC configuration exports, partition profiles, and capacity reports on a schedule. These show the cap and the assigned cores, giving you point in time evidence Oracle accepts for any date.