Oracle IBM LPAR licensing on Power. Only dedicated and capped partitions limit the count.

Oracle licenses an IBM Power LPAR on its own only when it uses dedicated processors or is a capped micro partition. Leave it uncapped and Oracle counts the shared pool, which on one 64 core frame costs $2.85 million more at list than capping.

Which IBM Power partition types does Oracle accept as hard partitioning?

Two. Oracle's partitioning policy lists IBM LPAR (with DLPAR) and IBM Micro Partitions, the latter for capped partitions only, and with either one you license the partition itself. Everything else on a Power frame is soft partitioning in Oracle's reading, and the count falls back to something larger.

The policy is dated February 14, 2022. It calls itself educational guidance that may not be incorporated into any contract and can change without notice.

Oracle still applies it in every audit, so treat it as the rulebook and keep a copy of the version in force when you configured each partition. Our guide to the Oracle partitioning policy covers the full list across platforms.

Why simultaneous multithreading does not change the count

Oracle counts cores. A Power core running eight hardware threads presents eight logical processors to AIX and still counts as one core. Turning simultaneous multithreading on or off changes performance and leaves the license requirement exactly where it was.

The same logic closes an older route. The policy states that running IBM processors in TurboCore mode is not permitted as a way to reduce licenses, and all cores must be licensed. If a vendor or integrator proposes a processor mode that switches cores off to shrink the Oracle count, check it against that line first.

Why workload partitions and AIX resource controls do not count

Workload partitions are the configuration teams most often mistake for a boundary. They give isolation, but Oracle does not recognize them for licensing, so the containing partition is licensed in full however the workload partitions inside it are sized.

• Isolation is a different thing from partitioning. An operating system container inside an approved partition adds no licensing benefit.
• Resource controls are invisible to the policy. A processor set or a workload manager limit inside AIX does not cap anything Oracle will count.
• Only the hypervisor defines the boundary. The partition definition held by the Hardware Management Console is the one that counts.

What changes between a capped and an uncapped LPAR for Oracle licensing?

The ceiling on processor consumption changes, and with it the number Oracle can support in an audit. A capped partition cannot exceed its entitled capacity. An uncapped partition can borrow idle cycles from the shared pool, up to the number of virtual processors it has online.

Which three numbers decide the license count?

• Entitled capacity. The guaranteed processing units, set in fractions of a core. For a capped partition this is the hard ceiling and therefore the licensable number.
• Online virtual processors. The cores the operating system can dispatch work onto. For an uncapped partition this is the real physical ceiling.
• Active cores in the pool. The cores available to be borrowed. Oracle opens with this number when the partition is uncapped.

Most of the negotiation happens in the gap between the second and third numbers. Oracle starts at the pool because the policy gives it no approved boundary to stop at. The technical argument that pulls the count down is that consumption cannot physically exceed the online virtual processors.

How does rounding of processing units waste money?

Fractional entitled capacity rounds up to whole cores for licensing. An entitled capacity of 3.2 processing units and one of 4.0 both need four Processor licenses, so a partition sized at 3.2 pays for capacity it declined to take.

Check every Oracle partition for this. Raising entitlement to the whole core you already pay for, or sizing just below the next one, is free performance.

Why the saved profile matters more than the running state

The console holds two versions of every partition: the running configuration and the saved profile. A partition capped by hand after an incident, without the profile being updated, returns to uncapped the next time it is activated from that profile. Auditors ask for both.

In the environments we reviewed, this mismatch was the second most common finding after partitions that were simply uncapped. To close it, save the running configuration back to the profile from the console, or run mksyscfg -r prof -m (frame) -o save -p (partition) -n (profile) --force, then export both states again.

What about the maximum values in the profile?

Each profile also carries minimum, desired and maximum processing units and virtual processors. Dynamic LPAR can raise entitlement up to the profile maximum while the partition runs, without a restart. An auditor who sees a capped partition at 4 processing units with a profile maximum of 16 may argue the partition can reach 16 at any time.

Keep the maximum close to the entitlement you intend to license. If operations wants burst headroom, give it through a documented change with a licensing check, and keep the partition's ceiling honest in the meantime. Our practical guide to implementing hard partitioning covers the settings platform by platform.

What does the cap decision cost on a real Power frame?

On a platform with a 1.0 core factor, it costs more than most infrastructure teams expect. The worked example below uses published list prices only, so you can rebuild it with your own frame and your own discount.

A worked example on one Power10 frame

• The frame. A Power10 system with 64 activated cores, all in one shared processor pool.
• The partition. One Oracle Database Enterprise Edition partition with entitled capacity of 3.2 processing units, eight online virtual processors and the sharing mode set to uncapped.
• Oracle's opening count. 64 activated cores at a 1.0 core factor gives 64 Processor licenses.
• The technical landing point. Eight online virtual processors gives eight Processor licenses.
• The capped position. Entitled capacity of 3.2 rounds up to four Processor licenses.

