Oracle Licence Minimums and Counting Rules in 2026: The Complete Enterprise Guide to NUP Minimums, Processor Counting, Core Factors, Multiplexing, and Virtualisation

Named User Plus (NUP) is Oracle’s per-user licensing metric. Each distinct individual (or device) authorised to access Oracle software requires one NUP licence. However, Oracle imposes a minimum NUP count per processor that applies regardless of how many users actually access the system. This minimum is the single most common source of Oracle audit findings.

1. The Core Rule — 25 NUP Per Processor (Enterprise Edition):

For Oracle Database Enterprise Edition — the most widely deployed Oracle product — the minimum is 25 Named User Plus licences per processor. The ‘processor’ here means the number of processor licences calculated using Oracle’s core factor table (covered in Section 3). This minimum applies per server where Oracle Database EE is installed. If the server has 2 processor licences (after core factor), you need at minimum 50 NUP. If it has 4 processor licences, you need at minimum 100 NUP. The actual number of users is irrelevant if it is below the minimum.

2. Worked Examples:

3. NUP Minimums by Product Category:

4. Why NUP Minimums Create Audit Findings:

Organisations typically count licences based on who actually uses Oracle. The IT team reports ‘we have 15 users on this database,’ procurement purchases 15 NUP licences, and everyone assumes compliance. During an audit, Oracle counts the processors, applies the core factor, and multiplies by 25 — revealing a shortfall of 185 licences (200 minimum minus 15 owned). At Oracle’s list price of $350 per NUP for Database EE, that’s a $64,750 shortfall on a single server. Across 10 servers, the finding can exceed $500K.

Processor-based licensing counts the server’s CPU capacity rather than individual users. It is Oracle’s preferred metric for production database and middleware deployments. The number of processor licences required is determined by the number of physical cores multiplied by Oracle’s core factor for that processor type.

1. The Core Factor Table:

Oracle publishes a Core Factor Table that assigns a multiplier to each processor type. The core factor determines how many physical cores equal one Oracle processor licence. The most common core factors in enterprise environments are:

2. The Calculation Process (4 Steps):

3. Critical Counting Rules:

All physical cores count: Oracle requires licensing of all physical cores in the server where Oracle software is installed, not just the cores ‘assigned’ to Oracle. Hyperthreading / SMT threads do not count as cores — Oracle counts physical cores only. If Oracle is installed on a server, all cores in that server must be licensed (unless hard partitioning limits the scope). Powered-off cores on an active server still count. If Oracle is installed anywhere on the server, every core is licensable.

Round up always: If the core factor calculation produces a fractional result (e.g., 5 cores × 0.5 = 2.5), always round up to the next whole number (3 processor licences). Oracle does not accept rounding down.

Cluster licensing: In clustered environments (RAC, failover), all nodes in the cluster that Oracle can run on must be licensed. If you have a 3-node RAC cluster, all cores across all 3 nodes require processor licences.

Oracle Standard Edition products use a different minimum model than Enterprise Edition. Instead of NUP-per-processor minimums, Standard Edition enforces per-environment (per-installation) minimums and hardware limitations that are frequently misunderstood.

1. Oracle Database Standard Edition 2 (SE2) Rules:

SE2 is Oracle’s entry-level database product, designed for smaller deployments. Its licensing is simpler than Enterprise Edition but carries its own restrictions:

2. Per-Environment vs Per-Processor Comparison:

3. Tools and Utility Minimums:

Some Oracle tools, utilities, and smaller products also enforce environment-based minimums. These are defined in the individual product’s ordering documents and may specify minimum NUP counts per installation, minimum processor counts, or minimum deployment configurations. Always verify the ordering document for any Oracle product before deployment to ensure the minimum requirements are met.

Beyond the standard NUP-per-processor and environment minimums, many Oracle products have unique minimum requirements defined in their ordering documents. These product-specific minimums are the most frequently overlooked aspect of Oracle licensing — and a reliable source of audit findings because they are not always intuitive from the product’s usage perspective.

