Oracle on IBM Power. The cap is the boundary.

IBM Power is one of the few platforms where Oracle agrees the partition is the licensable unit. That agreement is conditional, the condition is the cap, and on a 1.0 core factor platform the difference between a capped partition and an uncapped one is measured in millions.

Which Power partition types does Oracle actually accept?

Two of them. Oracle's partitioning policy lists dedicated processor partitions and capped micro partitions among the approved hard partitioning methods, and stops there.

Everything else on a Power frame is a soft boundary in Oracle's reading, which means the licensable unit reverts to something larger than the partition. Knowing which side of that line each partition sits on is the whole exercise.

Why simultaneous multithreading does not change the count

Oracle counts cores, not threads. A Power core running with eight hardware threads presents eight logical processors to the operating system and still counts as one core, so turning simultaneous multithreading on or off changes performance and changes nothing on the invoice.

The configuration that quietly fails the test

Workload partitions are the common one. Teams treat them as isolation, but Oracle does not recognize them as a licensing boundary, so the containing partition is licensed in full regardless of how the workload partitions are sized.

• Isolation is not partitioning. An operating system level container inside an approved partition adds no licensing benefit.
• Resource controls are not caps. A processor set or a resource limit inside AIX is invisible to the policy.
• The boundary must be the hypervisor's. Only the partition definition held by the management console counts.

What exactly changes between capped and uncapped?

The ceiling on how much processor the partition can consume, and therefore the number Oracle can defend. A capped partition cannot exceed its entitled capacity. An uncapped partition can borrow from the shared pool up to the number of virtual processors it has online.

Three numbers decide the answer

• Entitled capacity. The guaranteed processing units, set in fractional increments. For a capped partition this is the hard ceiling and therefore the licensable number.
• Online virtual processors. The count of 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. This is the number Oracle opens with when the partition is uncapped.

The gap between the second and third numbers is where the negotiation happens. Oracle's opening position is the pool because the policy gives it no approved boundary to stop at, and the technical argument that pulls the number down is that consumption cannot physically exceed the online virtual processors.

The rounding rule that wastes 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 license as four Processor licenses, so the partition sized at 3.2 is paying for capacity it declined to take.

Check every Oracle partition for this. Sizing to a whole number or just below the next one is free performance.

The saved profile trap

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

Auditors ask for both. In the estates we reviewed this mismatch was the second most common finding after outright uncapped partitions.

White Paper · Oracle

Oracle & VMware Licensing

Bound Oracle licensing on VMware. Read it free.

Read the white paper

What does the cap decision cost on a real frame?

On a 1.0 core factor platform, more than most infrastructure teams expect. Here is the arithmetic on a single frame, using published list prices only so you can rebuild it with your own numbers.

The worked example

• The frame. A Power10 system with 64 activated cores, all in one shared processor pool.
• The partition. One Oracle Database Enterprise Edition partition, entitled capacity 3.2 processing units, eight online virtual processors, sharing mode 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 3.2 rounds up to four Processor licenses.

At the published Enterprise Edition list of 47,500 dollars per Processor in Oracle's technology price list, that is 3.04 million dollars, 380,000 dollars and 190,000 dollars respectively. The sharing mode field is worth 2.85 million dollars of exposure on one frame.

The core factor row you have to read yourself

Modern IBM Power cores sit at 1.0 in Oracle's processor core factor table, 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 rather than assuming.

The practical consequence is that a Power core and an x86 core are not comparable units. Compare platforms on licensable cores after the core factor for the same delivered throughput, which is the comparison Power usually wins and core count comparisons usually lose.

What this does to a Standard Edition estate

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 assuming an edition change is the cheaper answer.

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

Yes, and both are routinely missed. Mobility widens the boundary from a frame to a group of frames, and capacity on demand changes the core count Oracle can point at without anyone raising a change request.

Mobility turns one frame into a pool of frames

If a partition can be moved live to another frame, Oracle argues that the target frames are in scope on the same reasoning it uses for any other mobility technology. The defence is the same as the exposure: restrict which frames are valid targets and evidence the restriction.

• Name the target frames. Keep the mobility group small and documented, ideally to a single partner frame 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 what is activated and available, not what is physically installed but dark. That distinction is worth real money on frames bought with unactivated capacity, and it is fragile.

• Permanent activations. Count from the day they are enabled. Track 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. Evidence which frames the capacity can land on.
• Approval gate. Put a licensing check into the activation process, so nobody turns on eight cores for a month end without knowing the price.

Shared pools with a maximum, and how far that gets you

A shared processor pool with a defined maximum capacity does bound what an uncapped partition can consume. Oracle's policy does not name pools as an approved boundary, so treat the pool maximum as a negotiating position supported by configuration evidence rather than as 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 holds rarely when the pool maximum is close to the frame.

