Consolidation, as it applies to databases, is simply putting more databases or SQL Server Instances on less hardware. This is a good thing, normally, because it allows you to save on hardware costs and use what you have at it’s highest capacity. It also saves on energy costs, floor and rack space, and in some cases even licensing and software.
But there are issues that you need to consider. When more databases or Instances there are on a single server, the higher your risk when that server is unavailable. For instance, let’s say you have 10 servers with various databases that hold your organization’s application data. If one of those servers goes down today due to a hardware failure, then one application is out of commission. Now take those 10 databases and host them on a single Instance, or set up 10 Virtual Servers on a single hardware box. If that system goes down, now 10 applications are out of commission.
And it isn’t just that. It’s the recovery time for all of those systems. Even in a single system failure, it isn’t a matter of simply restoring the last backup. Whenever an application goes down, you have to check the consistency of the system by verifying what data made it in before the failure and what needs to be re-keyed, or if the data made it in whole or in part. Now you have that on 10 systems, not 1, and that takes a lot more time.
How big a risk is this? Well, the other day I lost power to a switch (how in the world does THAT happen) and lost 5 Virtual Servers in the middle of a test run. I had a friend that same week that lost a SAN connection (driver issue) and lost a consolidated Instance of SQL Server with 25 applications on it.
So does that mean you shouldn’t consolidate? No, it just means that you need to consider that risk. Add what you need to make that system redundant as possible, and include the increased process in your Disaster Recovery planning. And you have to communicate that risk and increased time back to the business.