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.