A solid understanding of Oracle licensing is required whenever running Oracle software either on-premises or in AWS environments. It can be very easy to miscalculate the number of licenses needed and with Oracle being very fond of auditing their customers not having a solid understanding of the rules can be very expensive. Considering how expensive Oracle software is even modest deficiencies can cost hundreds of thousands or more. In this article we are going to start with the basics of Oracle editions, metrics, and the Cloud Policy.

---

Oracle Editions

There are two separate editions of Oracle Database software that can be licensed. They are: Enterprise Edition (EE) and Standard Edition 2 (SE2). The choice of which edition to use is discussed in more detail here.

Oracle Database software is licensed on the underlying CPUs that the software runs on. In terms of Oracle licensing a socket is a whole processor. A processor is actually a number of cores based on the processor model, and the Oracle Processor Core Factor Table. For x86_64 processors the core factor is 0.5, so a single processor with 4 cores would count as 2 processors for licensing purposes.

The following summarizes how the editions are licensed for on-premises environments.

• Enterprise Edition is licensed on what is referred to as a processor basis. All cores of the physical host are counted, the core factor is applied, and then that is the number of processor licenses that are required.
  • In on-premises virtualized environments all cores on the host are still counted, not just the number of vCPUs assigned to the VM.

• Standard Edition 2 is licensed by socket, the number of cores is irrelevant. However, there are several restrictions with SE2 that should be noted. SE2:
  • is only licensable on servers with up to 2 sockets
  • is restricted to 16 threads per database — (the database engine automatically enforces this)
  • does not allow for the license of any options or management packs for example Partitioning, Diagnostics Pack, and/or Tuning Pack

In addition to the current editions, there are two previous editions that are still relevant and still in use. These editions are Standard Edition (SE) and Standard Edition 1 (SE1). These editions were discontinued as of Database version 12.1.0.1 in favor of SE2. If licenses for SE or SE1 are owned, and Database version 12.1.0.2+ is desired, then the existing SE/SE1 licenses will have to be migrated to SE2.

• Standard Edition and Standard Edition 1 are also licensed by socket. The number of cores is irrelevant. The only two differences between SE and SE1 are:
  • SE is licensable up to 4 sockets per server and SE1 is licensable up to 2 sockets per server.
  • SE includes a license for 4 socket RAC cluster (2 hosts 2 sockets each, 4 hosts 1 socket each)

License Metric

Oracle’s Database and WebLogic software products can be purchased using one of two metrics: Processor and/or Named User Plus (NUP). As noted above, for processor-based licensing the number of cores in a server are counted, the core factor from the core factor table is then applied, and the result is the number of processor licenses required to license the server.

With EE for example, an x86_64 based server with 2 processors, 10 cores per processor, and a core factor of 0.5 would require 10 processor licenses.

Things do get a little more complicated for NUP licensing. As implied by the name the NUP metric licenses the users that access the database(s) on the server. When licensing using the NUP metric the number of processors from the processor-based model is still calculated. Then either a minimum number of users per processor must be licensed or the actual user count, whichever is greater.

The minimum NUP licensing is 25 NUP per processor for database EE products. Using the same example as above with 10 processor licenses a total of 250 NUP. The simple math here: 10 processor licenses * 25 NUP per processor minimum = 250 NUP. However, if there are say 300 users for the database then 300 NUP would be required.

Concerning the actual user counts there are a few things that should be noted.

• All users of an application that accesses a NUP based database must be counted. You cannot just count the service account(s) that the application uses.
  • For example, you have 200 application users, but the application only ever connects to the database as 1 application user, then 200 NUP will be counted not just 1.

• When licensing using the NUP metric an individual user is only counted once regardless of the number of databases and servers they access.
  • For example, if a user accesses five different databases (regardless of environment, dev/test) on three different physical severs only one NUP license is required. The per server NUP minimums still need to be respected.

With these rules we find that the NUP minimums are usually more than sufficient to cover the actual user counts.

For Standard Edition products the processor-based licensing simply counts populated CPU sockets. Thus, when licensing database SE2 with two populated sockets (regardless of number of cores) then two SE2 licenses would be consumed. When licensing database SE2 for the NUP metric a minimum of 10 NUP licenses per server is required. The number of populated sockets and cores is irrelevant.

