Oracle Database - Named User Plus or Processor metrics?


Oracle Database - Named User Plus or Processor metrics?

Mistakes that can cost us millions of zlotys

Licensing Oracle software is often a challenge, especially for large organizations whose IT infrastructure is highly complex, and it is easy to make a mistake that can cost a company millions of zlotys. That is why many clients decide to conduct a comprehensive license compliance review. In this article we will focus on selected aspects of licensing production environment for Oracle Database Enterprise Edition. We will show the difference between Named User Plus and Processor licenses and areas with most common costly mistakes.

Oracle Database license compliance

For most of its solutions, including Oracle Database Enterprise Edition, Oracle offers two license metrics that can be applied to its products: Processor or Named User Plus metric (in short, NUP). Both metrics prove to be a good solution, depending on the environment size and the number of users with access to software. All environments where the program is either installed or deployed need to be covered by a specified number of license units.

Using the Oracle Database software requires that the client purchases licenses for products installed in production and non-production environments (such as test and pre-production environments) as well as in disaster recovery ones. Oracles allows to use functionally limited products such as Oracle Technology Network (in short, ONT) in test environments, with a specific OTN license applied, but in such case a range of restricted terms and conditions need to be met, e.g. lack of revenues generated from an application run in a test environment. Similar specific rules apply to disaster recovery environments. So in order to achieve financial benefits consumer should take into account certain limitations regarding, for instance, the use frequency. Their contents and instructions for software use can be found in a document “Licensing Data Recovery Environments” made available by Oracle.


Processor vs. Named User Plus (NUP) metrics

Processor metric is used to license all processors on which Oracle data bases are either installed and/or deployed. Processor metric does not define a strict number of users entitled to access the software. All cores in a physical environment need to be covered by licenses whose number is calculated based on the “Oracle Processor Core Factor” document. Moreover, processor core coefficient should be multiplied by a total number of processors for each device, next the result should be rounded up to a whole number. This metric works well for large environments where accurate tracking of the number of users and their identification may cause problems. Processor metric is also used when its application proves to be more cost efficient. The Named User Plus metric allows to license programs based on the number of users. It also takes into account the number of processors on which the software is running. All physical cores need to be covered by user licenses whose minimum number is calculated based on licensing terms and conditions. For the Enterprise version, the minimum number of NUP licenses required is calculated by multiplying the current number of users or the number of Processor licenses required by 25, whichever is the higher. Clearly this method works best in cases when users are easily identified and counted, namely for small and meticulously administered environments.

It is worth highlighting that under the license terms and conditions the term “user” does not exclusively apply to a physical person having access to a data base. A device which is not serviced by a human being also counts as a user, same as every user with access to the program via such a device (via any interface).


Processor or NUP metrics?

Both metrics can be applied in any environment. In each case the best metric for a given environment is the one which generates less costs, both licensing as as well administrative ones. Using the NUP metric for test and pre-production environments (as it is easier to control access entitlements) is common practice but, despite popular belief, such a solution is not always cost-effective. Similarly, it appears that the Processor metric applied in a production environment is not necessarily the cheapest option cause the number of users may be low or regularly reduced. The selection of a relevant licensing method should be made based on the information on the number of users, environment purpose, its structure and type, and the number of operating processors. In the event when there is just a subtle difference between the cost of the two metrics, it is recommended to apply the Processor metric.


Minor errors, grand problems - incorrect installations in a virtual environment

Licensing Oracle data bases from the perspective of physical environments (with no virtualization implemented) may seem simple. Yet, the stumbling block appears after moving to virtualized environments on which the software is installed and/or deployed.

Oracle does not offer any separate licensing rules for virtualized deployments. Every virtual host, depending on the number of processors, has to be covered licenses whose number is calculated based on the previously mentioned “Oracle Processor Core Factor” document. The so-called Soft Partitioning, which segments environments via resource managers (i.e. limits the number of processors on which the data base is operating), cannot be used to limit the number of required software licenses.

In practice such approach means that for technologies recognized as Soft Partitioning, despite the installation of Oracle Database Enterprise or a different available data base version, even on one virtual devise, all hosts belonging to a given physical infrastructure are covered by the licensing obligation. The word “physical” is fundamental to understand producer’s approach. Let me illustrate it with a simple example: Oracle Database Enterprise Edition is installed on one virtual device operating within one of the clusters belonging to one bigger physical infrastructure. Despite one installation which has to be launched, the entire physical infrastructure, which includes many clusters, gets covered by the licensing obligation. Moreover, such an infrastructure, regardless of whether a component of the Oracle Database Enterprise program or Standard Edition has been installed or not, is covered by the licensing obligation applicable to the Enterprise edition. This results from restrictions for the Standard version that limit its use in environments where virtualization exceeds a specified limit for the number of machines.

To better illustrate the scale of discrepancies that may arise due to lack of understanding the rules formulated by producers, let’s make simple calculations based on two examples depicting four installations of Oracle Database Enterprise Edition software on two different platforms:

The necessary number of licenses required amounts to 15 Processor metric licenses.

In this case, the required number of Processor metric licenses would reach 300.

The difference between license requirements for exemplary environments stems from a lack of division within the VMware environment, composed of several substantial clusters. Despite the application of the soft approach, the number of required licenses will not be calculated for the virtual environment only but for the entire physical environment cause the software issuer does not allow to use the so-called affinity rule as a method to limit the number of licenses necessary to cover the physical environment.

Prevention is better than cure

Regular reviews of Oracle software are the best method which allows to maintain full licensing compliance and avoid non-compliance due to errors made, such as accidental installation of software on virtual machines or accidental deployment of software components not covered by licenses. Analyses carried out by independent specialists let clients adopt a holistic approach to infrastructures already covered with licenses and indicate which ones use licence metrics that are not cost-effective or in the case of which the current metric has become inefficient due to certain changes (e.g. increased number of users).

*The above article presents selected issues regarding Oracle software licensing only. To learn more about the licensing terms and conditions of Oracle software please read the materials published directly by the software producer.

Did you find this useful?