The Oracle processor core factor table in 2026. How cores become licenses, and where the count is argued.

Oracle processor licenses equal physical cores times the chip's core factor, added up per program and rounded up once. Current x86 chips carry 0.5 and IBM POWER 1.0. The factor rarely stays in dispute; the list of servers it applies to does.

This guide gives the current factor for each chip family and the arithmetic Oracle applies to it. Most of it deals with the more expensive question of which servers and which cores go into the count, above all on VMware.

What is the Oracle processor core factor table?

It is a short Oracle document that lists processor families with a licensing factor for each: 0.25, 0.5, 0.75 or 1.0. The Processor definition in your contract points to it, so the factor is contract arithmetic. The table has been in effect since March 16, 2009, and Oracle last updated it on January 28, 2026.

Oracle republishes the table without notice. The version in force on the day each ordering document was signed governs the licenses on that order, so save a dated PDF copy with every order. Three years later, when an auditor asks, the party holding that PDF sets the terms of the discussion.

Which core factor does each processor carry?

A few older rows are easy to misread. SPARC T3 sits at 0.25 while T4 and later sit at 0.5, and SPARC64 VII+ is 0.5 while the plain SPARC64 VII is 0.75. The older AMD Opteron families are listed at 0.5, the same as EPYC.

What happens when a chip is not on the table?

It falls to the last row, "All other multicore chips", at 1.0. Oracle has added new Intel and AMD families in later updates, and the version dated January 28, 2026 names EPYC 9005 and the Xeon 6 models. A new generation bought before Oracle lists it is, on the text, a 1.0 chip.

IBM POWER is the other place the factor decides the bill: on 24 POWER cores, the gap between 1.0 and 0.5 is 12 processor licenses, or $570,000 at Enterprise Edition list.

How do you calculate Oracle processor licenses from cores?

Add up the physical cores for each program, multiply by the factor and round the result up once. The order of operations comes from the Processor definition, which covers all processors where the programs are installed and/or running.

1. Count physical cores. Include every server where the program is installed or running. Threads and vCPUs play no part on premises.
2. Aggregate per program. Add the cores across all servers for each licensed program before you multiply anything.
3. Apply the factor. Use the row for each chip family in the table version that governs the order.
4. Round up once. Round the fraction on the total for the program.
5. Carry the count. Every option and pack on that program needs the same number of processor licenses.

Why does rounding once matter?

Rounding per server adds a license for every server with a fractional result. Say you run Enterprise Edition on three older Fujitsu servers, each with one two core SPARC64 VI chip. Per server, 2 x 0.75 is 1.5, rounded to 2, for a total of 6 licenses. Aggregated, 6 cores x 0.75 is 4.5, rounded once to 5.

At 0.5 the difference only appears on odd core counts, which modern servers rarely have. On 0.75 and 0.25 chips it appears all the time. When Oracle sends you a calculation, check that it rounds on the total and ask for it to be redone if each row is rounded.

Which options and packs follow the core count?

All of them. Partitioning, Diagnostics Pack, Tuning Pack, Real Application Clusters and the other database options are licensed on the same processor count as the database they extend. That is how one factor decision flows through the price list line by line.

What does a 256 core server cost to license at list price?

A two socket x86 server with 256 cores needs 128 processor licenses at the 0.5 factor. Each option you add is priced on the same 128, and the two packs below add $1,600,000 in licenses before discounts. The table prices one hypothetical server at the current Oracle list.

Discounts change the price of each license and leave the count alone, so every point you win applies to a number the factor and the core base have already fixed. That is why we agree the count with Oracle before any price discussion starts.

Does the factor change Named User Plus minimums?

It sets the minimum, because Enterprise Edition requires at least 25 Named User Plus licenses per processor and the processor number comes from the factor. On the server above, 128 processors x 25 gives a floor of 3,200 named users, even if only 400 people use the database.

If more people than the minimum use it, you license all of them. At list, 25 users x $950 is $23,750, exactly half a processor license, so the NUP floor on any server costs half its Processor price. The license metrics guide covers when NUP still pays, and our NUP minimum examples work through more cases.

How do you check your own Oracle core count?

Query each database for its core count, then confirm the chip model and the host against the table. The number the whole calculation rests on is NUM_CPU_CORES in V$OSSTAT, saved with a date for every database.

• V$OSSTAT. Select NUM_CPU_CORES, NUM_CPU_SOCKETS and NUM_CPUS. NUM_CPUS is the thread count, roughly double the cores on a host with hyperthreading on.
• lscpu on Linux. Socket(s), Core(s) per socket and Model name give the core count and the exact chip to match to a table row.
• The hypervisor console. Inside a virtual machine, V$OSSTAT reports what the guest sees. For virtualized databases, take physical cores per host and cluster membership from vCenter, or from the HMC on IBM POWER.
• Oracle's own collection scripts. If you hold them from an earlier audit, run them yourself first so you know what the CPU query output will show. Our script analysis explains how to read it.

Why do SAM tools overstate the count?

Many discovery tools read the operating system's logical processor figure, such as the CPU(s) line in lscpu or the logical processors count in Windows, and file it as cores. Inside the database the same slip is taking NUM_CPUS where NUM_CPU_CORES belongs.

