This editorial was originally published on November 12, 2009. It is being re-run as Steve is on holiday. 

In reading about virtualization, one of the main things that drives its acceptance is cost. It's the reduction in actual physical resources needed to run multiple servers that makes it popular with many IT departments. It doesn’t help with administrative costs, at least not the costs of the system administrators because you still have the same number of servers to manage. There are just less physical servers to buy, less power needed, less cooling, and probably other savings if you virtualize.

Virtualization is really a one-time cost savings. Once you've virtualized a server, you can't do I again, so there are no repeat savings from this event. Is consolidation the same? After all, the main driving force for that process is also cost, and once you've consolidated a server you can't do it again.

Or can you?

There's a great white paper by Allen Hirt that talks about the process of consolidation, and I'd urge you to read it before beginning a consolidation project. However I don't know that consolidation is, or should be, a large, one-time project.

If I consolidate 3 or 5 SQL Server instances onto one machine, I have a choice of how I can do this. It can be by moving databases to a new instance, having multiple instances, or even using virtual machines. But is that the end? It's not because I can add more databases later, or I could even move a database that is receiving a heavy load back to its own server and find other instances to consolidate onto this one.

Consolidation, unlike  virtualization ought to be something you periodically examine in your environment. On a regular basis review your baseline for all instances and see if it makes sense to perform some consolidation. Server sprawl can creep up on you, but with a little management and the multi-instance nature of SQL Server, you can keep it under control.

And if you don't have a baseline to examine, consider setting one up.