The Oracle Core Factor Table Explained: Cores, Factors and Where the Count Goes Wrong
The Oracle Processor Core Factor Table is a single page that decides the size of most Oracle bills. It assigns a multiplier to each processor family, and the number of Processor licences a server needs is its physical cores multiplied by that factor, rounded up. The factors range from 0.25 to 1.0, and because Enterprise Edition licences carry a list price in the tens of thousands per processor, a factor applied to the wrong chip or the wrong core count moves the position by six or seven figures.
This explainer covers how the table is applied, the factors that matter in current estates, where the table does not apply, and the mistakes that show up in almost every position we review.
How the calculation works
For Enterprise Edition and its options licensed by Processor, count all physical cores on every processor where the Oracle programs are installed and/or running, multiply by the core factor for that processor model, and round the result up to the next whole number. Hyper-threading does not change the count: a 16-core processor with 32 threads is 16 cores. The multiplication happens per server, and the rounding happens after the multiplication, so a server with 6 cores at a factor of 0.5 needs 3 licences, and one with 7 cores at 0.5 needs 4.
Named User Plus licences do not use the core factor directly, but the per-processor minimum (25 for Enterprise Edition) is calculated on the same processor count, so the table still sets the floor.
The factors in current estates
| Processor family | Core factor | Typical current use |
|---|---|---|
| Intel Xeon (all current server families) | 0.5 | The bulk of on-premises x86 estates |
| AMD EPYC and other AMD x86 | 0.5 | Growing share of refreshed hardware |
| IBM POWER8, POWER9, POWER10 | 1.0 | AIX estates running large databases |
| Oracle SPARC T-series and M-series (recent) | 0.5 | Legacy Solaris estates, mostly on the way out |
| Older SPARC, and some legacy families | 0.25 to 0.75 | Rare; check the table entry for the exact model |
| Any processor not listed | 1.0 | The table says so explicitly |
The current table is published by Oracle and revised without notice. The version that applies is the one in force on the date of the licence position, and any historical position should cite the version it used. Always check the actual document for the specific model; the families above are a guide, not the table.
Where the table does not apply
- Standard Edition 2 is licensed per socket; cores and factors are irrelevant, but the socket ceiling is not (see SE2 versus Enterprise Edition).
- Authorised cloud environments. On AWS and Azure, Oracle's cloud licensing policy replaces the table: two vCPUs count as one Processor licence when hyper-threading is enabled, one vCPU as one licence when it is not. The 0.5 factor is not applied on top. Oracle's own cloud uses OCPUs, where one OCPU is one Processor licence for Enterprise Edition.
- Unlimited License Agreements during their term; the table returns at certification, when the deployed count is fixed as your perpetual entitlement.
- Named User Plus beyond the minimums, where the user count governs.
The mistakes we see most
- Counting the VM's vCPUs. The table is applied to the physical cores of the host, and under Oracle's partitioning policy usually to every host in the cluster. A 4-vCPU VM on a two-socket, 64-core host is 64 cores × 0.5 = 32 licences at minimum, and more if the cluster is larger. How the hypervisor changes this is its own article.
- Applying 0.5 to a processor that is 1.0. IBM POWER is the usual case. An eight-core POWER9 partition is eight licences, not four.
- Rounding before multiplying. Rounding happens once, at the end, per server.
- Forgetting the options. Each option and pack in use is licensed to the same processor count as the database. A 32-licence database with Partitioning and Diagnostics Pack is 96 licences across three products.
- Using the cloud factor on premises, or the table in the cloud. They are different documents with different arithmetic, and a lift-and-shift to AWS changes the count even when the core count does not change.
Why the CPU model matters more than the core count
Two servers with 32 cores each can differ by 32 licences if one is Xeon and the other is POWER. Refresh decisions are therefore licence decisions: a move from IBM POWER to x86 for an Oracle workload halves the Processor count for the same core count, and a move to a cloud shape changes the rules entirely. The position must carry the CPU model of every host, not just the core count, and it must carry it for the whole cluster.
This is inventory work rather than licensing expertise, and it is where Infrastructure Mapper and Oracle Database Manager earn their place: the hosts, CPU models and cluster memberships come from the discovery data you already collect, the factor is applied per host from the current table, and the resulting Processor count feeds the Effective License Position directly. When Oracle revises the table, the position updates; when a cluster gains a host, the count moves with it.
Checklist
- CPU model recorded for every host running Oracle, cluster members included.
- Core factor taken from the current published table, version cited.
- Physical cores, not threads and not vCPUs, multiplied per server, rounded once.
- Cloud deployments counted under the cloud policy, not the table.
- Options and packs counted at the database's processor count.
- The position dated, with the table version it used.
