Oracle ULA Deployment Counting: Processors & NUP Rules

Why Counting Methodology Determines Your Financial Outcome

The ULA certification count is not just an administrative exercise — it creates a permanent license baseline that determines your Oracle support expenditure for as long as you remain on Oracle support. A certified count of 1,000 Oracle Database Enterprise Edition Processor licenses creates an annual support obligation of approximately $1.5M–$2.5M depending on your contract discount. Every additional 100 processors adds $150K–$250K per year in perpetuity.

Oracle's LMS team applies counting rules that systematically maximize the certified count. Every ambiguous situation — a server in a VMware cluster, a cloud instance with fractional vCPUs, a DR environment with passive software — is resolved in Oracle's favor under the standard counting methodology. Understanding the rules in advance, deploying your estate accordingly, and challenging Oracle's count where it deviates from the correct methodology are the three levers that determine your certification outcome.

Our ULA advisory service has managed 40+ ULA certifications. The enterprises that achieved the lowest certified counts were those that modelled the counting methodology thoroughly before certification and made deliberate deployment and de-deployment decisions based on that model.

Processor Metric: How Oracle Counts Cores

The Processor metric is Oracle's default metric for Oracle Database Enterprise Edition licenses under a ULA. A "processor" in Oracle's licensing context is not a processor socket — it is defined as each core on every physical server where Oracle software is installed and running. The formula is: Total Cores × Core Factor = Processor Licenses Required.

The Processor metric applies per server. For each server where Oracle software is installed, Oracle counts all physical cores on all populated sockets, applies the relevant Core Factor from Oracle's published table, and rounds up to the nearest whole number. The counts from all servers in scope are then summed to produce the total certification count.

Partial sockets — servers with sockets that are populated but have some cores disabled — are counted based on the full core count of the populated socket, not the enabled cores only. Oracle does not permit "core pinning" as a way to reduce the counted cores on a physical server. A 16-core processor installed in a server counts as 16 cores even if the operating system is only using 8.

For servers running Oracle software across multiple sockets of different processor types, Oracle applies the Core Factor for each processor separately and sums the results. Mixed-processor servers are unusual in production environments but do appear in some enterprise configurations.

The detailed Core Factor values for every current Oracle-certified processor are published in the Oracle Core Factor Table. The table is updated periodically and Oracle applies the version current at the time of certification, not at the time of deployment.

Core Factor Table: Key Values and Application

The Core Factor Table is Oracle's mechanism for adjusting processor license counts to reflect the relative compute power of different processor architectures. Processors with lower factors were historically considered to have less relative computing power per core than Intel x86 architecture. The factors have not kept pace with actual processor capability evolution, which means some server architectures are significantly undervalued under current Core Factor rules.

Intel x86-64 at 0.5 Core Factor is by far the most common configuration in enterprise environments. A 32-core Intel server counts as 16 Processor licenses. A 128-core Intel server — not uncommon in modern high-density configurations — counts as 64 Processor licenses. At Oracle Database Enterprise Edition list price of approximately $47,500 per Processor license, a single 128-core server generates $3.04M in license value at list price.

IBM Power processors at a 1.0 Core Factor mean every core counts as a full Processor license. IBM Power servers with high core counts can generate extremely large certified counts despite Oracle's counting rules ostensibly being in license units, not physical cores. Enterprises on IBM Power hardware approaching ULA certification should model their certified count specifically, as the results frequently surprise IT teams that are thinking in terms of physical core utilization rather than Oracle's counting methodology.

Named User Plus Counting Rules

Named User Plus (NUP) counts individual users authorized to access Oracle software, with a minimum per-processor floor. Under Oracle Database EE, the NUP minimum is 25 users per Processor license (calculated using the Processor formula above as the floor). The certified NUP count is whichever is higher: the actual authorized user count, or 25 × the Processor count.

An authorized user under NUP is any individual permitted to use the Oracle software — whether or not they actually do. This includes: named employees who have database access in their system profile, system accounts used by applications that access Oracle, service accounts, and any individual whose credentials could theoretically be used to access Oracle. Oracle's interpretation of "authorized" is expansive and includes potential access, not just active use.

The categories where NUP counting disputes arise most frequently are: service accounts used by middleware applications (Oracle says each represents a user), batch jobs running under shared accounts (Oracle may count each as a separate authorized user), and application users who access Oracle indirectly through an ERP or CRM system (Oracle may argue each constitutes an authorized user of the underlying database).

