为什么死锁图上有无受害者条目?

Sli*_*345 14 sql-server deadlock sql-server-2008-r2

我正在尝试学习如何分析SQL Server 2008 的死锁图,并且我发现了很多带有空<victim-list>节点的条目。我不明白这些条目代表什么:如果没有受害者,我如何识别导致死锁的等待资源?这些条目是什么意思?

这是我看到的条目的一个快速示例:

<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>
Run Code Online (Sandbox Code Playgroud)

** 编辑 ** 根据要求,以下是用于通过 sqlhandle 识别查询的查询:

select sql_handle as Handle,
    SUBSTRING(st.text, (qs.statement_start_offset/2)+1, 
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(st.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2) + 1) AS Text

from sys.dm_exec_query_stats as qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
where sql_handle = --0x04000D00E3572A56542E4601CE9E00010100001000000000
Run Code Online (Sandbox Code Playgroud)

来自RyanBoyer.net

Mar*_*ith 12

ExchangeEvent 和 e_waitPipeNewRow 表明您已经遇到了 Bart Duncan 所说的令人讨厌的笨拙术语:“查询内并行线程死锁”

大多数查询内并行死锁都被认为是错误,尽管其中一些可能是需要修复的有风险的错误,因此可能无法修复。如果您遇到了一个并且您已经在使用最新的 SQL 服务包,那么您最好的选择可能是调查解决方法。

所以,除了:

  • 确保您使用的是最新的服务包和累积更新。
  • 尝试识别索引和/或其他优化以提高查询的性能。您提到 inputbuf 未填充,但您可以通过图形 XML 中的 sqlhandle 识别正在执行的查询。如果您一无所获,请尝试运行跟踪并与这些死锁发生的时间相关联。
  • 减少MAXDOP此查询或尝试MAXDOP(1)强制单线程执行。请注意,您可能会修复死锁,但会通过限制并行性引入一组不同的性能问题。
  • 打开与 Microsoft 的支持电话。可能 a) 他们有针对这种情况的非公开修补程序或 b) 因为这些查询内死锁被认为是他们可能希望与您合作以找到修复程序的错误。