Thanks.

SELECT
db.name AS databaseName
, object_name(ps.OBJECT_ID, ps.database_id) AS objectName
, ps.index_id AS indexID
, ps.partition_number AS partitionNumber
, ps.avg_fragmentation_in_percent AS fragmentation
, ps.page_count
FROM sys.databases db
INNER JOIN sys.dm_db_index_physical_stats (NULL, NULL, NULL , NULL, N’Limited’) ps
ON db.database_id = ps.database_id
WHERE ps.index_id > 0
AND ps.page_count > 100
AND ps.avg_fragmentation_in_percent > 30
OPTION (MaxDop 1);

I used a NOT EXISTS approach to find these but the query seemed to be taking an inordinate amount of time, I suspected blocking and so checked the output of SP_WHO2, sure enough blocking was happening to the SPID that was running the query – but the blocking SPID was itself!

Clearly the parrallel operation was getting under it’s own feet, perhaps I could have used the WITH (NOLOCK) hint to avoid this (dirty reads were’nt an issue for this type of query), but decided instead to use MAXDOP. Sure enough next time round, only one instance of the query’s SPID listed by SP_WHO2, no blocking (of itself!) and the query came back much quicker.

Very interesting read.

http://blogs.msdn.com/b/davidhardin/archive/2011/09/28/sql-server-parallelism-the-dark-side.aspx

I get the message Transaction (Process ID 62) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

If I set MAXDOP to 1, the problem gets solved

Transaction (Process ID 62) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

I added Option(MaxDOP 1) query hint to my update query and that solved issue.

I know it isn’t how it is meant to be used but it certainly is a decent workaround.

I have not found a solid explanation for this behavior. I would be very interested to know WHY this works if anyone has found such an explanation.

Also, before setting this off we used to have too mach wait for CXPACKET wait type, but after setting parallelism off we are not getting wait for this wait type. This is applicable to DEV and QA environments having less then 3/4 GB ram.

Overriding it upwards like this is rare to see, but has some very good scenarios in which I would want to do it – in a high end transactional environment, and online index operation has the ability to get out of hand and runaway as new data is coming in and existing data is changing, whilst a single thread is trying to put together a new index. Overriding it upwards so that it has more threads allocated brings it under control.

It is better if we use hint for the parallelism instead of general setting. Because we require it sometime for the query and sometime not requite.