The core-factor table converts deployed cores into licensable processors. The Admodum read on the published reference, the named processor families and the buyer-side reading of the table against the deployed estate.
The Oracle Processor Core Factor Table is a publisher-published reference document, available on the Oracle public site. The table names processor families and assigns each family a core factor. The core factor is the multiplier applied to the deployed cores when converting cores into Oracle processor licences.
The table is structured as a single list. Each row carries a processor family name (often by vendor and series) and the named core factor for that family. The processor families that are not on the table read against a default factor (typically 1.0) unless the deployment runs on a substrate covered by a separate policy memorandum (such as the cloud authorisation document for AWS, Azure or GCP).
The full text and the wider context sit in the companion article The Oracle processor metric in plain language. This article reads the table itself; the metric article reads how the table is applied.
The buyer-relevant entries on the published table cover the chip families that carry most enterprise database deployments. The table extract below is illustrative; the buyer should verify against the current published reference at the date of any negotiation.
The Intel and AMD x86 entries cover the bulk of contemporary enterprise database deployments. The IBM Power entry covers the AIX and Linux-on-Power workloads (typically Oracle Database EE on Power Systems). The SPARC entries cover the legacy Solaris estate and the engineered systems that retain Solaris on SPARC.
The multiplier converts deployed cores into processor licences. The arithmetic is direct: a host carrying thirty-two cores of a 0.5-factor processor family reads at sixteen processor licences. The same host carrying thirty-two cores of a 1.0-factor processor family reads at thirty-two processor licences. The same host carrying thirty-two cores of a 0.75-factor processor family reads at twenty-four processor licences.
The commercial implication is that the chip choice carries a material licensing position. A workload that runs equally well on x86 or Power carries a doubled licence count on Power against x86. The chip choice is therefore a Total Cost of Ownership decision and not solely a performance decision.
The core factor applies to the deployed configuration at the date of deployment. Subsequent revisions to the table do not retroactively change the read for an established deployment. The buyer holding a deployed configuration at a published 0.5 factor is not exposed to a future revision that re-bands the family upward.
The procurement implication is that the buyer should record the published table at the date of any new deployment as part of the inventory documentation. The record sits inside the audit-quality inventory as a defensible position if a future revision changes the published number.
A new deployment on a chip family that does not yet appear on the published table reads against the default factor (typically 1.0). A buyer planning a deployment on a new family should request a publisher confirmation of the applicable factor before committing the architecture; the confirmation becomes part of the inventory record.
A processor-family migration changes the licence count under the same workload. The most common migrations in current procurement: Intel x86 to AMD x86 (no factor change, both 0.5); AMD x86 to ARM (a default factor read unless ARM appears on the published table at the date of deployment); IBM Power to x86 (a factor reduction from 1.0 to 0.5, halving the licence count); x86 to Power (a factor increase from 0.5 to 1.0, doubling the licence count).
The buyer-side methodology reads the migration as a licensing event. A reduction in the licence count creates a release of shelfware that the next renewal can absorb against a Schedule A repackaging; an increase creates a true-up exposure that the audit-quality inventory should flag in advance.
The Admodum methodology runs the chip-family read as part of every Oracle deployment audit. The output sits inside the audit-quality inventory and the licence-count reconciliation. The wider read sits in the LMS Audit Defence paper and the Oracle practice.
The buyer holds two positions against the core-factor table. The first is the published reference at the date of deployment, recorded inside the audit-quality inventory. The second is the contracted Schedule A, which records the processor licence count against the deployed configuration at the date of contract.
Where the two positions agree, the audit reading is the contracted count. Where they diverge (typically because the deployment has changed since contract date), the audit reading is the negotiated reconciliation. The Admodum methodology runs the reconciliation as a pre-audit exercise rather than as an audit response.
The wider editorial context sits in the Oracle licensing pillar. The engagement entry point sits in the Oracle practice. The aggregated reading list sits in the Oracle knowledge hub.
How the core-factor table is applied against the deployed estate.
When the NUP metric is the buyer’s friend, when it is not.
A senior Admodum Oracle advisor will read the core-factor table against your deployed estate on a private call. Active audits route to the Audit Defence programme.