The processor licence is the dominant Oracle Database licence metric and the most commonly audited count in the Oracle product line. The metric appears simple at first reading. The buyer counts physical cores, applies the core factor for the processor family, and multiplies by the number of running instances. In practice the metric is the source of more audit findings than any other licence count. The issues cluster around the core factor table, around the treatment of hyper threading, around virtualisation environments that use VMware or other hypervisors, and around the cloud deployment guidance. This article describes each issue and the buyer defence position.
The processor metric definition.
The processor metric is defined in the Oracle licensing documentation as the count of physical cores in the server that hosts the Oracle software, multiplied by the core factor specified in the Oracle Processor Core Factor Table. The metric does not count CPU sockets, CPU threads, or virtual CPUs. The metric counts physical cores. The core factor table assigns a multiplier to each processor family. Intel and AMD x86 processors carry a core factor of 0.5. Various Power, SPARC, and Itanium processors carry different core factors.
The metric applies to each server on which the Oracle software is installed and running, or on which the Oracle software can be installed and running according to the licensing policy. The licensing policy includes the partitioning rules that determine whether a virtualised environment is licensed at the cluster level or at the partition level. The partitioning rules are the source of the largest individual audit findings.
The core factor table.
The Oracle Processor Core Factor Table is published on the Oracle pricing site and is updated when new processor families enter the market. The buyer should reference the current table at the time of the audit and at the time of any historical period under review. The table changes over time and applying the wrong version to a historical period produces an incorrect count.
Buyers should also verify that the processor family in the deployed servers is the family identified by the table. Some processor families have variant numbers that affect the core factor. The audit position should reference the specific model number for each server in the deployment register. Generic processor family entries can produce disagreements with Oracle during the audit.
See the hyper threading counting note for the related issue.
Hyper threading and virtual CPU counts.
Hyper threading is a technology that allows each physical core to present as two logical processors to the operating system. The processor licence metric counts physical cores rather than logical processors. The metric is therefore not affected by hyper threading on bare metal deployments. The issue arises in virtualised environments where the virtual machine sees virtual CPUs that may correspond to logical processors or to physical cores depending on the hypervisor configuration.
The audit position should document the mapping from virtual CPUs to physical cores for each virtualised deployment. The mapping should be verified at the hypervisor level rather than at the virtual machine level. A virtual machine that reports four virtual CPUs may be running on two physical cores with hyper threading enabled. The licence count is two cores at the relevant core factor, not four.
VMware and cluster wide licensing.
Oracle treats VMware as a soft partitioning technology under the Oracle partitioning policy. The policy requires the buyer to licence every physical core in every server that is part of the VMware cluster, regardless of whether the Oracle workload is currently running on that server. The policy can extend the licence count to the entire VMware estate if vMotion is enabled across multiple clusters. The audit position on VMware deployments can produce findings that exceed the entire deployed footprint of Oracle workloads.
The buyer defence position on VMware deployments is technical and operational. The buyer can document the cluster boundaries and the vMotion settings. The buyer can also implement isolated clusters for Oracle workloads that limit the licence exposure. The contract position on the soft partitioning policy is also contested in the industry. The policy is not a contract term in the standard customer agreement. It is published guidance that Oracle applies during audits.
See the soft partitioning issue analysis for the full position.
Cloud deployment counting.
Cloud deployments are governed by the Oracle authorised cloud environment policy. The policy specifies that AWS, Azure, and Google Cloud Platform are authorised cloud environments for Oracle software. The policy specifies a counting rule for each authorised cloud environment. The standard rule is that two vCPUs equal one Oracle processor licence when hyper threading is enabled, and one vCPU equals one Oracle processor licence when hyper threading is disabled.
The policy applies to the specific cloud services and instance types listed in the policy. Deployments in cloud services not listed in the policy fall outside the authorised cloud environment guidance and require a different counting approach. The audit position should reference the policy in force at the time of the deployment and should document the cloud service and instance type for each deployment.
The audit data request and response.
The processor licence audit typically begins with a request for the Oracle deployment inventory. The request asks for the list of servers running Oracle software, the processor model in each server, the core count, and the virtualisation configuration. The buyer response should be coordinated and reviewed before submission. The response should reference the deployment register that the buyer maintained through the period under review.
The response should distinguish between licensed deployments, deployments that are pending decommissioning, and deployments that are scheduled for replacement. Each category should be documented separately. The response should also reference the contract terms that govern the licence position. The contract is the source of the buyer rights. The audit policy is the Oracle interpretation of the contract.
Engaging an independent advisor.
The processor licence audit benefits from external technical expertise and from external negotiation expertise. An independent advisor brings the experience of running multiple processor audits and can build the deployment inventory, the licence position, and the negotiation strategy on a compressed timeline.
For the wider cluster see Audit Defense. For the service see Audit Defense. For the deal structure see the Database licensing page. For the Oracle product see the Oracle Database product page. For the full research read the Oracle Negotiation Playbook white paper.
The historical period question.
Oracle audits typically cover a historical period of three years. The audit position requires the buyer to demonstrate licence compliance through the historical period as well as at the current state. The historical compliance question can be challenging because deployment and licence positions change over time. The buyer may have a clear current position and a less clear historical position.
The audit defence should include a historical deployment record that documents the deployment state at each point in time during the audit period. The record can be built from infrastructure inventories, from change management records, and from decommissioning records. The record should be reviewed against the licence position in force at each point in time. The historical position is often the source of audit findings even when the current position is clean.
A worked example.
A financial services buyer received an Oracle audit notice in 2024 covering Database deployments over the three years from 2021 to 2024. The buyer current deployment was approximately three hundred processor licences across an Intel x86 estate with hyper threading enabled. The Oracle audit proposal included a finding of four hundred and fifty processor licences after applying the partitioning policy to the VMware estate that hosted the Database workloads.
The buyer engaged an independent advisor. The advisor documented the cluster boundaries and the vMotion settings. The buyer had implemented isolated clusters for the Oracle workloads in 2022. The audit position was therefore limited to the isolated clusters from 2022 onwards. The advisor also identified that the Oracle position was applying the current partitioning policy retrospectively to the period before 2022 when the policy was different.
The final settlement recognised three hundred and twenty processor licences for the current state and a small historical settlement for a period before the cluster isolation was complete. The settlement was approximately six million dollars below the original audit proposal. The cluster isolation pattern and the historical contract analysis produced the outcome.
The renewal conversation after audit.
The conclusion of a processor audit is rarely the conclusion of the Oracle conversation. Oracle uses the audit settlement to set the platform for the next commercial conversation. The settlement may be conditioned on a new licence purchase that closes a gap identified during the audit, or on a support contract amendment that extends coverage of the licensed footprint. The conditions should be evaluated as a separate commercial conversation rather than accepted as part of the audit close.
Buyers that decouple the audit close from the renewal conversation produce stronger outcomes on both. The audit close should record the contract position for the period under review. The renewal conversation should price the forward looking arrangement on its own merits. Oracle prefers to combine the two. The buyer that holds the separation produces a cleaner audit settlement and a more favourable renewal.