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
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: 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.