Oracle Processor Factor Table:
How Multipliers Work, Which Processors Are Affected, and the 4× Cost Difference Between Architectures

Oracle Licenses Processors by Physical Core — But Not All Cores Are Equal

Oracle Database licensing for processor-based licenses (Enterprise Edition and Standard Edition 2 in server contexts) is calculated by counting physical processor cores and applying a core factor from Oracle's published processor factor table. The core factor is a multiplier — between 0.25 and 1.0 — that adjusts the number of Oracle processor licenses required based on the processor architecture. The formula is straightforward: processor licenses required = number of physical cores × core factor. What is not straightforward is that the same workload running on the same number of cores can require between 25% and 100% as many Oracle licenses depending solely on the processor architecture chosen. The difference between a 0.25 core factor processor and a 1.0 core factor processor, for a 32-core server running Oracle EE, is $380,000 vs $1,520,000 in license cost — the same hardware specification, the same Oracle installation, the same workload. This guide explains the processor factor table in operational detail, which architectures are affected, and how processor selection can be used to systematically reduce Oracle licensing costs. For Oracle virtualisation licensing (which interacts with processor factors), see our Oracle Virtualisation Licensing Guide. For container environments, see our Oracle Container Licensing Guide. For processor factor review support, our Oracle advisory team provides independent Oracle licensing assessments.

The Processor Factor Table: Complete Architecture Reference

Intel vs IBM POWER: The Most Common Processor Factor Mistake

The most expensive processor factor error in enterprise Oracle deployments involves IBM POWER servers. IBM POWER processors carry a 1.0 core factor — every physical core requires a full Oracle processor license. Intel Xeon and AMD EPYC processors carry a 0.5 factor — every two physical cores require one Oracle processor license. For an organisation running Oracle Database on IBM POWER systems, migrating equivalent Oracle workloads to Intel or AMD x86-64 hardware halves the Oracle license count required for the same core capacity. The hardware migration cost must be weighed against the Oracle license savings, but for large IBM POWER Oracle deployments, the Oracle license reduction alone typically exceeds the hardware migration cost within 2–3 years.

A specific example: an IBM POWER server with 4 sockets × 12 cores = 48 cores running Oracle EE requires 48 × 1.0 = 48 Oracle EE licenses at $47,500 each = $2.28M. An Intel Xeon server with equivalent performance capacity (likely 2 sockets × 16 cores = 32 cores given Intel's higher single-threaded performance) requires 32 × 0.5 = 16 Oracle EE licenses at $47,500 each = $760,000. The Oracle license cost difference alone is $1.52M — before annual support savings (22% of the license differential = $334k/year).

SPARC T-Series: The 0.25 Factor and Its Modern Relevance

Oracle SPARC T-series processors (T7 and T8) carry a 0.25 core factor — the lowest in Oracle's processor factor table. A SPARC T8 server with 32 cores requires only 8 Oracle EE processor licenses (32 × 0.25), compared to 16 licenses on an equivalent Intel 32-core server. The SPARC T-series factor advantage is real and significant in absolute license cost terms. However, SPARC T-series hardware has limited market availability following Oracle's reduction of its SPARC hardware investment, and Oracle's SPARC roadmap has been substantially scaled back. The T-series factor advantage must be weighed against hardware procurement risk, Oracle hardware support timelines, and the operational complexity of maintaining a SPARC-based Oracle estate alongside an otherwise x86-based infrastructure. For organisations with existing SPARC T-series deployments, the licensing economics favour retention — for new deployments, SPARC procurement risk is a meaningful consideration.

Core Factor Calculations in Virtualised and Cloud Environments

Processor factors apply to physical core counts — but in virtualised environments (VMware, Hyper-V, KVM), Oracle's soft partitioning policy requires licensing all physical cores of all hosts in the cluster, not just the virtual cores allocated to Oracle VMs. The processor factor is applied to the physical core count of the licensed hosts, not the virtual core count allocated to the Oracle VM. This means a decision to deploy Oracle on a cluster of Intel Xeon hosts (0.5 factor) versus IBM POWER hosts (1.0 factor) has a 2× license count implication that is multiplied by the number of hosts in the cluster. In large VMware DRS clusters, the processor architecture decision can represent millions of dollars in Oracle license exposure. In OCI, processor factor licensing does not apply — OCI uses OCPU-based consumption pricing regardless of the underlying physical processor architecture. Moving Oracle workloads to OCI eliminates the processor factor calculation entirely.

Common Processor Factor Mistakes in Oracle Audits

Oracle audits frequently surface processor factor errors in both directions — organisations under-licensed because they applied the wrong factor, and (less commonly) over-licensed because they incorrectly assumed a higher factor was required. The most common errors:

Applying a 1.0 factor to Intel multi-core processors. Single-core Intel processors — which no longer exist in enterprise servers — carried a 1.0 factor. All current Intel Xeon multi-core processors carry a 0.5 factor. Organisations using legacy Oracle license documentation or relying on outdated ITAM tools may be applying 1.0 to modern Intel Xeon processors.

Not updating processor factors when hardware is refreshed. A server refresh from an older Intel Xeon to a newer AMD EPYC generation does not change the factor (both are 0.5) — but a migration from IBM POWER to Intel halves the required license count, and this reduction must be formally documented and processed with Oracle to release the excess licenses.

Using virtual core counts instead of physical core counts. In VMware deployments, vCPU allocation to the Oracle VM is not the license count basis. Physical core counts of all hosts in the cluster, applying the physical processor's core factor, determine the license requirement. Using vCPU counts systematically under-licenses Oracle in soft-partitioned environments. For processor factor review, Oracle estate baseline assessment, and audit preparation, our Oracle advisory team provides independent Oracle licensing analysis. Contact us to discuss your processor factor position.