Getting Oracle licensing calculations wrong in either direction is costly — under-licensing creates audit exposure, over-licensing means paying for capacity you don't need. This guide walks through Oracle's licensing metrics, core factor calculations, virtualisation rules, and the full methodology for producing an accurate Oracle licence count.
Oracle uses three primary licensing metrics: the Processor metric, the Named User Plus metric, and — for Java SE since 2023 — an Employee metric. Understanding which metric applies to which product and deployment scenario is the first step in calculating Oracle licence requirements. Errors at this stage propagate through the entire calculation and can result in significantly incorrect licence counts in either direction.
The Processor metric is Oracle's preferred metric for technology products (Database, Middleware, Java). It is mandatory for applications providing access to an indeterminate or large number of users, and for internet-facing applications. It is calculated based on the number of processor cores running Oracle software, multiplied by a Core Factor determined by the processor architecture.
The Named User Plus (NUP) metric is an alternative to the Processor metric for closed-user applications with a defined, limited user population. NUP counts each person who accesses Oracle software — whether directly or through a multiplexed application layer — as one Named User Plus. Minimum NUP counts per Processor apply (typically 25 NUP per Processor for Database Enterprise Edition).
The Employee metric applies specifically to Oracle Java SE since January 2023. It requires licensing based on the total number of employees in the organisation, regardless of how many actually use Java. This is covered in detail below and in our Oracle Java licensing 2026 guide. For all product-specific licensing questions, see our Oracle Database licensing guide and our broader Oracle license negotiation pillar guide.
The Processor metric is the most commonly used and most frequently miscalculated Oracle licensing metric. The correct calculation follows a specific methodology that differs from simply counting servers or sockets.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Several common errors occur in Processor metric calculations. First, counting threads or logical CPUs rather than physical cores — Oracle licensing is based on physical cores, not hyperthreaded logical processors. A dual-socket server with 16-core Intel Xeons presenting 64 logical CPUs (with hyperthreading) requires 32 physical core × 0.5 = 16 Processor licences, not 64 or 32.
Second, applying core factors incorrectly for mixed-architecture environments. Organisations running Oracle on both Intel/AMD servers (core factor 0.5) and IBM POWER servers (core factor 1.0) must calculate each architecture separately. A single blended calculation will produce an incorrect result.
Third, failing to include all servers where Oracle software runs — including development, test, QA, and staging environments. Oracle's licence definitions require coverage of all instances where the software is "installed and/or running." The only exception is software covered by an Oracle Technology Network (OTN) Developer Licence, which restricts use to non-production development and testing purposes only.
Oracle's Core Factor Table assigns a multiplier to each processor architecture. The table below covers the most common architectures encountered in enterprise environments. Oracle's Core Factor Table is published on Oracle's website and should be consulted for the current version, particularly for newer processor architectures.
| Processor Type | Core Factor |
|---|---|
| Intel x86 (all models) | 0.5 |
| AMD x86 (all models) | 0.5 |
| ARM (AArch64, all models) | 0.5 |
| IBM POWER 6 | 1.0 |
| IBM POWER 7 | 0.75 |
| IBM POWER 8, 9, 10 | 1.0 |
| Oracle SPARC T4, T5, T7, T8 | 0.5 |
| Oracle SPARC M7, M8 | 0.5 |
| Oracle SPARC S7 | 0.5 |
| Oracle SPARC M10 (Fujitsu) | 0.5 |
| HP Integrity / Intel Itanium | 0.5 |
Oracle's Core Factor Table is updated periodically. Always verify the current core factor for your specific processor model on Oracle's official Core Factor Table document. For newer processor generations, confirm whether Oracle has published an explicit core factor or whether the general architecture factor applies.
The NUP metric counts the number of individuals authorised to access Oracle software — not concurrent users, not active users, but all individuals who have been authorised access. This includes employees, contractors, and any other individuals whose credentials could be used to access the Oracle system.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
NUP licensing requires compliance with minimum counts per Processor: 25 NUP per Processor for Oracle Database Enterprise Edition; 5 NUP per Processor for Oracle Database Standard Edition 2; 10 NUP per Processor for most Oracle Middleware products. These minimums exist because Oracle requires that NUP not be used as a cost-reduction mechanism relative to Processor licensing for applications with many users.
NUP is generally only cost-effective when the actual user count is less than the minimum threshold — meaning when there are fewer than 25 users per Processor for Oracle Database EE. For applications with more users than this minimum, the Processor metric is typically more economical and is often mandatory anyway for applications with internet or indeterminate access populations.
Virtualisation is the most contentious area of Oracle licence calculation. Oracle's partitioning policy distinguishes between "hard partitioning" technologies (which Oracle accepts as limiting deployment scope) and "soft partitioning" technologies (which Oracle does not accept as licensing boundaries).
Hard partitioning technologies allow an organisation to license only the physical resources allocated to Oracle's partition, rather than the entire physical host. Oracle accepts the following as hard partitioning: physical host isolation (dedicated physical servers), Oracle VM Server for x86 (OVM) with pinned vCPUs, Oracle Solaris Zones (with pinned CPUs), Oracle SPARC LDOMs, IBM LPAR (with appropriate configuration), HP Integrity Virtual Machines, and Oracle Cloud Infrastructure (OCI) VM instances.
For soft partitioning technologies, Oracle requires licensing of all physical processor cores on all hosts in the server cluster where Oracle software is deployed — regardless of which physical hosts the Oracle VMs currently reside on or are configured to run on. Technologies Oracle treats as soft partitioning include: VMware vSphere/ESXi (all versions), Microsoft Hyper-V, KVM (all distributions), Xen (except OVM), Docker and Kubernetes containers on non-hard-partitioned hosts, and AWS, Azure, and GCP shared infrastructure.
Oracle's VMware policy is not universally agreed to be legally enforceable, and specialist advisors can sometimes build defensible alternative positions — particularly where Oracle VM mobility has been demonstrably restricted. However, in an Oracle LMS audit, Oracle's starting position will always be the full-cluster calculation. For more detail, see our compliance checklist on Oracle license compliance.
Oracle Database options and management packs require separate licences in addition to the base Oracle Database licence. Each option must be licensed at the same metric (Processor or NUP) and same count as the underlying Oracle Database EE deployment. You cannot license options at a different count from the Database — if you have 16 Processor licences for Oracle Database EE on a server, any option deployed on that server requires 16 Processor licences of that option.
The key Database options to check in your licence calculation are: Partitioning (required when using table/index partitioning), Advanced Compression (required for OLTP or data compression), Real Application Clusters (required for multi-node RAC clusters), Active Data Guard (required when a standby database is open for reads), Advanced Security (required for Transparent Data Encryption or Data Masking), Diagnostics Pack (required for AWR, ASH, ADDM usage), Tuning Pack (required for SQL Tuning Advisor and automatic SQL tuning), Database Vault, Label Security, and Spatial and Graph.
Database options are frequently enabled automatically by Oracle Database — particularly in development environments where DBAs enable features during testing and forget to disable them, or where Oracle's automatic tuning features activate options without explicit administrator intervention. The Oracle compliance checklist covers how to audit enabled options systematically.
Oracle's January 2023 change to Java SE licensing introduced an Employee-based metric that fundamentally changed how Java SE must be calculated. Under the new model, the licence count is based on the total number of employees in the organisation — not the number of servers running Java, not the number of users accessing Java applications.
The critical step before accepting this calculation is assessing whether Oracle JDK can be replaced with a certified OpenJDK distribution (Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK) for some or all Java workloads. For organisations where this migration is feasible, it can eliminate Oracle Java SE subscription exposure entirely. See our Oracle Java licensing 2026 guide for a complete analysis.
Oracle Middleware products — principally WebLogic Server, SOA Suite, and Oracle Fusion Middleware — are licensed using the Processor metric following the same core factor rules as Oracle Database. The key Middleware-specific calculation issue is the application server processor count: the relevant processors are those running the Middleware application server, not those running the clients connecting to it.
For WebLogic Server, the Processor count covers all managed servers and admin servers in the WebLogic domain — including those in cluster configurations. WebLogic clustering typically requires WebLogic Enterprise Edition, which permits unlimited managed servers in a domain. Standard Edition limits the domain to a single managed server plus admin server.
A complete Oracle licence calculation follows this structured process: first, produce a full inventory of all Oracle software deployed across all environments (production, development, test, QA, disaster recovery, and cloud). Second, for each deployment, identify the applicable licensing metric (Processor or NUP). Third, for Processor-metric deployments, collect the physical server specifications: processor model, socket count, and cores per processor. Fourth, identify the virtualisation environment for each deployment and apply the appropriate calculation rule. Fifth, enumerate all Database options enabled on each Oracle Database instance. Sixth, apply core factors and calculate the licence count for each product and option. Seventh, compare the calculated requirement against your current licence entitlement.
This process, done accurately, produces an independent licence position — a document that identifies both compliance gaps and surplus licences. For organisations approaching an Oracle renewal or facing an audit, this independent position is the foundation of an effective commercial negotiation. Specialist advisors with Oracle LMS experience and appropriate tooling can conduct this assessment more efficiently and with greater precision than internal teams. For guidance on selecting the right advisor, see our Oracle negotiation firm rankings.
Need an accurate Oracle licence count? Specialist advisors reduce calculation risk and audit exposure.
For more context on how licence calculations feed into Oracle commercial negotiations, see our Oracle license negotiation pillar guide. For the compliance implications of licence calculation errors, see our Oracle compliance checklist. For ULA certification — which requires an accurate deployment count at expiry — see the Oracle ULA exit strategy guide. Download our free Oracle licensing guide for a comprehensive reference on all Oracle licensing rules.
Accurate Oracle licence calculations require specialist knowledge of Oracle's rules and current audit interpretation. Independent advisors deliver precise licence positions that withstand Oracle LMS scrutiny.