Database Reference
In-Depth Information
in a timely order.
The design goal is to run your SQL Server virtual machines with enough virtual CPUs to
satisfy peak requirements, and not a single virtual CPU more. By adding unnecessary
virtual CPUs to the virtual machines, you make the hypervisor's job of scheduling more
complex, and this may cause unnecessary delays in the scheduling of your virtual
machines, thus introducing unnecessary performance issues.
Tip
It is important to understand how the current version of vSphere handles
scheduling of virtual CPUs. To learn more, read this whitepaper:
Perf.pdf
.
For those who are looking to migrate physical databases into vSphere, a good starting
point is VMware Capacity Planner. Run VMware Capacity Planner against the target
servers to get an understanding of the current CPU workload. It is important to
understand the sample intervals for which VMware Capacity Planner has been
configured and whether this meets the cyclical nature of the databases under analysis.
The last thing you want is your analytical tool to miss a workload spike inside the
database because it did not fall within the sample interval. Several analytical tools are
available to perform this analysis, so be sure to choose the right one. We recommend
SQL Server System
.”
Note
Use the right tool that will capture the peaks and valleys of the target
database server's resource utilization. In addition, understand what level
the tool operates at: the entire server, SQL Server instance, or individual
database. If you miss peaks, you risk undersizing your virtual machines and
the physical hardware required to run them successfully.
From a design perspective, a typical starting point is 2 vCPUs:1 physical core. As you
increase the number of vCPUs in your virtual machines, this starting point will require
adjustment due to the requirements necessary to schedule this virtual machine's vCPUs.
The previously stated numbers are to be treated as dynamic and not as definitive
guidance or used as a benchmark for density. This is a starting point that should be
adjusted up or down based on workload, processor type, processor speed, and other
factors. Remember, our guidance is to always start conservative with Tier 1 workloads
such as SQL Server. It is always easier to add additional work to a physical server than
