Common Oracle License Metrics
Oracle software licenses are sold under various metrics – essentially, the ways Oracle measures usage for licensing purposes.
The most common metrics for Oracle database and middleware products are Named User Plus (NUP) and Processor licenses.
Additionally, Oracle uses a Core Factor concept to adjust processor licensing based on hardware. Understanding how these metrics work is essential for proper compliance and cost optimization.
Read more about Oracle Licensing Glossary and terms.
Below, we explain each in simple terms and provide examples:
- Named User Plus (NUP): This metric licenses a product based on the number of distinct users (or devices) that have access to the software. “Named User Plus” means that each human user and any device operated by humans count toward the total. Oracle requires a minimum number of NUP licenses per processor to ensure a base level of licensing. For example, Oracle Database Enterprise Edition requires at least 25 Named User Plus licenses for each processor (as defined by Oracle’s processor definition) that the database runs on. If you have fewer than 25 users, you still need to license at least 25 per processor. NUP licensing is ideal for environments where the user count is relatively small and known, such as an internal application used by 40 employees, which could be licensed with Named User Plus. However, if user counts grow or are uncertain (e.g., public-facing systems or large enterprises), NUP can become complex to track and may require many licenses.
- Processor License: This metric licenses the software based on the processing power of the machines running it, regardless of the number of users. It’s often used for server-side products, such as database or application servers, that support multiple users. Oracle defines a “processor” not simply as a physical CPU chip, but in terms of cores and a Core Factor table. The formula is usually: Processor licenses required = (Number of processor cores) × (Core Factor) for the specific hardware. The Core Factor is a multiplier that Oracle assigns based on CPU architecture, intended to account for performance differences. For example, most modern x86_64 CPUs have a core factor of 0.5. So, a server with eight cores of an Intel processor would count as 8 × 0.5 = 4 Oracle Processors, meaning you need four processor licenses for that server. Under the Processor metric, it doesn’t matter whether you have 10 users or 10,000 users accessing the system – the licensing cost is tied to the hardware capacity. This makes processor licensing suitable for high-volume systems or when the number of users is unknown or very large, such as on a public website or an enterprise-wide deployment.
- Oracle Core Factor: The Core Factor is essentially a weighting system that Oracle uses to calculate processor licenses. Oracle publishes a Core Factor table that lists different CPU types and a factor for each. The goal is to level the playing field for performance – for instance, a high-end processor might have a lower factor, requiring fewer licenses per core, whereas all cores on certain architectures count fully. As noted, common Intel and AMD chips typically have a 0.5 factor. Some other processors, especially older or very high-performance ones, may have a factor of 1.0, meaning one license per core. In practice, you usually don’t buy “Core Factor” licenses separately; instead, you apply the core factor to your hardware core count to determine how many Processor licenses you need. Always consult the latest Oracle Core Factor table when doing these calculations, as hardware innovations can change the factors over time.
Comparison of Metrics: Each metric has its use cases and pitfalls. Below is a brief comparison:
| Metric | How It’s Measured | When to Use | Example Calculation |
|---|---|---|---|
| Named User Plus (NUP) | Per named individual or device with access. Requires a minimum number of users per processor (e.g. 25 per proc for Enterprise Edition database). | Best for controlled user bases that are relatively small or capped. Useful when you know exactly how many users will access the system and that number is lower than the threshold where processor licensing is more economical. | Example: You have an application server with the equivalent of 2 Oracle processors. Oracle’s minimum is 25 NUP per processor, so even if you only have 30 actual users, you must procure 50 NUP licenses. If you had 40 users on that server, you’d still need 50 NUP (because of the minimum). If you had 100 users, you’d need 100 NUP (now above the minimum). |
| Processor | Per processor (after accounting for cores via Core Factor). Unlimited users can access. You count hardware, not people. | Best for large or unpredictable user counts. Often used for server software exposed to many users or the internet. Also suitable when administrative overhead of tracking named users is too high. | Example: You deploy Oracle Database on a 16-core server. The CPU type has a core factor of 0.5. Calculation: 16 × 0.5 = 8 processor licenses required. Whether 10 or 10,000 users use this database, you still just need 8 licenses. If later you upgrade to a 32-core server of the same type, you’d need 32 × 0.5 = 16 licenses. |
Risks of Incorrect Metric Usage: It’s important to choose the correct metric when acquiring licenses and to count properly:
- If you undershoot user counts with NUP (for example, licensing only 50 users but 80 people in your organization have access), you would be out of compliance – a common audit finding.
- Conversely, using Processor licenses when you have a very small user population could lead to overspending. For instance, a development environment with five users on an 8-core server could be licensed with 5 NUP (if minimums allow) instead of 4 processor licenses – the cost difference can be significant.
- The core factor adds another layer of complexity. Companies sometimes miscalculate required licenses by forgetting to apply the core factor or by using the wrong factor. Always verify the core factor for your exact hardware model. A mistake here could mean you either bought too few licenses (compliance risk) or too many (wasted budget).
Illustrative Scenario: A midsize enterprise is deploying Oracle Database on two servers. Server A has two processors, each with eight cores (Intel), and is used by an internal HR team of 50 users. Server B has four processors, each with 16 cores, hosting a public web application. For Server A, the company considers NUP licensing, with a minimum of 25 NUP per processor, which equals a total of 50 NUP.
This matches their 50 users, so NUP works perfectly (and is cheaper than licensing all cores). For Server B, which has a high-core count and an unknown number of external users, they choose Processor licensing. Each of the 4×16=64 cores is a 0.5 factor, so that’s 32 processor licenses needed.
Trying to use NUP on Server B would be impractical (and likely non-compliant) because thousands of web users would technically require thousands of NUP licenses.
By mixing metrics appropriately, the enterprise stays compliant and optimizes cost. They document these calculations to justify their licensing choice, which is useful if Oracle ever asks for or audits them.
Read about Oracle Support and Maintenance Terms.
Recommendations (License Metrics):
- Match Metrics to Usage: Evaluate your environment to determine whether to use NUP or Processor. As a rule of thumb, if the number of users is low and known, NUP can save money. If the number of users is high or unknown, go with Processor. Always respect Oracle’s user minimums per processor for NUP.
- Calculate Carefully: Perform thorough calculations of cores and apply the Core Factor correctly for each physical server or virtual environment. Keep a spreadsheet or record of how you arrived at the number of licenses required. Double-check against Oracle’s official core factor table and licensing rules.
- Review Periodically: As your infrastructure changes, re-evaluate your licensing metrics. For example, virtualization or cloud moves can affect how processors are counted. What was optimal last year might need adjustment after a hardware refresh or if user counts have spiked.
- Avoid Mixing Metrics Improperly: Oracle generally doesn’t allow mixing Named User Plus and Processor licensing for the same product deployment. Ensure that for each separate deployment or environment, you stick to one metric. If you have multiple environments, such as production (prod) and test, license each one appropriately and consider isolation if you use different metrics.
- Seek Expert Confirmation: When in doubt, consult with an independent Oracle licensing specialist or refer to Oracle’s official licensing guidelines. Misinterpreting metrics is one of the most common (and costly) errors. A quick expert review of your license counts (for example, confirming you counted a multi-core cluster correctly) can save you from compliance troubles down the road.
