Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I am trying to learn how to analyze SQL Server 2008's deadlock graph, and I'm finding alot of entries with an empty <victim-list> node. I don't understand what these entries represent: if there is no victim, how can I identify the waitresource that is causing the deadlock? What do these entries mean?

Here's a quick example of the entries i'm seeing:

<deadlock-list>
 <deadlock>
  <victim-list />
  <process-list>
   <process id="processd2b6508" taskpriority="0" logused="10000" waittime="31" schedulerid="63" kpid="9104" status="suspended" spid="69" sbid="0" ecid="184" priority="0" trancount="0" lastbatchstarted="2012-07-30T01:10:45.550" lastbatchcompleted="2012-07-30T01:10:45.550" clientapp=".Net SqlClient Data Provider" hostname="XXXXXXX" hostpid="3648" isolationlevel="read committed (2)" xactid="30461033" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
    <executionStack>
     <frame procname="" line="1" sqlhandle="0x020000002340c50225c17d0eec9bf7c51129348edffd1c70" /> 
     <!--About 2 more frame tags... -->
    </executionStack>
    <inputbuf /> 
   </process>
   <!-- 3 or so more process tags... -->
  </process-list>
  <resource-list>
   <exchangeEvent id="Pipeb005eeba0" WaitType="e_waitPipeNewRow" nodeId="7">
    <owner-list>
     <owner id="processd23fdc8" /> 
    </owner-list>
    <waiter-list>
     <waiter id="processd2b6508" /> 
    </waiter-list>
   </exchangeEvent>
   <!-- 2 more exchangeEvents -->
  </resource-list>
 </deadlock>
</deadlock-list>
share|improve this question
    
What is the exact version of SQL Server you're running? –  Jon Seigel Jul 31 '12 at 18:18
    
My version of SQL Server is 10.50.1617.0 –  Slider345 Jul 31 '12 at 18:33
    
Good thing I asked -- I've seen issues with the deadlock graph XML in SQL 2008 (non-R2). –  Jon Seigel Jul 31 '12 at 18:38

1 Answer 1

up vote 5 down vote accepted
+50

ExchangeEvent & e_waitPipeNewRow suggests you've run into what Bart Duncan refers too as Annoyingly-Unwieldy Term: "Intra-Query Parallel Thread Deadlocks".

Most intra-query parallelism deadlocks are considered bugs, although some of them can be risky bugs to fix so a fix may not be possible. If you run into one and you're already on the latest SQL service pack, your best bet may be to investigate workarounds.

So, not much you can do other than:

  • Ensure you're on the latest service pack and cumulative update.
  • Try to identify indexes and/or other optimisations to improve the performance of the query. You mention that inputbuf isn't populated but you may be able to identify the query in play via the sqlhandle in the graph XML. If you get nothing from that try running a trace and correlating with the times these deadlocks occur.
  • Reduce MAXDOP for this query or try MAXDOP(1) to force single-threaded execution. Be aware that you might fix the deadlocks but introduce a different set of performance issues by restricting parallelism.
  • Open a support call with Microsoft. Possible that a) they have a non-public hotfix for this scenario or b) as these intra-query deadlocks are deemed to be bugs they may want to work with you to find a fix.
share|improve this answer
    
This could be it. I'm going to sprinkle some MAXDOP on there and see if it resolves the deadlocks. –  Slider345 Aug 8 '12 at 22:28
    
I was able to use this query to identify one of the queries by it's sqlhandle. –  Slider345 Aug 8 '12 at 22:56
    
The deadlocks are gone! Thanks for your help. –  Slider345 Aug 10 '12 at 16:36
    
@Slider345 Pleasure, glad to hear you got it fixed. –  Mark Storey-Smith Aug 13 '12 at 23:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.