The Oracle Core Factor Table in 2026. How the factor maps to the bill.

The Oracle Core Factor Table is a multiplier published by Oracle that converts a count of physical cores into a count of Oracle processor licenses. The factor sits in the Oracle Software Investment Guide and applies to the Processor metric for Oracle Database, Middleware, and most options and packs.

The factor ranges from 0.25 for older IBM Power and SPARC chips up to 1.0 for legacy Intel Xeon and AMD EPYC server chips. The lower the factor, the fewer processor licenses needed on the same physical hardware.

Read this alongside the Oracle hub, the Oracle services page, the Oracle Database licensing guide, the Oracle pricing metrics CIO playbook, and the Vendor Shield subscription.

How the Oracle Core Factor works

The Processor license metric is the most common Oracle metric on Database, Middleware, and most options. The Core Factor Table sits inside the metric definition.

The core factor math

1. Count the physical cores. Sum every active core on the server or recognized hard partition.
2. Multiply by the factor. Apply the factor from the published Core Factor Table for the chip family.
3. Round up. Round the result up to the next whole processor license.
4. One license minimum. A single core chip at factor 0.25 still requires one full processor license.

Where the factor applies

• Oracle Database Enterprise Edition. The default Processor metric uses the factor.
• Database options and packs. Diagnostics, Tuning, Partitioning, Advanced Security, RAC, all carry the factor.
• Middleware. WebLogic Suite, SOA Suite, Identity Manager, and the rest sit on the same factor table.
• Java SE Universal Subscription. No factor applies. Java SE uses an Employee metric, not a Processor metric.

The 2026 Oracle Core Factor Table

The table below maps the chip family to the published core factor in 2026. The values are unchanged from the 2024 update except for two AMD EPYC additions at 0.5.

Core factor by chip family

Chip family	Core factor	Typical use case	Audit risk
Intel Xeon 64 bit (post 2012)	0.5	Standard x86 server	Low if hard partitioned
AMD EPYC 64 bit	0.5	High core count x86 server	Low if hard partitioned
IBM Power 8, 9, 10	1.0	AIX and IBM i workloads	Low on LPAR caps
IBM Power 5, 6, 7	0.5 to 0.75	Legacy AIX workloads	Medium on capped LPAR
SPARC T4, T5, M6, M7	0.5	Legacy Solaris workloads	Medium on capped LDOM
SPARC T1, T2	0.25	Older Solaris hardware	Medium on capped LDOM
Intel Itanium 9000 series	0.5	Legacy HP UX workloads	Low
Pre 2012 Intel single core	1.0	Very old hardware	Low

Three rules that shape the table

• Oracle Cloud at Customer. Oracle Engineered Systems on premises follow the factor table on the named chip.
• Oracle SPARC SuperCluster. The factor sits at 0.5 with documented hard partitioning on LDOM.
• BYOL to cloud. Bring Your Own License to Oracle Cloud or to AWS and Azure Authorized Cloud Environment uses a fixed two virtual CPU per processor license ratio, not the factor table.

Per chip values that move the audit

The chip choice on a refresh cycle moves the Oracle license count more than any negotiation lever. A 64 core EPYC server at factor 0.5 requires 32 processor licenses. The same workload on a 32 core Power 10 server at factor 1.0 requires 32 processor licenses on a smaller bill of materials.

Side by side compute decision

Server choice	Physical cores	Core factor	Processor licenses
2x Intel Xeon 32 core	64	0.5	32
2x AMD EPYC 64 core	128	0.5	64
1x IBM Power 10 32 core capped	32	1.0	32
2x SPARC T8 32 core	64	0.5	32
1x Intel Itanium 9740	16	0.5	8

Two policy quirks worth knowing

1. The factor is a policy, not a contract term. Oracle can update the table without renegotiating customer contracts.
2. The factor in force is the one published at the licensing event. The audit team will apply the table version current at the date of the audit.

Worked example: a database estate at scale

The math below uses a thirty server estate split across legacy SPARC, Intel Xeon refresh, and a small Power 10 footprint. The total physical core count is 1,200.

Baseline license requirement

Server pool	Servers	Cores per server	Core factor	Processor licenses
Legacy SPARC T5	10	32	0.5	160
Intel Xeon refresh	16	48	0.5	384
Power 10 critical	4	32	1.0	128
Total	30			672

At a 47,500 USD list price per Database Enterprise Edition processor license, the entitlement gap on a 672 processor estate sits at 31.9M USD list. The discount band on a renewal of this size lands at 50% to 70%, taking the run rate to roughly 9.6M to 16M USD plus 22% annual support.

VMware and the soft partitioning trap

Oracle treats VMware as non recognized soft partitioning. The audit position is that every host in the vMotion cluster requires Oracle licenses, not only the host running the Oracle VM.

Three Oracle audit positions on VMware

• vCenter scope from vSphere 6.0 onward. Oracle has argued every host visible to the vCenter is licensable.
• vMotion cluster scope. Every host that could ever run the Oracle VM through vMotion is licensable.
• DRS affinity rules ignored. Oracle does not recognize DRS or affinity rules as hard partitioning.

Buyer side counter positions

1. Documented physical isolation. A dedicated cluster with no shared storage and no shared vCenter narrows the audit scope.
2. Migration to recognized partitioning. Move the Oracle workload to OVM, IBM LPAR, SPARC LDOM, or Oracle Linux KVM.
3. BYOL to cloud. A move to Oracle Cloud, AWS Authorized Cloud, or Azure Authorized Cloud uses a fixed two vCPU per processor license ratio.

Seven Oracle Core Factor audit positions to anticipate

The seven positions below are the ones the Oracle License Management Services team carries into 2026 audits.

Seven positions worth a procurement memo

1. Factor in force at the audit date. Oracle applies the current table, not the table at the original contract date.
2. Hyper threading does not count. Logical cores are not licensable, only physical cores.
3. Disabled cores must be hard disabled. A BIOS toggle is not enough. Hardware level core disable is the audit standard.
4. Capped LPAR scope. An uncapped LPAR licenses the full physical server.
5. Standby and DR. Active Data Guard requires full licensing. A cold spare does not.
6. Named User Plus minimums. A move from Processor to NUP requires a 25 user per processor floor on Database EE.
7. Java SE separation. The Universal Subscription does not use the core factor.

What to do next

The eight step checklist takes an Oracle core factor position from the default audit posture to a buyer side position ready for the procurement memo.

1. Inventory the chip families. List every server running Oracle by chip family, core count, and partitioning mode.
2. Apply the factor. Compute the processor license requirement under the current table.
3. Document the gap. Compare the requirement against entitlement on the certificate.
4. Score the VMware exposure. Map every vCenter and vMotion cluster carrying an Oracle VM.
5. Quote the BYOL options. Cost the Oracle Cloud, AWS Authorized Cloud, and Azure Authorized Cloud paths.
6. Draft the audit memo. Counter positions on each of the seven audit risks above.
7. Run the procurement decision. Refresh, migrate, or renew with the factor in the line item math.
8. Lock the term. A three year support hold protects the factor math against a mid term table update.

Related advisory: Oracle audit defense services, Oracle negotiation and advisory, and how to reduce Oracle licensing costs before renewal.

Frequently asked questions

How Redress engages on Oracle core factor work

Redress runs Oracle Processor license advisory inside the Vendor Shield subscription, the Software Spend Assessment, the Renewal Program, and the Benchmark Program.

Read the related Oracle hub, the Oracle services page, the Oracle Database licensing guide, the Oracle pricing metrics CIO playbook, the Oracle ULA framework, the Oracle on VMware page, the benchmarking page, the about us page, and the contact page.