How does the Power question land in an actual audit?

As a data request first and a number later. 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 collection actually 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 sets 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. Scripts written by Oracle's license management function report what the platform is configured to allow, and you want to see that output before Oracle does.

The four moves that hold 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 is only about history.

The wider sequence sits in our Oracle audit response playbook and in the virtualization licensing guide.

What evidence actually proves the cap?

Dated exports from the hardware management console and the operating system, covering the whole audited period. A current screenshot proves the configuration today and says nothing about the year Oracle is asking about.

From the operating system

The partition level view is the fastest evidence to produce and the easiest to schedule. On AIX the standard command reports the fields that decide the license count.

• Type. Shows whether the partition uses shared or dedicated processors.
• Mode. Reports capped, uncapped or donating. This single field is the one under argument.
• Entitled capacity. The processing units that set the capped license count.
• Online virtual processors. The ceiling that bounds an uncapped partition.
• Active cores in the pool. The number Oracle will open with if the mode field says uncapped.

From the management console

Console output is the authoritative record because it holds both the running configuration and the saved profile. Export the partition list with the processor mode, sharing mode, processing units and virtual processor fields, 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 can 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.

The standby partition question

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 you rely on it for a high availability partition, because it is narrower than most architects assume.

Where the common advice on Oracle on IBM LPAR is wrong

The standard advice is that IBM Power is safe because Oracle approves the technology, so the platform choice solves the licensing question. We disagree. Approval attaches to a configuration, not to a product, and in roughly three out of five Power estates we reviewed the Oracle partitions were uncapped or sized to the frame, which means the approved technology was delivering none of its benefit. Worse, Power carries a 1.0 core factor, so every core an unbounded partition can reach costs twice what the same mistake costs on x86. The platform does not protect you. The sharing mode field, the entitled capacity, the saved profile and the dated export do.

Approved hard partitioning is a configuration, not a purchase. An uncapped Oracle partition is a soft partition wearing a hard partition badge.

What should a buyer do next?

Work this list in order. The first four items are configuration and evidence, cost nothing, and remove most of the exposure before any negotiation starts.

The sequence to run this quarter

1. List every partition that runs an Oracle program, and every frame those partitions can be moved to.
2. Read the sharing mode on each one, in the running configuration and in the saved profile, and fix any mismatch.
3. Cap every Oracle partition, sized to measured peak plus modest headroom rather than to the frame.
4. Round entitled capacity up to the whole core you are already paying for, and take the performance.
5. Start a monthly console and operating system export, stored outside the platform, retained for the full audit reach.
6. Restrict the mobility group, name the valid target frames, and put a licensing check in the capacity activation process.
7. Price both positions using the published Oracle price list and the core factor table explained, then revisit every cap at each renewal.

Related reading: the Oracle partitioning policy in detail, implementing approved hard partitioning, IBM Power and AIX licensing, and the x86 side of the same problem in our Oracle on VMware guide.

Frequently asked questions

Does Oracle accept IBM LPAR as hard partitioning?

Yes, for two configurations. Oracle's partitioning policy names dedicated processor partitions and capped micro partitions as approved, which lets you license the partition rather than the frame. An uncapped micro partition is not on that list.

What is the difference between a capped and an uncapped partition for licensing?

A capped partition cannot consume more than its entitled capacity, so that entitled capacity is the licensable number. An uncapped partition can borrow from the shared pool, so Oracle opens by claiming the pool and the argument moves to the online virtual processor count.

How are fractional processing units licensed?

They round up to whole cores. An entitled capacity of 3.2 processing units licenses as four Processor licenses, which is the same count as 4.0, so a partition sized just below a whole number is paying for capacity it is not using.

What core factor applies to IBM Power?

Modern IBM Power cores carry a 1.0 core factor against 0.5 for mainstream x86, so every Power core counts in full. Older Power generations are not all at 1.0, so read the row for your exact processor in the current core factor table.

Does Live Partition Mobility affect the license count?

It can widen it. If a partition can be moved live to other frames, Oracle argues those target frames are in scope, so keep the mobility group small, license or block the targets, and export the migration record as evidence.

Do Workload Partitions reduce Oracle licensing?

No. Oracle does not recognize operating system level containers inside a partition as a licensing boundary, so the containing partition is licensed in full no matter how the workload partitions are sized.

What evidence should we keep for an audit?

Dated exports from the management console showing both the running configuration and the saved profile, plus operating system output showing mode, entitled capacity and online virtual processors. Monthly is comfortable, quarterly is the minimum that survives a three year audit reach.

Is Oracle cheaper on Power or on x86?

It depends on throughput per licensable core, not on core count. Power cores count double under the core factor but deliver more work per core, so the honest comparison is licensable cores after the core factor for the same delivered workload.