1. Oracle E-Business Suite (EBS):

EBS licensing is module-based, with each module requiring a specific number of user licences. Minimums apply per module, and the user categories (Professional, Self-Service, Employee) each have different minimum counts. Common audit findings include licensing Self-Service users but not counting the Professional users required by certain modules, and overlooking module dependencies that trigger additional licence requirements.

2. Oracle Middleware:

Oracle’s middleware products (WebLogic, SOA Suite, Service Bus, Integration products) have their own NUP per-processor minimums that are typically lower than Database EE (often 10 NUP per processor rather than 25) but still override actual user counts. Additionally, middleware products often have role-based licence categories (e.g., administrators, developers, end users) with different counting rules for each role.

3. Oracle BI and Analytics:

Oracle’s Business Intelligence products (OBIEE, Oracle Analytics) require named user licences for anyone who accesses metadata, creates reports, or views dashboards. The minimum NUP requirements apply regardless of how the BI tool is accessed — including through web browsers, mobile apps, or embedded analytics in other applications.

Multiplexing is the use of hardware, software, or any device that pools connections, reroutes information, or reduces the number of users that directly access Oracle software. Oracle’s licensing policy is absolute on this point: multiplexing does not reduce the number of licences required. Every distinct end user or device that accesses Oracle — even indirectly through middleware, web applications, APIs, or service accounts — must be counted.

1. How Multiplexing Works (and Why It Creates Compliance Risk):

In modern enterprise architectures, users rarely connect directly to Oracle databases. They access Oracle through web applications (browsers → app server → database), through middleware (message queues, ESBs, integration platforms), through APIs (REST/SOAP calls from other systems), or through service accounts (batch processes, automated workflows, IoT devices). Each of these intermediary layers acts as a multiplexer — it consolidates many users into fewer database connections. A web application might serve 10,000 users but connect to Oracle through a single connection pool of 50 connections. Oracle’s position: all 10,000 users must be licensed, not just the 50 connections.

2. Common Multiplexing Scenarios and Their Licence Impact:

3. The Processor Licence Alternative:

When multiplexing makes NUP counting impractical or prohibitively expensive (because the number of indirect users is very large), processor licensing may be more cost-effective. Processor licensing counts only the server’s CPU capacity — it does not require counting individual users. For a web-facing application with 50,000 users accessing Oracle through a web portal, processor licensing on a 16-core server (8 processor licences at 0.5 core factor) may cost $376,000 (8 × $47,500 list), while NUP licensing would cost $17.5M (50,000 × $350 list). This is why many organisations choose processor licensing for high-multiplexing scenarios.

Virtualisation is the single most financially impactful area of Oracle licensing. Oracle’s position on virtualisation has created more audit findings — and larger compliance claims — than any other counting rule. The core issue: Oracle treats most virtualisation technologies as ‘soft partitioning’ and requires licensing of all physical cores across the entire cluster or host pool, not just the cores allocated to the Oracle VM.

1. Soft Partitioning vs Hard Partitioning:

2. The VMware Cluster Problem — Why a Single Oracle VM Can Require 100+ Processor Licences:

Consider a typical enterprise VMware environment: an 8-host vSphere cluster, each host with 2 sockets of 16-core Intel Xeon processors. Total physical cores across the cluster: 8 × 32 = 256 cores. If Oracle Database Enterprise Edition runs in a single VM with 4 vCPUs on one host, the organisation’s expectation is to license 4 vCPUs (2 processor licences at 0.5 core factor). Oracle’s position: because VMware is soft partitioning and VMs can move between hosts via vMotion, all 256 cores across all 8 hosts must be licensed: 256 × 0.5 = 128 processor licences.

3. Cloud BYOL Counting:

