Oracle PAH license guide the real cost of pooled hardware.

Processor aggregation across pooled hardware can quietly inflate an Oracle license requirement. The fix is bounding the pool before the auditor counts it for you.

This guide is for license managers dealing with pooled or aggregated processor hardware under Oracle. Read it with the Oracle partitioning policy and the core factor table.

Oracle licenses the cores where a database can run. When hardware is pooled or aggregated, that set is larger than most teams expect, and the bill follows the larger number.

What does processor aggregation mean for Oracle licensing?

Aggregated hardware pools combine processors so workloads can move freely across them. For Oracle, free movement means every core in the pool is a place the database could run.

Why does Oracle count where it could run?

Oracle's policy counts installed and running plus anywhere the software is available to run. In a pooled environment, that is the whole pool unless an approved boundary stops it.

• Installed and running: the obvious cores you expect to license.
• Available to run: any core the workload can reach in the pool.
• The gap: the difference is where pooled estates over expose.

Do soft limits reduce the count?

No. Tools that cap CPU through software are soft partitioning, which Oracle's policy does not accept as a boundary. The full pool stays in scope for the count.

How is an aggregated pool counted for licensing?

Counting starts with the full set of cores the database can reach, then applies the core factor. The first number is the one that surprises buyers.

What are the counting steps?

First, identify every core the workload can reach across the pool. Second, apply the core factor for the processor type. Third, compare the result to your held entitlement.

• Reachable cores: the total across the aggregated pool.
• Core factor: the multiplier for the processor family.
• Entitlement check: reachable cores against licenses held.

When does the core factor apply?

The factor applies after the reachable core count is fixed. Reducing the reachable set matters more than the factor, because the factor only discounts a number you have already inflated.

Oracle licenses where the database could run, not just where it does. In a pool, that is everything until you bound it.

Where do buyers slip on aggregated hardware?

The slips are predictable. Trusting soft limits, ignoring pool growth, and assuming usage equals exposure. Each one widens the gap between what you license and what Oracle counts.

Why is trusting soft limits a trap?

Soft caps feel like a boundary but Oracle does not treat them as one. A team that licenses to the soft cap is under licensed against the policy and exposed in an audit.

How does pool growth quietly raise cost?

Adding hardware to a pool adds reachable cores. The Oracle requirement rises even though the workload did not change. Review the pool size whenever capacity is added.

What buyer side moves bound the pool?

The moves are physical separation, approved partitioning, and timing. Bounding the pool before Oracle measures it is far cheaper than arguing after.

Why separate Oracle onto dedicated hardware?

A dedicated, licensed set of hosts removes the aggregation question. The reachable core count equals the licensed count, and the audit conversation becomes simple.

When is approved partitioning the answer?

Where separation is not practical, approved hard partitioning bounds the pool to a defined core set. It is the only software boundary Oracle accepts, so it is the only one worth designing around.

Suggested reading

• Oracle partitioning policy. Cross vendor reading from the wider library.
• Oracle core factor table. Cross vendor reading from the wider library.
• Oracle on virtualized hardware. Cross vendor reading from the wider library.

What to do next

1. Map every aggregated pool and the Oracle workloads inside it.
2. Identify every core each Oracle database can reach across the pool.
3. Replace any reliance on software CPU caps with an approved boundary.
4. Apply the core factor only after the reachable core count is fixed.
5. Separate Oracle onto dedicated licensed hosts where practical.
6. Review reachable cores whenever pool capacity is added.
7. Document the boundary as audit evidence before measurement.

Frequently asked questions

What does Oracle count in an aggregated processor pool?

Oracle counts every core the database can reach, not only the cores where it runs. In a pooled environment that is the whole pool unless an approved hard partitioning boundary limits it.

Do software CPU caps limit Oracle licensing?

No, software CPU caps are soft partitioning and Oracle's policy does not accept them as a boundary. The full pool stays in scope, so licensing only to the soft cap leaves you exposed in an audit.

How are licenses calculated for a pool?

Identify the reachable cores across the pool, apply the core factor for the processor family, then compare the result to the licenses you hold. The reachable count is the number that usually surprises buyers.

Does adding hardware to a pool raise my Oracle cost?

Yes, adding hardware adds reachable cores, which raises the Oracle requirement even when the workload is unchanged. Review the reachable core count whenever you add capacity to a pool.

What is the only accepted way to bound a pool?

Approved hard partitioning, or physically dedicating licensed hosts to Oracle. These are the only boundaries Oracle's policy accepts, so they are the only designs worth building a licensing position around.

Should I dedicate hardware to Oracle?

Where practical, yes. A dedicated, licensed set of hosts makes the reachable core count equal the licensed count and removes the aggregation argument, which simplifies every future audit conversation.