For enterprises with large server footprints but concentrated user bases — such as financial services firms running high-frequency trading platforms or manufacturing companies with automated production systems — NUP can produce a certified count significantly lower than the Processor metric. The metric selection must be modelled before the ULA is signed. See our detailed comparison of NUP vs Processor metric for the full framework.

Virtualisation & VMware Counting: The Biggest Certification Risk

Oracle does not support or endorse the concept of "limiting" Oracle software to specific virtual machines within a VMware cluster for licensing purposes. Oracle's policy is that when Oracle software is deployed anywhere within a VMware cluster, the license requirement is based on all physical processors in the entire cluster — not just the processors in the VM(s) running Oracle.

This policy is the single biggest source of unexpected certification exposure for enterprise ULA customers. An organization may believe it is running Oracle on 4 VM cores within a 1,000-core VMware cluster. Under Oracle's policy, it requires licenses for all 1,000 cores (at the applicable Core Factor). The entire cluster is the license unit, not the VM.

There is a valid exception to the full-cluster counting rule: if Oracle software is deployed within a VMware cluster that has been configured with Oracle-specific Hard Partitioning using VM lockdown mode (a specific VMware configuration that prevents Oracle VMs from being vMotioned off designated hosts), Oracle may accept counting only the processors on the locked hosts. This is an extremely specific configuration and must be maintained continuously — any vMotion event that moves an Oracle VM to an unlicensed host triggers a licensing requirement for the entire cluster.

The practical advice: in ULA contexts, the full cluster count is the certified count unless you have maintained Oracle-approved Hard Partitioning throughout the term. Most enterprises running VMware have not, and Oracle's LMS team knows this. Our detailed VMware licensing guide covers the Hard Partitioning configuration requirements precisely.

Cloud Deployment Counting for ULA Certification

Oracle's counting methodology for cloud environments depends on the cloud provider and the type of instance. For Oracle Cloud Infrastructure (OCI), Oracle uses OCPU-based counting which may produce a lower count than the equivalent on-premise deployment. For AWS, Azure, and GCP, Oracle's standard Processor metric applies at the virtual CPU level using Core Factors from the published table.

For AWS, Azure, and GCP instances, Oracle treats each vCPU as equivalent to a core for counting purposes. A virtual machine with 32 vCPUs in AWS running Oracle requires 32 × 0.5 = 16 Processor licenses under Oracle's standard counting rules. There is no reduction for the fact that vCPUs are not equivalent to physical cores in terms of computing power — Oracle's policy does not distinguish.

For OCI specifically, Oracle uses the OCPU metric: 1 OCPU = 2 vCPUs for counting purposes. An OCI instance with 16 OCPUs running Oracle requires 8 Processor licenses (16 OCPUs × 0.5 Intel Core Factor). This makes OCI licensing systematically more favorable than equivalent deployments in other clouds, which is by design — Oracle uses the licensing model to incentivise OCI adoption.

ULA contracts that pre-date 2019 typically contain no explicit cloud deployment rights. Oracle will apply its standard cloud counting policy to all cloud instances found during certification regardless of when the ULA was signed. Enterprises with significant cloud deployments in a pre-cloud ULA should seek specific contractual clarity before certification begins. See our Oracle cloud licensing guide for the complete cloud counting framework.

Choosing the Right Metric: Modelling Before You Sign

The metric decision — Processor or NUP — must be made when the ULA is signed and cannot be changed at certification without renegotiation. The right metric depends on your specific deployment profile: server count and core density relative to user count. There is no universally correct answer — it requires a forward-looking model of your estate over the ULA term and at the point of certification.

Enterprises for whom Processor metric typically produces a lower certified count: organizations with dense server environments but small active user bases, financial services firms with automated trading systems, manufacturing companies with machine-to-machine database connections, and organizations planning significant server footprint reduction before certification.

Enterprises for whom NUP metric typically produces a lower certified count: high user-count environments with relatively modest server footprints, retail and consumer-facing businesses with large authorized user populations, healthcare organizations with high staff-to-server ratios, and organizations with very high core-count servers but limited user access patterns.

The modelling exercise requires a current inventory of your server estate (core counts, Core Factor values) plus a count of authorized users per system. Running both calculations and projecting forward over the expected ULA deployment trajectory will identify which metric minimises your certification exposure. This exercise should be performed before ULA negotiation — not after the contract is signed — because changing the metric once signed requires Oracle's agreement and typically costs additional license fees. Our compliance review service includes metric modelling as a standard deliverable.