The Oracle core factor, a settled multiplier on a negotiable denominator
The Core Factor Table converts physical cores into licensable Oracle processors: cores times factor, rounded up, equals licenses. Get the multiplier wrong and the bill doubles; get the core base wrong and it can multiply by five. Across our disputes, nobody argued the multiplier for long, and everybody argued the server list.
Prepared by Redress Compliance · August 7, 2026 · Oracle advisory. Based on 20 to 28 core factor disputes worked 2024 to 2025.
Executive summary
The multiplier is settled; the denominator is negotiable. In our 20 to 28 disputes the factor itself was agreed inside a week almost every time, nobody on either side argued a current x86 chip was anything but 0.5, and what ran for months was the list of servers it applied to.
Where the auditor counted a whole VMware cluster, the licensable core base came back 2 to 5 times the cores actually running Oracle, swinging the bill 30 to 70 percent before any discount discussion.
The arithmetic is contractual, and three words carry the money. The Processor definition requires cores aggregated across the estate per program, before multiplying, with fractions rounded up once, not once per server.
Modern AMD EPYC and Intel Xeon 6 chips are not named on the table by model; they land on the general Intel and AMD multicore x86 entries at 0.5, and IBM POWER at 1.0 doubles the same core count, the one place the multiplier genuinely decides the bill.
The worked example is sobering. A two socket 256 core x86 server at the 0.5 factor is 128 processor licenses: $6.08 million at the $47,500 Enterprise Edition list rate, plus $1.34 million a year of support, before options.
Every option and pack on that program carries the same count, which is how the multiplication compounds through the estate.
Your own count is probably wrong in Oracle's favor. The most common self inflicted error we find is a SAM tool reporting NUM_CPUS, the thread count, roughly double NUM_CPU_CORES, as the core base.
One query per database, dated and filed, fixes it, and estates that could produce a dated core and chip inventory in week one closed disputes 2 to 4 times faster than those that could not.
The rows that matter, and the two worth the most attention
| What you run | How the table reaches it | Factor | Two socket example |
|---|---|---|---|
| AMD EPYC 9004 and 9005, Intel Xeon 6 | Not named by model: the general Intel and AMD multicore x86 entries | 0.5 | 2 x 128 cores = 256 cores = 128 licenses |
| Intel Xeon Scalable, E5, E7 | The Intel Xeon Series entries | 0.5 | 2 x 32 cores = 64 cores = 32 licenses |
| IBM POWER8 and POWER9 | Named by generation | 1.0 | 2 x 12 cores = 24 cores = 24 licenses |
| SPARC T and M series, SPARC64 X and XII | Named by generation | 0.5 | 2 x 32 cores = 64 cores = 32 licenses |
| Fujitsu SPARC64 VI and VII | Named by generation | 0.75 | 2 x 4 cores = 8 cores = 6 licenses |
| Any single core chip | All single core chips | 1.0 | 8 chips = 8 licenses |
Save a dated copy of the table. Oracle republishes the Core Factor Table without notice, and the version in force on the day each ordering document signed is the one that governs.
The IBM Power row is where the check pays: on 24 POWER cores the gap between 1.0 and 0.5 is 12 processor licenses, $570,000 at Enterprise Edition list, so confirm the row by name in the version in effect and get it in writing.
Three years later, the party holding the dated PDF sets the terms of the discussion.
The formula, and the query that anchors it
The order of operations is contract text: count physical cores where Oracle is installed or running, never threads and never vCPU; aggregate across the estate for each program; multiply by the factor for the chip family; round the fraction up once.
Then apply the same count to every option and pack on the program, which is how a factor decision propagates through the price list line by line.
The anchor is one query per database, kept with a date: NUM_CPU_CORES from V$OSSTAT is the number the whole calculation hangs on, and NUM_CPUS, the thread count a hyperthreaded host doubles, is the number SAM tools keep reporting in its place.
Inflating your own position in Oracle's favor before an auditor says a word.
The Oracle core factor brief
The table row by row, the aggregation and rounding arithmetic, the audit positions on the core base, and the evidence file that closes disputes fast.
Get the white paper →The real fight, the core base under virtualization
On soft partitioned hypervisors Oracle's position is that every core in the cluster can run Oracle, so every core must be licensed, a contractual interpretation set in the partitioning policy rather than a product limitation, and the single most expensive trap in Oracle database licensing.
The same database yields three counting positions on the same cluster: the cores Oracle actually runs on, the pinned set under approved hard partitioning, and the full cluster under the soft partitioning position, and the spread between the first and last is the 2x to 5x we kept meeting.
The defenses are architectural and documentary, dedicated hosts or approved hard partitioning with the paper trail, worked in the virtualization licensing analysis.
And the table has a boundary worth respecting: it is expressly excluded in Authorized Cloud Environments, which count vCPU instead, so a 0.5 assumption carried into a cloud business case is wrong at the first line.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across core factor disputes, 2024 to 2025
Across the 20 to 28 Oracle matters Fredrik Filipsson worked in 2024 and 2025 where a core factor number was in dispute, the pattern never varied:
Nobody on either side seriously contested 0.5 on current x86; the factor row settled almost immediately.
The core base under virtualization, 2x to 5x apart between positions, was where the money moved.
The lesson repeats across every engagement: buyers spend their effort defending the multiplier, which is settled, and neglect the denominator, which is negotiable.
The factor also has one interaction worth remembering on the sales side: it never reduces a Named User Plus count, it only sets the processor number the 25 per processor NUP minimum is calculated from, the interplay the license metrics guide covers.
The quarterly discipline is one inventory: cores and chips per server, Oracle mapped to each, dated, and filed beside the dated table PDF.
Your first five moves
- Run the V$OSSTAT query on every database and file the dated output: NUM_CPU_CORES is your number, and the thread count is not.
- Build the dated core and chip inventory now, the artifact that closed disputes 2 to 4 times faster in week one.
- Save the dated Core Factor Table PDF in force at each ordering document, and confirm any non x86 row by name, in writing.
- Fix the virtualization boundary before the audit prices it: dedicated hosts or approved hard partitioning with the paper trail, because the cluster position is the 2x to 5x.
- Never carry the factor into the cloud case: Authorized Cloud Environments count vCPU, on different rules. The Oracle practice runs the count with you.
Frequently asked questions
What is the Oracle core factor?
A per chip multiplier that converts physical cores into licensable Oracle processors: count the cores running Oracle, multiply by the factor from the published Core Factor Table, and round up.
Modern Intel and AMD server chips carry 0.5, IBM POWER carries 1.0, and the definition, including aggregation before rounding, is contract text, not guidance.
What core factor do AMD EPYC and Intel Xeon 6 chips carry?
0.5, but not by name: Oracle stopped enumerating x86 models long ago, so EPYC 9004 and 9005 and Xeon 6 land on the general Intel and AMD multicore x86 entries. The number is settled; what changes is the citation you give an auditor, which is why the dated copy of the table version in force matters.
How many licenses does a 256 core server need?
At the 0.5 x86 factor, 128 processor licenses: $6.08 million at the $47,500 Enterprise Edition list price, plus about $1.34 million a year of support, before options, and every option and pack on the program carries the same count.
The arithmetic is cores times factor, aggregated across the estate per program, rounded up once.
What is the biggest core factor mistake?
Not the multiplier: licensing a virtualized host on its full cluster core count because the partitioning was soft. Where auditors counted whole VMware clusters, the core base came back 2 to 5 times the cores actually running Oracle, a 30 to 70 percent bill swing.
The second most common: SAM tools reporting the thread count instead of NUM_CPU_CORES.
Does the core factor apply in the cloud?
No. The table is expressly excluded in Authorized Cloud Environments, which count vCPU under their own rules, so a 0.5 assumption carried into a cloud business case is wrong from the first line.
The factor governs on premises hardware, under the table version in force when the ordering document signed.
Does the core factor reduce Named User Plus counts?
No. The factor sets the processor count, and the 25 NUP per processor minimum is then calculated from that number: a lower factor lowers the floor, but the actual named user population still licenses in full if it exceeds the minimum. The factor never directly reduces a NUP count.
