Processor metric licensing looks deterministic on the order document and indeterminate everywhere else. Core factor tables, hard versus soft partitioning rules, virtualization carve-outs, cloud-vendor factors and the standard-edition socket rule each produce different compliance numbers from the same hardware. This is how the math actually works — and where the compliance gaps appear.
Oracle Enterprise Edition is licensed by Processor. The Processor count for a server is calculated by multiplying the number of physical cores in scope by the Oracle Core Factor for the relevant CPU family. The result, rounded up to the next whole processor, is the licence count required for that server. The same calculation applies to every Option and Pack deployed on that server, each licensed at its own metric and rate.
The simplicity ends there. The "cores in scope" definition is the contested variable. Whether you count every core in the box, only the cores in a partition, or the cores in an entire VMware cluster depends on the platform and the partitioning method Oracle recognises. Each of those readings can be correct under one definition and wrong under another.
Oracle publishes a Core Factor Table that maps each CPU family to a multiplier. For the platforms most enterprise customers run on, Intel Xeon and AMD EPYC processors carry a 0.5 factor — meaning a 32-core server requires 16 Processor licences. IBM Power systems range from 0.5 to 1.0 depending on the generation. Older SPARC processors range from 0.25 to 0.75. The factor table is referenced in Oracle ordering documents and is the authoritative source for the calculation, although Oracle reserves the right to update it.
The core factor math is rarely where the compliance gap is — it is in the partition definition.
The single most consequential rule in Oracle processor licensing is the partitioning policy. Oracle distinguishes between hard partitioning — physical CPU allocation that Oracle accepts as bounding the licence requirement — and soft partitioning, where the partitioning mechanism does not limit the licence requirement at all. On a server using soft partitioning, the customer must license every core in the physical server regardless of how few cores the database VM actually consumes.
Oracle's published Hard Partitioning document recognises a narrow list: Solaris Containers (capped), Solaris Logical Domains (LDoms), AIX LPARs and DLPARs (under specific configurations), HP-UX vPars (capped), IBM zSeries and LinuxONE LPARs, and Oracle's own VM Server for x86 and OCI Compute partitions. Anything not on that list is, in Oracle's reading, soft partitioning.
VMware vSphere is the largest single source of Oracle processor licensing disputes. Oracle's audit position has consistently been that VMware does not constitute hard partitioning, and that customers running Oracle Database on VMware must license every core in every host where the Oracle VM could potentially run. Recent VMware vSphere versions have introduced features Oracle has interpreted as expanding the scope further — across linked vCenter instances, across vMotion-eligible hosts, and in some cases across entire datacentres. The defensible position requires either physically isolated clusters dedicated to Oracle workloads, or hard partition equivalents — neither of which is what most VMware deployments look like.
For a deeper treatment of the VMware boundary, see our soft partitioning and VMware licensing guides.
The processor-metric framework with worked examples and partition rules.
Oracle's Cloud Licensing Policy translates processor licences to the major public clouds with a different set of factors than the Core Factor Table. On AWS and Azure, Oracle counts two vCPUs as one Processor licence where hyperthreading is enabled, and one vCPU as one Processor where it is not. On OCI, one OCPU equals one Processor licence — an OCPU on Oracle's own cloud being equivalent to a physical core. GCP follows the AWS/Azure rule with a recent amendment that the customer should verify against current policy.
The policy is, importantly, a policy and not a contract. It can be updated unilaterally, and recent updates have tightened the cloud factor on some instance types. Customers should not assume the cloud factor in force at the time of licence purchase persists indefinitely.
Oracle Database Standard Edition (SE2 in current form) is licensed by socket rather than core, with a hard maximum of two sockets per cluster and 16 threads per database. SE2 has no Core Factor — the calculation is fundamentally different. SE2 also has no Options or Packs available, and is incompatible with most of the Enterprise Edition features customers reach for in production.
SE2 makes sense for smaller workloads, development environments, and isolated departmental databases. It does not work for consolidated platforms, RAC topologies above two nodes, or anywhere the customer needs Partitioning, Advanced Compression, Diagnostic Pack, Tuning Pack, or Active Data Guard. Migrating from EE to SE2 is occasionally a real licence reduction; it is more often an architectural error.
The six most common Oracle processor compliance gaps, in rough order of frequency:
The baseline you build before an audit is the baseline you negotiate from. We've built dozens.
If you have a VMware-on-Oracle deployment, an audit notice, or a major hardware refresh ahead, the cost of getting independent advice is small relative to the cost of getting the math wrong. When the notice is already in hand, this is where our Oracle audit defense work starts — rebuilding the processor count Oracle will actually have to accept.
Our Oracle team builds defensible processor baselines for negotiation and audit defence.
Weekly compliance intelligence for IT leaders.