It is the most common self inflicted error we find, and it hands Oracle a larger number before an auditor says a word. Before you export anything from the tool, check which field it maps to "cores" and test it against one host whose specification you know.

How does VMware change the core count Oracle claims?

On soft partitioned hypervisors such as VMware, Oracle's position is that every core in the cluster can run Oracle, so every core must be licensed. That position comes from the partitioning policy, a contractual interpretation rather than a product limitation, and it is the single most expensive trap in Oracle database licensing.

Say Oracle runs in virtual machines on 2 hosts of a 10 host VMware cluster, each with 2 x 32 cores, and the workload needs 48 cores. VMware is not an approved hard partitioning technology, so the lowest of the three counts below needs another platform, such as IBM PowerVM LPARs.

The gap between the hosts where Oracle runs and the full cluster here is 5 times, the top of the range we met in disputes. The defenses are architectural and documentary: dedicated hosts, or approved hard partitioning with the paper trail, as set out in our virtualization licensing analysis.

Does the core factor apply in AWS, Azure or Google Cloud?

No. In Oracle's Authorized Cloud Environments, which are AWS EC2 and RDS, Microsoft Azure and Google Cloud Platform, the table is expressly excluded. Two vCPUs count as one processor license when multithreading is enabled, and one vCPU counts as one when it is disabled.

A 0.5 assumption carried into a cloud business case is wrong at the first line. A 16 vCPU instance with multithreading needs 8 licenses, while the same 8 physical cores on premises at 0.5 would need 4.

• Oracle Cloud Infrastructure. OCI uses its own OCPU conversion, covered in our OCI shapes guide.
• Standard Edition 2. SE2 skips the factor entirely and counts occupied sockets on premises, as the SE2 guide explains.

What have we seen in Oracle core factor disputes in 2024 and 2025?

Across the 20 to 28 Oracle matters I worked in 2024 and 2025 where a core factor number was in dispute, the factor itself was agreed inside a week almost every time. Neither side seriously argued that a current x86 chip was anything but 0.5.

• The server list took months. Where the auditor counted a whole VMware cluster, the licensable core base came back 2 to 5 times the cores actually running Oracle. That alone swung the bill by 30 to 70 percent before any discount discussion.
• Dated evidence shortened disputes. Customers who produced a dated core and chip inventory in week one closed their disputes 2 to 4 times faster than those who could not.

Why we think core factor checklists spend effort on the wrong number

Most audit preparation advice tells you to verify the factor on every server. We disagree with that emphasis, because the factor is published and in our disputes it settled in days.

The core base under virtualization is where the months went and where the money changed hands. Spend your preparation on the server list instead: which hosts can run Oracle, why, and the records that prove it.

Buyers spend their effort defending the multiplier, which is settled, and neglect the core base, which is where the negotiation happens.

What will Oracle's auditors say about your core count, and how should you answer?

Expect them to claim the whole cluster, read threads as cores, default an unlisted chip to 1.0 and round server by server. Answer each claim with evidence already on file.

• "Every host in the cluster can run the database, so every core is in scope." Ask which contract clause they rely on. Then show your dated host inventory, the cluster boundaries and the storage the Oracle hosts can reach, and argue from where the programs are installed and running.
• "Your tool shows 512 CPUs on this host." That is NUM_CPUS, the thread count of a hyperthreaded 256 core host. Provide NUM_CPU_CORES from V$OSSTAT with the date of the query.
• "This chip is not listed, so the factor is 1.0." Produce the table version in force when the order was signed, open at the row that names the chip.
• A findings sheet that rounds each server. The definition aggregates cores per program before multiplying and rounds the fraction up once. Ask for the calculation to be redone on the total.

What contract terms protect your Oracle core count?

Ask for terms that fix the reference points before anyone counts. Oracle will refuse some of them, and each one you get removes a future argument.

1. A dated table reference. Name the Core Factor Table version, by date, in the ordering document, so a later update cannot reopen the factor on licenses you own.
2. Written confirmation for non x86 chips. For POWER, SPARC or Ampere, get the factor confirmed in writing against the chip name.
3. A counting method. State that cores means physical cores as reported by NUM_CPU_CORES or the hardware vendor's specification.
4. A named environment. Where you run a dedicated Oracle cluster, list its hosts in the order so the boundary is on paper before any audit.

What to do next

1. This week. Run the V$OSSTAT query on every database and file the dated output, taking NUM_CPU_CORES as the core figure.
2. This month. Build the dated core and chip inventory: cores and chips per server, Oracle programs mapped to each, refreshed every quarter.
3. At every order. Save the Core Factor Table PDF in force on the signing date, and confirm any non x86 row by name, in writing.
4. Before any audit. Fix the virtualization boundary with dedicated hosts or approved hard partitioning and its paper trail, before an auditor prices the full cluster.
5. Before a hardware refresh. Check the new chip's row and the new core count per socket, and price the licenses before you order.
6. Before a cloud move. Rebuild the business case on vCPU counting. The Oracle practice runs the count with you.

Frequently asked questions