Oracle Core factor and Oracle or non-Oracle Cloud

By Franck Pachot

.
Oracle Database licensing can be based on two metrics: Processor or Named User Plus (NUP). NUP also necessitate to count the processors because there is a minimum number of NUP per processor. Then it is very important to know how to count processors. The time where a machine had 1 socket with 1 processor with 1 chip with 1 core running 1 thread is really old past. Today, we have physical machines with multi-core processors, running multiple threads per core. And virtualization allocates part of it to virtual machines, often called vCPU.

Oracle still uses the name ‘processor’ but declines the way of counting them by processor vendor (Core Factor), virtualization solution, and cloud provider.

References

The main document referenced here are:

The Oracle Processor Core Factor Table: http://www.oracle.com/us/corporate/contracts/processor-core-factor-table-070634.pdf which describes how to adjust core count to processor count. It also describes how to count Oracle Cloud CPU (aka OCPU).

The Licensing Oracle Software in the Cloud Computing Environment: http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf which describes how to count Amazon AWS vCPU and Microsoft Azure Cores.

There is no mention of other cloud providers, but they all run virtualization so comes the Oracle Partitioning Policy to know how to count physical vs. virtual CPU: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf. However, their hosting contract may mention different things.

At the end of those documents, you see a mention that they are ‘for educational purposes only’ so basically there’s no legal truth in them and my blog post being my interpretation on that has no value at all… Your contracts have the truth when it comes to legal interpretation.

So you might wonder what’s the point reading those documents if they have no value? Well, your goal, as an IT manager, is not to go to court and fight with attorneys. If you want to avoid any problems, it is better to read those rules and adhere to them, whether you find them fair or not. Of course, you can also choose to go to other vendors with other models, such as open source. But that’s not the goal of this post. Here I suppose that you like the oracle database technology, as much as I do, and that you are looking for a way to run it at affordable cost without worrying about LMS audits…

Something else about those documents: they change, so you may want to look at history. For example, about Amazon and Azure, the definitions were a bit different a few days ago and the web time machine can help us: http://web.archive.org/web/20161226082104/http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf.

Vendors

Of course, there may be some technical reasons behind core factor, virtualization and cloud factors. But let’s face it, besides the database, Oracle is also a hardware vendor, a virtualization software vendor, and a cloud provider. They are at the top in database market, willing to do the same on the cloud market. Making database cheaper on their products may be a way to achieve that. Customers wanting to stay with Oracle Database will be tempted to go to full Oracle stack.

The combination of core factor and virtualisation rules clearly disadvantages all competitors:

• IBM LPAR virtualisation is accepted, but IBM POWER core factor makes the database 2x more expensive than on processors you find in Oracle hardware (Intel, SPARC)
• Most data center run on VMWare ESX with 0.5 core factor Intel, but counting vCPU is not accepted and the whole datacenter may have to be licenced
• We are allowed to count vCPU on Amazon and Azure virtualization, they run Intel Xeon, but core factor applies only on Oracle Cloud. You need x2 processor licenses on AWS or Azure for the same processor cores
• Disabling cores from the BIOS is how Capacity on Demand is done on bare metal ODA, but we are not allowed to do the same on similar hardware

So basically, running Oracle Database is cheaper on Oracle Hardware, Oracle virtualization and Oracle Cloud. When you do it on other vendors, you can’t do capacity on demand, and you need more processor licenses to run on same number of CPU.

Enterprise Edition

On the Oracle Cloud, you allocate CPU resources with shape OCPU. One OCPU is the equivalent of one Intel Xeon core with 2 threads. And one processor licences covers 2 OCPUs. This looks like the core factor for Inter Xeon even if it is not directly mentioned (but this equivalence is written in the core factor document). So One processor license covers 2 cores, 4 vCPU with hyper-threading.

On Amazon EC2 and RDS one processor licence covers 1 core. This can be 1 vCPU (T2 and m3.medium have one thread per core) or 2 vCPU (hyper-threaded instances). The AWS document https://aws.amazon.com/ec2/instance-types/ mentions that each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.

On Microsoft Azure one processor license covers 1 core. This is 1 vCPU as there is no hyper-threading enabled.

23-Jan-2017

I mentioned looking at archive.org version of the documents. Tim Hall has mentioned what has changed on is blog

The previous document was not very clear, mentioning ‘virtual cores’. Actually, ‘virtual cores’ are the number of cores that are behind the vCPU: one for T2 instances (and m3.medium), two for hyper-threaded instances. And this is listed precisely on https://aws.amazon.com/ec2/virtualcores/ for Amazon. It is clear also for Azure as there is no hyper-threading.

