One of the challenges in writing about a new version of SQL Server is finding out information, especially for the less than detailed technical topics. Consolidation is an interesting topic because it seems simple in theory, but the details of how to proceed and what to do are harder to divine from public knowledge. I've consolidated some servers and to a large extent it was using my experience as a guide to make the sizing decisions or determine if a new instance would overload existing hardware.

But for SQL Server 2005, there is relatively little information here. In fact, very few people have even deployed 2005 into their production environments. There are a couple of interesting white papers on 2000 consolidation and one great one on 2005 performance, but not much between.

So I've struggled to get concrete backing for my writing. And things like these don't help:

• When you perform your analysis, it is crucial that you understand the impact of consolidation. It is also critical to understand the effects on CPU utilization in the other server processes. The server processes on a single physical server designated as the consolidation server will be affected by applications and server processes such as SQL Server consolidated from other servers onto the consolidation server.
• You can promote success by performing proper capacity planning and applying solid performance metrics.

Nowhere in the details of looking through the white papers and research in performance books do I see concrete examples of say add up your average CPU usage and do not exceed 70%. Nowhere do I actually find guidelines that specifically make recommendations. I see lots of information about configuring AWE/PAE, and setting CPU affinity, but no detailed guidelines. Just lots of "test, don't overload things, watch for high values, etc" without specifically marking that is "high".

Maybe it's just me, but I think that part of developing the product and providing the support is that MS needs to provide detailed guidelines on what performance levels people should shoot for. There is a great white paper for 2005 on Performance Problems that goes into the type of details I wish I had seen from past versions.