How a single multiplier buried in Oracle's documentation can swing your licensing bill by millions. What CIOs, CFOs, and procurement leaders must know to calculate, optimise, and defend their position.
Complete Oracle Core Factor guide. See also: Oracle Database Licensing Models · Oracle Technology Price List Calculator · Oracle Licensing in VMware · Oracle Licensing in Public Cloud · Oracle Cost Optimisation Playbook.
Oracle's Core Factor Table is an official reference document that assigns a specific multiplier (core factor) to every processor type on the market. That multiplier determines how many Oracle processor licences you need for a given number of physical CPU cores. It is, in practical terms, the single most important variable in your Oracle licensing cost equation.
The concept exists because not all CPU cores deliver the same throughput. Oracle designed the core factor to normalise licensing across different hardware architectures. A high-performance RISC core and a commodity x86 core are not treated identically. The result is a sliding scale of factors, typically ranging from 0.25 to 1.0, where a lower factor means fewer licences per core (and lower cost).
The core factor table is deceptively simple: a short list of processor types and multipliers. But it drives billions of dollars in global Oracle licensing spend. Choosing between a 0.5-factor Intel server and a 1.0-factor Power server can double your Oracle bill overnight. It is the first thing we examine in any enterprise licence assessment.
Physical Cores × Core Factor = Required Oracle Processor Licences
Always round up to the next whole number. Oracle does not sell fractional licences.
That single equation governs hundreds of millions of dollars in global Oracle licensing spend. Here is how it works step by step.
Count physical cores. Identify the total number of physical CPU cores on each server running Oracle software. This means actual cores, not threads. Hyper-threading (Intel) or SMT (AMD/IBM) creates logical threads, but Oracle counts physical cores only. A 2-socket server with 16-core CPUs has 32 physical cores.
Identify the core factor. Look up your processor model in Oracle's official Core Factor Table. Intel Xeon and AMD EPYC are 0.5. IBM POWER9/10 is 1.0. Oracle SPARC M8 is 0.5. Oracle Ampere (ARM) is 0.25.
Multiply and round up. Multiply total physical cores by the core factor. If the result is a fraction, always round up to the next whole number. Oracle licences are sold in whole units only.
Apply per product. The licence calculation applies independently to each Oracle product installed on that server. If you run Oracle Database Enterprise Edition plus three options (Partitioning, Diagnostics Pack, Tuning Pack), each requires the same number of processor licences. This multiplicative effect is where costs escalate rapidly.
Options multiply your cost. Every Oracle option and management pack must be licensed on the same number of processors as the base product. If your database requires 12 processor licences, each add-on (Partitioning at $11,500/licence, Diagnostics Pack at $7,500/licence, etc.) also requires 12 licences. A single server can easily carry $1M+ in option licensing alone.
| Processor Family | Core Factor | Common Server Platforms | Notes |
|---|---|---|---|
| Intel Xeon (all generations) | 0.5 | Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem | Most common enterprise platform globally |
| AMD EPYC (all generations) | 0.5 | Dell PowerEdge, HPE ProLiant, Supermicro | Increasingly popular for high-core-count servers |
| Oracle SPARC M8 / M7 | 0.5 | Oracle SPARC M8, T8 servers | Oracle's own hardware, same factor as x86 |
| Oracle SPARC T-series (older) | 0.25-0.5 | SPARC T5, T7 (varies by model) | Check exact model against Oracle table |
| Ampere Altra (ARM) | 0.25 | Oracle Cloud Infrastructure (OCI) bare metal | Lowest factor available. Oracle incentivises OCI ARM. |
| IBM POWER10 | 1.0 | IBM Power S1022, S1024, E1080 | Full factor. Doubles licence cost vs x86. |
| IBM POWER9 | 1.0 | IBM Power S922, E980 | Same 1.0 factor as POWER10 |
| IBM POWER8 | 1.0 | IBM Power S824, E880 | Legacy systems, still common in large enterprises |
| Fujitsu SPARC64 | 0.5 | Fujitsu M12, SPARC M10 | Primarily Japanese enterprises |
| Unlisted / New processors | 1.0 | Any platform not in Oracle's table | Default is 1.0 until Oracle publishes a factor |
Hardware decision = licensing decision. Enterprises choosing IBM POWER servers for Oracle workloads because of raw performance often discover they need twice as many licences as the equivalent x86 deployment. One Fortune 500 manufacturer spent $4.2M more in Oracle licensing over five years purely because of the 1.0 vs 0.5 core factor difference. Always run the licence cost calculation before the hardware procurement decision, not after.
The core factor's financial impact is direct and dramatic. Since Oracle Database Enterprise Edition lists at $47,500 per processor licence, every fractional difference in the core factor translates to tens or hundreds of thousands of dollars. And that is before options and annual support.
Consider a standard database server with 2 sockets, 16 cores each (32 physical cores), running Oracle Database EE with Partitioning and Diagnostics Pack:
| Component | Intel Xeon (0.5) | IBM POWER10 (1.0) | Ampere ARM (0.25) |
|---|---|---|---|
| Physical cores | 32 | 32 | 32 |
| Core factor | 0.5 | 1.0 | 0.25 |
| Required licences | 16 | 32 | 8 |
| DB EE ($47,500 ea.) | $760,000 | $1,520,000 | $380,000 |
| Partitioning ($11,500 ea.) | $184,000 | $368,000 | $92,000 |
| Diagnostics Pack ($7,500 ea.) | $120,000 | $240,000 | $60,000 |
| Total licence cost (list) | $1,064,000 | $2,128,000 | $532,000 |
The same 32-core server costs $532K on ARM, $1.06M on Intel, and $2.13M on IBM POWER. A 4x range driven entirely by the core factor. Enterprises with dozens of Oracle database servers face cumulative differences measured in tens of millions.
Case study: IBM-to-Intel migration halves Oracle licensing exposure. A Fortune 500 manufacturer ran Oracle Database EE and WebLogic Server on eight IBM POWER9 servers (384 total cores, factor 1.0 = 384 licences per product). Redress Compliance identified that migrating to commodity Intel Xeon servers with identical core counts would reduce the licence requirement to 192 per product, eliminating $8.6M in cumulative licensing exposure. The migration completed within 14 months. Hardware investment paid for itself within the first year.
Example: Two-socket Intel Xeon server.
Hardware: Dell PowerEdge R760. 2x Intel Xeon 8490H (60 cores each). 120 physical cores total.
Software: Oracle Database EE + Advanced Security + Diagnostics Pack.
Core factor: 0.5 (Intel Xeon).
Calculation: 120 cores x 0.5 = 60 processor licences.
DB EE: 60 x $47,500 = $2,850,000.
Advanced Security: 60 x $15,000 = $900,000.
Diagnostics Pack: 60 x $7,500 = $450,000.
Total list price: $4,200,000 + $924,000/year support.
Example: IBM Power S1024 server.
Hardware: IBM Power S1024. 2x POWER10 (12 cores each). 24 physical cores total.
Software: Oracle Database Enterprise Edition.
Core factor: 1.0 (IBM POWER10).
Calculation: 24 cores x 1.0 = 24 processor licences.
DB EE: 24 x $47,500 = $1,140,000.
Comparison: An equivalent Intel Xeon server with 24 cores would require only 12 licences ($570,000). Exactly half the cost. IBM POWER premium: $570,000 (100% more than Intel).
Example: Odd-core-count virtualised host.
Hardware: HPE ProLiant DL380. 2x Intel Xeon 6330 (28 cores each, 3 cores disabled). 25 active physical cores.
Core factor: 0.5.
Calculation: 25 cores x 0.5 = 12.5. Round up to 13 processor licences.
Oracle does not sell half-licences. Always round up. This matters especially when enterprises deliberately disable cores to optimise licence counts.
Virtualisation is where the core factor calculation becomes dangerous. The formula itself does not change, but the definition of which cores to count expands dramatically depending on your virtualisation technology.
The number one Oracle audit exposure. Virtualisation miscalculation is the single largest source of Oracle audit findings. Enterprises routinely assume they only need to license the virtual CPUs allocated to an Oracle VM. Oracle's policy says otherwise. The financial consequences can reach eight figures.
Oracle classifies most mainstream virtualisation technologies as soft partitioning, meaning they do not limit your licensing requirement. Under Oracle's policy, you must license all physical cores on every host in the cluster where the Oracle VM can potentially run.
Technologies Oracle considers soft partitioning include: VMware vSphere/ESXi, Microsoft Hyper-V, KVM (when using live migration), Citrix XenServer, and most other commercial hypervisors.
Case study: VMware miscalculation creates $14M audit exposure. A major retailer ran Oracle Database EE on a VMware cluster of 12 hosts, each with 2x Intel Xeon 8280 processors (28 cores each = 56 cores per host, 672 total cores). The VM was allocated 8 vCPUs. The IT team believed they owed 8 x 0.5 = 4 licences. Oracle's audit team calculated: 672 cores x 0.5 = 336 licences. At $47,500 each, the compliance gap was $15.7M before negotiation. Redress Compliance helped reduce the settlement to $2.1M by demonstrating the VM was pinned to specific hosts and negotiating a forward-looking agreement.
Oracle recognises certain partitioning methods that legally limit your licensing requirement to a subset of cores.
| Technology | Oracle Classification | Licensing Scope |
|---|---|---|
| Oracle VM Server (OVM) | Hard partitioning | Licensed vCPUs only |
| Oracle Linux KVM | Hard partitioning | Licensed vCPUs only |
| IBM LPAR (on POWER) | Hard partitioning | Licensed partition cores only |
| Solaris Zones (capped) | Hard partitioning | Licensed zone cores only |
| Physical core disabling (BIOS) | Hard partitioning | Active cores only |
| VMware vSphere / ESXi | Soft partitioning | All physical cores on all accessible hosts |
| Microsoft Hyper-V | Soft partitioning | All physical cores on all accessible hosts |
| KVM (with live migration) | Soft partitioning | All physical cores in migration boundary |
Using hard partitioning effectively can reduce your Oracle licensing footprint by 80 to 90% compared to soft partitioning. However, the configuration must be documented rigorously. Oracle auditors will verify that VMs are truly pinned and cannot migrate to unlicensed hosts.
In cloud environments, Oracle replaces the traditional Core Factor Table with platform-specific vCPU conversion rules. Understanding these rules is essential for enterprises pursuing cloud migration or hybrid architectures.
| Cloud Provider | BYOL Licensing Rule | Core Factor Applies? | Key Consideration |
|---|---|---|---|
| AWS | 2 vCPUs = 1 licence | No | Most instance types are hyper-threaded |
| Azure | 2 vCPUs = 1 licence | No | Same rule as AWS for authorised instances |
| Google Cloud | 2 vCPUs = 1 licence | No | Added as authorised provider in 2023 |
| OCI (x86) | 1 OCPU = 1 licence | No (OCPU-based) | Most cost-effective BYOL option |
| OCI (ARM/Ampere) | 1 OCPU = ~0.25 licence equivalent | Embedded in pricing | Lowest effective licence cost |
| On-premises | Cores x Core Factor | Yes | Standard calculation applies |
Cloud migration warning. Enterprises frequently assume moving to the cloud simplifies Oracle licensing. It can. But only if you model the licence requirements accurately before migration. We have seen organisations migrate Oracle workloads to large AWS instances and discover they needed more processor licences than on-premises because the vCPU-to-licence mapping was less favourable than their existing core factor arithmetic. Always run the numbers on both sides before committing.
Assuming VM vCPUs limit licence scope. This is the most expensive mistake in Oracle licensing. Allocating 4 vCPUs to an Oracle VM on a VMware host does not mean you need only 4 x 0.5 = 2 licences. Under Oracle's soft partitioning policy, you must licence every physical core on every host in the vMotion-enabled cluster. A 4-vCPU VM on a 10-host cluster can generate a licensing requirement 50 times larger than expected.
Confusing threads with cores. Oracle counts physical cores, not logical threads. Intel Hyper-Threading and AMD SMT double the apparent CPU count in operating system tools, but Oracle ignores these logical threads for licensing purposes. A server reporting 64 logical CPUs in the OS may have only 32 physical cores. Always verify through hardware documentation or BIOS settings.
Using outdated core factor data. Oracle periodically updates the Core Factor Table as new processor families are released. Using stale data can cause under-licensing (if a new processor has a higher factor than assumed) or over-licensing (if Oracle has assigned a favourable factor you have not captured). Always reference the latest official table.
Forgetting licence minimums. If you licence Oracle Database EE by Named User Plus, there is a minimum of 25 NUP licences per processor (as calculated using the core factor). This minimum can force higher licence counts than your actual user population warrants.
Standard Edition vs Enterprise Edition confusion. Oracle SE2 uses per-socket licensing and does not use the Core Factor Table. Each occupied socket counts as one licence, regardless of core count. Enterprises migrating from SE to EE often underestimate the cost increase because the licensing metric shifts from sockets to cores x factor.
Ignoring disabled or decommissioned servers. Oracle auditors look for evidence of Oracle software on any server, including development, test, staging, and disaster recovery environments. An old server with Oracle installed but not in production still requires licensing. Ensure decommissioned servers have Oracle software fully removed.
DR and non-production licensing. Disaster recovery servers running Oracle must be licensed. The core factor calculation applies identically to DR hosts. There is no standby discount for Oracle Database Enterprise Edition. Some limited exceptions exist for failover configurations where the standby database is genuinely passive, but these are narrow and heavily scrutinised in audits.
The Core Factor Table is an official Oracle document that assigns a multiplier (0.25 to 1.0) to each processor type. It determines how many Oracle processor licences are required per physical CPU core. Intel Xeon processors have a 0.5 factor (each core counts as half a licence), while IBM POWER processors have a 1.0 factor (each core requires a full licence).
Use the formula: Physical Cores x Core Factor = Required Oracle Processor Licences (rounded up). For example, a server with 24 Intel Xeon cores (factor 0.5) requires 24 x 0.5 = 12 processor licences. If the result is a fraction (e.g., 25 x 0.5 = 12.5), round up to 13. Apply this calculation to each Oracle product installed on the server.
No. The core factor applies only to Oracle products licensed on a processor metric: primarily Oracle Database Enterprise Edition, WebLogic Server, and middleware suites. It does not apply to Standard Edition 2 (per-socket licensing), products licensed by Named User Plus, or Oracle applications licensed by user-based metrics. Cloud environments use vCPU-based calculations instead.
No. This is the most costly misconception in Oracle licensing. Oracle classifies VMware as soft partitioning, meaning you must license all physical cores on every host in the VMware cluster where the Oracle VM can potentially run via vMotion. Only Oracle-approved hard partitioning (Oracle VM, IBM LPAR, Solaris Zones, BIOS core disabling) limits licensing to the allocated subset.
Absolutely. Moving from IBM POWER (factor 1.0) to Intel Xeon or AMD EPYC (factor 0.5) halves your Oracle licence requirement for the same core count. Moving to Oracle's ARM-based Ampere processors (factor 0.25) reduces it to one quarter. Some enterprises also deliberately disable physical CPU cores in BIOS, which Oracle recognises as a valid licensing boundary.
In AWS, Azure, and Google Cloud (authorised cloud environments), Oracle does not use the traditional Core Factor Table. The rule is: 2 vCPUs = 1 Oracle Processor Licence for hyper-threaded instances. For non-hyper-threaded instances, 1 vCPU = 1 licence. On OCI, 1 OCPU = 1 licence under BYOL. Always use cloud-specific licensing rules rather than the on-premises core factor.
Oracle will typically demand you purchase the missing licences at list price plus backdated support (22% per year for the period of non-compliance). This can result in multi-million-dollar unbudgeted expenditures. Oracle may also use the audit finding as leverage to push a large forward-looking deal. Proactive compliance checks and independent audit defence are the best protection.
No. Oracle Database Standard Edition 2 is licensed per occupied CPU socket, not per core. Each socket counts as one licence regardless of the number of cores. SE2 is limited to servers with a maximum of 2 sockets. A 2-socket server requires only 2 licences (at $17,500 each) regardless of whether the sockets contain 8-core or 64-core processors.
Oracle updates the table periodically as new processor families are introduced. Updates are infrequent for existing processors. Once a factor is assigned, it rarely changes. Until a new processor appears in the table, Oracle's default policy assigns it a factor of 1.0. Always check the latest version before any licensing calculation.
An Oracle ULA can make sense if your Oracle deployment is large and growing rapidly. A ULA provides unlimited deployment rights for specified products during a fixed term (typically 3 years), with certification at the end counting deployed licences as perpetual entitlements. However, ULAs carry significant risks around certification complexity, renewal lock-in, and support cost escalation. Evaluate a ULA only with independent advisory support.