Oracle Processor Factor Table Guide: Core Factors, Licence Calculations, and 2026 Updates

What is Oracle's Processor Core Factor Table?

Oracle licences its software on a Processor metric for server-side deployments. A "processor" in Oracle's licensing framework is not a CPU socket or a logical thread — it is a defined unit of licence consumption calculated by multiplying the number of physical CPU cores by the core factor assigned to the processor family in Oracle's official Processor Core Factor Table.

The Core Factor Table is a publicly available document published by Oracle on its contracts and licensing documentation page. Oracle updates the table when new processor families are released or when existing entries require revision. The table is the authoritative reference for any Oracle processor licence calculation, and it supersedes any prior understanding or informal guidance that does not reflect the current published version.

The table matters because different processor families have different core factors, and the difference between a 0.5 and a 1.0 core factor doubles the number of processor licences required for the same physical core count. At Oracle Database Enterprise Edition list prices of $47,500 per processor licence, the choice of processor architecture can mean the difference between 10 processor licences and 20 — a $475,000 difference in licence cost and approximately $104,500 per year in additional support fees compounding at 8 percent annually.

The Core Licence Calculation Formula

The Oracle processor licence calculation follows a consistent methodology for all Oracle products licensed on the Processor metric:

Step 1: Count the total number of physical cores in all processors in the server (or servers) where Oracle software is installed and running. Oracle counts physical cores only — not logical threads created by Intel Hyper-Threading or AMD Simultaneous Multi-Threading (SMT). A 24-core Intel Xeon processor that presents 48 logical CPUs to the operating system has 24 physical cores for Oracle licensing purposes.

Step 2: Identify the processor family from Oracle's Core Factor Table. The table is organised by manufacturer and processor family. Every physical processor in the server must be identified; if the server contains processors from multiple families (uncommon but possible), each processor type is factored separately.

Step 3: Apply the formula: Total Physical Cores × Core Factor = Processor Licences Required. Round the result up to the nearest whole number. Oracle requires rounding up — partial processor licences do not exist.

Example 1 — Intel Xeon Dual-Socket Server: Server contains two Intel Xeon Gold 6348 processors, each with 28 physical cores. Total physical cores = 56. Core factor for Intel Xeon = 0.5. Processor licences required = 56 × 0.5 = 28 processor licences.

Example 2 — AMD EPYC Single-Socket Server: Server contains one AMD EPYC 9654 processor with 96 physical cores. Core factor for AMD EPYC = 0.5. Processor licences required = 96 × 0.5 = 48 processor licences.

Example 3 — IBM POWER10 Server: Server contains two IBM POWER10 processors, each with 15 physical cores. Total physical cores = 30. Core factor for IBM POWER10 = 1.0. Processor licences required = 30 × 1.0 = 30 processor licences.

For a structured framework, download our Oracle Total Cost Optimisation Playbook — a step-by-step resource built from 500+ Oracle advisory engagements.

Current Core Factor Reference Table

The following table reflects the current Oracle Processor Core Factor Table entries as of early 2026, including additions made during 2025. Always verify the current version at Oracle's official contracts documentation page before performing licence calculations, as Oracle may update the table with new processor additions at any time.

For processors not listed in the Core Factor Table, Oracle's default core factor is 1.0. Any unlisted processor must be treated as a 1.0 factor until Oracle formally adds the processor to the table with a defined factor. Organisations deploying Oracle software on new processor architectures should verify table status before deployment to ensure the licensing economics are understood in advance.

2025 Processor Core Factor Table Updates

Oracle made significant additions to the Core Factor Table during 2025, extending favourable 0.5 core factors to new Intel and AMD processor generations. Understanding these additions is important both for new deployments and for organisations that may have been calculating licences incorrectly for processors added to the table during the year.

April 2025 Intel Additions

On 1 April 2025, Oracle added several new Intel Xeon processor families to the Core Factor Table, all with a 0.5 core factor. The additions included the Intel Xeon 69xxP series (high-performance data centre processors), the Intel Xeon 67xxE and 67xxP series, the Intel Xeon 65xxP series, and the Intel Xeon E-24xx series. These additions cover Intel's current-generation Xeon Scalable and workstation-class processors, ensuring that organisations deploying Oracle software on recently purchased Intel hardware have a defined, favourable core factor.

May 2025 AMD Additions

On 19 May 2025, Oracle added AMD's fifth-generation EPYC processor families — the 9xx5, 9xx5F, and 9xx5P series — with a 0.5 core factor. Oracle also expanded coverage of its existing 4th generation EPYC entries to include the 9xx4F and 9xx4P variants, and extended the 3rd generation EPYC coverage to include the 7xx3P variant. These additions confirm that AMD's latest EPYC processors, which offer some of the highest core counts available in the x86 market, continue to benefit from the 0.5 core factor.

