This blog is by a long-time Oracle storage professional who has history with both NetApp and EMC.

May 26, 2010

Oracle License Costs on the VMware vSphere Platform

I have received many questions recently concerning license costs of Oracle Database running under VMware, and there seems to be a great deal of confusion on this issue. Let me try to clarify this here.

First, understand that Oracle Database software is always priced on the physical CPU hardware on which the software runs. There is no exception to this, regardless of whether the software is running under a hypervisor or on normal hardware. This is made abundantly clear by Oracle's Global Price List, which states as follows:

Processor: shall be defined as all processors where the Oracle programs are installed and/or running.... The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table....

These two entries control the vast majority of x86-64 chips sets that we deal with on a daily basis. Thus, you can pretty much count on your Oracle license cost being 50% of the number of physical cores on the box where Oracle is running, multiplied by the license cost for the Oracle Database software version you are running. For example, using Oracle Database 11g R2 Enterprise Edition, running on a dual-socket, quad-core processor box, this would be:

4 * 2 * 0.5 * $47,500 = $190,000

Note: Standard Edition and Standard Edition One are special cases. They are priced on a processor socket, not a core basis. The essential idea remains the same: Oracle software is always licensed on the physical processor hardware.

When using VMware, this can be either very advantageous or very disadvantageous to you, depending on how you manage your VMs. Take two scenarios:

This shows the worst case. We have created a four-node VMware DRS / HA cluster in which Oracle VMs are allowed to migrate willy-nilly pretty much wherever they want. In this case, you owe Oracle the license fee for all of your physical boxes, in this case $280,000. Given the high cost of Oracle software, that's definitely not the way you want to go.

Now the second scenario:

Here, you have physically isolated all Oracle VMs to their own dedicated VMware DRS / HA cluster. That's how you want to do this. This way, you only pay the Oracle license on hardware that is dedicated to running Oracle.

The advantage to doing this is that you can typically get more transactional throughput on the same physical hardware by running Oracle virtualized under VMware ESX than you can when running physically booted. This is because the utilization of Oracle database servers is typically fairly low. That is what virtualization is largely about after all: Improving utilization of resources by pooling workloads. Because of the high cost of Oracle database software, this effect is amplified, making Oracle one of the most attractive workloads for virtualization, at least from a cost perspective.

Comments

Hi,
I think, that the way, how you calculate the number of Oracle SE licenses in your example is not correct. I'm not commenting about the way how you license Oracle in a VMWare environment, but the way, how you describe Oracle licensing on one server.
When licensing Standard Edition or Standard Edition One, you don't care about cores and factors. The important sentence from the Oracle Price list is in the definition of "Processor":
"When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is
counted as one occupied socket.".
So if you licence Standard Edition (or SE One) for dual-socket, quad-core processor box, you only need 2 CPU licenses of DB SE in my opinion.
Of course, when licensing any other Oracle product (for example Database Enterprise Edition), you calculate the number of CPU licenses by multiplying the cores and factor as you did (2 sockets x 4 cores x factor 0.5).

As usually: this is my personal opinion only and it may not necessarily reflect the views of Oracle Corp.

"Oracle Database software is always priced on the physical CPU hardware on which the software runs. There is no exception to this".

Except...

"For the purposes of licensing Oracle programs in the [Amazon Web Services – Amazon Elastic Compute Cloud (EC2)] Cloud environment, customers are required to count each virtual core as equivalent to a physical core. This policy applies to all programs available on a processor metric."

Also keep in mind that different virtual server technologies have different rules if oracle determines that your virtulisation technology is hard partitioning or soft partitioning, vmware is classes as soft but some other technologies count as hard so you just licence the CPUs available to the VM hosting oracle.
Oh and remember not to licence 26 virtual cpus on a machine with only 20 real cpus.

"Also keep in mind that different virtual server technologies have different rules if oracle determines that your virtulisation technology is hard partitioning or soft partitioning...".

And as far as I understand: Oracle's own hypervisor is the only software hypervisor classified as supporting hard partitioning - via a rather arbitrary construction - and thus potentially saving license costs. VMware and the rest are classified by Oracle as supporting soft partitioning only, typically implying more license costs.

I couldn't have said it better myself. Thanks for posting this. Like you suggest, we run all our Oracle instances in a 2 node HA/DRS cluster vs in the larger general 16 node cluster. I hesitate to even try and calculate the cost if we licensed all 16 nodes.

It seems like software companies like Oracle who are clinging to the CPU based pricing model in a world of Cloud Computing and SaaS are truly being slow to adapt to the new realities of how computing power is delivered. I make this point in mroe detail here:

In regards to licensing. As of the Intel 5600 series processors, there does not appear to be any dual core chips. We have several Oracle servers running on single dual core machines. As the hardware ages it appears that we can not legally upgrade the hardware due to the latest processors are quad core. Or a $5000 server replacement becomes $50,000 to keep the enterprise install legal. Not a way to keep customers, especially in these economic times.

If one licence Standard Edition (or SE One) for 1 processor, (such as one of these HP Proliant Server)and say after some months you increase the processors to 2. Will the Oracle software stop working on this server?
I need an answer soon.
Thanks all.

"Here, you have physically isolated all Oracle VMs to their own dedicated VMware DRS / HA cluster." How have you done this? Have you configured the SAN or something? Is it not the case that all ESX Servers on a network can be seen by Virtual Centre, and added as a resource to your "physically isolated" Oracle servers, through a relatively simple configuration change? Not a VMWare expert, so excuse me if this sounds simplistic.

Oracle have not been clear on this, all they say publicly is that they do not recognise Soft Partitioning as a way of reducing the number of licences required for any given server (by which they also mean cluster, even though they don't specify this).

As an ex-Oracle LMS consultant, I have asked their internal pricing and licensing team about this for a variety of customers. They, in their typically non-committal way, have responded with variations on this statement "The configuration of the SAN is unimportant. If Oracle is configured to run, it must be licensed".

Starting from the position that Oracle do not recognise VMWare/Soft Partitioning AT ALL as a way of controlling where Oracle is configured to run (it doesn't matter if it can do it, the problem is that Oracle don't recognise the way in which VMWare does it), I am not convinced that your "physical separation" would actually be acceptable, especially if it involves LUNs or something.

disclaimer: The opinions expressed here are my personal opinions. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.