Oracle processor counting multiplies the physical cores in each licensed server by a core factor for that processor type, then sums the result across every server running an in scope product. At ULA certification that total becomes your perpetual entitlement, so how each server is counted decides what you keep forever.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
The core mechanic is simple to state and easy to get wrong in practice. For each server running an in scope Oracle product, you take the number of physical cores, multiply by the core factor that Oracle assigns to that processor type, and round according to the rules. You then add the result across every relevant server to reach a processor count. Where the agreement uses Named User Plus rather than processor metrics, that metric applies instead. At certification, the processor total you declare is converted to perpetual licenses and the unlimited right ends, so every server that should count needs to be counted, and every core factor needs to be correct.
The formula is cores times core factor, summed across the estate. The value is won or lost in two places: making sure every legitimately deployed server is included, and making sure virtualization does not silently inflate the hardware that counts.
A core factor is the multiplier that turns physical cores into a licensable processor number. Oracle assigns it by processor type. Many common server processors carry a factor of 0.5, which means a server with sixteen physical cores equals eight Oracle processors. Some processor types carry different factors, so the count is only as accurate as the hardware inventory behind it. Getting the chip identification right is not a detail. A wrong core factor applied across a large estate moves the certified number by a meaningful amount in either direction.
The table below shows an indicative worked example for a small estate. The figures are illustrative and use a 0.5 core factor for clarity. Your real factors depend on your specific processors.
| Server role | Physical cores | Core factor | Oracle processors |
|---|---|---|---|
| Production cluster | 64 | 0.5 | 32 |
| Disaster recovery | 32 | 0.5 | 16 |
| Test and non production | 24 | 0.5 | 12 |
| Certified total | 120 | 60 |
Indicative example only. A firm that left disaster recovery and test out of this count would certify 32 processors rather than 60, losing 28 processors of permanent entitlement.
The worked example shows the most common loss. Disaster recovery, test, and non production instances deployed within the term are legitimately countable in most cases, yet they are the environments firms most often leave out. Each omitted server is permanent entitlement surrendered, because the unlimited right ends at certification and cannot be reused.
The opposite error is just as costly. Under Oracle's partitioning stance, soft partitioning does not limit scope. An Oracle instance running on a shared cluster can, in Oracle's view, require licensing across every host the cluster can reach, not just the host the instance sits on. Without isolation, a single small Oracle workload can pull a large cluster into the count. Dedicated clusters and documented isolation keep the processor count tied to the hardware you actually use.
A processor identified incorrectly carries the wrong factor, and that error scales with the size of the estate. An accurate hardware inventory, with the specific processor type recorded for every server, is the foundation the whole count sits on.
A processor count is only as strong as what stands behind it. The certified number needs to be supported by server lists, tool output, and a documented methodology, because that file is what proves the count during the certification review and defends it in any audit that follows. A number without a file is a number you cannot rely on. The count and the evidence are one piece of work, not two.
Read the peak deployment question to understand which point in the term your count should reflect, and server lists, screenshots, and tool output to build the evidence file that holds the count up. When you want your own processor count measured and defended, our Oracle ULA certification guide is the pillar that covers counting and certification in full.
Oracle processor licensing counts the physical cores in each licensed server and multiplies them by a core factor that depends on the processor type. The results are summed across every server running an in scope product. Named User Plus counting applies where the contract uses it. The certified processor number is the total you declare at the end of the term.
A core factor is a multiplier Oracle assigns to a processor type that converts physical cores into a licensable processor count. Many common server processors carry a factor of 0.5, so a sixteen core server can equal eight Oracle processors. The factor depends on the specific chip, so the hardware inventory has to be accurate.
It can change it dramatically. Under Oracle's partitioning stance, soft partitioning does not limit scope, so an Oracle instance on a shared cluster can pull the cores of every host that cluster can reach into the count. Isolation onto dedicated hosts is what keeps the processor count tied to the hardware you actually use.