The Oracle Core Factor Table: Counting Processors Right

On premises, Oracle does not license physical cores. It licenses cores multiplied by a core factor, and getting that multiplier wrong is the most common over and under licensing error in an Oracle estate.

Prepared by Redress Compliance · July 2026 · Oracle licensing advisory. Representative Oracle estate scenario (benchmark scenario, not a quote). Core factors per the Oracle Processor Core Factor Table.

Oracle's Processor metric does not count cores directly. It counts licensable processors, defined as the number of physical cores in scope multiplied by a factor that Oracle assigns to each processor type in its Processor Core Factor Table. The formula is one line:

The factor exists because Oracle rates different chip architectures differently. It is applied to physical cores, never to threads or vCPUs on premises, and the result is what feeds every downstream number: the Processor licence, the Named User Plus minimum of 25 per processor, and the per-processor price of every option and management pack.

Because that one number cascades into so many others, it is the highest-leverage figure in an Oracle estate. An error in the core factor is not a single mistake; it is a mistake replicated across the base licence, the user minimum, and every option, in the same direction and by the same proportion. Getting it right once removes error from all of them at once, which is why the counting step deserves more care than it usually receives.

The full table lists many processor families, but a handful cover almost every enterprise estate. The values below are the ones you will use; always read the current table for the exact chip, because Oracle revises it.

The spread is the point. The same 32 core workload is 16 licences on x86 and 32 licences on IBM POWER, a two to one difference driven entirely by the chip, before any negotiation. Architecture choice is a licensing decision, not only a performance one.

Take a two socket x86 server, each socket a 16 core processor, for 32 physical cores. The count is not 32. Apply the 0.5 factor and the licensable count is 16 processors. On Enterprise Edition at $47,500, that is $760,000, against $1.52M if the cores were counted raw. The factor halves the base licence and, with it, the NUP minimum and every option.

The single most expensive misconception is that the core factor travels everywhere. It does not. It is a feature of on premises processor counting only.

• On premises: yes. Physical servers and hard-partitioned environments count cores times the factor. This is the home of the 0.5 x86 benefit.
• Authorized cloud environments: no. On AWS and Azure the vCPU rule governs — two vCPUs per processor with hyperthreading on — and the core factor does not apply. Carrying the 0.5 assumption into the cloud under licenses by half.
• Standard Edition Two: no. SE2 is licensed per socket, so the core factor is irrelevant to it entirely.

The pattern to hold onto is that the core factor is a property of owned, on-premises processor counting, and of nothing else. It is not a general Oracle discount that follows the software wherever it runs; it is a rating applied to physical cores under the Processor metric. The moment the counting basis changes — to vCPUs in an authorized cloud, or to sockets on Standard Edition Two — the factor leaves with it, and assuming otherwise is the most expensive counting error a buyer can make.

The boundary matters most in a migration. A database counted at 8 processors on premises with the factor becomes a 16 vCPU cloud instance counted as 8 processors under the vCPU rule — often the same number, but arrived at by a different route, and easy to miscount in either direction. Our companion paper, the Oracle on Azure and AWS BYOL Field Guide, works the cloud counting in full.

Virtualization is where the factor is most often misapplied, and the error is expensive. Oracle recognises only hard partitioning as a way to bound the licensable core count. Soft partitioning — assigning a VMware virtual machine four vCPUs on a large cluster — does not, in Oracle's position, limit the count to those four. Oracle counts every physical core in the environment on which the database could run, applies the factor to that full set, and prices accordingly.

On a large VMware cluster, that position can turn a four vCPU database into a licence claim across every host the workload could migrate to. The buyer side move is to bound the environment deliberately — dedicated hosts, approved hard partitioning, or affinity rules Oracle recognises — and to apply the core factor only to the cores genuinely in scope, with the boundary documented before an audit tests it.

The financial stakes on a large cluster are easy to understate. A four vCPU database that a team believes is a small, cheap deployment can, under Oracle's soft partitioning position, carry a licence claim across every physical core in a cluster it could reach, factored and priced in full. The difference between the assumed count and the claimed count on a busy virtualization estate is frequently an order of magnitude, which is why bounding the environment is the single most valuable control in a virtualized Oracle deployment, and why it must be designed in rather than argued after the fact.

The core factor does not only price the Processor metric. Because the Named User Plus minimum is 25 per processor, the factored processor count sets the NUP floor as well. A 32 core x86 server at 16 licensable processors floors Named User Plus at 400 users, regardless of how few people use the database.

One number therefore drives the whole licence: the Processor licence, the NUP minimum, and the per-processor price of every option. Counting it correctly is the precondition for every other decision, including the metric choice worked in our companion paper, Named User Plus or Processor.

The common advice is that moving to the cloud is automatically cheaper because the vCPU rule is simpler than the core factor. We disagree, and the missing factor is why.

On premises, the 0.5 x86 factor already halves the count. In the cloud, the vCPU rule counts two vCPUs to a processor, which lands at a similar number for the same hardware but removes the factor as a lever and, for Standard Edition Two, applies a hard vCPU cap that on premises sockets do not. In the estates we reviewed, buyers who assumed the cloud was cheaper on licensing, rather than on hardware, were frequently wrong once the lost factor and the options were counted. The saving is real on infrastructure; it is not automatic on the Oracle licence.

The buyer side move is to count both ways — cores times the factor on premises, vCPUs under the policy in the cloud — and to compare the licence, not just the compute rate, before deciding where the workload belongs.

The deeper point is that the counting regimes are not interchangeable conveniences; each is a full rule with its own consequences. On premises the factor rewards dense, high-core x86 hardware; in the cloud the vCPU rule rewards right-sized instances and punishes disabled hyperthreading; on Standard Edition Two the socket rule rewards a small, bounded footprint. A buyer who knows which regime governs each deployment can place workloads to be counted favourably, rather than discovering the counting basis only after the hardware has been bought and the licence position is fixed.

The core factor is one multiplier that sets three numbers: the processor licence, the user minimum, and every option. Count it once, correctly, and the rest of the Oracle bill falls into place.

Counting an Oracle estate correctly runs on a short, ordered sequence, and it is worth repeating whenever the hardware, the hypervisor, or the deployment changes.