Skip to main content
added 1 character in body
Source Link

Have you checked following blog on Intra-Query Parallel Thread Deadlocks

The SyncPoint resource indicates the use of an exchange event if I'm not mistaking.
Looking at the participants of your deadlock you can see that they are all coming from the same spid(55) and batch(0), but are using different threads. This indicates that they are all part of the same parallel query and is confirmed by the fact that you don't recievereceive any deadlocks whenever you run the query with MAXDOP 1. In the case of Intra-Query Parallel Thread Deadlocks, the threads of a single query will end up deadlocking each other waiting for synchronizationsynchronisation objects, SyncPoints in your case.

Last time when I witnessed this kind of behaviorbehaviour, I was able to further optimizeoptimise the query and thus preventing the query query from using a parallel execution plan. I suspect you did the same thing by limiting your resultsetresult set to 32 records or by using a different index.
Another option would be to add MAXDOP 1 to your query, though not a great fan of this option.

But before fiddling around with those two options, first check if you are on the lastestlatest SP/CU.

Have you checked following blog on Intra-Query Parallel Thread Deadlocks

The SyncPoint resource indicates the use of an exchange event if I'm not mistaking.
Looking at the participants of your deadlock you can see that they are all coming from the same spid(55) and batch(0), but are using different threads. This indicates that they are all part of the same parallel query and is confirmed by the fact that you don't recieve any deadlocks whenever you run the query with MAXDOP 1. In the case of Intra-Query Parallel Thread Deadlocks, the threads of a single query will end up deadlocking each other waiting for synchronization objects, SyncPoints in your case.

Last time when I witnessed this kind of behavior, I was able to further optimize the query and thus preventing the query query from using a parallel execution plan. I suspect you did the same thing by limiting your resultset to 32 records or by using a different index.
Another option would be to add MAXDOP 1 to your query, though not a great fan of this option.

But before fiddling around with those two options, first check if you are on the lastest SP/CU.

Have you checked following blog on Intra-Query Parallel Thread Deadlocks

The SyncPoint resource indicates the use of an exchange event if I'm not mistaking.
Looking at the participants of your deadlock you can see that they are all coming from the same spid(55) and batch(0), but are using different threads. This indicates that they are all part of the same parallel query and is confirmed by the fact that you don't receive any deadlocks whenever you run the query with MAXDOP 1. In the case of Intra-Query Parallel Thread Deadlocks, the threads of a single query will end up deadlocking each other waiting for synchronisation objects, SyncPoints in your case.

Last time when I witnessed this kind of behaviour, I was able to further optimise the query and thus preventing the query from using a parallel execution plan. I suspect you did the same thing by limiting your result set to 32 records or by using a different index.
Another option would be to add MAXDOP 1 to your query, though not a great fan of this option.

But before fiddling around with those two options, first check if you are on the latest SP/CU.

Source Link

Have you checked following blog on Intra-Query Parallel Thread Deadlocks

The SyncPoint resource indicates the use of an exchange event if I'm not mistaking.
Looking at the participants of your deadlock you can see that they are all coming from the same spid(55) and batch(0), but are using different threads. This indicates that they are all part of the same parallel query and is confirmed by the fact that you don't recieve any deadlocks whenever you run the query with MAXDOP 1. In the case of Intra-Query Parallel Thread Deadlocks, the threads of a single query will end up deadlocking each other waiting for synchronization objects, SyncPoints in your case.

Last time when I witnessed this kind of behavior, I was able to further optimize the query and thus preventing the query query from using a parallel execution plan. I suspect you did the same thing by limiting your resultset to 32 records or by using a different index.
Another option would be to add MAXDOP 1 to your query, though not a great fan of this option.

But before fiddling around with those two options, first check if you are on the lastest SP/CU.