Perché ci sono voci Victimless nel grafico Deadlock?

Sto cercando di imparare come analizzare il grafico del deadlock di SQL Server 2008 e sto trovando molte voci con un <victim-list>nodo vuoto . Non capisco cosa rappresentino queste voci: se non c'è vittima, come posso identificare la risorsa di attesa che sta causando il deadlock? Cosa significano queste voci?

Ecco un breve esempio delle voci che vedo:

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

** modifica ** Come richiesto, ecco la query utilizzata per identificare una query dal suo 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

da RyanBoyer.net

ExchangeEvent & e_waitPipeNewRow suggerisce che ti sei imbattuto in quello che Bart Duncan definisce anche come termine fastidioso e poco maneggevole: "deadlock di thread paralleli intra-query" .

La maggior parte dei deadlock di parallelismo intra-query sono considerati bug, sebbene alcuni di essi possano essere bug rischiosi da correggere, quindi una correzione potrebbe non essere possibile. Se ti imbatti in uno e sei già sull'ultimo service pack SQL, la soluzione migliore potrebbe essere quella di indagare sulle soluzioni alternative.

Quindi, non puoi fare molto altro che:

• Assicurati di essere aggiornato sull'ultimo service pack e sull'aggiornamento cumulativo.
• Prova a identificare gli indici e / o altre ottimizzazioni per migliorare le prestazioni della query. Dici che inputbuf non è popolato ma potresti essere in grado di identificare la query in gioco tramite sqlhandle nel grafico XML. Se non si ottiene nulla da ciò, provare a eseguire una traccia e correlare con i tempi in cui si verificano questi deadlock.
• Ridurre MAXDOPper questa query o provare MAXDOP(1)a forzare l'esecuzione a thread singolo. Tenere presente che è possibile correggere i deadlock ma introdurre una serie diversa di problemi di prestazioni limitando il parallelismo.
• Apri una chiamata di supporto con Microsoft. Possibile che a) dispongano di un hotfix non pubblico per questo scenario oppure b) poiché questi deadlock all'interno della query sono considerati bug che potrebbero voler lavorare con l'utente per trovare una soluzione.