How do you count Oracle processor licences?
You count Oracle processor licences by multiplying the number of physical cores by the core factor for that processor, taken from Oracle's core factor table, and then rounding the result up to the next whole number. The core factor is the step that the raw count leaves out, and it is usually what separates an inflated figure from the real one. A processor metric does not licence raw cores, it licences cores adjusted by the published multiplier, so any count that skips the factor is counting the wrong thing. This is core database licensing mechanics, and the full picture is in the Oracle Database Licensing Guide.
What is the Oracle core factor table?
The Oracle core factor table is Oracle's published list of multipliers, one for each processor type, used to convert physical cores into licensable processors. Each chip family has its own factor, and a very common value is 0.5, which means two physical cores equal one licensable processor for that family. Other families carry different factors, so the table has to be read against the actual hardware rather than assumed. Because the table is published by Oracle, applying it is not a concession you are asking for, it is the method Oracle itself defines, which makes it one of the strongest and least disputable corrections available to a buyer.
Identify the exact processor model on every host, look up its factor in the core factor table, and apply it before agreeing any count. Never accept a processor figure built on raw cores, because the core factor is Oracle's own rule.
A worked example
Consider a server with two sockets, each holding a 16 core processor, giving 32 physical cores. If that chip family carries a core factor of 0.5, the licensable processor count is 32 multiplied by 0.5, which is 16, rounded up where needed. A raw count would have claimed 32 processors, double the true figure. Across an estate of similar servers, applying the factor consistently can halve a processor finding on its own, before any other correction is made. The same data also has to be tested against the deployment boundary, because in a virtualized estate the cluster wide assumption can inflate the core count before the factor is ever applied.
| Input | Raw count | Core factor 0.5 |
|---|---|---|
| One server, 32 cores | 32 processors | 16 processors |
| Five servers, 160 cores | 160 processors | 80 processors |
| Effect on the finding | Overstated | Halved to the true figure |
Why do audits overstate processor counts?
Audits overstate processor counts because raw script output often reports physical cores before the core factor is applied, and in a virtualized estate it can assume a cluster wide boundary on top of that. The two errors compound: the boundary inflates the number of cores in scope, and the missing factor doubles the figure for many chip families. Correcting both, by applying the core factor table and rebuilding the boundary from the hosts that actually run Oracle, is the heart of an accurate processor count. For the boundary side of this, see how scripts overcount in virtualized estates and for the data behind it, feature usage data, the DBA views that matter.
What is the next step?
The next step is to recount every processor in your finding against the core factor table and the real deployment boundary before you accept a single number. The factor is Oracle's own published rule, so applying it is simply counting correctly, and the difference it makes is often half the figure. Book a strategy call and we will rebuild your processor count from the hardware up, with the factor and the boundary applied.
Have a processor count to check? Book a Strategy Call and we will recount it against the core factor table, or read the full method in the Oracle Database Licensing Guide.