Oracle On-Premise Software Licensing
Oracle’s on-premises software licensing is known for its complexity and rigorous terms. Understanding these licenses is critical for enterprise IT staff to ensure compliance and optimize costs. Unlike cloud or SaaS subscriptions, traditional Oracle licenses are perpetual contracts governed by legal agreements rather than license keys.
Oracle provides documents, such as the Oracle Master Agreement (OMA) and detailed ordering documents, to outline licensing terms.
In this guide, we’ll break down the key on-premise license types, metrics, and common compliance pitfalls in a clear, practical tone. We will focus solely on traditional on-premise Oracle software (databases and related products), leaving out Oracle Cloud or SaaS specifics.
By the end, you should have a solid understanding of Oracle’s licensing models – Processor-based, Named User Plus (NUP), Application User, Concurrent licenses, and even custom metrics – along with how to count licenses and avoid compliance mistakes.
Oracle License Types and Metrics
Oracle uses several licensing metrics to measure software usage.
The main license types for on-premise Oracle software include Processor licenses, Named User Plus (NUP) licenses, Application User licenses, Concurrent Device/User licenses, and occasionally custom metrics defined in contracts.
Below, we explain each type and how it’s counted, with examples to illustrate their application:
Processor-Based Licensing
Processor licenses let you license Oracle software by the hardware resources (CPU cores) on which it runs rather than by user counts. Under this model, all processors (CPU cores) in any server where the Oracle program is installed and/or running must be licensed.
This is true even in clustered or mirrored setups – if Oracle is installed on a machine (including standby or failover servers), every processor on that machine is considered for licensing.
Oracle defines a “processor” for licensing purposes using its Core Factor Table, which assigns a weighting to each type of CPU core. For example, Intel x86 cores often have a 0.5 factor, meaning you need one license per two cores. To calculate the required processor licenses, multiply the total number of physical cores by the core factor and round it up.
Example: If an Oracle database runs on a server with 8 Intel cores (0.5 factor each), the calculation is 8 × 0.5 = 4, so 4 Processor licenses are required. If those cores were on a CPU with a 1.0 factor, 8 × 1.0 = 8 licenses are needed.
All cores of all servers where the database could run (in a cluster or active-passive setup) must be accounted for, unless you employ Oracle-approved partitioning to limit the software to specific cores (discussed later).
A Processor license allows unlimited users to access the software on that server . It is ideal when the user population is large and uncountable or when it’s impractical to track individual users (such as public web applications or large enterprise systems).
Why choose Processor licensing?
Organizations opt for Processor-based licensing when user counts are high or variable. It simplifies compliance because you don’t have to track named users – once the hardware is fully licensed, any number of people or devices can use the software.
For instance, an e-commerce website backed by Oracle Database might serve thousands of customers; licensing by Processor covers all of them by licensing the servers’ CPUs.
The trade-off is cost: Processor licenses are expensive, so this model only makes financial sense if you have a large or unpredictable user base. (Oracle’s price list is structured such that one Processor license often equals the cost of 50 Named User Plus licenses.) The NUP model (below) could be more cost-effective if you have fewer users than that threshold.
Named User Plus (NUP) Licensing
User Plus licenses are based on the number of distinct users authorized to use the Oracle software. Oracle’s formal definition is that a NUP is “an individual authorized to use the Oracle programs, regardless of whether the individual is actively using at any given time”. This includes people and non-human-operated devices or batch processes accessing the software.
You must count all end points that directly or indirectly use the Oracle program. For example, if 100 employees access an Oracle database through a business application, those 100 individuals each count as Named Users, even if they connect via a shared application account.
Batch processing or multiplexing does not reduce the count – Oracle requires counting the distinct end-users or devices that ultimately use the data.
One important rule is that NUP licensing is also tied to the hardware. Oracle products require a minimum number of NUP licenses per processor. The minimum of Oracle Database Enterprise Edition is 25 Named Users per processor.
Even if you have just 10 users on a 2-processor server, you must still purchase 2×25 = 50 NUP licenses (whichever is higher: the actual user count or the per-processor minimum). Oracle Standard Edition 2 databases have a lower minimum (often 10 NUP per processor); many middleware products also use 10 NUP/processor as a minimum.
These minimums ensure that very powerful servers are not under-licensed with just a handful of named users.
Example: Suppose an Oracle database is deployed on a server with four processors and accessed by 80 employees through a web application. Enterprise Edition requires a minimum of 25 NUP per processor: 4 × 25 = 100.
Since your actual user count (80) is below 100, you would still need to purchase 100 Named User Plus licenses to meet the minimum requirement. Conversely, if 500 employees use that database, you would need 500 NUP licenses (which exceeds the 100 minimum).
In summary, for NUP licensing, you must purchase at least the minimum per-processor quantity or the actual number of users, whichever is greater.
NUP licensing is typically used in environments with a small, known user population. It can be very cost-effective if you have, say, 20 or 50 total users on a server that would otherwise require a pricey processor license.
Many internal business applications with limited user counts, such as an HR system for 40 HR staff, might be good candidates for NUP licensing. Just ensure you meet the Oracle minimums.
Also note that NUP and Processor licenses are mutually exclusive for a given deployment – you must choose one metric for a product on a given system and cannot mix them for the same product. However, you can use different metrics for different products or environments as appropriate.
For instance, you might license a production database by Processor but a development database by NUP if user counts are small. Oracle allows either metric in any environment; the choice should be driven purely by user count and economics, not whether it’s production or test.
Application User Licensing
Application User is a licensing metric often used for Oracle’s enterprise applications (such as E-Business Suite, PeopleSoft, JD Edwards, etc.) or certain middleware products. An Application User is typically defined similarly to a named user: “an individual authorized by you to use the application programs, regardless of whether the individual is actively using them at any given time”.
This is essentially the same concept as a Named User Plus, but the terminology “Application User” is used in the context of specific Oracle applications. For example, Oracle E-Business Suite modules often count Application Users – each human given login access to the Oracle application counts as one license.
The distinction between NUP and Application User is mostly in name and context. Application User licenses usually don’t have core-based minimums like the database NUP metric does, because many Oracle apps are licensed strictly by user count.
However, some application modules might instead be licensed by other metrics (like Employee count, $$ revenue, or records – see Custom metrics below).
If you have Oracle applications, check your ordering documents for the metric definitions. For instance, Oracle’s license definition manual states that for Oracle Order Management, an Application User license allows a user to manually enter orders in the system, but any orders coming in via an external system require separate licensing by order volume.
This example shows that Application User metrics can have specific rules tailored to the application’s functionality.
In practice, Application User licensing means you need a license for every person who will use the software (typically named accounts in the application). There is no unlimited usage concept unless you negotiate a custom arrangement.
Always refer to the specific Ordering Document for your Oracle application, as it will define who counts as an “Application User” for that product and any special inclusions or exclusions (for example, some supplier-facing modules include your supplier users for free under your licenses).
Concurrent Device/User Licensing
Concurrent User or Concurrent Device licenses are legacy metrics that were used in the past (primarily in the 1990s) and are rarely sold for new Oracle products today. Under a concurrent licensing model, you license the maximum number of users or devices that may simultaneously access the software. In other words, the licenses are shared among a pool of users, but you cannot exceed the licensed count at any given moment.
Oracle’s classic definition was that one Concurrent Device license allows any number of users to share that device connection, as long as only one user at a time is using it. Similarly, a Concurrent User metric would mean, for example, a larger group of people could use 5 Concurrent User licenses, provided no more than five are connected at the same time.
Oracle has moved away from these metrics in favor of Named User Plus, which is easier to audit and doesn’t depend on measuring real-time usage. Oracle stopped offering Concurrent Device licenses for databases around 1999.
However, you might still encounter these metrics if your organization has very old Oracle licenses with active support. They remain valid if you’ve been grandfathered in under an old contract.
Keep in mind that some Oracle documentation from the past suggested minimums for concurrent licenses, such as eight concurrent devices per processor for Oracle8i Enterprise Edition. Still, if such minimums were not in your contract, Oracle cannot enforce them retroactively.
The key point:
Concurrent licensing allows multiple users to share a smaller number of licenses as long as the usage is not simultaneous beyond the license count. It’s beneficial for scenarios where user access is infrequent or staggered.
Example: If you somehow have 10 Concurrent User licenses for an Oracle database, an unlimited number of users could exist, but only 10 total could be logged in and actively using the database at one time.
An 11th user trying to connect would require someone else to disconnect or would require an additional license. Again, Oracle doesn’t sell this model anymore to new customers, but understanding it is useful if your organization has older Oracle products under this metric.
You should also be cautious with compliance – monitoring concurrent usage is your responsibility if using these licenses, and it can be tricky. Consider migrating to NUP or Processor licenses if possible, as Oracle often allows converting legacy metrics (for example, 1 Concurrent Device might convert to a certain number of NUP licenses).
Custom License Types (Special Metrics)
Oracle’s standard metrics (Processor, NUP, Application User, etc.) cover most scenarios, but sometimes Oracle defines custom license metrics in an ordering document. These are tailored to a specific product or a specific customer’s situation.
Common examples include metrics based on business measurements like $M in revenue, number of employees, number of customer accounts, or number of API calls. For instance, Oracle has metrics like “$M in Application Annual Revenue” or “# of Bank Accounts” for certain financial services products.
In such cases, the license quantity is tied to a figure that can grow over time. E.g., if you licensed 100,000 customer accounts for a banking system and your business grows to 120,000 accounts, you would need to true-up your licenses accordingly.
Custom metrics are usually clearly defined in the ordering document or an attached schedule, including how to measure usage and what triggers the need for additional licenses.
If your Oracle order includes any non-standard terms like “Enterprise Metric” or usage tied to specific named metrics (anything other than user or processor), pay special attention to the definition provided.
For example, an ordering document might grant a license for “Oracle Database Enterprise Edition – Limited to use on up to 50 physical CPUs for ERP workload X only” – that would be a custom restriction outside the normal metrics. Always refer to the exact wording in your Oracle ordering documents, as they are the final authority on how your licenses can be used.
Oracle’s OMA and License Definitions documents provide baseline definitions, but the ordering document can refine or override those for your purchase.
Custom metrics often come into play in large enterprise agreements or negotiations where Oracle and the customer agree on a unique way to measure usage (for example, an unlimited license based on headcount, or a capped usage license).
These can be beneficial but also require diligence to track the agreed metric (since it might not be as straightforward as counting users or CPUs).
Oracle Licensing Agreements Structure (OMA & Ordering Documents)
Understanding Oracle’s contracts is as important as understanding the metrics. A combination of a master agreement and transactional documents governs Oracle’s on-premise licenses:
- Oracle Master Agreement (OMA): This is the umbrella contract that outlines the overall terms and conditions of your relationship with Oracle. The OMA covers things like license grants, usage restrictions, payment terms, warranties, confidentiality, support policies, audit rights, and termination conditions. Essentially, the OMA sets the legal framework that applies to all Oracle software you license. Once you have an OMA in place (Oracle often requires new customers to sign one), it will govern all your orders moving forward. The OMA is a standard template (though it can be negotiated) that ensures consistent terms across your organization’s Oracle purchases.
- Oracle Ordering Document: For each purchase of Oracle software or services, you receive an Ordering Document (sometimes just called “order form” or “license agreement” in older terms like OLSA). This document is transaction-specific – it lists the exact products you are buying, the quantities, the license metrics, and any special restrictions or additional terms. In other words, the Ordering Document specifies the purchased products and services, along with their details. For example, an ordering document might state you are buying “Oracle Database Enterprise Edition – 4 Processor licenses” plus “Partitioning Option – 4 Processor licenses” with support, etc., effective on a certain date. It may also include notes like “limited to use in country X” or other usage constraints if negotiated. The Ordering Document typically references the OMA (incorporating its terms by reference), meaning all the general rules from the OMA apply to that order.
Together, the OMA and Ordering Documents form your license entitlement. The Ordering Document tells you what you bought and how it’s measured, while the OMA tells you the rules under which you must use it. It’s important to keep copies of all Oracle ordering documents and any amendments.
For instance, if you ever converted some licenses or upgraded from an older metric, the paperwork would detail that. Oracle also publishes Licensing Policy documents (for things like virtualization, Cloud usage, etc.) and Technical Support Policies, but these are generally referenced by the OMA rather than personalized to you.
In a compliance audit, these documents are key – auditors will check your usage against what’s stipulated in your ordering documents and the definitions in the OMA.
Tip: Always verify that your internal understanding of terms (like what constitutes a “user” or a “processor”) matches Oracle’s contract definitions. The OMA’s definitions section and Oracle’s official “License Definitions and Rules” booklet contain precise meanings for each metric and any minimums or special rules.
For example, the OMA (or related policies) will clarify the rules around running Oracle on a backup server or whether you can relocate licenses. Knowing these can prevent costly mistakes.
Database Options and Management Packs Licensing
Oracle Database Enterprise Edition has a modular approach – certain high-end features are packaged as Options or Management Packs that must be licensed separately in addition to the base database license.
This is a common area of confusion. Many organizations install Oracle Database and inadvertently start using features like partitioning, Advanced Security, or performance packs, not realizing each is a chargeable product.
According to Oracle’s official licensing guide, you may not use any Options or Packs unless you have purchased the appropriate licenses for them, even if the functionality is present in the software by default.
The inclusion of an option’s binaries in the installation or its mention in documentation does not mean it’s free – you must have a license to use that feature.
Oracle Database Options are add-ons to Enterprise Edition (EE) that provide extra capabilities. Examples include: Real Application Clusters (RAC), Partitioning, OLAP, Advanced Security, Data Mining, Database In-Memory, Active Data Guard, Multitenant, and several others. Each option, if used, must be licensed under the same metric and quantity as the database itself.
That means if your database is licensed per Processor, and you enable the Partitioning option on that database, you need the corresponding number of Processor licenses for the Oracle Partitioning option.
You cannot license an option for just some users or a subset of the processors – it covers the database instance. If your database is NUP-licensed, you must have NUP licenses for the option (with the same user count and minimums applying).
In short, the option licensing mirrors the database licensing. Oracle prohibits mixing metrics for the base product with options. So, you can’t, for example, have an EE database by Processor but try to license RAC by NUP on that same database – both must be on Processor in that case.
Oracle Management Packs are similar add-ons, usually for Oracle Enterprise Manager or for specific DB management features (like Diagnostics Pack, Tuning Pack, Data Masking Pack, etc.).
These, too, require separate licensing per the database’s metric. Notably, Diagnostics Pack and Tuning Pack are often unknowingly used because Oracle Enterprise Manager (OEM) or even certain database scripts can automatically use them (for instance, accessing AWR reports or running OEM’s performance pages requires those pack licenses).
It’s important to disable or restrict access to unlicensed packs to stay compliant. Oracle’s documentation lists which views or features belong to which pack.
Compliance example: If you have an Oracle Database EE running on four processors and using Oracle Advanced Compression for your data, you must purchase four Processor licenses of the Advanced Compression option (in addition to the base database licenses). If you do not purchase it, you are technically out of compliance the moment you start using that feature.
Similarly, enabling Oracle Real Application Clusters (RAC) on a two-node cluster requires that both nodes are fully licensed for the RAC option, matching the Enterprise Edition (EE) licenses on those nodes. Even features like Oracle Java VM inside the database or certain security features (encryption) fall under separately licensed options (Advanced Security or Database Vault).
Always consult the Oracle Database Licensing Information manual for your DB version – it has a chapter listing which features require extra licenses. Make sure your DBAs and architects are aware of these boundaries. A common mistake is turning on features during testing (such as partitioning a table) and forgetting that it requires a purchase.
In summary, do not assume that having an Oracle Database license alone covers every feature you use. Options and packs are a major area where Oracle finds compliance issues during audits.
Good practice is to install only what you’re licensed for (many DBAs perform a “custom install” to exclude packs/options not purchased) and use Oracle’s provided scripts to verify feature usage. If an Option or Pack is not licensed, its features should not be used. If needed for business, consider purchasing it.
Common Oracle Licensing Compliance Issues and Pitfalls
Even with a solid understanding of license metrics, organizations often fall into certain compliance traps with Oracle. Oracle’s License Management Services (LMS) frequently find these issues during audits.
Below, we highlight the most common pitfalls and how to avoid them:
- Virtualization Missteps (Soft Partitioning): Perhaps the #1 compliance issue is with virtualized environments. Oracle’s licensing policy does not automatically accommodate common hypervisors like VMware or Microsoft Hyper-V when it comes to limiting license scope. Oracle distinguishes between hard partitioning (physically tying software to specific CPU cores) and soft partitioning (flexible virtualization where VMs can move around). VMware is considered soft partitioning, which means Oracle requires you to license all physical hosts or cores on which the software could run in the environment. For example, suppose you have a VMware cluster of 10 hosts and an Oracle database VM that can technically reside on any of them. In that case, Oracle’s stance is that all 10 hosts must be fully licensed for the database, unless you segregate Oracle into a sub-cluster or use Oracle-approved hard partitioning methods. This catches many companies off guard, as they assume they only need to license the cores assigned to the virtual machine (VM). To stay compliant, you need to either implement Oracle-approved Hard Partitioning (such as using Oracle Linux KVM with pinned CPUs, Oracle VM Server with a hard partition configuration, or certain physical partitioning on Unix systems) to confine Oracle to a subset of hardware or license the entire cluster. Always consult Oracle’s published partitioning policy for which technologies are recognized as hard partitioning. Soft partitioning technologies (such as VMware) do not reduce licensing requirements. The implication is that it comes with a higher cost: many Oracle customers inadvertently under-license in virtual environments. A best practice is to physically isolate Oracle workloads to dedicated hosts if you want to limit license exposure (e.g., a dedicated Oracle VMware cluster separate from other workloads, with vCenter-level separation, which Oracle sometimes has accepted via custom contract terms). Compliance tip: Document your virtualization setup and consider negotiating contract clauses if you use VMware – Oracle might offer a contractual waiver if you agree to certain network/storage isolation, but without it, the default is all-encompassing licensing.
- Unlicensed Use of Enterprise Edition Options: As noted above, using Database Options or Management Packs without licenses is a frequent audit finding. This can happen unintentionally – for instance, a DBA creates a partitioned table (triggering the Partitioning option license requirement) or turns on Transparent Data Encryption (requires Advanced Security option), or enables Active Data Guard for a standby database (requires Active Data Guard option). Oracle’s audit scripts will detect these uses. The misconception that “if it’s technically there, I can use it” is dangerous – Oracle explicitly forbids the use of any option or pack without purchase. Even features like Database Vault, Multitenant (Pluggable Databases) in 19c+, or Spatial features are separately licensed. To avoid this pitfall, educate your technical teams on which features are included in the base license and which are add-ons. Regularly run Oracle’s License Measurement Tools or scripts (available from Oracle Support) to check feature usage. If you find an unlicensed option in use, you either need to disable it or procure the license. Oracle also provides a GUI in Enterprise Manager that can show which packs are used – use these tools proactively rather than waiting for an audit.
- Over-Deployment Beyond Licensed Counts: Oracle does not enforce license limits with a software key, so it’s possible to accidentally deploy more instances or users than you have purchased. For example, you might spin up an additional Oracle database on a new server without realizing it wasn’t licensed, or add 50 more users to an application that only had 40 licensed. Over-deployment is essentially using more of the software (in terms of processors, users, or instances) than your entitlement allows. Common scenarios include expanding an Oracle cluster with an extra node but not buying an extra license, or cloning a database to a new server for load balancing without licensing the new server. The remedy is straightforward: track your deployments. Use tools or spreadsheets to map each Oracle installation to a license. Oracle’s definition of “installed and/or running” means if the binary is installed on a server, they consider it licensable, even if that server is not actively in use. So, even having Oracle software installed on a cold standby server can count, unless it’s truly dormant and not configured for use. Regular internal audits can catch over-deployments early. Also, beware of virtual sprawl – in cloud-like environments or containerized setups, it’s easy to spin up Oracle instances; each such instance on an unlicensed core is non-compliant. Some customers use Oracle’s own LMS scripts periodically to self-audit and ensure they stay within purchased limits.
- Non-Production Environments Not Licensed: A prevalent misconception is that development, test, or QA servers don’t need licenses. In Oracle’s licensing policy, there is no free ride for non-production. Suppose you install Oracle software in any environment – whether production, test, or development – it must be properly licensed (usually with the same type of licenses as production). Oracle does offer a free Developer License for Oracle Database. Still, that license is only for individual use in a learning or prototyping context, not for enterprise-wide test systems or multi-user development environments. Companies sometimes mistakenly think that because no revenue work is done on dev/test systems, they don’t have to license them. In reality, if Oracle software is installed on a server and used for any purpose other than approved trial or education uses, you need to own a license for it. The OMA or OLSA makes no distinction for environment – a server is either licensed or not. That said, you could choose a lower-cost edition for non-prod (for example, using Oracle Standard Edition for a test environment if it suffices, while production runs Enterprise Edition – as long as the features used in test align with that edition’s allowed features). The bottom line: Every Oracle installation must be accounted for in your licenses. Oracle’s partitioning policy and certain promotions aside, the company expects full compliance across all environments to protect its IP. Ensure your procurement includes licenses for dev/test and that these environments don’t accidentally enable EE-only features (which would then also require options licensing).
- Disaster Recovery (DR) and Backup Pitfalls: Oracle’s licensing rules for DR environments can be tricky. The general rule is that any server on which Oracle is installed and running for more than ten days per year must be fully licensed. Oracle has a policy that allows an unlicensed spare for failover in a clustered environment, limited to a total of 10 days of use per year. This typically applies to scenarios like a passive Data Guard standby or a failover node in an HA cluster. For example, suppose you have a primary database server and an identically configured standby that is normally idle. In that case, you do not necessarily need to license the standby, only if it is truly passive and only activated during a failover or test that cumulatively does not exceed 10 days in a given year. However, if the standby is open read-only for reporting, or used for any other purpose (even backups or queries), Oracle considers it “in use” and it must be licensed. Many organizations get caught by this if they use the standby for reporting or regularly switch over – doing so would void the 10-day rule and require full licensing of both servers. As for backups, simply storing Oracle backup files on disk or tape does not require a license. But if you restore those backups onto a server (for a drill or to recover data) and start the Oracle database up, that server now needs to be licensed while the database is operational. A common mistake is performing annual DR tests by spinning up Oracle on DR hardware without licenses – those count toward the 10-day allowance, or licenses are required if exceeded. The safe approach to DR: if you have a 24×7 standby or any kind of active-active or frequent failover configuration, assume you need to license all nodes. Only in a pure emergency or passive scenario can you use the spare without a license, and even then, track the days of use. Always document your disaster recovery (DR) design and ensure your licensing team is aware of any Oracle use on secondary systems. If unsure, consult Oracle’s formal policies or get written clarification from Oracle to avoid a nasty surprise in an audit.
- Mixing License Metrics Improperly: Another pitfall is using licenses in a way that wasn’t intended in the contract. For instance, using a Named User Plus license from one environment to cover usage in another environment that Processor better measures, or vice versa. Oracle licenses are sold per specific product, metric, and quantity as stated on the ordering document. You cannot, for example, take 50 extra NUP licenses you bought for Database A and assume they cover 50 users of Database B, unless Database B is under the same license pooling. Licenses are not universal tokens; they’re tied to the program and sometimes even the location or other restrictions (some licenses are limited-use). Ensure you don’t apply licenses across different programs or violate any restriction in the ordering document (like “program X is licensed for use only in department Y”). Also, Named User Plus and Processor licenses are not interchangeable without a contractual conversion. If you decide to switch a system from NUP to Processor licensing, you must purchase the Processor licenses or negotiate a conversion; you can’t just declare that your 100 NUPs equate to 2 Processors and call it done (unless Oracle agrees in writing). This is more of a procurement note than an audit finding, but it’s worth mentioning as a caution.
Example Scenarios and Best Practices
To solidify these concepts, here are a few practical examples and recommended best practices:
- Choosing NUP vs Processor for a User Population: Imagine you have 100 total end-users (employees or customers) who will access an Oracle Database via a middle-tier application. The database runs on a server with two processors. You have two licensing options:
- Named User Plus: Oracle Database EE requires a minimum of 25 NUP per processor. With two processors, that minimum is 50 NUP. Since you have 100 actual users, you need 100 NUP licenses, as it’s greater than the 50 minimum. Those 100 licenses entitle those 100 named individuals (and only those individuals) to use the database. If you add more users beyond 100, you will need to purchase additional NUP licenses.
- Processor: Alternatively, you can license two processors. Suppose each processor has eight cores with a 0.5 core factor – that’s 8 × 0.5 × 2 = 8 Processor licenses needed. With Processor licensing, an unlimited number of users can access the database. In this example, if the cost of 1 Processor license equals 50 NUP licenses (which Oracle’s price list often reflects), then 8 Processor licenses equate to 400 NUPs worth of cost, far more expensive than buying 100 NUPs. So NUP is the economic choice here. Best Practice: Calculate the break-even point (roughly 50 NUP per Processor for most products). If your user count per processor is well below 50, NUP is likely cheaper; if it’s above 50, Processor might be better. Also consider future growth – if that 100 users might become 1000 next year, a Processor license would preemptively cover growth without needing incremental purchases.
- Licensing in a VMware Cluster: Your company runs a VMware cluster of 5 physical hosts (each 2 CPUs, 20 cores total across the cluster) and deploys an Oracle database VM on just one of the hosts, with four vCPUs. You might think you only need to license 4 CPUs for Oracle. However, by default, Oracle will consider this a soft partitioning scenario – the VM could move to any host. Unless you have restricted the VM’s movement to one host (and have documentation or are using a hard partition feature), Oracle expects you to license all 20 cores in the cluster for the database. That could mean, for example, 10 Processor licenses if the core factor is 0.5. To avoid licensing inactive hosts, you have a few options:
- Use an Oracle-approved hard partitioning method to pin the Oracle VM to a subset of cores or a single host, per Oracle’s partitioning policy (for instance, using VMware’s VM-Host affinity rules is not officially accepted by Oracle, but using Oracle Linux KVM with hard partitioning or physically segmenting into a smaller cluster might be).
- Segregate Oracle into a dedicated cluster or ESXi host that is fully licensed, ensuring the Oracle VM never runs elsewhere. Some companies create a small 2-host cluster just for Oracle and license those hosts, separate from the general VMware farm.
- If neither is possible, factor the cost of full-cluster licensing into your budget, or consider alternative architectures, such as using Oracle Cloud or Oracle’s virtualization, if that’s strategically viable.
- Best Practice: Always clarify virtualization licensing in writing with Oracle. If you rely on soft partitioning, you’re accepting a compliance risk. Consider negotiating a contract clause that limits Oracle’s scope to certain hosts or a specific environment – Oracle sometimes provides a custom contract amendment for VMware environments, but you must explicitly get it, otherwise their standard policy applies.
- Audit Readiness for Options/Packs: You have Enterprise Edition databases, and you’re unsure if any additional options have been used over time. Best Practice: Run Oracle’s chopt tool or query the DBA_FEATURE_USAGE_STATISTICS view to see what features have been exercised. For example, if it shows “Partitioning used: YES” on a database that you did not license Partitioning for, you have a compliance issue to address. Either disable partitioning and rebuild those tables, or purchase the option. Similarly, use Oracle Enterprise Manager’s licensing dashboard if you have it, to review any use of Diagnostics or Tuning Pack (e.g., querying an AWR report = Diagnostics Pack usage). Regularly reviewing this, say quarterly, can catch problems early. Also, maintain a whitelist of allowed features for your DBAs – e.g., “we are licensed for RAC and Advanced Security, but not for Partitioning or Active Data Guard” – so they know what not to implement.
- Document and Archive Agreements: Keep a central repository of all Oracle OMAs, ordering documents, support renewals, and any amendments. When staff change over time, critical knowledge like the terms of your ULA (Unlimited License Agreement, if any) or specific license restrictions can be lost – having the documents ensures you can check the original terms. For instance, if an Ordering Document notes that some licenses are limited to a certain country or a subsidiary, using them elsewhere could breach terms. Oracle’s audit teams will go by what’s on paper. Best Practice: Upon any Oracle purchase, have both IT and contract management review the order to confirm it matches expectations (correct metric, quantities, etc.). Misunderstandings can sometimes occur, such as buying “Application User” licenses when you thought you were getting NUP – the impact can be significant if not caught early.
- Train Your Team: Given the complexity, it pays to train your DBAs, application admins, and procurement staff on Oracle licensing basics. Something as simple as a DBA knowing that creating a new Oracle instance on an unlicensed server is a no-go can prevent an incident. Oracle licensing should be a checklist item whenever a new system is provisioned: “Do we have the licenses for this deployment, and is it within our allowed use?” Consider designating an “Oracle license steward” in your organization who liaises between the technical and procurement teams. Oracle will also happily brief you on licensing if you ask – just be mindful that their goal is often to sell more, but they can clarify rules.
