Database Reference
In-Depth Information
all has performed well. Now a database comes along—one of the most resource-
intensive programs you will ever virtualize. This same environment where over
commitment of resources like CPU and memory has performed well will very quickly
see performance degrade to unacceptable levels.
It is important that the team has embraced this new way of thinking, where you ask for
what you really need to ensure resources are not being hoarded so they are available
more needy virtual machines. That they take to heart that, more can be had in terms of
resources, if needed, down the road quickly and easily.
Why Full Virtualization Matters
Just as there are different hypervisor types, there are also different ways of virtualizing.
VMware made a decision to not cut any corners and do a full virtualization
implementation of the hypervisor. VMware built a Type-1 hypervisor that means your
database will behave exactly as a database would behave on a physical implementation.
Another way of saying this is, the guest operating system does not know it's being
virtualized and requires no modification in order to run in a virtualized environment. It
also means that the many applications (such as a SQL Server database) running on the
guest operating system also do not know they are virtualized and require no
modification to run. In addition, the guest operating system and applications running on
the guest operating system will run the way they always have, with no surprises,
provided you allot them the resources they need. This in our opinion is a powerful
differentiator.
Okay, so for those vSphere admins reading this, you are right, the VMXNET3 network
driver and the PVSCSCI driver are “paravirtualized,” which means these drivers know
they are running on a virtualized stack, but the point is the operating system is unaware it
is residing on a hypervisor (more on that later).
Living a DBA's Worst Nightmare
We had a customer running a SQL Server database on a Type-2 hypervisor that utilized
paravirtulization. The customer had backups being done on this SQL Server database,
as you would expect.
We asked the customer if we could perform fire drills on all the production database
backups to validate them. We consider testing backups a best practice that should be
done at least once a year, at minimum, and quarterly if possible; you don't want an
entire year to go by and find out your backups for the last eight months are no good. By
testing, we mean performing an actual restoration to ensure that when you really need it,
it will work. The client made a business decision not to test the backups of this key
production SQL Server database.
