Por que existem entradas sem vítimas no gráfico de deadlock?

Estou tentando aprender a analisar o gráfico de deadlock do SQL Server 2008 e estou encontrando muitas entradas com um <victim-list>nó vazio . Não entendo o que essas entradas representam: se não houver vítima, como posso identificar o recurso de espera que está causando o impasse? O que essas entradas significam?

Aqui está um exemplo rápido das entradas que estou vendo:

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

** edit ** Conforme solicitado, aqui está a consulta usada para identificar uma consulta por meio do 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

de RyanBoyer.net

ExchangeEvent e e_waitPipeNewRow sugerem que você também se depare com o que Bart Duncan chama de Termo Irritante: "Deadlocks de threads paralelos entre consultas" .

A maioria dos bloqueios de paralelismo intra-consulta são considerados bugs, embora alguns deles possam ser arriscados para corrigir, portanto, uma correção pode não ser possível. Se você se deparar com um e já estiver no service pack mais recente do SQL, sua melhor opção poderá ser investigar soluções alternativas.

Portanto, você não pode fazer muito além de:

• Verifique se você está no service pack mais recente e na atualização cumulativa.
• Tente identificar índices e / ou outras otimizações para melhorar o desempenho da consulta. Você mencionou que o inputbuf não está preenchido, mas pode ser possível identificar a consulta em execução via sqlhandle no XML do gráfico. Se você não obtiver nada disso, tente executar um rastreamento e se correlacionar com os horários em que esses conflitos ocorrem.
• Reduza MAXDOPpara esta consulta ou tente MAXDOP(1)forçar a execução de thread único. Esteja ciente de que você pode corrigir os impasses, mas introduza um conjunto diferente de problemas de desempenho restringindo o paralelismo.
• Abra uma chamada de suporte com a Microsoft. Possível que a) eles tenham um hotfix não público para esse cenário ou b) como esses conflitos de consulta interna são considerados bugs que eles podem querer trabalhar com você para encontrar uma correção.