Posted by Disclaimer: I am not an expert on Oracle RDBMS licensing. Please verify any and all licensing statements about IBM or Oracle before relying on them. I am likely biased towards IBM, having based my career on them, but am not an IBM employee.
My husband happens to be a Virtualization Architect. This is a particularly useful person to have in one’s home to help navigate some of the virtualization topics that DBAs must visit without being experts. It was my husband that first brought Oracle’s licensing stance for virtual systems like VMWare to my attention. From what I’ve read, it sounds like when licensing Oracle to run on VMWare, one has to license every single CPU on any host server that the VM could possibly reside on. This is a particular headache for some VMWare admins and engineers because it means they have to design their layout around minimizing licensing costs rather than around what works best for providing resources to the multitude of VMs in most modern enterprises.
I’ve done my homework, and while some sources seem to disagree, the majority seem to take this approach to licensing Oracle RDBMS on VMWare. This is my main source from what appears to be an Oracle RDBMS licensing expert. Essentially, it feels like when you went to park in the Oracle garage, they’re going to charge you for every space, even though you only used one, because you could have parked anywhere. I’d love to hear comments and real world experiences with this.
The ease of licensing DB2 in virtual environments, by comparison, has been covered before. But as the difficulty and expense of properly licensing Oracle on VMWare was a surprise to me, I thought I’d share.
Licensing DB2 on Virtual Servers
Generally, a number of sub-capacity licensing FAQ’s for IBM DB2 are covered here. The general gist is that for DB2, the CPUs you must license are the lesser of either the CPUs allocated to the VM OR the number of cpus on the host. That means if you are over-subscribing CPUs and have hosts dedicated to hosting DB2 VMs, then you could save money by just licensing the physical CPUS. But in the much more common scenario where your DB2 servers reside on a shared VM infrastructure, you only have to license the number of CPUs allocated to the VM. Can this number change with time? Sure. If you increase them, you must make sure you are in licensing compliance.
Simplification with DB2 Direct on DB2 11.1
This approach already seemed fairly easy and logical to me. However, sometimes the power of the CPUs matters. Different CPU models have different PVU values from IBM – generally the PVU count is higher for a more powerful CPU. This means that you can’t get around licensing costs simply by buying fewer, more powerful CPUs. In my experience, virtualization engineers tend to keep the power of the CPUs balanced, but it is possible that a VM could move from a host with less powerful CPUs to one with more powerful CPUs, and lead to being out of compliance on your PVU counts. With DB2 11.1, IBM introduced DB2 Direct Standard Edition and DB2 Direct Advanced Edition. These editions introduce the concept of a VPC or Virtual Processor Core. There are no differing PVU values here – no matter the power, a CPU is a CPU. Public cloud or private cloud servers would be the same. These editions are billed at a monthly rate instead of a one-time purchase plus annual support and licensing fees. This makes them all the more flexible. Need more cores to support a peak period? No problem, add them for a month or two, and then take them away when you’re done – you pay the licensing only for the number of VPCs you had allocated each month.
Geeze, I’m Starting to Sound a Bit Sales-y Here
While it may sound like I’m trying to sell you IBM software, IBM has been working hard to build compatibility for applications written for Oracle on DB2. With a parameter or two, you can enable this functionality in ANY edition of DB2, including the free Express-C. Affinity for a particular database platform is often very much ingrained in an organization. It is tough to go into an organization that has personnel and infrastructure dedicated to one RDBMS and convince them to move to another. Having based my career on IBM DB2, I am obviously biased when I say I believe that DB2 is the best RDBMS in most situations. And bonus, it runs beautifully, for less in virtual environments.
This is also a good topic for DB2 DBAs to be aware of, since many DBAs have to work on multiple database platforms.
