The Oracle Core Factor Table turns physical cores into licensable processors. Get the multiplier wrong and the processor count, and the bill, can double. This is the buyer side read of how it works.
The Oracle Core Factor Table converts physical cores into licensable Oracle processors using a per chip multiplier. This guide covers how the factor works, the common values, the audit positions to expect, and the buyer side moves.
The Oracle Core Factor is a multiplier that converts physical processor cores into Oracle licensable processors. It is the bridge between hardware and the Processor license metric.
The formula is simple. Count the physical cores running Oracle, multiply by the core factor for that chip, and round up to the next whole number. Oracle publishes the values in the Processor Core Factor Table.
The factor depends on the chip family. Most modern x86 server chips sit at 0.5, but older and specialty processors differ.
The table below shows representative values. Always confirm against the current published table, because Oracle updates it as new chips ship.
Representative Oracle core factor values
| Processor family | Core factor | Cores to licenses on 32 cores |
|---|---|---|
| Intel and AMD x86 | 0.5 | 16 processor licenses |
| Older single core x86 | 1.0 | 32 processor licenses |
| SPARC newer families | 0.25 to 0.5 | 8 to 16 processor licenses |
| IBM Power | 1.0 | 32 processor licenses |
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
The core factor itself is rarely the fight. The fight is the core base the auditor multiplies. Virtualization is where the count explodes.
On soft partitioned hypervisors, Oracle takes the position that every core in the cluster can run Oracle, so every core must be licensed. Oracle sets this stance in its partitioning policy, and it is contractual interpretation, not product limitation.
The common advice is to focus on getting the core factor multiplier right, as if the factor is the battleground. We disagree. In the disputes we have defended, the multiplier was agreed quickly and the real money sat in the core base the auditor applied it to. The buyer side move is to control the denominator. Pin Oracle to the cores actually running the software, isolate Oracle workloads onto defined hosts, and use approved hard partitioning so the cluster wide counting argument never gets traction. Arguing the factor while conceding the core base loses the negotiation before it starts.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The auditor wins on the core base, not the multiplier. Control which cores run Oracle and the core factor argument resolves itself.
Three moves reduce the licensable processor count without changing the workload.
Pin Oracle to defined hosts and use approved hard partitioning. This removes the cluster wide counting argument and caps the cores in scope.
It is a multiplier that converts physical processor cores into Oracle licensable processors. You multiply the physical cores running Oracle by the core factor for that chip and round up to get the processor license count.
Count the physical cores where Oracle runs, multiply by the core factor for the chip family, and round up to the next whole number. For 32 x86 cores at a 0.5 factor, that is 16 processor licenses.
Most modern Intel and AMD x86 server processors carry a core factor of 0.5. Always confirm against the current published Processor Core Factor Table, because Oracle updates it as new chips ship.
No. The core factor applies to the Processor metric. Named User Plus licensing counts users and devices, although it carries its own per processor minimum user requirements.
No. Oracle Cloud and authorized cloud environments use their own conversion rules based on OCPU or vCPU, not the on premises core factor table. The two models are separate.
On soft partitioned clusters, Oracle counts every core the database could move to, not just the cores it runs on today. That cluster wide position can inflate the licensable core base several times over.
Isolate Oracle onto defined hosts and use hard partitioning methods Oracle accepts in writing. This caps the cores in scope and removes the cluster wide counting argument.
Control the core base, not just the multiplier. A current core and chip inventory that proves which hosts run Oracle resolves most disputes far faster than arguing the factor alone.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
Engage independent buyer side Oracle licensing experts. We do not resell. We do not implement. We sit on your side of the table.
See engagement scope, comparison vs Big4 and resellers, and the buyer side framework.
Visit page →The core factor is a multiplier, not a discount. Know your chip, know your factor, and never let an auditor apply the wrong one to a virtualized estate.
