Oracle Core Factor Table: How Oracle Counts Your Processor Licences

What is the Oracle Core Factor Table?

Oracle's Processor metric does not simply count physical CPU cores. Instead, Oracle applies a multiplier — the Core Factor — to each physical core based on the chip architecture. The result is the number of processor licences you must hold to run Oracle software on that server.

The Core Factor Table is a document Oracle publishes and updates periodically. It lists every major CPU architecture — Intel Xeon, AMD EPYC, IBM POWER, SPARC, ARM, and others — alongside the corresponding factor. Oracle considers this table definitive. When Oracle's LMS team conducts an audit, they apply the Core Factor Table current at the time of the audit to calculate your licence requirement. If your internal count used an outdated table or the wrong processor family, you will have a compliance gap before the conversation even begins.

The formula is straightforward: Processor Licences Required = Number of Physical Cores × Core Factor. Round up to the nearest whole number — Oracle does not permit fractional processor licences.

How the Core Factor Calculation Works

To calculate your Oracle Database Processor licence requirement for a given server, you need three pieces of information: the number of physical sockets, the number of cores per socket, and the Core Factor for the processor type. Multiply total physical cores by the Core Factor, then round up.

The 0.5 factor for Intel and AMD processors means a 64-core server requires 32 processor licences. Oracle Database Enterprise Edition lists at $47,500 per processor licence (plus 22% annual support). That 64-core server costs $1,520,000 in licence fees alone at list price, and $334,400 per year in support. Now multiply that across a ten-server cluster and you understand why the Core Factor Table is at the centre of nearly every Oracle financial dispute.

Core Factors by Processor Type

The Oracle Core Factor Table covers every mainstream enterprise CPU architecture. The factors below reflect Oracle's published table as of 2026. Always verify against the current Oracle document — Oracle has updated the table multiple times, and using an outdated version in your compliance calculations can create a false sense of security.

The most consequential factors for most enterprises are Intel/AMD at 0.5 and IBM POWER at 1.0. The IBM POWER factor is double the Intel factor — meaning an IBM POWER server with 64 cores requires twice as many Oracle licences as an equivalent Intel server, all else being equal. This has significant implications for enterprises migrating workloads between hardware platforms or running Oracle on IBM AIX environments.

Intel & AMD: The 0.5 Factor and Its Traps

The 0.5 Core Factor for Intel and AMD processors has been the standard for over a decade. It effectively means you need one processor licence for every two physical cores. On the surface, this appears to reduce licence costs. In practice, the combination of ever-increasing core counts per socket and Oracle's partitioning rules creates compound compliance traps that Oracle's LMS team routinely exploits.

Hyper-Threading does not reduce your licence count. Oracle's Processor metric counts physical cores, not logical processors. A 32-core Intel Xeon with Hyper-Threading presents 64 logical CPUs to the operating system, but Oracle licences the 32 physical cores at 0.5, giving you 16 processor licences. This is correctly applied. The trap occurs when configuration tools or monitoring scripts report logical CPU counts — your ITAM team may have inadvertently used the wrong figure in their licence calculations.

AMD EPYC chiplet architecture. EPYC CPUs physically integrate multiple chiplets. For Oracle licensing purposes, AMD EPYC is treated identically to Intel x86-64 at a 0.5 factor. The chiplet architecture has no effect on Oracle's count. However, because EPYC chips offer very high core counts (up to 96 cores per socket in current-generation parts), a dual-socket EPYC server can require 96 Oracle processor licences — a significant exposure if you have multiple such servers running Oracle Database without careful hard partitioning.

IBM POWER: Why the 1.0 Factor Changes the Economics

IBM POWER servers are widely used in financial services, insurance, and government environments that run Oracle Database alongside IBM DB2 or other POWER-native workloads. The Oracle Core Factor for IBM POWER is 1.0, meaning every physical core requires one full Oracle processor licence. This doubles Oracle's cost relative to Intel and AMD hardware at equivalent core counts.

For an IBM POWER10 server with 4 sockets and 24 cores per socket (96 total physical cores), the processor licence requirement is 96 licences. At Oracle Database Enterprise Edition list price of $47,500 per licence, that represents $4,560,000 in licence fees plus $1,003,200 per year in 22% annual support. The same workload on a dual-socket Intel Xeon with 48 cores per socket (96 total physical cores) would cost $47,500 × 48 = $2,280,000 in licences — exactly half.

