VMware: Interesting Possibilities

One of the neatest things that virtualization offers the DBA trying to optimize or tune a database is the ability to leverage the flexibility of virtual machines to make some interesting possibilities a reality. We will examine some of the more common examples.

Divine Isolationism

In politics it may be a fundamental mistake to practice isolationism, but for database tuning efforts, it might yield substantial insights otherwise not available. Assume you have two databases, X and Y, on one physical server and that one or both are having problems. Now you could try to tune the problematic databases in place, or just as easily relocate one of the virtual machines to another server. There are two immediate benefits to this approach. First, you are obviously tuning databases one at a time. Sometimes it is easier to tune them separately and then put them back together to see how well they play together once individually tuned. Second, you can instantly identify a problem that is solely due to cohabitation. If either database performs acceptably after the relocation, then you can reasonably ascribe the performance problem (or at least the bulk of it) to sharing that server.

Dueling Databases

Sometimes two databases will behave perfectly fine when isolated but cannot seem to cohabitate together on one server. So in that case, you must either separate them or try to optimize the underlying problem by tuning them in conjunction. You are then forced to tune them together or relocate them permanently away from each other. Assuming you try to tune them together, you are in for an interesting challenge that reminds me of the mythical pushmi-pillyu (see picture below) beast from the 1967 version of Dr. Doolittle. Yes  - I am dating myself!

I brought this up for a reason. I am not sure how a llama with two front ends was supposed to walk. Likewise, I am not sure what the value in cohabitation is if it is simply easier and cheaper to relocate. That is the real beauty behind database virtualization. You can treat their servers as nothing more than general purpose resource pools. When one pool seems uncomfortable, too full or otherwise unfriendly, just move on.

Upgrade Heaven

A serious and often unnerving task many DBAs face at some point is that of hardware upgrades. In the old days, that almost always meant that something significant was changing that would affect your Oracle database. For example, I might move my Windows database server from an Intel based motherboard to an AMD based one. Many times, changes like these would require properly moving the database from one platform to another and often with some platform specific issues to address. But with virtualization, you avoid that problem most of the time now. Since the hardware has been abstracted or virtualized, you can relocate the database and be up and running by simply restarting the virtual machine. This one item alone may free up a few three-day weekends spent doing such upgrades.

RAC Smack Down

With the general consensus being that RAC is only as strong as its weakest link, namely the interconnect, many DBAs spend inordinate amounts of time trying to completely tune that one aspect of their cluster. Sometimes they spend so much time on this one item that they do not move on to other more pressing issues. So here is where virtualization can assist RAC optimization efforts. You might not want to deploy a RAC setup where one physical server hosts multiple RAC nodes/instances. But you can with the benefit being that there will actually be no interconnect going over a network, but rather all being performed in memory. So if you tested this way and there still was a major performance problem, you could immediately deduce that it must be somewhere other than the RAC interconnect. Being able to eliminate such issues so readily makes RAC deployment actually less fearsome. That alone makes virtualization worth serious consideration.

Distributed Nirvana

Very similar to RAC, you have a distributed or replicated database where performance is an issue. Once again for performance testing purposes, you could co-locate them to eliminate the network issue. That might more quickly lead you to the often suspected bottleneck, and as a result, permit you to find the true underlying problem. So, if my two-phase commits or snapshot refreshes are still having problems once the network is eliminated as the possible cause, then it must be something else. That knowledge alone is quite often worth its weight in gold. The same technique can even be used to resolve suspected DBLINK performance issues.

Dynamic Databases

It is very tough to initially size a database servers needs. Sometimes even once the database has been built, the growth rate or retention period is sometimes radically different than initially planned. So it is quite easy to over- or under-order on your hardware. But with virtualization and the general ability to assign resources based upon true current need, DBAs now have the ability to increase or decrease database resources via the abstraction layer. This is infinitely easier and cheaper than doing it in stand alone hardware. Therefore, a new tuning and optimization discipline emerges, that of right sizing the hardware on an ongoing basis. That is really never been feasible before.

Database Grids

I am hoping that with the adoption of virtualization, another long standing dream may finally be realized shared corporate data. What I mean is singular, centralized databases containing one true copy of mission critical data. Think of this as normalization at the highest level. I have seen many companies where the customer  table is implemented fifteen different ways within their distinct business units or lines of business. So the data architecture group gets them to agree on a standard definition, but that still results in at least fifteen tables that essentially contain the exact same data. Imagine my surprise when one financial company I dealt with said that I had to send seven change of address cards to their various business units in order to actually completely effect the change. Needless to say, I switched to a new financial company. I am hoping that down the road (not there quite yet), organizations may actually start to collapse all those duplicate copies of tables as subject area virtual machines. That would have two tremendous values to their customers: having a single copy of accurate data that can easily be changed at one time and place and the companies would benefit from reduced scrubbing/cleansing of the data between systems. As for the reduced disk space, at $50 per gigabyte, that is just not a factor for consideration.

Conclusion

In this chapter, we examined many of the techniques, backgrounds and other diverse issue related to database optimization. There are many great papers and books on these topics and most will apply fairly well within the virtualized database world with a few minor exceptions. Furthermore, virtual databases add some interesting new wrinkles and possibilities to the equation. But through the application of a simple technique that combines the best of many other techniques, knowing when to quit, meaning that SLA has been met, and by leveraging virtualization to augment our tuning repertoire, we should be able to successfully deploy Oracle databases of any kind on virtual servers. In fact, given some of the benefits possible, we actually should prefer it!

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