The significance of the AMD 5th generation addition cannot be overstated for organisations considering processor architecture decisions. AMD's EPYC 9xx5 series offers up to 192 physical cores per socket. With the 0.5 core factor, that 192-core socket requires 96 processor licences. The same Oracle software on an IBM POWER10 server with equivalent performance characteristics would require processor licences at the 1.0 factor, potentially doubling the licence cost for equivalent workloads.

Physical Cores vs. Logical Threads: The HyperThreading Trap

The distinction between physical cores and logical processor threads is one of the most common sources of Oracle licence miscalculation, and it can work in both directions — causing over-licensing when logical threads are used as the basis for calculation, and potentially creating audit exposure when organisations that reduced their logical thread allocation assume this reduces their Oracle licence requirement.

Why Hyper-Threading Does Not Affect Oracle Licensing

Intel's Hyper-Threading (HT) and AMD's Simultaneous Multi-Threading (SMT) technologies allow each physical core to present two logical processing threads to the operating system. A server with 24 physical cores running Intel HT presents 48 logical CPUs to Windows, Linux, or other operating systems. Oracle counts physical cores only. The 48 logical CPUs do not affect the Oracle licence count — only the 24 physical cores are relevant.

This means disabling Hyper-Threading at the BIOS level does not reduce Oracle licence requirements (the physical core count remains unchanged), and enabling Hyper-Threading on a server does not increase Oracle licence requirements. The operating system CPU count — what you see in Task Manager, top, or similar tools — is an unreliable source for Oracle licence calculation. Always use physical core counts from hardware specifications or server management tools that report physical processor topology.

How to Accurately Count Physical Cores

Accurate physical core counting requires hardware-level verification rather than reliance on operating system reports. On Linux systems, the lscpu command output includes "Core(s) per socket" and "Socket(s)" fields that, when multiplied, provide the physical core count. The /proc/cpuinfo file contains "cpu cores" per socket. On Windows servers, the System Information tool and Device Manager provide physical processor and core count information. For VMware environments, the VMware vSphere client shows physical core counts at the host level. Oracle LMS uses certified data collection scripts that interrogate hardware topology at the physical level — organisations should use the same level of detail in their own licence calculations.

Processor Licensing in Virtualised Environments

The Core Factor Table determines the base licence count for physical deployments. In virtualised environments, the licence count calculation depends on whether the virtualisation technology qualifies as Oracle-approved hard partitioning.

Non-Oracle Hypervisors: Full Server Licensing

When Oracle software runs on a virtual machine hosted by a hypervisor not on Oracle's approved hard partitioning list — including VMware ESXi, Microsoft Hyper-V, Citrix XenServer, and all other non-Oracle hypervisors — Oracle requires licences for all physical cores in the entire server, regardless of how many vCPUs are assigned to the Oracle VM. The core factor calculation is applied to the full physical server core count.

For a VMware environment with a 2-socket server containing two Intel Xeon processors with 32 cores each (64 total physical cores), an Oracle Database VM assigned 4 vCPUs requires: 64 × 0.5 = 32 processor licences. Not 4 × 0.5 = 2 processor licences based on the VM's vCPU allocation. This is the most common and most costly Oracle licensing misunderstanding in enterprise environments.

Oracle-Approved Hard Partitioning: VM-Level Licensing

When Oracle software runs on a virtual machine or partition created by an Oracle-approved hard partitioning technology — Oracle VM Server for x86, KVM on Oracle Linux or Oracle Private Cloud Appliance, Oracle Solaris Zones (both non-global and caged), and a small number of other approved technologies — the core factor calculation is applied only to the physical cores assigned to the partition or VM's CPU pool.

Using the same 64-core server example, if Oracle Database runs on an Oracle VM instance with a CPU pool of 4 physical cores, the licence calculation is: 4 × 0.5 = 2 processor licences. The 60 remaining physical cores in the server not assigned to the Oracle VM CPU pool require no Oracle Database licences. This is the hard partitioning benefit that makes Oracle-approved hypervisors so financially valuable in Oracle deployments.

Multi-Tenant and Container Considerations

Oracle's licensing for containerised workloads follows the same physical core logic as virtualised workloads, with the key determinant being the container orchestration technology used. Kubernetes on standard Linux does not provide Oracle-recognised partitioning — all physical cores in any node where Oracle software runs must be licensed. Oracle Linux KVM-based container environments may qualify for hard partitioning treatment depending on the specific configuration.

For Oracle Cloud Native Environment deployments on Oracle Private Cloud Appliance, the CPU pool assignments at the KVM level provide the licence limitation mechanism. Container workloads running on top of KVM-partitioned infrastructure inherit the hard partitioning treatment of the underlying KVM configuration, provided the CPU pool assignments are properly documented and maintained.

Processor Architecture Strategy for Licence Cost Reduction

