The processor metric is the load-bearing Oracle Database commercial unit. The Admodum read on what the metric actually says, how the deployed estate lands against it, and what the buyer should hold against the publisher reading.
The processor metric is the commercial unit on which Oracle Database (Enterprise Edition), most Oracle Middleware and a wide set of Oracle options are sold. The metric reads as the deployed processor cores multiplied by the published Oracle core factor for the named processor family. The result is the licensable processor count.
The mechanics are simple in the abstract and surprisingly load-bearing in practice. A server with two Intel Xeon sockets each carrying sixteen cores presents thirty-two cores to the operating system. Under the core-factor table, the Intel x86 family carries a core factor of 0.5. The licensable processor count is therefore thirty-two cores multiplied by 0.5, or sixteen processor licences.
The same server filled with IBM Power chips would read at thirty-two cores multiplied by 1.0, or thirty-two processor licences. The same workload, the same applications, the same database; the licence count doubles because the underlying processor family carries a different published core factor. The metric reads against the hardware, not against the workload.
The published reference is the Oracle Processor Core Factor Table, available on the Oracle public site. The table lists named processor families against their published core factor. The table is updated periodically and applies to the deployed configuration at the date of deployment (not at the date of contract).
The procurement implication is that a buyer deploying on a new processor family must read the core factor at the date of deployment and reflect the read in the licence count. A processor family that carries a 0.5 core factor today may carry a different factor under a future revision; the buyer holds the published factor at the date of deployment under most contractual constructions.
The full reading of the table sits in a companion article: Reading the published core-factor table. The table reading is the first step in any Oracle deployment audit.
A virtual deployment reads against the Oracle Partitioning Policy. The policy distinguishes hard-partitioning technologies (which limit the licence count to the partitioned cores) from soft-partitioning technologies (which require licensing of the full physical host).
The hard-partitioning list is short and named (Oracle VM Server with named CPU pinning, IBM LPAR with named processor binding, Solaris Containers with named CPU caps, certain HP-UX nPars and vPars). The soft-partitioning list is long and includes most enterprise hypervisors as deployed in default configuration: VMware vSphere, Microsoft Hyper-V, Red Hat KVM, Citrix XenServer and so on.
The procurement implication is direct. A four-core Oracle workload running on a sixteen-core ESXi host under default vSphere configuration reads, under the policy, as a sixteen-core licensing event (not as a four-core event). The Admodum methodology audits the partitioning posture before sizing the licence count.
The metric does not directly translate to AWS, Microsoft Azure or Google Cloud. The Oracle Cloud Authorisation document applies its own conversion rule for deployments on the authorised public clouds. The rule reads (broadly) two vCPUs as one processor licence on a hyperthreaded instance and one vCPU as one processor licence on a non-hyperthreaded instance.
The rule is a policy memorandum rather than a contractual entitlement. The contractual position is the master agreement plus the order document; the policy memorandum is a publisher reading of how the contract applies to the public-cloud substrate. The two read together but they are not the same document.
The buyer-side methodology reads the deployment substrate (on-premise, virtual, public cloud) and applies the appropriate construct. The full reading sits in the companion articles The Oracle Cloud Authorisation document and Oracle on AWS, Azure and GCP.
The publisher reading of the buyer’s processor metric runs against the Oracle License Management Services audit methodology. The LMS scripts collect the deployed estate; the report reads the deployed cores against the contracted entitlement; the closing letter records the publisher position.
The buyer-side defence runs against the audit-quality inventory: the per-host list of every processor running Oracle, the processor family, the core count, the deployment topology (physical, virtual, cloud), the licence metric on the contracted line item and the deployment’s position against the published policy memoranda.
Without the inventory, the publisher reading runs unopposed. With the inventory, the closing position is the negotiated reading of the inventory against the contract and the policy. The full methodology sits in the LMS Audit Defence white paper and runs inside the Audit Defence programme.
The buyer holds three load-bearing positions against the processor metric. The first is the audit-quality inventory; without it the metric reads against the publisher’s assumed deployment, which is rarely the buyer’s actual deployment. The second is the deployment substrate read; the on-premise core-factor table, the partitioning policy and the cloud authorisation document each apply differently. The third is the contractual position; the master agreement, the order document and the Schedule A together define what the buyer actually owes.
The Admodum methodology runs the three positions inside any Oracle engagement under one of three commercial frameworks: fixed fee for scoped audits, contingency / gainshare for measurable savings and annual retainer for continuous coverage.
The closing reading reaches the Oracle licensing pillar for the wider editorial context, the Oracle practice for the engagement entry point and the Oracle knowledge hub for the aggregated reading list.
Intel, AMD, Power, SPARC and the named exceptions, set out against the published reference.
Hard-partitioning, soft-partitioning, what the policy actually says against the deployed estate.
The notice, the scripts, the report, the settlement letter and the buyer-side defence.
A senior Admodum Oracle advisor will run the processor-metric methodology through with your CIO, CFO, procurement team or audit response team on a private call. Active LMS audits route immediately to the Audit Defence programme.