Hyper threading is a common source of confusion in Oracle counting on x86 hardware. Intel and AMD processors expose two logical threads per physical core to the operating system. The operating system reports the thread count rather than the physical core count in many tools. The Oracle counting rule applies to physical cores rather than to logical threads. The misalignment between the reporting and the counting rule produces both over counting and under counting in buyer estimates. The audit position is consistent. The buyer position needs to be derived from the hardware specification rather than from the operating system report.
The Oracle counting rule.
The Oracle processor metric is defined in the customer agreement and is supplemented by the Oracle core factor table. The metric counts physical cores on the server hardware. The metric applies a multiplier from the core factor table to the physical core count. The resulting figure is the processor count for licence purposes.
The core factor table is published on the Oracle pricing site. The table lists processor families and assigns a multiplier to each family. The current multiplier for Intel Xeon and for AMD EPYC processors is zero point five. A server with sixteen physical cores from an Intel Xeon processor family requires eight processor licences under the metric. The figure does not change based on the hyper threading state of the operating system.
The hyper threading misalignment.
The misalignment between the reporting and the counting rule arises from the way operating systems present processor information. A modern Linux system reports the thread count as the CPU count in tools such as nproc and lscpu. A modern Windows system reports the thread count in Task Manager and in WMI queries. The thread count is twice the physical core count when hyper threading is enabled.
Buyers that build their licence position from the operating system report can over count by a factor of two. The over count results in unnecessary purchasing or in audit settlements that are higher than the contract position requires. The error is common in organisations where the procurement function is separated from the technical function and where the counting work is delegated to procurement without technical review.
The hardware specification as the source.
The reliable source of the physical core count is the hardware specification rather than the operating system report. The hardware specification is documented in the manufacturer datasheet for each processor model. The datasheet lists the physical core count and the thread count separately. The datasheet also identifies the processor family that maps to the core factor table.
Buyers should record the hardware specification for each Oracle server during the operational record keeping process. The record should include the server model, the processor model, the physical core count, the thread count, and the processor family. The record forms the basis of the counting work and supports the audit defence position. See the Named User Plus counting rules note for the parallel metric.
The audit position.
The Oracle audit position on hyper threading is consistent with the contract metric. The audit team counts physical cores rather than logical threads. The audit script that Oracle uses during a Licence Management Services engagement collects both the physical core count and the thread count and applies the core factor table to the physical core count.
The audit position is therefore aligned with the buyer counting position when the buyer counting position is derived from the hardware specification. The audit dispute arises when the buyer counting position is derived from the operating system report. The dispute is usually resolved by reference to the hardware specification once the disagreement surfaces. Buyers that have not done the hardware specification work should expect a delay in the audit process while the data is collected.
Virtualised environments.
The hyper threading question is more complex in virtualised environments. A virtual machine sees virtual CPUs that map to a combination of physical cores and logical threads on the host. The vCPU count reported inside the guest operating system is not a direct measure of either physical cores or threads on the host. The counting rule still applies to the physical cores on the host.
The buyer counting position in a virtualised environment is built from the host hardware specification rather than from the guest vCPU count. The hardware specification of the host is combined with the partitioning policy to determine the licence requirement. The partitioning policy is contested in soft partitioned environments such as VMware. See the Oracle on VMware soft partitioning note for the related question.
The core factor table evolution.
The Oracle core factor table is not a contract term. It is published guidance that Oracle has revised over time. The multipliers have changed for several processor families. The Intel Itanium multiplier has been one point zero throughout the table history. The Intel Xeon multiplier was one point zero on early generations and is currently zero point five. The AMD EPYC multiplier is currently zero point five.
Buyers should record the core factor table that applied on the date of the purchase rather than the current core factor table. Oracle can argue that the current table applies to the current count. The buyer position is that the table that applied at the time of the licence purchase is the contract reference. The argument is usually settled by negotiation rather than by litigation. The argument is most relevant on long lived perpetual licences where the table has changed multiple times since the original purchase.
Engaging an independent advisor.
The hyper threading question is a small part of a larger Oracle counting exercise. An independent advisor can build the full counting position across the Oracle estate including the physical core counts, the core factor table application, the partitioning policy treatment, and the Named User Plus counts where applicable. The full position is the foundation of any audit defence or renewal negotiation.
For the wider cluster see Licensing Compliance. For the service see Audit Defense. For the deal structure see Database licensing. For the Oracle product see Oracle Database. For the full research read the Oracle Negotiation Playbook.
A worked example.
A North American retailer was preparing for an Oracle renewal in 2024 and asked an independent advisor to validate the counting position. The buyer counting position was eighty four processor licences derived from the operating system report across the Oracle Database estate. The hardware specification review identified that the operating system report included the hyper thread count rather than the physical core count.
The corrected counting position was forty two processor licences. The buyer had purchased licences against the inflated count over a multi year period. The advisor recommended a settlement conversation with Oracle to recognise the over licensing in the renewal negotiation. The renewal closed with a credit of approximately one point two million dollars against the new term.
The standing record.
The hyper threading question is resolved at the operational level by the standing record of the hardware specification. Buyers should treat the hardware specification record as a standing requirement of Oracle estate management. The record should be maintained alongside the deployment record and the version record. The combined record forms the foundation of the counting work and supports the audit defence and the renewal negotiation. See the compliance posture note for the broader record keeping framework.