Reasonable Choices

As was briefly pointed out in the prior chapter, there are at least five significantly different technologies for implementing virtualization.  Each has their pros and cons, especially with respect to database performance or throughput. However, only two of them are the subject of this book: Paravirtualization and Full Virtualization, as shown below in Figure 1. The restriction was chosen for the simple reason that these technologies and products from VMware permit one to intermix and upgrade or downgrade between them as one sees fit. That is maximum flexibility and portability, which is always highly, if not most, desirable. Plus, it provides a single vendor solution that also happens to start as freeware for low-end servers and developer machines. Therefore, it offers higher market adoption and a commanding market share, both of which contribute to easier staffing. It is available on two of the most common operating systems: Windows and Linux.

Figure 1:  Paravirtualization and Full Virtualization

Contrary to popular belief, both these methods are really nothing more than software solutions that fundamentally accomplish nearly the same end result. In the case of VMware Server ESX, the hypervisor is really nothing more than their own radically pared down, stand-alone operating system that has been specially design and optimized to run virtual machines. Think of it as a mini-OS, with drivers to talk to hardware components like network cards, storage devices, etc. And since it is from the virtual solution provider, you can rest assured that its truly both an effective and optimal solution. But that comfort zone comes with a cost (i.e. $$$).

Now look again at Figure 1 and see that the freeware server product is essentially the exact same solution where the hypervisor is your own operating system install. So, if you pair down that OS to its barest minimums, with the least overhead and excess of features enabled, you would essentially have your own hypervisor. It may not be as efficient or nimble as the excellent hypervisor available from VMware, but its both doable and 100% free. Moreover, you can easily upgrade from your own OS to their hypervisor solution anytime you like.

So what does all this virtualization mean to our standard perception of the Oracle database architecture as shown in Figure 5?

Figure 5:  Oracle Database Architecture

Let us go back to the most fundamental definition of the term database: the Oracle processes, memory and files. If we zoom out, the picture becomes just four fundamental components: shared memory, processes that are stand alone, processes that access files or devices, and files or devices, as shown in Figure 6.

Figure 6:  Database Components

Now lets combine full-virtualization server (right side of Figure 1), Oracle ASM database instance (right side of Figure 3), virtualized storage (Figure 4), and the high-level Oracle architecture (Figure 6) to form our overall Oracle architecture in a virtualized world as shown below in Figure 7. This will also serve as our primary example throughout the rest of this book of deploying Oracle on a virtual server. Remember this way it is free and we can always scale up.

Figure 7:  Virtualized Oracle Architecture

That is certainly of a lot of moving parts! If that is not bad enough, then think of how the picture would change if doing RAC. The one concept that this picture should clearly communicate is that in the virtualized world, nothing maps one-to-one anymore. So we cannot assume too much, especially as it relates to the assignment of the underlying hardware assets.

Virtualized Oracle Architecture

So why did we spend so much time correctly visualizing the overall architecture in Figure 7? Because we cannot optimize or tune what we cannot comprehend; therefore, we need to see it. For example, in the old days, DBAs might have looked for disk hot-spots as part of their standard tuning regimen. But look again at Figure 7; we really cannot point to the spindles anymore because they are multiple levels of abstraction removed. In fact, most database and operating system monitoring tools cannot see behind this veil of abstraction. So how would we look for a hot disk and should we even try?

The point is that we cannot approach database tuning and optimization as we did before. Not only can the resources allocated dynamically change over time; but furthermore, we cannot even really see the actual resources were being allocated when they are static. This picture makes it very clear that we must tune differently, which I will cover more fully in Chapter 9. In order to grasp and affect those new tuning/optimization techniques, we must always measure performance metrics and ask questions about them with the complete virtualized picture in mind. Otherwise, much like a confused dog, we could chase our own tail to no end.

Lastly, none of these issues means that we cannot effectively tune an Oracle database on a virtualized server. It just means we have to tune smarter with current and future asset allocation always in mind.

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