Oracle counts physical cores, then multiplies each by a core factor that varies by chip to produce processor licenses. Get that math right and your certified number holds up under review. Get it wrong and you either undercount your entitlement or declare a figure you cannot defend.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
Oracle's processor metric does not count sockets or servers. It counts physical cores, then applies a core factor to each core to produce a number of processor licenses. The core factor is a multiplier published by Oracle that varies by processor type. For many common server chips the factor is 0.5, so a core counts as half a processor license. For some processors it is higher. The formula is simple to state: cores multiplied by the core factor equals processor licenses. The complexity lives in getting the core counts right across the estate and applying the correct factor to each chip, because the same core count produces different license numbers depending on the hardware underneath it.
Processor licenses equal physical cores multiplied by the core factor for that processor type. The core factor is set by the chip, not by you, so the first job is to know exactly what hardware runs your Oracle workloads.
Because the core factor is a multiplier, it scales your entire count. A wrong factor applied across a large estate moves the number by a wide margin. Use a factor that is too high and you inflate the count beyond what you can defend, handing exposure to a future audit. Use one that is too low and you undercount, surrendering perpetual entitlement you were free to claim. The factor also interacts with hardware refresh during the term: a fleet migrated to a different chip part way through the term may carry a different factor on its new platform, and the count has to reflect what was actually deployed and when. This is why the calculation is documented chip by chip rather than estimated as a single blended rate.
Take an indicative estate of three server groups running Oracle Database Enterprise Edition within the term. The math is the same for each: count the cores, apply the factor, sum the result.
| Server group | Physical cores | Core factor | Processor licenses |
|---|---|---|---|
| Group A (common x86) | 320 | 0.5 | 160 |
| Group B (common x86) | 192 | 0.5 | 96 |
| Group C (higher factor chip) | 128 | 1.0 | 128 |
| Total | 640 | mixed | 384 |
The estate has 640 physical cores but certifies at 384 processor licenses, because two thirds of it sits on a 0.5 factor chip and one third on a 1.0 factor chip. Note what the factor does: had every group carried a 0.5 factor, the count would be 320 processors, and had every group carried 1.0, it would be 640. The same hardware spans a 320 processor range purely on the factor. The figures here are indicative and the published factor for any given chip must be confirmed against Oracle's current core factor table, but the mechanism is exactly this.
The most common error is treating the estate as one factor rather than mapping each chip. A single assumed rate is fast, but it is wrong wherever the hardware is mixed, and a mixed estate is the normal case. The defensible method applies the correct factor to each processor type and shows the working, which is also what survives a review.
The factor is only as good as the hardware data behind it. An inventory that records the wrong chip, or that misses a refresh during the term, applies the wrong multiplier. Accurate, current hardware discovery is the input that makes the core factor math trustworthy, which is why counting and discovery are tightly linked, a subject we take up in discovery tooling for a ULA count.
Processor counting is not the only metric. Where Named User Plus applies, the count is based on users rather than cores, and for some deployments that metric produces a different and sometimes more favourable result. The method is to check which metric governs each product under your agreement, not to assume processor counting everywhere.
Counting in authorized public cloud follows Oracle's cloud licensing policy rather than the on premises core factor table, and it is governed by your contract conditions. The prior question is whether cloud counts toward your certification at all, which is contract specific: many ULAs name AWS and Azure with conditions, some exclude public cloud entirely, and many are silent on GCP, where silence is not inclusion. Read the cloud clause first, decide whether the cloud volume qualifies, and only then apply the appropriate counting method. Applying the on premises factor to a cloud instance, or counting cloud the contract excludes, is how a count loses its footing.
Core factor math is the difference between a count that holds and a count that wobbles. Count physical cores, apply the correct factor for each chip from Oracle's current table, show the working, and check whether Named User Plus or cloud rules change the picture for any product. Do that and the number you certify is both maximised and defensible. The undercount that comes from sloppy factor work is real money lost, as we set out in the undercount risk and its cost, and the full process sits in our pillar, the Oracle ULA certification guide.
Oracle counts physical cores, then multiplies each core by the core factor for its processor type to get processor licenses. A server with 32 cores at a 0.5 core factor counts as 16 processor licenses. The core factor varies by chip, so the same core count can produce different license numbers depending on the hardware.
Counting in authorized public cloud follows Oracle's cloud policy rather than the on premises core factor table, and it is governed by your contract conditions. Whether cloud counts toward certification at all is contract specific, so the cloud clause is read before any cloud counting method is applied.
Book a confidential assessment and we will run the core factor math across your estate so the number you certify holds up.