Oracle’s primary licensing metrics for Database and Middleware products include the “Processor” and “Named User Plus” (NUP) metrics. There are many others as well in the realm of Oracle Applications products; for example session based, revenue based, and business activity based metrics, among others.
For this discussion, we will focus on the “Processor” and “NUP” metrics. As its name suggests, the “Processor” metric is based on the processors where Oracle software is “installed and/or running”. This definition can be a stumbling block for many customers. You see, “installed and/or running” means that if Oracle software, or even a component of Oracle software, is merely present on a server, then all the processors on that server must be licensed. This has profound impacts in many ways, including DR and virtualization. Say you have a DR server that has a copy of a production server that includes Oracle Database binaries and data. Even if that DR server was never pulled into duty in a DR event, it will require licensing of all processors on it since Oracle software is “installed and/or running”. Likewise, say one of your DBAs enabled a licensable Database Pack/Option like Advanced Security Option but never used it. According to the processor definition, you will need to fully license Advanced Security Option for the full server, and failure to do so will make you non-compliant.
Now let’s extend this discussion to virtualization and clustering. Oracle’s position is that if a customer deploys Oracle software in a virtualized environment or in a cluster, then, per Oracle, every processor in the virtualized or clustered environment must be fully licensed since Oracle software is considered to be “installed and/or running” on the entire environment. The implications become very clear very quickly.
Long story short – if Oracle software is present on a server, it must be fully licensed. This applies even if the software was inadvertently installed and never used, or if a licensable feature was enabled for testing and never used. Migrating servers or making copies of servers immediately leads over deployments as well. Say you want to upgrade hardware on Server A that has Oracle Database. You clone Server B from A and direct traffic to B while you power down server A for upgrading. Even if A and B were never simultaneously handling the workload, both require full licensing because according to Oracle, its software is installed on both servers simutaneously. Even with technologies like IBM’s Live Partition Mobility, where LPAR duplicates exist for a brief instant, per Oracle, both LPARs require licensing.
Is this position extreme? Yes. Is it firmly grounded in contractual definitions? Absolutely.
How do NUPs play into this? Remember that NUPs do have processor minimums. For example, in the case of Oracle Database Enterprise Edition, the minimum is 25 NUPs per processor. Say you have a 1 processor machine, but you choose to license it by NUPs, then you must purchase at least 25 NUPs. Even if you only had 5 users, you would still need to purchase at least 25 NUPs or more if you had more than 25 users. Now, say you copied a server for migration so that, as in our previous example, there were momentarily two servers where Oracle software was “installed and/or running”, each with 1 processor. Then even if your entire user pool was just 5 users, you would be required to license at least 50 NUPs – that’s 25 NUPs for the primary server and another 25 NUPs for the cloned server (assuming that the clone is also running on 1 processor).
The bottom line is that if Oracle software is present anywhere, whether it’s “running” or not does not matter – it must be fully licensed. Customers that fully understand and grasp the implications of this definition have already taken a big step in avoiding non-compliance.