Databases Reference
In-Depth Information
SQL Server 2012 and Virtualization
Many people ask me how SQL Server behaves when it's virtualized. The answer is that it should
behave no differently to when it runs on a physical server, especially when it's deployed in a properly
resourced virtual environment, just like you would do with a physical server. However, virtualized
instances of SQL Server still need adequate, and sometimes large, amounts of CPU, memory, and
storage resources in order to perform well. The challenge with virtualization is making sure the
resources SQL Server needs to perform adequately are always available to it.
Additionally, virtual servers running SQL Server can benei t from some of the features that
encapsulation brings, which we've just discussed; however, it's at this point that some virtualization
features, such as snapshotting a virtual server, which we'll discuss later in this chapter, Microsoft
does not support using with SQL Server.
However, regardless of all the resource allocation activity that happens between the physical
server and virtualization software, it's true to say that SQL Server itself does not change its
behavior internally when run in a virtualized environment. That should be reassuring news, as
it means that SQL Server will behave the same way whether you run it on a laptop, a physical
server, or a virtual server. Nor are any new error messages or options enabled within SQL Server
because of it running on a virtual server, with the exception of Dynamic Memory support that's
described in a moment. That's not to say that you don't need to change how you coni gure and
use SQL Server once it is virtualized; in fact, some of the server resource coni gurations are more
important in the virtual world, but they are still all coni gured with the standard
SQL Server tools.
The one feature in SQL Server 2012 that does automatically get enabled on start-up as a
consequence of being in a virtual environment is hot-add memory support. This feature was released
in SQL Server 2005 and originally designed to support physical servers that could have hundreds
of gigabytes of memory and large numbers of processors, yet could still have more added without
them being powered down or rebooted. Once additional memory had been plugged in and the server
hardware had brought it online, Windows and SQL Server would then auto-detect it and begin
making use of it by expanding the buffer pool. While this sounds like a clever feature, I suspect very
few users ever had both the right hardware and a need to use it, so the feature never gained
widespread use.
Fast-forward a few years and Microsoft's Hyper-V virtualization technology shipped a new feature
called Dynamic Memory. By monitoring a virtual server's Windows operating system, the Dynamic
Memory feature detects when a virtual server is running low on memory; and if spare physical memory
is available on the host server, it allocates more to the virtual server. When this happens, the
hot-add memory technology in Windows and SQL Server recognize this new “physical memory”
being added and dynamically reconi gure themselves to use it — without needing to reboot
Windows or restart SQL Server.
This behavior was available in the Enterprise and Data Center Editions of SQL Server 2008,
but support for it has expanded in SQL Server 2012 to include the Standard Edition. This expanded
support demonstrates how closely Microsoft wants its virtualization software, operating system,
and database server software to work together. The expectation by Microsoft is that use of this
feature will become routine once it's made available to the Standard Edition of SQL Server.
Search WWH ::
Custom Search