How to Count Oracle Database Processor Cores Correctly
To count Oracle Processor licences on premises, multiply the number of physical cores in scope by the core factor for that processor type from Oracle's core factor table, then round the result up to the next whole number. On authorised clouds the core factor does not apply and a vCPU rule is used instead. The hard part is defining which cores are in scope, because virtualisation can pull an entire cluster into the count.
Counting Processor licences correctly is the foundation of every Oracle Database position, and it is where estates most often go wrong in both directions, paying for cores that are out of scope or under licensing cores that are in. The arithmetic itself is simple; the difficulty is knowing which cores to feed into it. This article sets out the formula, the physical core rule, the core factor, the rounding convention, and above all how to define scope, so an estate can produce a count it can defend. It sits under the database licensing pillar and depends on the core factor table.
The core counting formula
The on premises formula is straightforward: take the number of physical cores in scope, multiply by the core factor for that processor type, and round the result up to the next whole number. Sixteen physical cores at a core factor of 0.5 produces eight Processor licences. The same sixteen cores at a factor of 1.0 produce sixteen. The formula never changes; what changes is the two inputs, the in scope core count and the correct factor.
Because the formula is reliable, errors come from the inputs. The most expensive input error is the scope of cores, addressed below; the most common is using the wrong core factor for the processor, which the core factor table exists to prevent.
Counting physical cores, not threads
On premises, Oracle counts physical cores, not the logical threads that hyperthreading presents. A processor with sixteen physical cores that exposes thirty two threads through hyperthreading is sixteen cores for licensing. Counting threads instead of cores doubles the figure and is a frequent source of accidental over licensing by estates that read the operating system's logical processor count rather than the physical core count.
The figure to use is the physical core count of the processors in scope, taken from the hardware specification rather than from an operating system view that may report threads. The cloud vCPU rule is the deliberate exception to this, treated separately below.
Applying the core factor table
The core factor is Oracle's multiplier for each processor type. Common Intel and AMD x86 processors carry a factor of 0.5, so two physical cores equal one Processor licence, while several other architectures carry higher factors up to 1.0. The factor is applied to the physical core count before rounding. Using a 1.0 factor where 0.5 applies doubles the licence count; using 0.5 where a higher factor applies under licenses and creates a finding.
The factor depends on the exact processor model, so the count starts with an accurate hardware inventory mapped to the published table. This mapping is also what determines whether the Processor metric or Named User Plus is cheaper, the comparison drawn in the Processor versus Named User Plus article.
How rounding works per server
Rounding to the next whole Processor licence is applied after multiplying cores by the core factor, and it is applied per server or per licensing boundary rather than across the whole estate at once. A computed 8.0 requires eight licences; a computed 8.5 requires nine. The point at which rounding is applied matters: rounding each server separately can produce a higher total than aggregating raw fractional results first, so the rounding boundary has to follow what the contract specifies.
Getting the rounding boundary wrong is a subtle but real error, especially across many small servers where fractional results would otherwise combine. The convention should be confirmed against the licence agreement rather than assumed.
Defining which cores are in scope
Scope is where the real money is. On a physical server the cores in scope are the cores of that server. On virtualised infrastructure, Oracle's position pulls every core the software could run on into scope, which on VMware can mean an entire cluster within reach of vMotion, as the VMware licensing guide explains. A four core Oracle deployment on a two hundred core cluster can be assessed against the two hundred cores without isolation Oracle accepts.
Defining scope therefore means establishing the hard boundary around Oracle workloads, through dedicated clusters or a recognised partitioning approach, so the in scope core count is small, defined, and defensible. Scope, not the formula, is what separates a modest count from a catastrophic one.
Counting cores in the cloud
On Oracle's authorised cloud list the core factor table does not apply. Instead a vCPU rule governs: with hyperthreading enabled, two vCPUs count as one Processor licence, and without it one vCPU counts as one. This replaces the physical core and core factor arithmetic entirely, so a cloud instance is sized by its vCPU count against the rule, as set out in the Oracle on AWS guide and its Azure and Google Cloud counterparts.
The shift from core factor to vCPU counting is one reason cloud migrations need their own licence plan, because a count that was correct on premises does not translate directly to the cloud's rule.
Worked core counting examples
| Configuration | Calculation | Processor licences |
|---|---|---|
| 16 physical x86 cores, factor 0.5 | 16 times 0.5 | 8 |
| 18 physical cores, factor 0.5 | 9.0, no rounding needed | 9 |
| 10 cores, factor 0.5, two servers | 5 plus 5 rounded per server | 10 |
| 32 vCPUs cloud, hyperthreading on | 32 divided by 2 | 16 |
The buyer side view
The buyer side position is that core counting is two thirds scope and one third arithmetic. The formula, the physical core rule, the core factor, and the rounding convention are all knowable and fixed, so an estate that gets them right will not over or under license on the maths. The decisive work is defining the boundary of cores in scope, because virtualisation can multiply a small deployment into a cluster sized count, and the cloud replaces the whole method with a vCPU rule. Establish the hardware inventory, apply the published factor, round on the contractual boundary, and above all isolate Oracle so scope stays small. Start with the database pillar and the core factor table, and where scope is contested bring in audit defence or request a consultation. For a related scenario, see Enterprise versus Standard Edition 2.
Common questions.
How do you calculate Oracle Processor licences?
Multiply the number of physical cores in scope by the core factor for that processor type, taken from Oracle's published core factor table, then round the total up to the nearest whole number. For example sixteen physical cores at a core factor of 0.5 equals eight Processor licences. On authorised clouds the core factor is not used; a vCPU rule applies instead, typically two vCPUs to one Processor licence with hyperthreading on.
Do you count physical cores or threads?
On premises you count physical cores, not threads or logical processors. Hyperthreading, which presents two logical threads per core, does not change the physical core count for licensing, so a sixteen core server presenting thirty two threads is still counted as sixteen cores. The vCPU counting on authorised clouds is the exception, where Oracle counts vCPUs that correspond to threads under a separate rule.
What is the core factor and where do I find it?
The core factor is a multiplier Oracle assigns to each processor type that converts physical cores into Processor licences. It is published in Oracle's Processor Core Factor Table, with common Intel and AMD x86 processors at 0.5 and many other architectures at higher values. The factor is applied to the physical core count before rounding, and using the wrong factor is a frequent cause of both over and under licensing.
How does rounding work when counting cores?
Rounding to the next whole Processor licence is applied per server or per licensing boundary after multiplying cores by the core factor, not across the whole estate at once. A result of 8.0 needs eight licences and a result of 8.5 needs nine. Rounding per server rather than aggregating first can change the total, so the boundary at which rounding is applied has to follow the contract.
How are cores counted in the cloud?
On Oracle's authorised cloud list the core factor table does not apply. Instead, with hyperthreading enabled, two vCPUs count as one Processor licence, and without hyperthreading one vCPU counts as one Processor licence. This replaces core factor arithmetic entirely, so a cloud instance is sized by its vCPU count against this rule rather than by physical cores and core factors.