In the past several years, I’ve had the opportunity to assist many customers with their plans to virtualize their Oracle environments.  In almost every case, I’ve had to address the issues of licensing, performance, and support.  Since performance is a such a large topic of its own, I will address it in multiple future blog posts.  In this post however, I want to consider briefly licensing and support of Oracle on VMware, using Cisco UCS blades servers as the use case.

Licensing Oracle on VMware

For a topic that is continually debated and frequently misunderstood, Oracle’s licensing policy is actually very straightforward – Every CPU core in a server that is running Oracle must be licensed, as well as every CPU core in a server that is a member of a HA cluster, whose members are eligible to host an Oracle instance.  This is true when running Oracle on physical hosts or on virtual hosts.  This means the following must be considered in any Oracle on VMware design:

• Every CPU core on ESXi host that will be hosting Oracle VMs must be fully licensed.  This is true even if you only plan to run Oracle VMs on a subset of cores and other application VMs on other cores.  However, it also means that once all physical cores are licensed, you are free to run as many Oracle VMs or database instances as you wish on that ESXi host.
• Every CPU core of every ESXi host that is a member of an HA cluster where at least one Oracle VM is hosted must be fully licensed for Oracle, unless you use DRS Affinity Rules to restrict movement of Oracle VMs to a subset of licensed hosts in that HA cluster.

Based on Oracle’s licensing policies, here are what I consider the two best server hardware options available:

1. Use the largest server with the most available cores you can find and fully license that server for Oracle.  This is the best option for a customer who has their database designed in such a way that they can either host multiple Oracle VMs or multiple database instances on the same ESXi host.  In a Vblock, I would recommend either the Cisco UCS B250 M2 blades with 20 cores and up to 512 GB RAM or the B440 M2 blade with 40 cores and up to 512 GB RAM.
2. If hosting multiple Oracle VMs or multiple database instances on the same ESXi host is not an option or you don’t have a large enough Oracle environment to justify dedicating large multi-core servers for Oracle, then you could choose to use servers with fewer cores.  In a Vblock, I would recommend the Cisco UCS B200 M3 blades with either 4 or 8 cores and up to 384 GB RAM or the B22 M3 blades; the B22 blades can come with either 6 cores and up to 96 GB RAM or 4 or 8 cores and up to 48 GB RAM.

As mentioned above, every CPU core of an ESXi host that will or may host an Oracle VM (if part of an HA cluster) must be licensed even if you only intend to use a subset of cores for Oracle. This is due to the fact that Oracle does not currently recognize “soft-partitioning” technologies such as CPU Pinning or CPU Affinity Rules to partition CPU cores on a single host.  However, once specific hosts in an HA cluster are properly licensed, a customer should be able to design their environment in such a way that Oracle VMs will only run on those licensed hosts.

This means that customers have 2 option when it comes to HA design for their Oracle VMs, regardless of the type of servers they choose:

1. Create a dedicated HA cluster for Oracle where each host is fully licensed and every core will be used for hosting Oracle VMs; it doesn’t matter if this cluster will only host Oracle VMs or if other application VMs will be hosted as well.  I currently have customers who have 2 node clusters sitting alongside larger clusters that are used for applications other than Oracle.
2. Use CPU Affinity Rules to restrict movement of Oracle VMs to a subset of licensed hosts in a larger HA cluster.  The other hosts in that cluster can be left unlicensed for Oracle as long as VM movement is closely tracked and documented to ensure Oracle VMs do not move to a host that is not properly licensed.  Currently, Oracle does not have any stated policy regarding clustering technologies or Host Affinity Rules; so, the key is proper tracking of VM movement for license compliance purposes.  Tools to do this tracking include vCenter and vCenter Configuration Manager

Oracle disaster recovery design is a special case when it comes to licensing and often misunderstood.  Oracle’s policy is as follows:

• In a DR scenario, servers running Oracle at the DR site can run without dedicated licensing for up to 10 days of any calendar year.  It can essentially “borrow” the licenses from the production site for up to 10 days; beyond that time period, all DR servers that will host Oracle VMs must be fully licensed.  This policy allows for the production site to be taken offline for short maintenance periods or for DR testing without the need for additional Oracle licenses.  It also allows for business avoidance scenarios where a data center may be vacated for less than 10 days or an actual disaster where the production site can be restored in 10 days or less.
• If a customer chooses to fully license the DR site or Oracle has to run at the DR site for more than 10 days in a given calendar year, all ESXi hosts at the DR site, that are eligible to host Oracle VMs, should be fully licensed.

Oracle’s licensing policy can be found in their Software Investment Guide.

Support For Oracle on VMware and the Vblock

The challenge with understanding Oracle support of vSphere or the Vblock is the amount of FUD that exist and the fact that Oracle seems to be intentionally vague about their own support policies on this matter.  Part of the reason for confusion is the misunderstanding that folks often have regarding Oracle’s stance on certification and support.

First of all, Oracle has not certified any of its products to run on vSphere or on a Vblock.  That is because Oracle does not actually certify any third-party platforms below the operating system, such as the hypervisor or the hardware.  This has not prevented Oracle from supporting their products on vSphere, Vblocks, Cisco or HP servers, or EMC or NetApp storage.  The reason for that is obvious – they would lose customers en masse if they strictly required that their software can only run on Oracle/Sun hardware.

Second, Oracle has an official support policy regarding Oracle that states, “Oracle will only provide support for issues that either are known to
occur on the native OS, or can be demonstrated not to be as a result of running on VMware.” Since vSphere does not modify the guest operating system that it hosts, it is unlikely that an issue will be found that only occurs for an Oracle instance running on a VM.  In addition, VMware has a dedicated team that supports Oracle on VMware, who will take ownership of any support case if needed and drive that case to resolution.

Dealing With Oracle FUD

As I mentioned earlier, the FUD around licensing and support often come from Oracle themselves, particularly the sales organization.  I have been in several meetings where and Oracle sales team has stated or suggested that every server in a Vblock has to be licensed even if there is a dedicated cluster for Oracle VMs and/or that Oracle is not certified or supported on VMware or on a Vblock.  I’ve yet to lose an argument in such a situation and no one ever should, if they have the facts and understand the policies.  Here are some questions I would put to Oracle if FUD comes up regarding licensing and support:

• Does Oracle require customers to license every server on their SAN just because they share the same storage subsystem?
• Does Oracle officially certify any hypervisors or hardware platforms other than Oracles’ own products?
• Has Oracle ever refused support to any customer who is running Oracle on an non-certified platform, such as HP servers or IBM storage?
• Has Oracle ever refused support to any customer who decided to run Oracle on vSphere or Hyper-V?
• How many known support cases exist where an issue occurred, at the application or OS layers, while on a virtualized server that does not exist on a physical server?
• In what percentage of support cases did a customer have to reproduce the problem on physical hardware before the issue could be resolved?

Hopefully, this blog post will help provide clarity and encourage customers to continue in their journey to the Cloud, by giving them confidence to move forward with virtualizing Oracle. In future posts, I will cover the performance aspects of Oracle on VMware design.

For additional information regarding Oracle on VMware, visit VMware’s “Virtualizing Oracle with VMware” webpage; there you can download the “Understanding Oracle Certification, Support and Licensing for VMware Environments” white paper.  I’ve also found several of the VMware Communities Roundtable podcasts to be particularly helpful.  I recommend listening to the “Virtualizing Oracle” and “Oracle DB on vSphere” episodes.

Related articles

• Fight the FUD – Oracle Licensing and Support on VMware vSphere