Processor architecture selection is a legitimate and effective Oracle licence cost management lever. When organisations have flexibility in hardware procurement, selecting processor architectures with lower core factors or fewer physical cores can reduce Oracle licence requirements substantially.

Intel and AMD Versus IBM POWER

The 0.5 core factor for Intel Xeon and AMD EPYC versus the 1.0 factor for IBM POWER9/10 creates a structural Oracle licence cost advantage for x86 deployments over IBM POWER deployments, all else being equal. Organisations running Oracle Database on IBM POWER can reduce their Oracle licence requirement by 50 percent — by processor count alone — by migrating the same workload to an x86 server with an equivalent core factor. This is a significant driver of IBM POWER to x86 migration in Oracle Database environments.

AMD High-Core-Count Strategy

AMD's EPYC processors offer significantly higher core counts per socket than Intel Xeon Scalable at equivalent price points. With the same 0.5 core factor, a higher-core AMD EPYC processor does not reduce the Oracle licence count per core — it increases it in absolute terms. However, for workloads that require high physical core counts for performance reasons, AMD EPYC's density allows organisations to consolidate more workloads onto fewer physical servers, which can reduce total Oracle-licenced server count even if the core count per server is higher.

Oracle Ampere on OCI

Oracle Ampere A1 processors on Oracle Cloud Infrastructure carry a core factor of 0.25 — the lowest core factor in the current table. For cloud-eligible Oracle workloads, deploying Oracle software on OCI Ampere A1 instances reduces processor licence requirements by 75 percent compared to IBM POWER and 50 percent compared to Intel Xeon. This favourable core factor is Oracle's mechanism for making OCI competitive for Oracle Database workloads and is a genuine cost consideration for organisations evaluating cloud migration options for their Oracle estates.

Common Core Factor Calculation Errors and Audit Risks

Oracle LMS auditors are experienced in identifying processor licence calculation errors, and the most common errors consistently produce under-licensing claims that generate significant back-billing demands. Understanding where errors occur helps organisations avoid them in their own licence position management.

Using Logical CPU Count Instead of Physical Core Count

This is the most common calculation error. IT teams report the logical CPU count from operating system tools, procurement uses that number as the basis for licence calculation, and the resulting licence count is half of what Oracle requires for Intel or AMD processors — because the logical count includes Hyper-Threading or SMT threads. The error is typically discovered in audit when Oracle's collection scripts report the physical topology and the gap between logical-based and physical-based calculations becomes apparent.

Applying the Wrong Processor to the Table

When a server contains processors that were not in the Core Factor Table at the time of purchase, organisations sometimes apply the factor from a similar processor family rather than Oracle's default 1.0. This produces an incorrect calculation unless the processor has subsequently been added to the table with a confirmed factor. Organisations should always check the current version of the Core Factor Table and, where a processor is not listed, apply the default 1.0 factor and document the rationale for any deviation.

Failing to Include All Licensed Servers

Oracle licensing applies to every server where Oracle software is installed and running — not just production servers. Development, test, staging, and disaster recovery servers where Oracle software is installed require licences unless specific licence terms exempt them (as is the case for certain DR configurations under Oracle's 10-day rule and failover provisions). Organisations that exclude non-production servers from their licence calculations routinely face significant compliance gaps in audit.

Not Updating Licence Count When Hardware Changes

Server hardware changes — processor upgrades, server replacements, blade chassis migrations, or VM migrations to new physical hosts — can change the core factor calculation. Licence positions that were accurate at the time of original deployment may become inaccurate following infrastructure changes if the licence count is not reviewed and updated to reflect the new hardware configuration.

Key Takeaways

Oracle's Processor Core Factor Table is the foundation of every processor-based Oracle licence calculation. The core factors assigned to different processor families — ranging from 0.25 for Oracle Ampere to 1.0 for IBM POWER9/10 — have a direct, linear impact on the number of processor licences required for any Oracle software deployment. Getting the core factor right, counting physical cores rather than logical threads, and applying the current version of the table to all licenced servers are the three non-negotiable requirements for an accurate Oracle licence position.

The 2025 table updates — adding Intel Xeon 69xxP/67xx/65xx and AMD EPYC 5th generation with 0.5 factors — extend favourable licensing economics to the latest x86 processor generations. Organisations that have deployed Oracle software on recently purchased Intel or AMD hardware should verify that their licence calculations reflect the current table entries rather than any prior assumptions.

Processor architecture strategy is a legitimate and material Oracle licence cost management lever. The choice between Intel/AMD x86 and IBM POWER has a 2× impact on Oracle licence requirements for equivalent core counts. Oracle Ampere on OCI creates a 4× licence efficiency advantage versus IBM POWER for cloud-eligible workloads. These differences compound significantly over the life of a deployment, particularly given Oracle's 8 percent annual support cost increase — lower licence counts produce lower support bases that grow more slowly in absolute terms year on year.