The obvious question or bone of contention between these two key alternatives is performance. And yes, the vendor provided hypervisor is probably always going to be faster choice. This topic will be more thoroughly examined with empirical benchmark results in Chapter 8.

The question really becomes one of total cost. If I have Windows or Linux system administrators who already know how to configure the database server hardware routinely used, if I already have or know where to go for drivers and updates, and if I?m just more comfortable with not introducing yet another new technology to embrace, then the cost savings on the staffing side alone could radically outstrip the meager savings on the software itself. Also, VMware permits one to move up as business requirements demand, so what's there to lose?

Besides, the recent trend of substantial and growing hardware performance improvements, which also happens to be why DBAs are now doing so much virtualization, means that reasonable overhead is now quite acceptable. Also, the bar to clear for being considered reasonable is lowering almost daily.

For example, a single database server from just five to six years ago cost four to five times as much as a server today - and today's servers come with multiple multi-core CPUs and lots of memory. So a 10-20% overhead is not that big of a deal anymore on a machine that has so much raw capacity that you?re going to virtualize it into multiple machines. Today's hardware is just too inexpensive and fast to make this the sole decision criteria anymore. We truly live in great and interesting times.

An analogy might help here. Back in the 1970's oil crunch, automobiles got much worse fuel mileage and air conditioners were often an afterthought in terms of the car's overall engineering, i.e. efficiency.  So driving with the AC on was doubly expensive. But today's cars get much better gas mileage and the air conditioners now have been engineered from the ground up as a key component of the vehicle. Hence, even though oil is nearing $100 per barrel, I don't think we?d consider driving with the AC off like we did back in the 1970's to save a few percentage points. Today, we value our comfort more and the cost is far much less. In short, we ignore the overhead because it's no longer relevant.

That's really not as cavalier an attitude as it may seem. Person hours cost so much more now than computer hardware (even with inexpensive offshore outsourcing), that it is sound business these days to throw cheap hardware at problems. It is at least, if not more, cost effective than having the staff tuned and optimized for the same net effect.

Besides, a failed tuning and optimization effort leaves you exactly where you started. At least the hardware upgrade approach leaves you with a faster/better server experiencing the same problem that may still have future value to the business once the fundamental problem is eventually corrected. And if nothing else, the hardware can be depreciated, whereas the time spent tuning is always just a cost taken off the bottom line. So, with such cheap hardware, it might be a wiser business bet to throw hardware at some solutions sooner than we did in the past. We might even go so far as to make an economic principle claim that the opportunity cost of tuning is foregoing cheap upgrades that might fix the issue and also possess intrinsic value. Stated this way, it is a safe bet that is where the business people would vote to spend.

The only reason I am stressing this hardware-first attitude is that, in the virtualized server world, it is generally best to think of hardware resources as just assets that are deployed when and where they are needed as they are needed. Also, a viable business solution is simply to deploy more assets as needed. Since the concept of the server (the asset) is now virtualized, it could well mean just assigning more CPUs or memory from a virtual pool to a particular virtual machine. In the virtual world, we no longer have to think in terms of the physical constraints of a particular server. We must also abstract our thinking - which leads nicely into our next topic.

This is an excerpt from Oracle on VMWare: Expert tips for database virtualization by Rampant TechPress.