Were not quite done just yet. If all these levels of increased abstraction were not enough, there is yet another wrinkle to this new and overly complex environment in which DBAs must now function. With the specialization and/or segregation of job responsibilities typical in many enterprise information systems areas these days, a DBA might have to talk to three or more people to implement a database within such a virtualized environment as Figure 7. So a DBA might have to talk to people whose various roles and/or titles might include:

• Storage Administrator
• Network Administrator
• Operating System Administrator
• Virtualization Asset Administrator
• Infrastructure Architecture Consultant

And as we all know, the lines of communication grow exponentially based on the number of people you have to work with to get a job done. The communication complexity formula most often quoted is:

Lines of Communication = N * (N 1) / 2

Thus, the DBA has some 30 distinct lines of communication with just the few additional people listed above. That means more email, more phone calls, longer meetings, less agreement and, often, longer times until a consensus is reached. So the DBAs job is made that much more difficult, especially when you consider that good DBAs tend to be heads down technical experts who would rather just do the work than sit around and talk about it.

Host Impacts

How true the above cartoon rings since every DBA feels like they're wearing such a target. Furthermore, many DBAs feel like all those who are shooting arrows have the rapid-fire crossbow from the 2004 Van Helsing movie. Because when the fecal matter hits the fan, the DBA stands at the forefront and foremost against the ensuing onslaught. At times like that, just remember we chose this profession.

But the above cartoon rings true for another reason in the virtualized world; namely, the onion-like nature of the abstracted technology layers upon which weve built our databases. The center ring (i.e. the one with the highest point value) is our virtual host, and we can score our most valuable tuning and optimization goals by maximizing the raw performance of that host. The mantra in the virtualized world is that any database server guest can be no more optimized than the host containing it, so always make sure to get the host right from the start.

Also, remember that optimizations made to the host will apply to multiple database guests, so you are double-dipping in terms of benefits realized. Often, fixing a host performance problem whose symptoms are realized by optimizing that host for just a single guest can translate into improved performance for most, if not all, the guests running on that host. All of that can be accomplished for the singular cost of finding and tuning that one issue centrally.

Furthermore, highly shared hosts (i.e. those with the more guests) will realize cumulative magnified improvements and, thus, triple-dipping in terms of benefits. For example, a host with four database servers is having some performance issues. By tuning the host using one database guest as the test subject, you find that a host change can provide a 10% improvement. However, once that host is running all four of its guests once again, the observed improvement is magnified by the fact that the benefits are realized globally and concurrently. So, in effect, that single 10% may translate into much more than 10% net.

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