Overview
What do politicians, statisticians, pollsters,
benchmarks (even industry standard database benchmarks) and the
cartoon above all have in common? Namely, that they can be easily
manipulated to tell you what you want to hear. That does not mean
that they do not have value. Nor does it mean we should skip or
totally ignore them. It just means that we need to weigh each within
their appropriate context and with some level of overall skepticism
as to general applicability. The same is equally true of this
chapters material.
I am not going to present facts and figures to
convince anyone to follow any particular course of action or setup
configuration. I am merely going to present enough material so that
readers can see and deduce that virtualization alternatives are both
reasonable and manageable. Yes, all the benchmarks within this
chapter could have run faster without the additional overhead
virtualization necessarily introduces. But then you would not
realize all the other many benefits that have been examined thus
far, especially not the increased flexibility, which often is enough
justification by itself for many people given todays cheap yet
powerful hardware. So the goal here is to convince you that
virtualization is a viable alternative for your database
infrastructure possibilities. Then it is up to you to verify whether
it actually is a good fit or not for your particular project needs.
The Benchmarking Process
The science of benchmarking is sometimes better
practiced as an art. What I mean is that simply and/or blindly
running industry standard benchmarks like the TPC-C, which mimics
OLTP (online transaction processing) workloads, might be reasonably
expected to yield conclusive results. But there are so many variable
factors in the hardware and software configurations that people
often obtain unexpected, non-repeatable or just plain wrong results.
That has, in turn, led to much skepticism regarding the science.
When doing database benchmarks on simple non-RAC
and non-virtualized databases, I tell people to allocate double the
time they think it will take to run the benchmark in order to
properly configure and tune all the components that contribute to
the overall performance result. So if they think it will take a week
to run the tests, allocate three weeks to complete the entire
project. That usually loses most peoples attention or buy in
which is too bad, because most failed benchmarking projects are
simply due to improper planning for time.
The second greatest contributor to significant
benchmarking problems is confining ones scope of the project to
just the database. Contrary to some DBAs who subscribe to the
Galilean logic that the world revolves around their Oracle
databases, that is not the way to successfully benchmark. If people
doing benchmarking do not fully understand and optimize every
contributing portion of the entire technology stack, then the
results are relatively worthless. I have seen far too many
benchmarking projects deemed a failure where the team had no idea
how their disk LUNs were allocated, what stripe depth and width they
were using, how many physical spindles their database had access to,
and many other key critical success factors. Yet they fully expected
to arrive at meaningful results.
Virtualization by its very nature adds another
level of abstraction, and therefore, more moving parts. Complete and
intimate knowledge of the entire technology stack is even more of a
must in this complex scenario. So the next two sections are going to
address some benchmarking quick bites, best practices, and
recommendations. For a more thorough review of benchmarking, I
recommend the following book: Database Benchmarking: Practical
methods for Oracle & SQL Server [ISBN 0-9776715-3-4].
This is an excerpt from
Oracle on VMWare:
Expert tips for database virtualization
by Rampant TechPress.
and include the URL for the page.