Enterprise Edition lists at $47,500 per Processor in Oracle's technology price list. That puts the three positions at $3.04 million, $380,000 and $190,000 in license fees. The sharing mode field on this one partition is worth $2.85 million of exposure.

The five year total is the license fee plus five years of support at 22 percent of the license fee. Discounts change the dollar amounts. They do not change the ratio between the rows.

Why management packs multiply the gap

Options and packs are licensed on the same Processor count as the database. Say the partition also runs the Diagnostics Pack at $7,500 and the Tuning Pack at $5,000 per Processor, which is common wherever DBAs use Enterprise Manager performance pages. At list that adds $800,000 on the pool count, $100,000 at eight virtual processors and $50,000 when capped.

Which core factor row applies to your Power processor?

Oracle's processor core factor table puts modern IBM Power cores at 1.0, against 0.5 for mainstream x86. Older generations are not all at 1.0, and the table is revised, so read the row for your exact processor. Our explainer on the core factor table covers how the multiplier is applied.

The January 2026 table does not list Power11. If you are moving Oracle to Power11 hardware, ask Oracle in writing which factor it will apply before you size the partitions, and keep the reply with your license records.

How to compare Power and x86 fairly

A Power core and an x86 core are different units. Take a hypothetical workload that needs 16 Power cores, which is 16 Processor licenses. On x86, 32 cores produce the same 16 licenses, so Power is cheaper in Oracle terms only if 16 Power cores do more of your work than 32 x86 cores.

That is the comparison Power often wins on throughput and loses on a simple core count. Run it with your own benchmark data before any platform decision. Our IBM Power and AIX licensing guide covers the IBM side of the same hardware.

Where Standard Edition 2 fits on Power

Standard Edition 2 is licensed by socket with a server maximum, which makes a large Power frame an awkward home for it. Check the current server limits in our Standard Edition 2 guide before you assume an edition change is the cheaper answer.

Do Live Partition Mobility and Capacity on Demand change the Oracle boundary?

Yes, and both are often missed. Mobility widens the boundary from one frame to every frame a partition can move to. Capacity on Demand changes the core count Oracle can point at, often without any change request reaching the license team.

How Live Partition Mobility widens the count

The policy is explicit here. PowerVM Live Partition Mobility is not an approved hard partitioning technology, and Oracle states that all cores on both the source and destination servers must be licensed where it is used. The response is to control which frames are valid targets and to prove it.

• Name the target frames. Keep the mobility group small and documented, ideally one partner frame used for maintenance.
• License the targets or block them. A frame that is a valid live target and is not licensed is an open claim.
• Keep the movement log. The console records each migration. Export it, because the record proves the partition stayed inside the group.

Activated cores, installed cores and elastic activation

Oracle counts cores that are activated and available, and leaves out cores physically installed but dark. That distinction is worth real money on frames bought with unactivated capacity, and it is fragile.

• Permanent activations. These count from the day they are enabled. Record the date, because it sets when the license obligation started.
• Elastic and trial activations. These turn cores on temporarily. If the pool an Oracle partition can borrow from grows, so does the number Oracle can argue.
• Enterprise pools. Mobile capacity shared across frames raises the same question as mobility, so record which frames the capacity can land on.
• An approval step. Put a licensing check into the activation process, so an operator does not turn on eight cores for a month end without knowing the price.

How far does a shared pool maximum get you?

A shared processor pool with a defined maximum capacity does bound what an uncapped partition can consume. The policy does not name pools as an approved boundary, so treat the pool maximum as a negotiating position backed by configuration evidence. It is not an entitlement.

In the matters we have run, that position holds more often than not when the pool maximum is small, documented and stable. It rarely holds when the pool maximum is close to the size of the frame. The same arguments on x86 appear in our virtualization licensing guide.

What have we seen in Oracle on IBM Power reviews?

Partition configuration decided the outcome every time. Between 2024 and 2025 Fredrik Filipsson reviewed roughly 16 to 22 Oracle on IBM Power environments; our engagement file records 19. None of the disputes was about whether Oracle approves Power; each one turned on how the partitions were set up and whether the customer could prove it.

Why buying Power does not settle the Oracle question

The usual advice is that IBM Power is safe for Oracle because Oracle approves the technology. We disagree with that. Approval attaches to a configuration, and in roughly three out of five Power environments we reviewed, uncapped or oversized partitions meant the approved technology delivered none of its benefit.

