Db2 runs heavily on IBM Power hardware, and Power virtualization counts cores differently from the commodity hypervisors most teams picture when they think about sub-capacity. The difference is not a footnote. It is the single most common reason a Db2 on Power deployment looks compliant on the floor and lands as a finding under audit. Understanding how the LPAR core count actually works is the whole game.
How Power counts cores.
Sub-capacity licensing lets you license only the cores running IBM software rather than the entire physical host. On Power, the relevant figure is the capacity assigned to the logical partition where Db2 runs. The trap is that a partition is counted on its allocated or maximum entitled capacity, not on how busy it happens to be. A partition sized to four cores is a four core partition for licensing even if Db2 sits nearly idle. Teams that size partitions generously for headroom, or that set a high maximum for occasional bursts, can be paying for capacity they almost never use, and an auditor will count the entitled maximum, not the average load.
Where the count goes wrong.
The recurring problems on Power are specific and avoidable once you know to look for them:
- Maximum versus desired capacity. A partition with a low desired core count but a high maximum can be assessed on the maximum, inflating the PVU figure well past day to day use.
- Uncapped partitions. An uncapped partition that can draw cores from a shared pool may be counted on the pool capacity it can reach, not the entitlement you intended.
- Missing or stale ILMT data. Without continuous tooling that captures the partition capacity correctly, IBM defaults the deployment to the full physical host, and a large Power frame makes that delta enormous.
- Frame consolidation. Several Db2 partitions on one frame, each sized for headroom, quietly add up to far more licensable PVU than the workload requires.
The PVU math on a Power frame.
The arithmetic is the same as any PVU product: PVU per core times the cores the software is entitled to use. The amplifier on Power is the size of the physical frame. If sub-capacity is not supported by clean tooling and IBM falls back to full-capacity charging, the count jumps from the cores in the Db2 partitions to every core on the frame. On a large frame that can be the difference between a few hundred PVU and several thousand. The defense is to keep the partition capacity correctly captured and reported so the claim never has grounds to default to the whole machine.
Db2 on Power findings almost always trace to partition sizing and tooling, not to genuine over deployment. The buyer side response is a partition by partition recount: what each LPAR is entitled to, how it was sized, and whether the tooling captured it continuously. Done before IBM finishes its own count, that recount is what keeps the claim off the full frame and on the cores Db2 actually uses.
The buyer side defense.
Defending Db2 on Power starts by containing the data request, then independently reconstructing the core count for every partition: desired and maximum capacity, capped or uncapped behavior, and the shared pool exposure. We validate the sub-capacity position against the tooling record, dispute any default to full-capacity charging where the partition data supports a smaller count, and confine genuine gaps to the precise partition and period. The corrected position is written into the settlement alongside a forward sizing plan that keeps Power partitions inside their entitlements.