What is the Oracle core factor table?
The Oracle core factor table is a published list of multipliers that turn physical processor cores into the number of Oracle Processor licenses your hardware requires. Every supported processor family is assigned a factor, and the factor reflects Oracle's view of that chip's relative performance for licensing purposes. The table matters because Oracle does not license Enterprise Edition databases by the raw core count. It licenses by a derived number, and the core factor is the conversion rate between the two.
The distinction is not academic. The same physical server can require very different license quantities depending on the factor that applies to its chips, and the table is updated over time as new processor families appear. The table is also a policy document published by Oracle, which means it sits alongside your signed agreement rather than inside it. Where the published table and your contract differ on how a metric is defined, the contract language governs, and the policy document is not the contract. That principle decides more audit disputes than most buyers expect.
How does the 0.5 core factor work?
The 0.5 core factor means each physical core counts as half of one Oracle processor, so a server with sixteen x86 cores at a factor of 0.5 requires eight Processor licenses. The calculation is deliberately simple: count the physical cores in scope, multiply each by the factor from the table, add the results across the server, then round the total up to the next whole number. Rounding is always upward, never to the nearest, which means a fractional result of 8.1 becomes 9 licenses, not 8.
Physical cores multiplied by the core factor, summed across the server, then rounded up to the next whole number. That total is the Processor license requirement for Enterprise Edition on that hardware.
Two details catch people out. First, the factor applies to physical cores, not threads, so hyperthreading does not change the count. Second, the factor is applied before any rounding, so you sum the fractional results across all processors in the server and round only once at the end. Rounding each socket separately can inflate the total, and an inflated total is exactly what a preliminary audit finding tends to show.
Which processors carry which core factor?
Most modern Intel Xeon and AMD EPYC cores carry a core factor of 0.5, while some older or specialised processors carry higher or lower values, so the chip family decides the multiplier. The table below shows the shape of the values you will meet most often. Always read the current published table for the exact figure that applies to your hardware, because the values are revised and a server bought in one year may sit on a different factor than one bought in another.
| Processor family | Typical core factor |
|---|---|
| Intel Xeon, recent generations | 0.5 |
| AMD EPYC, recent generations | 0.5 |
| Some legacy x86 single core | 1.0 |
| Certain SPARC and Power lines | 0.25 to 0.75 |
Standard Edition 2 is the important exception. It is not licensed by the core factor table at all. It is licensed by occupied sockets, with its own rules and limits, which is why a move between editions changes the whole licensing basis rather than just the price. If your estate mixes editions, you cannot apply one rule across all of it, and an audit will test whether you have applied the right basis to each server.
Where does the core factor table create audit exposure?
Core factor exposure usually comes from one of three errors: applying the wrong factor to a chip family, counting cores on hardware that is not actually running Oracle, or failing to round at the right point in the calculation. Each of these is a measurement question, and measurement questions are where independent line by line review does its work. A preliminary finding that assigns a factor of 1.0 to cores that should sit at 0.5 doubles the apparent requirement on that hardware, and the correction is simply reading the right value from the published table against the right chip.
The wider pattern matters too. Oracle's audits arrive with preliminary findings inflated at list price, and independent line by line review of those findings typically cuts the claim 60 to 80 percent. A material share of that reduction comes from correcting the count itself: the right core factor, the right cores in scope, and the right rounding. None of this is adversarial toward the reader. It is the disciplined application of Oracle's own published table to the hardware you actually run.
Our database licensing guide works through the core factor calculation with examples and shows where audit findings inflate it. We reduce your Oracle exposure or we reimburse our service fee, on a Fixed Fee or Gainshare basis with no risk to you.
What is the buyer move?
The buyer move is to rebuild the Processor count yourself from the published core factor table before you accept any finding, server by server, with the right chip family and a single rounding step at the end. Start from a verified inventory of which servers actually run Oracle Enterprise Edition, identify the precise processor family in each, read the current factor, and compute the requirement. Compare your number to the finding and treat every gap as a question to be answered with the published table, not a figure to be conceded. For the full method, read counting processors correctly with core factors and how Named User Plus minimums bite, then work up to the Oracle database licensing guide for the complete picture.
FAQ
What is the Oracle core factor table? A published list of multipliers that convert physical cores into licensable Oracle processors. Each family has a factor, and most modern x86 cores carry 0.5.
How do you calculate Oracle Processor licenses? Count the physical cores in scope, multiply each by its core factor, sum across the server, and round up to the next whole number.
Does the core factor table apply to the cloud? No. Oracle applies separate counting rules for authorised cloud environments, so the same workload can carry a different count. The applicable rule is contract dependent.