Database Reference
In-Depth Information
When you build the virtual machines, keep this in mind as you make the many choices
you have available to you. Don't install features of the Windows operating system you
will never need, and don't install features of the database you will never need. Also,
disable all unnecessary foreground and background processes you don't need; by doing
so, you will keep the VM as lean as possible.
When building a virtual machine that will house a production database, it is
recommended that you build it from scratch, not using the P2V converter. A database is
a very complex environment, and experience has taught us that over time the
environment can be become very cluttered with components that are no longer needed.
Use this opportunity to create the new database environment as lean and clean as
possible.
More VMs, More Database Instances
One of the questions we get asked at conferences by database administrators is, “Is it
better to have more virtual machines, or one or two virtual machines that house a
number of database instances?”
In
Figure 7.12
, we illustrate the two configurations. On the left side, we have one virtual
machine that hosts three SQL Server instances, whereas on the right side, we have three
separate virtual machines, each hosting an individual SQL Server instance. There may
be licensing issues that require you to use one configuration over the other. But if we
take licensing out of the equation, our experience has shown us that it is better to
implement with more distinct virtual machines, as illustrated on the right in
Figure 7.12
.
Figure 7.12
More VMs versus more database instances.
A SQL Server database is one of the most resource-intensive applications you will ever
virtualize. By implementing each production SQL Server database as a separate virtual
machine, you will have much better control over how resources such as memory are
utilized.
For example, if you had three SQL Server databases on one virtual machine—let's