The 1.0 core factor makes it worse, because every core an unbounded partition can reach costs twice what the same mistake costs on x86. What protects you is the sharing mode field, the entitled capacity, the saved profile and a dated export for every month of the audit period. Set those first, then choose the platform on throughput.

An uncapped Oracle partition is a soft partition wearing a hard partition badge.

How do you check your own Power partitions before Oracle does?

Run the same commands Oracle's collection will rely on, from AIX and from the Hardware Management Console, and read the fields that decide the count. Every command below only reads configuration, so you can run it on production frames and see the numbers before an auditor does.

What the AIX output tells you

The partition level view is the fastest evidence to produce and the easiest to schedule. Read these lines of the lparstat -i output for every partition with an Oracle home.

• Type. Reads Shared or Dedicated, followed by the SMT setting, for example Shared-SMT-8. The SMT part has no licensing effect.
• Mode. Reports Capped, Uncapped or Donating. This single field is the one under argument.
• Entitled Capacity. Round it up and compare it with the Processor licenses you hold for that partition.
• Online Virtual CPUs. Your counter figure if the partition turns out to be uncapped.
• Maximum Capacity. The profile maximum an auditor may say the partition can reach through dynamic LPAR.
• Active CPUs in Pool. The figure Oracle will open with if Mode says Uncapped.

What the console export must contain

Console output is the authoritative record because it holds both the running configuration and the saved profile. Export the partition list with processor mode, sharing mode, processing units and virtual processors, and export the pool level core counts alongside it.

• Export both states. Running configuration and saved profile, in the same file, on the same date.
• Export the frame. Installed, activated and available core counts for every frame that hosts or could host an Oracle partition.
• Schedule it. Monthly is enough. Quarterly is the minimum that survives a three year audit reach.
• Store it outside the platform. Console history is not an archive, and it will not be there when you need it.

Does a standby partition need a license?

Usually yes. Oracle's licensing documentation allows a standby node in a clustered configuration with shared storage to run unlicensed for a limited number of days each calendar year. Read the wording in the Database Licensing Information manual for your release before relying on it for a high availability partition, because it is narrower than most architects assume.

How does the Power question play out in an Oracle audit?

It starts as a data request and ends as a number. Oracle's collection asks for operating system and console output across every frame, and the sharing mode field is read before anything else in the pack.

What the audit collection asks for

• Operating system output per partition. Processor mode, sharing mode, entitled capacity, virtual processors and pool membership.
• Frame level core counts. Installed, activated and available cores, which set the ceiling of any uncapped claim.
• Database inventory. Installed homes, versions, editions, and the options and management packs in use, because packs are priced per Processor on the same count.
• Non production partitions too. Development, test and standby partitions are licensable unless a specific term says otherwise, and they are where uncapped settings survive longest.

Run that collection yourself first. The scripts from Oracle's license management function report what the platform is configured to allow, and you want to read that output before Oracle does. Our analysis of the audit scripts explains what each one captures.

What Oracle's auditors say, and how to answer

Four steps that keep the number down

1. Agree scope and period in writing, naming the frames in scope, before any output is shared.
2. Produce your own dated exports rather than accepting a live collection across every frame.
3. Answer the uncapped claim with the virtual processor ceiling and the pool maximum, with evidence for both.
4. Fix the configuration before the closing meeting, so the forward position is capped and the argument covers only history.

The wider sequence sits in our Oracle audit response guide. If part of your Oracle footprint also runs on x86 hypervisors, our white paper on Oracle and VMware licensing and the Oracle on VMware guide cover the same problem on the other platform.

What to put in writing when you settle or buy

• A named list of frames and partitions. Record in the audit closure letter which partitions were reviewed and the configuration accepted, so the same history is not reopened.
• A price hold for extra Processor licenses. If you later license a mobility target frame, you want the same discount already agreed.
• The deployment described in the ordering document. A line stating the licenses cover capped partitions on named frames gives both sides a shared starting point at the next review.
• A clear audit scope clause. Frames, period and data format fixed up front stop a Power question from turning into a full data center collection.

What to do next

1. List the scope. Record every partition that runs an Oracle program, and every frame those partitions can be moved to.
2. Read both states. Check the sharing mode on each partition in the running configuration and in the saved profile, and fix any mismatch.
3. Cap every Oracle partition. Size it to measured peak plus modest headroom instead of to the frame, and bring the profile maximum down to match.
4. Round up on purpose. Set entitled capacity to the whole core you already pay for, and take the performance.
5. Start the evidence file. Run a monthly console and operating system export, stored outside the platform and kept for the full audit reach.
6. Control mobility and activation. Restrict the mobility group, name the valid target frames, and add a licensing check to capacity activation.
7. Price both positions. Use the published Oracle price list and the core factor table explained to cost capped and uncapped, then revisit every cap at each renewal.

Frequently asked questions