Database server virtualization wars: VMs vs. Oracle RAC

Database server virtualization is always tough. Should you put multiple VMs on one machine or spread your database instances across several servers?

Independent Oracle Users Group

Virtualization is all the rage. Call it the cloud, VM, increased utilization, consolidation or your own favorite term, it is the focus of a lot of effort in all IT organizations today. In this article, we will provide a discussion between two battle-hardened IT pros from the Independent Oracle Users Group, comparing the flavors of database server virtualization and pitting VM technology against Oracle Real Applications Cluster (RAC). Do you consolidate multiple databases to a single server running one operating system? Or is it better to run a virtual machine layer and have multiple virtual servers each running individual databases?

Gary Gordhamer: Let's start off with virtual machine technology like VMWare, Oracle VM, KVM and VirtualBox. This database server virtualization technology provides some of the quickest ways to bring up a full database server with complete isolation, controlled performance, a high degree of reliability and using low-cost hardware. I'll use the terms host for the physical server and virtual machine or VM for the virtual server throughout this article.

Arup Nanda: Let's not forget consolidating multiple databases on a single piece of hardware. This reduces the number of physical systems, hence reducing the number of sysadmins needed. It reduces the data center footprint, using less cooling and energy. But perhaps the biggest benefit comes from servers using CPU cycles more effectively, especially if the databases don't demand hardware resources at the same time.

Gary GordhamerGary Gordhamer

Gordhamer: With VM technology, I can consolidate many small hosts into one larger host container. In doing so, I can increase my CPU utilization and reduce my hardware footprint even more. This kind of database server virtualization lowers the overall costs and gives everyone the performance they need. Plus, with the redundancy features in VMs, I can automatically move VM guests across failed VM host hardware with almost no downtime, providing redundancy with no additional database technology.

Nanda: Using RAC, you can also move database instances across different physical machines. It's not as trivial as moving a VM, but that's a technology that has been around a very long time, and it works. Besides, with VM, you can't actually move VMs seamlessly. There will be downtime, no matter how small, in the entire database. With RAC, you can move to a different physical server one instance at a time without a full outage.

Gordhamer: Well, with VM technology, I can control my license usage and performance needs by capping the CPU and memory on individual VM guests and sharing VM host resources. This helps me provide better performance with the least amount of hardware costs, including the added benefit dynamically changing these settings.

Nanda: I wouldn't be so sure about licensing. Most database vendors have some sort of multiplier on the VM-centric servers, diluting license usage savings. But don't forget the most important task of all: managing the VMs. With a physical machine, the hardware usage numbers are pure, clear and unambiguous. In a VM world, the data on the virtual resources utilization is difficult to interpret and easily subject to misinterpretation.

Gordhamer: OK. So maybe VM guests are not the best for every workload, but database server virtualization is one of the fastest ways to bring up new databases. You can clone a VM, or use a template that has DB software installed, patched and ready to go. And cleanup is simple. When you are done, you delete the VM and away it all goes.

Nanda: With RAC, you can rapidly add a node. Using response files, you can bring up a new database altogether rapidly. If you love that GUI thingy, just whip up Database Configuration Assistant (DBCA) or Enterprise Manager; it can do these for you.

Gordhamer: You can move VMs from one environment to another, so once a full application is configured in a VM (or made into a template), it could be easily replicated to production. This deployment method is also a one-time kind of movement in general. Databases are constantly changing, so you can't "redeploy" the VM guest to production without taking very special care of your data or having a unique design.

Arup NandaArup Nanda

Nanda: Speaking of rapid deployment, you are absolutely correct: A very high degree of maturity is a must-have for a perfect VM-centric world. Entertaining the thoughts that such a perfect world does exist, why can't the maturity be applied to a non-VM-centric organization using the same rapid deployment and provisioning techniques?

It sounds like, either way you go, there are benefits and tradeoffs to all kinds of database server virtualization. Well, let's wrap up this conversation with some parting comments.

Gordhamer: Modern database server virtualization technology (mostly x86) provides a quick and reliable method to manage multiple different generic workloads. The tools and technology have advanced far enough to provide rapid deployment, high availability features and quick adoption with limited training and knowledge. There are still limitations in total capacity and dealing with granular patching, management and image/data refreshing.

Nanda: When choosing a technical platform, you should first settle on priorities -- be on a platform a majority uses for consistent, reliable (bug-free) experience, or be on the road less traveled, getting higher returns with some risk. The former is especially relevant in production systems where RAC on VM is not very common. For non-RAC databases, you may want to put a lot of nonproduction systems in the VM world to squeeze every ounce of juice from the underlying hardware, but you also sacrifice the ability to prevent cross-machine issues effectively. In the end, you have to decide for yourself which of these competing priorities is more important in your specific case.

Arup Nanda is the principal database architect at a major  international corporation based in New York and has been an Oracle Database technologist for the last 18 years, touching upon performance tuning, disaster recovery and everything in between. He is an Oracle ACE director, a member of the Oak Table Network and was Oracle's DBA of the Year in 2003 and Architect of the Year in 2012.

Gary Gordhamer is currently a senior ERP DBA with GE Power and Water. He has more than 21 years of IT experience in the field, working in various areas, including database administration on Oracle in every version since 6.x and all the related infrastructure and application technologies used in the database ecosystem. Currently, he is focused on database virtualization, performance and security in the context of industrial manufacturing.

Next Steps

How to create services for an Oracle RAC database

Dig Deeper on Oracle virtual machine