Oracle's database licensing rules are deliberately complex. The Processor metric, the Core Factor Table, Named User Plus minimums, virtualisation exceptions, and the ever-expanding options catalogue create a compliance minefield that Oracle's LMS team navigates with precision — while most enterprises fly blind. This guide explains every rule, every trap, and every legitimate defence.
Oracle Database can be licensed under two primary metrics: the Processor metric and the Named User Plus (NUP) metric. The choice between them is not optional in all situations — Oracle's rules constrain which metric applies, and getting it wrong is the most common source of back-licence claims in Oracle audits.
The Processor metric licenses the physical or virtual server environment based on the number of processor cores, adjusted by the Core Factor Table (discussed in Section 2). Every core running Oracle Database software must be licensed, regardless of how many users access it or how infrequently the database is used. This makes Processor metric particularly punishing for large-core-count servers running low-intensity workloads.
The Named User Plus metric licenses the number of named users or devices that access the database directly or indirectly. "Indirect access" is a key concept Oracle exploits in audits — if a web application, middleware layer, or third-party system connects to Oracle Database, every end-user of that upstream application may be considered a Named User, regardless of whether those users are even aware that Oracle exists in the stack.
Oracle imposes minimum NUP requirements: for Enterprise Edition, the minimum is 25 NUP per Processor (after Core Factor adjustment). If your user count is below this threshold, you must licence at the minimum. This catch prevents organisations from buying a single Processor licence and claiming one Named User.
| Metric | How It's Counted | Minimum | Best For |
|---|---|---|---|
| Processor | Cores × Core Factor | None | High-user-count workloads, external-facing apps |
| Named User Plus (NUP) | Named users + devices | 25 NUP per Processor | Low user count, internal systems, dev/test |
Audit Risk: Oracle's USMM script and LMS methodology specifically probe for indirect access relationships. A middleware tier, API gateway, or reporting tool that queries Oracle Database on behalf of hundreds of end-users creates a Named User Plus exposure that many IT teams have never quantified. Our Oracle Compliance Review service maps every access pathway before Oracle does.
The Core Factor Table is Oracle's mechanism for translating physical processor cores into licensable units. Not all cores are equal in Oracle's model. A 32-core Intel Xeon processor at a Core Factor of 0.5 yields 16 Processor licences. A 32-core SPARC T-series at a Core Factor of 0.25 yields just 8. An IBM POWER processor uses a factor of 1.0.
The practical consequence: organisations that have migrated from legacy RISC/SPARC hardware to modern Intel/AMD x86 environments will typically see their Oracle Processor licence requirements change significantly. Oracle publishes the Core Factor Table and updates it periodically — but the version in effect at the time of licence purchase versus the version at audit can create disputes.
| Processor Family | Core Factor | Example (32 cores) |
|---|---|---|
| Intel x86-64 / AMD x86-64 | 0.5 | 16 Processor licences |
| IBM POWER (non-SPARC) | 1.0 | 32 Processor licences |
| Sun/Oracle SPARC T-series | 0.25–0.5 | 8–16 Processor licences |
| Sun/Oracle SPARC S/M/T | 0.5 | 16 Processor licences |
| ARM (select) | 0.5 | 16 Processor licences |
The Core Factor Table applies only to physical hardware. In virtualised and cloud environments, different rules apply — Oracle's partitioning policy, discussed in Section 6, determines whether hard partitioning allows core count reduction or whether you must licence the entire physical host.
Our forensic estate mapping identifies exactly how many Processor licences your environment requires — before Oracle's LMS team does. We've identified over-licensing and under-licensing in equal measure.
Oracle offers three main on-premises Database editions with substantially different licensing rules, costs, and restrictions. Choosing the wrong edition — or inadvertently running workloads that breach edition restrictions — is a recurring audit finding.
Oracle Database Enterprise Edition (EE) is the full-featured edition. It is sold by the Processor or NUP metric, supports all add-on options (RAC, Partitioning, Advanced Security, Data Guard, In-Memory, Diagnostics Pack, etc.), and has no hard limit on processor count. EE is the edition Oracle's LMS audits focus on most heavily, because the available add-on options create significant incremental licence exposure.
Oracle Database Standard Edition 2 (SE2) was introduced in October 2015 as a replacement for SE and SE1. It carries important restrictions that Oracle customers frequently violate without knowing: SE2 is limited to servers with a maximum capacity of 16 CPU sockets, it is licensed per Named User Plus or by 2-socket server, and it cannot use any of the Enterprise Edition options (RAC in SE2 is replaced by Oracle Database Standard Edition High Availability, and even that is restricted to 2-node clusters). SE2 is substantially cheaper than EE, but running EE options or EE features on an SE2 licence is a direct compliance violation.
Oracle Database Express Edition (XE) is a free, limited edition: single CPU, 2GB RAM, 12GB user data. XE cannot be used for commercial production workloads beyond its restrictions, and its use in environments adjacent to licensed Oracle products is an area Oracle sometimes investigates during audits.
SE2 Trap: Oracle removed SE and SE1 from its price list in October 2015 but the installed base is vast. Customers running SE or SE1 licences can continue on existing installations but cannot add new deployments under those now-discontinued editions. Upgrading or expanding typically forces migration to SE2 or EE — with Oracle using the occasion to upsell. If you are in this situation, our contract negotiation team can protect your entitlement position.
Oracle Database Enterprise Edition is sold as a base product, but the features that most enterprises actually need — or inadvertently enable — are sold as separately licensed add-on options and management packs. This is one of Oracle's most effective revenue mechanisms, and one of the most dangerous for enterprise compliance.
The key risk: many Oracle Database options are feature-flagged within the database itself, and enabling a feature automatically starts consuming that option's licence — even if no one consciously decided to purchase it. Oracle's USMM and LMS diagnostic scripts detect feature usage data from the DBA_FEATURE_USAGE_STATISTICS view, which records every licensed feature that has ever been invoked.
Critical options that generate frequent audit findings include: Diagnostics Pack (required for AWR, ADDM, and ASH — tools that DBAs routinely use), Tuning Pack (required for SQL Tuning Advisor and Automatic Tuning), Partitioning (partitioned tables require this licence even if partitioning was used historically and is no longer active), Advanced Security (TDE, network encryption), Data Guard (standby databases, even for DR purposes), In-Memory Database, and RAC.
| Option / Pack | Key Feature Triggers | Typical Cost (per Processor) |
|---|---|---|
| Diagnostics Pack | AWR, ADDM, ASH reports | ~$7,500 |
| Tuning Pack | SQL Tuning Advisor, Auto Tuning | ~$5,000 |
| Partitioning | Any partitioned table/index (historical) | ~$11,500 |
| Advanced Security | TDE, network encryption | ~$15,000 |
| Real Application Clusters | Cluster database configuration | ~$23,000 |
| Data Guard | Physical/logical standby database | ~$11,500 |
| In-Memory | INMEMORY clause on any object | ~$23,000 |
Oracle Diagnostics Pack is accidentally enabled in over 40% of enterprise Oracle Database environments, according to our engagement data. The STATISTICS_LEVEL parameter at the database level, and the CONTROL_MANAGEMENT_PACK_ACCESS parameter, control whether these packs are active — but most DBA teams are unaware of the licensing implications of the default settings.
Oracle's LMS team identified $14M in alleged option exposure across a 200-database estate. We challenged the Diagnostics Pack findings (STATISTICS_LEVEL had never been changed to ALL, AWR data was system-level only), the Partitioning findings (historical usage with no current partitioned objects), and the Core Factor calculations. Settlement: $6M below Oracle's opening claim. Read the full case study →
Oracle Real Application Clusters (RAC) allows multiple database instances to run on separate server nodes while accessing the same database storage. It is Oracle's primary high-availability and scalability option for Enterprise Edition — and one of its most heavily licensed.
RAC is licensed as a separate add-on option at approximately $23,000 per Processor (plus 22% annual support). In a RAC cluster, every node running Oracle Database must be licensed for both the base database and the RAC option. A 4-node RAC cluster with 32 cores per node (16 Processors each at 0.5 Core Factor) requires 64 RAC Processor licences in addition to 64 Database EE Processor licences.
A common compliance gap: organisations implement RAC for high availability but license only the primary node. In an active-active RAC cluster, every participating instance must be fully licensed. In an active-passive configuration, Oracle's policy also requires the passive node to be licensed — there is no "warm standby" exemption for RAC.
For Standard Edition 2, Oracle Database SE High Availability (DSHA) replaced the former SE RAC. DSHA allows a 2-node failover cluster but does not permit active-active workload distribution. Customers running SE2 DSHA clusters are frequently caught using it in ways that technically require RAC and EE licences.
Many RAC environments are significantly over-licensed due to node-count expansion over time or legacy hardware decommissions that were never reflected in Oracle licence positions. Our License Optimisation service right-sizes RAC deployments and recovers shelfware.
Virtualisation creates the single biggest Oracle compliance trap in enterprise IT. Oracle's partitioning policy — which has not fundamentally changed since 2005 despite a vastly different technology landscape — determines when a customer can limit their Oracle Database licence count to a subset of physical cores.
Oracle recognises only hard partitioning as sufficient to limit core licensing. Hard partitioning technologies include: Oracle VM Server for x86, Oracle VM Server for SPARC (LDoms), IBM LPAR (if Oracle approves the specific configuration), and Solaris Zones (with restrictions). Hard partitioning means the Oracle software cannot physically access cores outside its assigned partition, regardless of any virtual layer above it.
Soft partitioning — which includes VMware vSphere, Microsoft Hyper-V, Citrix Hypervisor, AWS EC2, Azure VMs, GCP Compute, and virtually every other commonly used hypervisor and cloud platform — does not limit Oracle licence requirements. If Oracle Database runs in a VMware environment and the VMware cluster contains 200 cores, Oracle's position is that all 200 cores (adjusted by Core Factor) must be licensed, regardless of how many vCPUs are assigned to the Oracle VM.
This position is not universally accepted and has been challenged in contract negotiations. Oracle's partitioning policy is a unilateral document, not part of most licence agreements — which creates legitimate grounds for pushing back. However, absent explicit contractual language acknowledging soft partitioning, Oracle will assert the full host licence requirement in an audit.
In public cloud environments (AWS, Azure, GCP, OCI), Oracle's licensing rules diverge significantly. For AWS and Azure, Oracle has Authorized Cloud Environments policies that allow core counting at the virtual machine level under specific conditions. For OCI (Oracle Cloud Infrastructure), BYOL (Bring Your Own Licence) rules are more favourable and Oracle counts OCPUs at 1:2 against Processor licences. Our Cloud & OCI Advisory service navigates the full spectrum of cloud licensing complexity.
Based on over 500 Oracle licensing engagements, the following patterns generate the largest audit claims against enterprise Oracle Database environments:
LMS Audit Process: Oracle's LMS scripts collect DBA_FEATURE_USAGE_STATISTICS, hardware topology data, cluster configuration, and virtualisation layer information. The USMM tool generates a report Oracle uses to calculate the licence shortfall. You are under no obligation to run Oracle's scripts in your environment without independent review first. Our Audit Defence service manages this process end-to-end.
Oracle database licence compliance challenges are not binary. Oracle's audit claims are opening positions, not final determinations. Every element of an LMS claim is negotiable — the Core Factor interpretation, the feature usage attribution, the virtualisation host scope, the indirect access headcount, and the settlement structure. Enterprises that treat Oracle's initial claim as a bill to be paid are paying far more than necessary.
Effective defence strategy starts before Oracle arrives. A proactive compliance review identifies the gap between entitlement and deployment, quantifies the maximum audit exposure, and — critically — gives you time to remediate before Oracle's LMS team builds their claim. Remediating a compliance gap pre-audit is always cheaper than resolving it post-audit with Oracle's full commercial team engaged.
When Oracle does initiate an audit, your response posture matters. Oracle's LMS team is skilled at extracting more information than your contractual obligations require. Under most Oracle licence agreements, you have significant discretion over what data you provide and when. Independent advisors who have worked within Oracle's own LMS practice understand exactly where these boundaries are.
Post-claim negotiation leverages several pressure points: Oracle's desire to close the fiscal quarter, renewal timing, cloud migration commitments, and the cost and reputational risk Oracle faces from prolonged disputes. A well-prepared enterprise with independent expert support typically settles at 20–60% of Oracle's opening claim. Enterprises that engage Oracle's commercial team without preparation settle at or above the initial claim.
A comprehensive, 40-page technical white paper covering Core Factor calculations, option exposure quantification, virtualisation compliance scenarios, and the complete audit defence playbook. Written by former Oracle LMS consultants.
Download Free →Weekly insights on database licensing, audit defence, contract negotiation, and cost reduction. Free. Written by former Oracle insiders.
No spam. Unsubscribe anytime. Not affiliated with Oracle Corporation.
We identify the gaps before Oracle does. Our forensic compliance reviews have saved clients an average of $3.2M per engagement on database licensing alone.
✓ Confidential · ✓ Independent · ✓ Not affiliated with Oracle Corporation