Five reasons to choose VMware vs Oracle Multitenant

While busy preparing another blogpost on my dedupe analyzer tool, I was triggered to write a quick hotlist of reasons why one would strategically choose VMware virtualization over Oracle multitenant option if the goal is to achieve operational and cost benefits. There may be other good reasons to go for Oracle Multitenant but cost savings is not one of them.

On twitter I claimed I could give 5 reasons why, so here we go…

WARNING: Controversial topic – further reading at own risk 😉

So why is Oracle Multitenant not the best choice when you try to achieve some control over license expenses and the operational environment?

1. Direct & indirect license cost: The Multitenant option costs $17,500 per processor (per 2 CPU cores on Intel x86) – direct license cost – so in order to achieve cost savings you first have to add 37% on top of of the base Enterprise Edition license ($47,500 per processor). You probably also need additional licensed manage pack options. Then, multi-tenant still doesn’t achieve high CPU utilization like you can with VMware, so it still wastes precious license investments. Note that Multitenant is not available for Standard Edition (2) at all. Of course VMware is not for free either but the cost difference is huge (and getting worse as sockets get more cores)
2. Every pluggable database in a container database shares Oracle software (ORACLE_HOME, the “binaries”) and the software patch level, so one pluggable database requiring a patch or other fix (a change in init.ora settings for example) potentially affects all other pluggable databases (worst case, causing downtime or other problems)
3. System resources (Memory, IO, redo logs, networking, etc) are also shared (noisy neighbor syndrome) so it requires additional workload management and performance tuning to maintain service levels
4. Security – The DBA has full access to all pluggable databases in the container, and so does the OS administrator (root). No way to isolate environments from each other. One may argue that the VMware administrator has similar access to all VMs in the VMware cluster and that’s a valid point, but the control over individual VMs can be much more fine-grained. If the VM admin does not have the root/dba passwords then all she can do is get access to the raw disk/memory images and that makes the risk on abuse, data theft, or accidents, much, much smaller
5. Live Migration (VMotion in VMware language – the capability of moving a virtual machine to another server without any noticeable interruption) to another container database is not really possible (or it takes a very complicated mechanism requiring full data replication first, followed by a failover – causing long running batch jobs to abort and possibly some dips in OLTP availability as well) and cannot be automated based on actual workloads like with VMware HA/DRS (this is the main reason for not achieving high CPU efficiency). You could however run RAC  (Real Application Clusters) so that instances can move to other nodes – but that requires another $23,000 (48%) per processor, causes performance impact, requires expert tuning skills and you’re still limited to the same (now RACified) container

One point of confusion is, that as of Oracle 12.2 ALL databases must be deployed as container/pluggable combo (at least on Enterprise Edition). Sure, but as long as you keep one PDB per container then the additional license cost is not required. So claiming that multitenant is mandatory is false. Another reason I hear often is that Multitenant allows sharing of RAM between databases which is not (entirely) possible with VMware and that’s a valid point – however, RAM is cheap these days and database licenses are not. Are you willing to spend the extra 37% on licenses to save on RAM? Realizing that such sharing can also increase the noisy neighbor syndrome mentioned above?

I can think of a few more reasons but let’s stick with the top 5 for now. I can also think of some reasons why multitenant could be useful but there’s been enough bragging by the marketing guys already so I’ll leave it with this.

And yes – I am a VMware fan when it comes to Oracle databases – not just because it’s part of our company but mostly because it just works, has good integration with 3rd party products and is stable (and the license problem FUD can easily be avoided). That said, if you can achieve the same CPU efficiency (= cost savings) with another (virtualization) platform, then I fully endorse that (hence the name of my blog). There are good alternatives (IBM pSeries for example). But beware of the trojan horse effect: getting a “free” hypervisor from the vendor that sells the database license may not get the desired effect (for both technical and political reasons). Which makes sense if you think about it:  nobody kills their own Cash Cow.

So for all CIOs out there trying to optimize your license costs: choose wisely. And feel free to contact me if you appreciate further explanation.

This post first appeared on Dirty Cache by Bart Sjerps. Copyright © 2011 – 2017. All rights reserved. Not to be reproduced for commercial purposes without written permission.