The Oracle Core Factor Table Explained

The core factor table is one of the few genuinely simple instruments in Oracle licensing, and yet it quietly decides the cost of every Processor licensed database in an estate. Understanding it is the prerequisite to the processor versus Named User Plus decision and to any hardware refresh plan. This article explains what the factor is, how to apply it, and where it stops applying.

What is the Oracle core factor?

The core factor is a multiplier Oracle publishes for each processor type in a document called the Oracle Processor Core Factor Table. It exists because not all cores are treated as equal for licensing. Rather than license one processor licence per physical core, Oracle weights each core by the factor assigned to its processor family. The licensable processor count is simply physical cores multiplied by the factor, rounded up to the next whole number.

The table is a policy document Oracle maintains and can revise. The factor that applies to a given licence is generally the one in force when the licence was acquired, which means the contract governs rather than the current published table. This distinction matters in disputes, because Oracle sometimes applies the current table to historic licences, and the customer is entitled to the factor that applied at acquisition.

How the multiplier works

The calculation has three steps: identify the processor type, read its factor from the table, and multiply by the number of physical cores in the server. A server with two sockets of sixteen cores each has 32 physical cores; at a factor of 0.5 that is 16 processor licences. The factor applies to cores, not sockets or threads, and hyper threading does not change the count because it does not add physical cores.

The rounding rule is that fractional results round up to the next whole licence. A 0.5 factor applied to an odd core count therefore lands on a half and rounds up. Most modern data centre x86 processors carry a factor of 0.5, a small number carry 1.0, and a handful of older or specialised processors carry 0.25. The full set of factors is in the published table and is reproduced in the database licensing white paper.

Worked examples by processor

The practical takeaway from the table is that the processor family, not just the core count, drives the licence requirement. Two servers with identical core counts can require very different licence quantities if they use processors with different factors. This is why a hardware decision is also a licensing decision, a point we return to below.

Why the core factor does not apply in the cloud

The single most important exception is that the core factor table does not apply in Oracle's authorised cloud environments. In Oracle Cloud Infrastructure and certain authorised third party clouds, capacity is counted per OCPU or per vCPU under separate published rules, and the on premise core factor is irrelevant. This catches many estates planning a cloud migration, because a calculation done with the core factor will not match the cloud counting model.

The consequence is that a migration which looks cheaper on a core factor basis can be more expensive once the cloud counting rules and any Bring Your Own Licence conversion ratios are applied. A cloud move should always be modelled on the actual cloud counting model rather than the on premise factor, work that sits with the cloud and OCI licensing service. The interaction between virtualisation and core counting on premise is covered separately in the database on VMware article.

Hardware decisions and the core factor

Because the factor weights cores by processor family, hardware refresh decisions carry hidden licence consequences. Moving to a denser processor with more cores per socket increases the physical core count and therefore the licence requirement, even if the workload is unchanged. Moving to a processor family with a higher factor increases it further. A refresh that improves performance can quietly double a licence bill if the licensing dimension is ignored at procurement.

The disciplined approach is to evaluate the licence impact of any new hardware before purchase, treating the core factor as a line item in the total cost of ownership. Sometimes a server with fewer, faster cores is cheaper to license than a denser alternative that delivers the same throughput. This is the kind of cross functional analysis the database licensing service brings into hardware planning.

Where core factor disputes arise

Two disputes recur. The first is Oracle applying the current published table to licences acquired under an earlier table; the customer is generally entitled to the factor in force at acquisition, and the contract should be checked rather than the current document accepted. The second is the cloud exception being overlooked, with on premise factors applied to cloud deployments or vice versa, producing a number that neither party can defend. Both are resolved by reading the actual agreement and the applicable counting model rather than the headline table.

The buyer side view

