Oracle's Processor metric is the default licensing basis for Oracle Database Enterprise Edition on most enterprise servers — and it is the mechanism Oracle uses to extract maximum commercial value from modern multi-core hardware. A 2-socket server with 64 total cores requires 32 processor licenses at $47,500 each: $1.52M in Database EE license cost alone, before annual support. Understanding exactly how Oracle counts cores, how the Core Factor Table modifies that count, and what the virtualisation and cloud rules mean for your real liability is the foundation of any Oracle cost reduction program. This guide explains it without Oracle's obfuscation.
Oracle's Processor metric requires that every physical processor core on every server where Oracle software is "installed and/or running" must be counted as a fraction of a processor license, with the fraction determined by the Core Factor Table. This is Oracle's primary mechanism for licensing its Database, Middleware, and other server-based products in enterprise environments.
The metric applies to the hardware on which Oracle software is present — not just where it is actively running at a given moment. Oracle's definition of "installed" is broad: the presence of Oracle binaries on a server, including standby nodes, development servers with production software installed, and nodes in a cluster that Oracle could be migrated to, all count toward the Processor metric.
The key differences from other metrics are important to understand. Unlike Named User Plus, which scales with users, the Processor metric scales with hardware — and as enterprise servers have grown from 8-core to 128-core configurations over the past decade, the per-server Oracle license cost has grown proportionally. A server that required 4 processor licenses in 2012 may require 32 licenses today at current core counts.
The Processor metric is mandatory for Oracle Database EE in most contexts — though NUP is available as an alternative where user populations are small and well-defined. See our NUP vs Processor comparison for the full analysis.
The Core Factor Table is a document Oracle publishes and periodically updates that assigns a multiplier to each processor architecture. The factor represents the fraction of an Oracle Processor License required per physical core. Oracle introduced the Core Factor Table to accommodate the reality that different processor architectures deliver different compute capability per core — but the factors are also set in ways that reflect Oracle's commercial strategy, not just raw compute equivalency.
| Processor Architecture | Core Factor | Notes |
|---|---|---|
| Intel x86-64 (Xeon, all generations) | 0.5 | Most enterprise deployments |
| AMD x86-64 (EPYC, Opteron) | 0.5 | Same as Intel |
| IBM POWER (all generations) | 1.0 | Full license per core |
| IBM z (mainframe) | varies | Contact Oracle for current table |
| Oracle/Sun SPARC T-series | 0.25–0.5 | Lower factors — commercially attractive for Oracle workloads |
| ARM (including AWS Graviton) | 0.5 | Consult Oracle for cloud-specific ARM guidance |
The practical significance: for the vast majority of enterprise environments running on Intel or AMD x86-64 servers, the Core Factor is 0.5 — every two physical cores = one processor license. IBM POWER environments face double the license count for the same number of physical cores. The SPARC T-series factor of 0.25 is what made Oracle's own engineered systems commercially attractive for Oracle workloads — a deliberate pricing decision, not a performance calculation.
Hyperthreading Does Not Affect Licensing: Oracle counts physical cores, not logical CPUs or threads. A 32-core Intel Xeon processor with hyperthreading enabled presents 64 logical CPUs to the operating system — but Oracle requires licenses for 32 physical cores × 0.5 = 16 processor licenses. However, LMS audit scripts typically collect physical core counts directly from the hardware, so hyperthreading confusion rarely creates licensing disputes in practice.
Our forensic compliance review calculates your exact processor license requirement, identifies over-licensing opportunities, and benchmarks your position against what Oracle's LMS team would count. Most clients discover significant differences from their assumed position.
Understanding how the Core Factor arithmetic works in practice is essential for both compliance assessment and cost planning. The following examples reflect configurations commonly encountered in enterprise Oracle environments.
Oracle's position on virtualisation is the single most commercially aggressive policy in enterprise software licensing. Oracle does not recognize VMware ESXi, Microsoft Hyper-V, KVM, Citrix Hypervisor, or Oracle VM Server as mechanisms that "hard partition" physical processors for licensing purposes. Oracle classifies all of these as "soft partitioning" — and for Oracle Database running in a soft partitioned environment, the Processor metric applies to all physical cores in the entire cluster, not just the cores allocated to the Oracle VM.
The implications are severe. A VMware cluster of 8 hosts, each with 2×32-core Intel processors (64 cores per host, 512 total cores), requires 256 processor licenses (512 × 0.5) if any Oracle Database VM could run on any of those hosts. Even if the Oracle VM is configured with 4 vCPUs and only 2 hosts are actually capable of running it due to affinity rules, Oracle's position is that all 8 hosts are in scope unless hard partitioning is proven.
Oracle's recognized hard partitioning technologies are limited: Oracle VM Server with hard partitioned domains, LPAR/DLPAR on IBM POWER (where the partition is physically capped), Solaris Zones, and a small number of other platform-specific mechanisms. VMware's "pin to host" affinity rules do not qualify, and DRS rules are explicitly insufficient in Oracle's policy documentation.
VMware Compliance Gap Is Oracle's Biggest Audit Weapon: The majority of the largest Oracle audit claims — those in the $50M+ range — are VMware-related. Oracle's LMS team specifically targets large VMware estates running Oracle Database. If your Oracle Database runs on VMware, you almost certainly have a compliance gap between what you believe you are licensed for and what Oracle would claim in an audit. See our complete VMware licensing guide and our audit defense service for risk mitigation options.
For organizations that cannot migrate off VMware in the short term, the practical compliance options are: license the full cluster, isolate Oracle to a dedicated Oracle-only cluster sized to what you are willing to license, or engage an independent adviser to negotiate a settlement position with Oracle that reflects actual risk. Our Fortune 500 bank case study illustrates how structured VMware-to-dedicated infrastructure migration reduced a $40M+ audit claim to a negotiated $8M settlement.
Each major cloud provider has a specific Oracle licensing policy negotiated with or published alongside Oracle's BYOL guidance. The rules are not consistent across providers and are updated periodically — making cloud Oracle licensing one of the most dynamic compliance areas.
On AWS EC2 using standard shared-tenancy instances, Oracle requires licensing by vCPU (virtual CPU), with a minimum of 1 Oracle Processor License per 2 vCPUs. A 32-vCPU EC2 instance requires 16 processor licenses. On AWS Dedicated Hosts, Oracle allows licensing by the physical cores of the dedicated host (applying the relevant Core Factor), which typically results in fewer licenses required. See our Oracle on AWS guide for the full policy.
Azure Dedicated Hosts are recognized by Oracle for BYOL purposes — Oracle Database can be deployed on a Dedicated Host and licensed by the physical core count of that host. On standard Azure VMs, the vCPU rule applies (1 processor license per 2 vCPUs). Azure's Hybrid Benefit does not apply to Oracle licenses. Our Oracle on Azure guide covers the compliance rules in detail.
Oracle Cloud Infrastructure is Oracle's most favorable licensing environment. Oracle's BYOL rules on OCI allow on-premises EE licenses (with active support) to be applied to OCI Database services at 1 license per 2 OCPUs (OCI CPUs). For organizations with surplus on-premises Oracle licenses, OCI BYOL can dramatically reduce cloud Oracle costs. Our cloud advisory service models whether OCI BYOL is commercially viable for your workload mix.
Oracle's Processor metric applies to all servers where Oracle software is "installed and/or running." This definition is deliberately broad and catches several scenarios that organizations frequently assume are outside license scope.
Standby databases: An Oracle Data Guard physical standby database requires processor licenses for the standby host — unless the standby is operating in a passive state with standard Data Guard (not Active Data Guard). Even a cold standby that never receives queries must be licensed if Oracle software is installed and the instance is available for activation. Many organizations discover unlicensed standby databases in audit processes.
Development and test environments: Oracle does not provide a "development only" exception for processor licensing. A development server running Oracle Database EE requires the same license count as a production server with equivalent hardware. Oracle's licensing terms do not distinguish use case — only installation and runtime. The only exception is Oracle Technology Network (OTN) Developer licenses, which allow individual developers to use Oracle software for development and testing purposes with specific restrictions.
Dormant installations: Binaries installed on a server but with the database not running still count as "installed" under Oracle's policy if Oracle is configured to start automatically or if the installation is of a currently supported version. Removing Oracle software from servers that are no longer in use is essential housekeeping for compliance management.
Oracle Database EE can be licensed under either the Processor metric or the Named User Plus (NUP) metric, but the choice has long-term commercial implications that should be modelled carefully before any procurement decision.
The crossover point — where Processor licensing becomes cheaper than NUP — depends on user count versus hardware. For EE, the minimum NUP count is 25 per processor license. At 0.5 core factor on Intel hardware, a 2-socket 32-core server requires 16 processor licenses, which means a minimum NUP floor of 400 users (16 × 25). If the actual user count is below 400, NUP pricing is: actual count × $950. If actual count exceeds 400, NUP gets more expensive. At $47,500 per processor, the 16-processor cost is $760,000 — equivalent to 800 NUP licenses. Below 800 real users, NUP is always cheaper. Above 800 real users, Processor is likely cheaper.
The critical caveat is indirect access. Any user of a system that queries Oracle data — even through an application layer — may need to be counted as a NUP. In environments with web applications backed by Oracle, the NUP count can explode to tens of thousands of users. Our NUP vs Processor guide covers the full calculation methodology and indirect access rules.
Our comprehensive white paper covers Processor licensing, NUP, Core Factor calculations, and the 10 most common compliance gaps — with worked examples from real enterprise environments.
Reducing processor license exposure requires a combination of architectural decisions, compliance management, and commercial negotiation. The following strategies have delivered the largest verified reductions across our client engagements.
The most durable solution for VMware-related processor over-exposure is migrating Oracle workloads to a dedicated cluster — sized to exactly what you are willing to license, with hard partitioning or bare-metal deployment. This eliminates the "all hosts in cluster" exposure permanently and reduces ongoing support costs proportionally.
A full inventory of all Oracle Database installations — including dormant, standby, and development instances — typically reveals 15–30% more installed software than the license management team is aware of. Decommissioning unlicensed instances before an audit eliminates retrospective back-license claims for that period. See our audit preparation checklist for the inventory methodology.
Oracle Standard Edition 2 does not use the Processor metric in the same way as EE — it is limited to 2-socket servers and licensed at $17,500/processor. For qualifying workloads, migration from EE to SE2 reduces the license cost by 63% and the hardware footprint requirement simultaneously. Our license optimization service has mapped over 200 EE databases to SE2 candidates across client engagements.
For databases serving a small, well-defined internal user population — 50–300 users on a high-core-count server — switching to NUP licensing can reduce costs substantially. The switch requires evidence of user count and a compliance declaration process. Our compliance review service validates the user count methodology Oracle will accept.
Enterprise Agreement renewals are the primary opportunity to challenge Oracle's assumed processor count in your estate. Oracle's sales teams frequently model aggressive processor counts as their opening negotiating position. Presenting a counter-analysis built on actual deployment data — with independent validation — routinely results in 20–40% reductions in the license count Oracle is willing to use as the renewal baseline. Our contract negotiation service manages this process with benchmarked discount intelligence.
Weekly briefings on Oracle audit trends, pricing changes, and cost reduction tactics — from former Oracle insiders.
Our compliance review counts your Oracle processors the way Oracle's LMS team counts them — with the VMware, standby, and development exposures included. Most clients are surprised by what we find.
Free Research
Download our Oracle OCI Licensing Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the OCI Licensing Guide →Free Research
Download our Oracle BYOL on AWS and Azure Guide — expert analysis from former Oracle insiders, 100% buyer-side.
Download the BYOL on AWS & Azure Guide →