IBM POWER Logical Partitioning (LPAR) using Power VM is one of the few non-Oracle technologies Oracle recognises as hard partitioning. When properly configured and when the LPAR has been granted hard partitioning status by Oracle, you can restrict Oracle licences to the cores allocated to the partition. The configuration requirements are strict: dedicated processor mode, capped LPARs, and no live partition mobility that would allow Oracle workloads to move to unlicensed cores without advance notification. Oracle's LMS team scrutinises IBM LPAR configurations closely during audits.

Core Factor in Oracle LMS Audits

When Oracle's LMS team initiates an audit, Core Factor calculation accuracy is one of the first things their scripts probe. The USMM (Usage Metrics Management) tool and Oracle's broader LMS script suite collect server hardware inventory, including CPU topology — physical sockets, cores per socket, processor model identifiers. LMS analysts then cross-reference this inventory against the Core Factor Table.

Common Core Factor errors that Oracle exploits in audits include using an outdated Core Factor Table version, failing to account for new servers added after your last internal compliance review, misidentifying processor generation (particularly relevant for IBM POWER where older processor families sometimes carry different factors), and applying soft partitioning factors to environments where Oracle requires hard partitioning.

Oracle's audit findings will present a licence shortfall based on their calculation of your requirement versus your entitlement. The figure will almost always be higher than what your internal team calculated. Challenging these figures requires documentation: hardware configuration reports, server purchase records, and evidence of any Oracle-approved hard partitioning configurations. Without this documentation, Oracle's claim becomes very difficult to push back against.

Our Oracle Audit Defence practice has challenged Oracle Core Factor calculations in dozens of engagements. The average initial Oracle claim has been three to five times what the client actually owed after forensic review of the hardware evidence. The discrepancy almost always traces back to Oracle counting all cores in a cluster rather than applying approved partitioning, or applying the wrong processor family to servers that had been upgraded.

How to Challenge Oracle's Core Factor Count

Challenging Oracle's Core Factor calculation is entirely legitimate and frequently successful — but it requires evidence, not argument. Oracle's LMS team responds to documentation, not assertions. Here is how we approach a Core Factor challenge on behalf of clients.

Step 1: Obtain the raw hardware inventory. Pull server configuration reports from your hardware vendor, your data centre management platform, and any available CMDB records. You need processor model identifiers, socket counts, and cores per socket for every server in scope. Do not rely solely on what the LMS scripts report — verify against vendor-supplied documentation.

Step 2: Identify the correct Core Factor for each processor model. Cross-reference against the Oracle Core Factor Table version that was current at the time of the relevant licence period. If Oracle is using a different table version, establish why and challenge the application of a newer version retroactively.

Step 3: Document all approved hard partitioning configurations. For any Oracle VM, IBM LPAR, or Solaris Zone environment, gather the configuration files, Oracle support documentation confirming hard partition status, and any correspondence with Oracle confirming the partitioning approach.

Step 4: Calculate independently. Prepare your own complete licence count, documented with evidence. Submit this as a formal counter-position to Oracle's LMS findings. Oracle is required to engage with documented counter-positions. Without expert support, most clients accept Oracle's figures. With forensic review, the figure almost always changes materially.

Our Oracle Compliance Review gives you an independent, evidence-based licence count you can defend in any audit conversation. We also manage the Oracle LMS correspondence directly, keeping your team at arm's length from the process.

Virtualisation and the Core Factor: What Changes, What Doesn't

The Core Factor always applies to physical cores. What virtualisation changes is which physical cores you are required to licence — and this is where Oracle's rules are most aggressively enforced.

Under Oracle's partitioning policy, only a handful of technologies qualify as hard partitioning: Oracle VM Server for x86 (when configured correctly), IBM LPAR (dedicated processor, capped), Solaris Containers/Zones with CPU binding, and Fujitsu SPARC Enterprise M-Series with PPAR. Every other technology — VMware, Microsoft Hyper-V, Citrix Hypervisor, KVM, Docker, Kubernetes — is soft partitioning. Oracle does not recognise soft partitioning as limiting your licence requirement.

This means that in a VMware vSphere cluster with 10 hosts, each with two 32-core Intel Xeon processors (640 physical cores total), Oracle requires you to licence all 640 cores at 0.5 — giving you 320 processor licences — regardless of how many VMs are running Oracle and regardless of how many vCPUs those VMs have assigned. The Core Factor applies to all physical cores in the cluster where Oracle can potentially run.

Enterprises that have been told by their virtualisation team that limiting vCPUs reduces their Oracle licence count are exposed. The Oracle licence obligation exists at the physical layer. The vCPU count is irrelevant to Oracle's Processor metric.

For a comprehensive treatment of this topic, read our Oracle Database Licensing on VMware guide and the Oracle Database Licensing Guide.