Throughout my career I've been looking to consolidate SQL Servers when I find them. The typical employer I've had usually grows their IT infrastructure over time and many projects look like this:
Build or buy a software package
Buy a new server
Install SQL Server and one database for the application
Over time this means I find lots of individual servers running at much less than full capacity. That's something that DBAs like, because it means that we can handle the inevitable spikes in resource usage that our workloads will encounter. However that's not what the rest of the business, especially the financial management, wants. Underused resources mean money that isn't spent well.
As a result, I've often looked to consolidate instances where possible. Often I let an instance run by its own hardware for a period of months, perhaps even a year, during which I can get a good idea of what level of resources the database and application require. Once I have that, I try to match up the needs with an existing SQL Server that might be underutilized by at least that amount of resources. Typically I'm looking at RAM and CPU since disk resources can often be transferred to a new piece of hardware. It's not quite as simple as it sounds as I also need to look at workload patterns and potentially match up instances whose workload peaks occur at different times.
I've successfully consolidated many instances this way, often reducing the amount of physical hardware in data centers substantially. As hardware cycles turn over and newer machines are purchased, I can usually repeat the process again and again. The advent of virtualization has made this even easier as bad guesses can usually be reversed or corrected by moving the database to a different instance.
I suspect that virtualization will become more important in the future, especially as licensing changes in SQL Server make it much more expensive to add the ad hoc instance on its own hardware. I'd encourage you to plan on consolidating new databases from the beginning to ensure that your organization gets the most performance out of the hardware that it has purchased.
With this eBook, adapted from the Stairway to Replication, learn the different kinds of replication and how to use each one. Replication isn't always the answer, this eBook also explains when log shipping or AlwaysOn are better options.
SQL Server Execution Plans shows you what's going on behind the scenes in SQL Server. They can provide you with a wealth of information on how your queries are being executed by SQL Server, including: Which indexes are being used, and where no indexes are being used at all. How the data is being retrieved, and joined, from the tables defined in your query. How aggregations in GROUP BY queries are put together. Grab your copy today from Amazon!
Yesterday's Question of the Day
(by Steve Jones):
What's the hot key to get the results in Management Studio (SSMS) to come out as text instead of a grid?
The answer is CTRL+T. If you click this hot key, you will get results from your queries as text, which is handy for pasting short results into other documents.
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.