Database Reference
In-Depth Information
Tip
Test each database backup by doing an actual database restoration at least every
quarter.
The customer had a mission-critical third-party application they ran their business on
that required updating. The application and the database ran on a virtual machine. An
upgrade plan was put in place. As part of this upgrade, we had to take the most current
backup and restore the database onto a new virtual machine, and then proceed with an
upgrade of the application.
When we attempted to restore the database on the new virtual machine, it would not
work. We double-checked the backup logs to see if there was a problem with the
original SQL Server backup. Every indication we had was there were no issues. We
then decided to do another full backup of the production SQL Server database and apply
that to the new virtual machine. No matter what we did, we could not restore the
database. We could not find a problem anywhere with the backups that were being
performed.
This was a production SQL Server database where the backups were being taken with
no errors, yet would not work on the restore. As a database administrator, this is a
serious problem—and a DBA's worst nightmare. We immediately opened up critical
tickets with Microsoft, the vendor that provided the hypervisor, and the third-party
application vendor. When we got the answer, we nearly lost it. This was a known
problem when a SQL Server database was being virtualized on this vendor's
hypervisor. The virtualization vendor did not have any workarounds and acted like this
was not a big deal.
From a DBA's perspective, this was a huge problem. By altering the operating stack,
they had created a situation that could have put the company out of business. Because the
database was running on a Type-2 hypervisor, the database was running differently than
it would have on physical equipment. The combination of the alterations to the operating
system and the lack of full virtualization created this very dangerous situation.
When you virtualize a database, make sure it's on VMware vSphere, which has been
proven by hundreds of thousands of customers successfully running mission-critical
systems. vSphere is a full-virtualization implementation and does not alter the
operating stack in any way. This means the virtualized database will perform exactly
as its counterpart on physical hardware, and you won't ever have to worry about your
database backup not being valid like our customer experienced in this example.
Do not confuse a paravirtual hypervisor with paravirtual drivers. Paravirtual drivers
are built to optimize performance in a virtual environment. In our experience, you
should take full advantage of these drivers where it makes sense. A great example of a
 
Search WWH ::




Custom Search