In cloud environments (OCI, AWS, Azure), Oracle’s Bring Your Own Licence (BYOL) rules typically count 2 vCPUs as 1 processor licence for standard compute (and 1 vCPU = 1 processor licence for some high-performance instances). The NUP per-processor minimums still apply in cloud environments. A cloud instance with 8 vCPUs under BYOL requires 4 processor licences, and if using NUP, at minimum 100 NUP (4 × 25). Organisations moving to cloud must recalculate their licence requirements using the cloud-specific counting rules.

Oracle audit findings related to minimums and counting rules are almost entirely preventable. They occur because organisations do not have systematic processes for applying Oracle’s rules at the point of deployment and change. The compliance framework below embeds Oracle’s counting rules into operational processes so that licence requirements are calculated correctly from the start.

1. The 5 Compliance Pillars:

2. Hardware Change Trigger Protocol:

Every hardware change must trigger an immediate licence recalculation. This includes adding or upgrading processors (more cores = more processor licences and higher NUP minimums), adding hosts to a VMware cluster (expands soft partitioning scope), migrating Oracle workloads to new servers, provisioning new cloud instances with Oracle BYOL, and changing virtualisation configuration (e.g., enabling vMotion across additional hosts). The protocol: no hardware change affecting Oracle environments is completed without a licence impact assessment signed off by the SAM team.

3. Multiplexing Audit Checklist:

For every Oracle database, answer these questions: What applications access this database? For each application, how do users connect (direct, web, API, batch)? For each connection path, how many distinct end users or devices exist? Are any of these paths multiplexed (many users through few connections)? Have all upstream users been counted in the NUP total? If the NUP count exceeds the processor-licence equivalent cost, should we switch to processor licensing?

This section walks through a realistic example that combines all counting rules: NUP minimums, processor counting, core factors, multiplexing, and virtualisation. Understanding how these rules interact in practice is essential for accurate licence management.

Scenario: A mid-size enterprise runs Oracle Database Enterprise Edition with Partitioning and Diagnostics Pack options on the following infrastructure:

Step 1 — Determine Processor Licence Count (Virtualisation Impact):

VMware is soft partitioning. Oracle requires licensing all physical cores across all 4 hosts: 4 hosts × 32 cores = 128 cores. Core factor for Intel Xeon = 0.5. Processor licences required: 128 × 0.5 = 64 processor licences. (Note: the organisation expected to license only the 16 vCPUs = 8 processor licences.)

Step 2 — Count All Users (Multiplexing Impact):

Web portal users: 5,000 (all count — multiplexing does not reduce). Direct users: 30 DBAs/developers. Service accounts: 15. Total NUP count: 5,045.

Step 3 — Apply NUP Minimum:

NUP minimum = 25 per processor × 64 processors = 1,600 NUP minimum. Actual users (5,045) exceed minimum (1,600), so actual count applies: 5,045 NUP required.

Step 4 — Calculate Licence Cost (NUP vs Processor):

In this scenario, processor licensing ($4.27M) is $1.03M cheaper than NUP ($5.30M) because the multiplexing effect (5,000 web users) inflates the NUP count far beyond the per-processor minimum. However, the real cost driver is virtualisation: without the VMware cluster expansion, the organisation would need only 8 processor licences (not 64), reducing the processor cost to approximately $533K. The $3.7M difference is entirely attributable to Oracle’s soft partitioning policy.

Organisations that embed Oracle’s counting rules into operational processes — rather than applying them only at audit time — consistently achieve zero or near-zero audit findings. The cost of proactive compliance management is a fraction of the cost of remediation during an Oracle audit, where Oracle controls the timeline, the methodology, and the negotiation leverage.

For enterprises managing complex Oracle environments, Redress Compliance provides independent advisory with deep expertise in Oracle’s licence minimums, counting rules, core factor calculations, virtualisation licensing, multiplexing analysis, and the audit defence strategies that protect customers from Oracle’s compliance claims.