But what has changed is that there were previously two mentions of applying the core factor:

• An example on 8 virtual cores requiring 8 * 0.5 = 4 processor licenses
• The mention that AWS implements Oracle VM and then follow the rules of hard partitioning and ‘standard processor metric’ which, IMO, includes the core factor

Those two have disappear in the new document, with an explicit mention that When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable. This makes the Oracle Cloud competitors two times more expensive than before for running Oracle Databases. The fun part is that IaaS providers that are not ‘Authorized’, or private clouds, can apply core factor and count vCPUs as long as they virtualize with Oracle VM on Intel Xeon. But hosting companies may have different rules in their contracts.

Update 20-MAY-2020

The document as changed again and now the vCPU counts whether it is hyper-threaded or not:
Standard Edition 2 may only be licensed on Authorized Cloud Environment instances up to eight Amazon vCPUs or eight Azure vCPUs. If licensing Database Standard Edition 2 by Named User Plus metric, the minimums are 10 NUP licenses per 8 Amazon vCPUs or 8 Azure vCPUs.

I have recap’d the rules in a new blog post:
https://www.dbi-services.com/blog/oracle-core-factor-and-non-oracle-cloud/oracle-standard-edition-on-aws-a-socket-arithmetic

NUP

When licensing in NUP, the metric is not the number of processor. But you have to count them because you need to buy more than 25 NUP per processor. This means that if you have 25 NUP only (for a development environment with few developers for example) you can run it on 2 cores in the Oracle Public Cloud, but only one core on the other ‘Authorized’ ones.

Standard Edition

Note that the core factor has nothing to do in Standard Edition. Processor metric for Standard Edition is not a core but a socket. On current Intel processors, a socket can run 12, 18, or 24 cores. But maths are different in the Cloud from an Oracle licensing perspective.

In the Oracle Cloud, one ‘socket’ is 4 OCPU which is 4 cores (8 threads). An instance with 1 to 8 vCPU requires 1 SE2 processor license. 9 to 16 vCPU requires 2 SE processor licences and I think it is the maximum you can have on Oracle Cloud. So the idea is that one socket is equivalent to 4 cores. This is low, but it was worse before October where one ‘socket’ was 2 cores only.

Worse also for the competitors cloud, as this has not changed and it is still one ‘socket’ for 2 cores. This means that in Azure a SE2 processor licence covers 2 cores, and in Amazon it covers 4 vCPU (which are 4 threads on 2 cores).

Standard Edition 2

Now if you remember that SE2 has a limit of 16 threads for on-premises, the limit on the Cloud is 8 vCPUs on Amazon. You cannot run SE2 on a AWS instance with more than 8 vCPU. This is a big limitation. On-premises, the limit is soft only: resource manager will schedule at most 16 user sessions on CPU. But more resources can be used by background processes. On AWS, you are limited to 8 CPU treads in total, which means that you have only 4 cores for all processes – user and background included. And CPU starvation is not very good when you wait for LGWR.

This is even worse on Azure where the limit is 4 cores without hyper-threading.

This is clearly stated in the ‘Authorized Cloud’ document:
Oracle Standard Edition One and Standard Edition 2 may only be licensed on Authorized Cloud Environment instances up to eight Amazon vCPUs or four Azure CPU Cores.. Here again, the SE2 comes at the price of SE but with limitations of SE1.

Once again, rules are more friendly for Oracle Cloud where you can create a Standard Edition instance on 16 OCPU (which is 32 threads). SE2 resource manager will still limit to 16 user sessions, and they will have one core for each. And background processes will be able use the additional resource coming from hyperthreading.

ULA

There are two important points regarding ULA and ‘authorized clouds’: ULA licences can be used during the ULA, but they don’t count in certification to exit ULA.

So what?

I don’t think I’ll risk a conclusion here. Having different price for same software running on similar hardware doesn’t look fair. I’m more annoyed by the difficulty to compare, espacially when rules change from time to time. But I can understand that vendors want to push their own products.

Let’s get technical. My recommandation is to use the minimum of CPU resources so that you don’t have to run your application on dozens of vCPUs. This is why we like Oracle: it is very efficient both for OLTP and BI. Most of the code used by your critical use-cases was optimized decades ago for mono-core processors. Look at an AWR report, identify the queries that are responsible for most of CPU and tune them. Stop hard parsing over and over. Stop reading always the same blocks. Stop doing row-by-row round-trips to your database. Don’t waste your CPU cycles doing all this unnecessary work and you will save money, whatever the ‘core factor’ is.