Even though NUP licensing is more complicated it can provide a significant cost savings. It is most commonly used in non-production environments when the user counts (developers and testers) are usually much lower. At list prices the break-even between processor licensing and NUP licensing is 50 users per processor.

Back to our example above, at list price 10 processor licenses for EE is $475,000, while 250 NUP is $237,500; quite literally ½ the cost. In addition, support costs will be lower as support is based on purchase price.

Oracle Licensing for Cloud

Now to really complicate things: licensing Oracle software for a public cloud environment (AWS and Azure). Technically, the Oracle contract does not allow Oracle software to be licensed in cloud environments. Licensing for cloud environments relies on an extra-contractual policy document. The document title is Licensing Oracle Software in the Cloud Computing Environment; however, it is usually referred to as the Cloud Policy.

As this is an extra-contractual policy it will be best to have your legal counsel review your contracts and the Cloud Policy. In House of Brick’s experience this document can be relied on in order to implement in ASW and Azure. The following article goes into greater detail on the topic. August, 2017 NoCOUG Article

This then brings us to the details of what the Cloud Policy allows.

• Defines only two public clouds that the policy may be applied to.
  • AWS (EC2 and RDS) and Azure
  • All other public cloud environments will require traditional per host licensing.

• Allows for VMs to be licensed by vCPU rather than the entire host.
  • EE – 1 processor license is needed for every 2 vCPUs with multi-threading enabled and 1 processor license for 1 vCPU with hyper-threading disabled.
  • SE1/SE2 – a VM with up to 4 vCPUs counts as 1 socket and a VM is allowed up to 2 sockets worth of vCPUs. Thus, a max of 8 vCPUs.
  • SE – allows for up to 16 vCPUs.
  • NUP licenses are allowed with minimums calculated on vCPUs.

• The Oracle Processor Core Factor Table is not used for AWS or Azure.
  • When licensing bare metal hosts traditional host-based licensing is used, and then the core factor table would apply.

• Oracle license is to be supplied by the end user through Bring Your Own License (BYOL).
  • AWS Relational Database Services (RDS) instances have an optional license included (LI) type. The license for these instances is “leased” through AWS.
  • When using RDS LI the maximum number of available vCPUs is 16 even with SE2 versions of the Oracle database engine.

Examples

Now that we have the basics down it is time for a few real-world examples of applying the rules to AWS EC2 or RDS instances.

NOTE: all NUP counts are minimums, as noted actual user counts may require additional licenses.

• 2 vCPU EC2 or RDS instance (r6i.large)
  • 1 processor license of EE, or
  • 25 NUP of EE, or
  • 1 socket license of SE2, or
  • 10 NUP of SE2
• 4 vCPU EC2 or RDS instance (r6i.xlarge)
  • 2 processor licenses of EE, or
  • 50 NUP of EE, or
  • 1 socket of SE2, or
  • 10 NUP of SE2
• 8 vCPU EC2 or RDS instance (r6i.2xlarge)
  • 4 processor licenses of EE, or
  • 100 NUP of EE, or
  • 2 socket licenses of SE2, or
  • 10 NUP of SE2
• 16 vCPU EC2 or RDS instance (r6i.4xlarge)
  • 8 processor license of EE, or
  • 200 NUP of EE, or
  • SE2 – RDS License Included
  • This VM exceeds the SE2 maximum vCPU for BYOL
• 32 vCPU EC2 or RDS instance (r6i.8xlarge)
  • 16 processor licenses or EE, or
  • 400 NUP licenses of EE
  • This VM exceeds the SE2 maximum vCPU for BYOL, and RDS License Included

Conclusion

---

There are numerous advantages to utilizing cloud environments for your IT needs and there is absolutely no reason that your Oracle workloads should not be a part. With the information provided one can easily get started planning an Oracle deployment in AWS. It is just as simple as determining the edition to be used, the metric to use, the size of the instance, and then working through the simple math.

As always if you have any questions in applying this information to your specific situation contact us and we will help.