The core factor table is simple to apply but powerful in its consequences. The buyer side discipline is to apply the factor that the contract actually grants rather than the current published table, to model cloud deployments on the cloud counting model rather than the on premise factor, and to treat the factor as a procurement input on every hardware decision. Used well, it is a lever for reducing licence cost; ignored, it is a source of avoidable overspend and disputes. For the full factor reference and worked migrations, see the database pillar and the white paper, or request a consultation to model your estate.

How the factor table has evolved

The core factor table is not static. Oracle has revised it over the years as processor architectures changed, adding new families and adjusting factors. Most of the movement has settled around the 0.5 factor for mainstream x86 processors, but the existence of revisions is exactly why the contractual question matters. A licence acquired years ago was acquired under the table then in force, and the customer is generally entitled to that historic factor even if Oracle has since published a different one.

This becomes a live issue in audits and renewals, where Oracle occasionally applies the current table to historic entitlements. The buyer side response is to anchor the factor in the agreement and the table in force at acquisition, not in the document Oracle happens to publish today. Where the agreement is silent, the table contemporaneous with the purchase generally governs, and the dates on the original ordering documents become the decisive evidence. This contractual anchoring is part of the broader discipline set out in the database licensing pillar and applied by the audit defence practice.

Standard Edition and why the factor does not apply

The core factor is an Enterprise Edition concept. Standard Edition 2 is licensed on a different basis entirely: per socket, with a hard cap on the number of populated CPU sockets and a defined thread limit, and the core factor table plays no part. This is a frequent source of confusion when teams try to apply core factor maths to a Standard Edition deployment and arrive at a number that does not match the contract.

The practical consequence is that the edition decision and the metric decision precede any core factor calculation. Only once a database is confirmed as Enterprise Edition licensed by Processor does the factor enter the maths. For Standard Edition, the discipline is to stay within the socket and thread limits and to resist features that silently require Enterprise Edition, because a single Enterprise only feature can convert a cheap Standard Edition database into a full Enterprise Edition obligation where the core factor suddenly does apply. That conversion risk overlaps directly with the options and packs problem.

Using the factor in capacity planning

The core factor turns capacity planning into a licensing exercise. Every decision that changes the physical core count or the processor family changes the licence requirement, and those decisions are usually made by infrastructure teams who do not see the licence bill. Bringing the factor into capacity planning, as an explicit cost per core, aligns the two and prevents the common pattern where a performance driven refresh quietly inflates licensing.

The most useful planning artefact is a simple model that translates any proposed hardware change into its licence delta before purchase. A move from a 0.5 factor processor to another 0.5 factor processor with more cores per socket increases the requirement in proportion to the extra cores. A move that consolidates onto fewer, faster cores can reduce it. Modelled in advance, the factor becomes a lever for cost control rather than a surprise; the same modelling feeds directly into the metric choice, since the processor licence count drives the Named User Plus minimum. This combined analysis is core to the database licensing service.

Common core factor mistakes to avoid

Several recurring errors turn a simple calculation into an overpayment or a dispute. The first is counting threads instead of cores. Hyper threading presents two logical processors per physical core to the operating system, and teams that read the operating system's processor count can double their licence requirement on paper. The core factor applies to physical cores only, so the count must come from the hardware specification, not the operating system view.

The second is applying the wrong factor after a hardware change without re reading the table for the new processor family. A refresh to a different chip can change the factor, and assuming the old factor carries over produces an incorrect count in either direction. The third is forgetting to round up: a fractional licence result always rounds up to the next whole licence, and ignoring this understates the requirement by enough to create an audit finding.

The fourth, and most expensive, is conflating on premise and cloud counting. Applying the core factor to a cloud deployment, or applying cloud OCPU counting to an on premise server, produces a number neither party can defend and invites a dispute. Each environment has its own counting model, and the two must never be mixed. Avoiding these four mistakes is mostly a matter of sourcing the inputs correctly, the physical core count from the hardware, the factor from the table in force at acquisition, and the counting model from the actual deployment environment, a discipline that feeds directly into the metric choice and the cloud and OCI service.