デッドロックグラフに犠牲者のいないエントリがあるのはなぜですか？

SQL Server 2008のデッドロックグラフの分析方法を学習しようとしていますが、<victim-list>ノードが空のエントリがたくさん見つかります。これらのエントリの意味がわかりません。被害者がいない場合、どのようにしてデッドロックの原因となっているwaitresourceを特定できますか？これらのエントリはどういう意味ですか？

ここに私が見ているエントリーの簡単な例があります：

<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>

**編集**要求されたとおり、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

RyanBoyer.netから

ExchangeEvent＆e_waitPipeNewRowは、Bart Duncanがあまりにも扱いにくい用語として「クエリ内並列スレッドデッドロック」と呼ぶものに遭遇したことを示唆しています。

ほとんどのクエリ内並列処理のデッドロックはバグと見なされますが、一部のバグは修正するのが危険なバグであり、修正できない場合があります。1つに遭遇し、すでに最新のSQLサービスパックを使用している場合は、回避策を調査す​​ることをお勧めします。

したがって、次のこと以外にできることは多くありません。

• 最新のサービスパックと累積アップデートを使用していることを確認します。
• クエリのパフォーマンスを向上させるために、インデックスやその他の最適化を特定するようにしてください。inputbufにはデータが入力されていませんが、グラフXMLのsqlhandleを使用して、実行中のクエリを特定できる場合があります。それでも何も得られない場合は、トレースを実行して、これらのデッドロックが発生する時間と関連付けてみてください。
• MAXDOPこのクエリを減らすか、MAXDOP(1)シングルスレッド実行を強制してみてください。デッドロックを修正する可能性があることに注意してください。ただし、並列処理を制限することにより、別の一連のパフォーマンス問題が発生します。
• Microsoftとのサポートコールを開きます。可能性としては、a）このシナリオ用の非公開の修正プログラムがあるか、b）これらのクエリ内デッドロックが、修正プログラムを見つけるために協力したいバグであると見なされているためです。