Pourquoi y a-t-il des entrées sans victime sur le graphique de blocage?

J'essaie d'apprendre à analyser le graphique de blocage de SQL Server 2008 et je trouve beaucoup d'entrées avec un <victim-list>nœud vide . Je ne comprends pas ce que ces entrées représentent: s'il n'y a pas de victime, comment puis-je identifier la ressource d'attente qui est à l'origine du blocage? Que signifient ces entrées?

Voici un exemple rapide des entrées que je vois:

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

** modifier ** Comme demandé, voici la requête utilisée pour identifier une requête par son 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 et e_waitPipeNewRow suggèrent que vous avez également rencontré ce que Bart Duncan appelle aussi un terme gênant et peu maniable: "Blocages de threads parallèles intra-requête" .

La plupart des interblocages de parallélisme intra-requête sont considérés comme des bogues, bien que certains d'entre eux puissent être des bogues risqués à corriger, ce qui peut ne pas être possible. Si vous en rencontrez un et que vous êtes déjà sur le dernier Service Pack SQL, votre meilleur pari peut être d'enquêter sur les solutions de contournement.

Donc, vous ne pouvez pas faire grand-chose d'autre que:

• Assurez-vous que vous êtes sur le dernier service pack et mise à jour cumulative.
• Essayez d'identifier les index et / ou autres optimisations pour améliorer les performances de la requête. Vous mentionnez que inputbuf n'est pas renseigné mais vous pourrez peut-être identifier la requête en cours via le sqlhandle dans le graphique XML. Si vous n'obtenez rien de cela, essayez d'exécuter une trace et de corréler avec l'heure à laquelle ces blocages se produisent.
• Réduisez MAXDOPpour cette requête ou essayez MAXDOP(1)de forcer l'exécution sur un seul thread. Sachez que vous pouvez corriger les blocages mais introduire un ensemble différent de problèmes de performances en limitant le parallélisme.
• Ouvrez un appel d'assistance avec Microsoft. Il est possible que a) ils disposent d'un correctif non public pour ce scénario ou b) car ces interblocages intra-requête sont considérés comme des bogues, ils peuvent vouloir travailler avec vous pour trouver un correctif.