Shekhar,

Thanks for the well wishes.

As for the default setting for max degree of parallelism, the answer is: it depends. I would recommend that you examine the queries that are experiencing that particular wait type and see if they can be tuned.

Paul,

Thanks for the clarifications. I have only rarely needed to configure a system to be a specified number. I try to let the optimizer do the work for me instead.

Thanks for that. Server MAXDOP is controversial I know. My thoughts are that SQL Server generally load-balances between concurrent requests very well (co-operative scheduling) so cores-1 is not necessarily a good rule of thumb. Diminishing returns and NUMA concerns are so I tend to set MAXDOP 4 and tune on a case-by-case basis, except heavily-OLTP systems which get server MAXDOP 1 and OPTION overrides to that as required.

Fragmentation. The optimiser does not *directly* consider fragmentation at all – but it might make a different cost-based decision if an index happens to have more pages than it needs due to wasted space (page splits, low fillfactor etc).

Paul

Thanks Adam, I will add that to my original post.

Paul,

Great questions. I’ll start with number two first.

It only makes sense (to me, at least) if you have been seeing problems with queries that are consuming all CPU’s as a result of parallelism *and* your instance still needs to service other requests at the same time. If you have a batch process that takes up 32 cores but no one else needs to use that box then you really don’t have an issue. But if you take all 32 cores and someone else is locked out as a result then chances are your phone will ring. To avoid that problem it *may* make sense for you to configure your instance to be N-1 by default.

My understanding of that is you could be fragmented to the point that the plan decides to do a scan rather than a seek, and the scan could also be kicked off in parallel. Now, the optimizer is always going to choose the plan with the least cost, so it is trying to do you what it thinks is a favor. So, you could see evidence of parallelism which is only there as a result of some fragmentation. If you clean up the fragmentation, you should get a different plan, and the optimizer may even decide that parallelism is not needed. So, it is not necessarily a direct correlation (fragmentation implies parallelism), but more of a cause and effect (fragmentation implies a less than optimal plan which implies parallelism is used). I guess you could look at this as a warning sign for you to look to a root cause rather than just changing some config options.

Yes! Craig’s blog is resourcedb for so many things. I particularly like his PDF presentation http://blogs.msdn.com/b/craigfr/archive/2007/04/17/parallel-query-execution-presentation.aspx

I was fortunate enough to make a small contribution to that.

His chapters in Inside SQL 2005 Query Tuning & Optimisation are also excellent.

Paul