¿Por qué hay entradas sin víctimas en el gráfico Deadlock?

Estoy tratando de aprender a analizar el gráfico de punto muerto de SQL Server 2008 , y estoy encontrando muchas entradas con un <victim-list>nodo vacío . No entiendo lo que representan estas entradas: si no hay una víctima, ¿cómo puedo identificar la fuente de espera que está causando el punto muerto? ¿Qué significan estas entradas?

Aquí hay un ejemplo rápido de las entradas que estoy viendo:

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

** editar ** Según lo solicitado, aquí está la consulta utilizada para identificar una consulta por su 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_waitPipeNewRow sugiere que te has encontrado con lo que Bart Duncan se refiere también como Término molesto y difícil de manejar: "Interbloqueo de hilos paralelos intra-consulta" .

La mayoría de los puntos muertos de paralelismo intraconsulta se consideran errores, aunque algunos de ellos pueden ser errores riesgosos de corregir, por lo que es posible que no sea posible. Si te encuentras con uno y ya estás en el último paquete de servicio SQL, tu mejor opción puede ser investigar soluciones alternativas.

Entonces, no puedes hacer mucho más que:

• Asegúrese de estar en el último service pack y la actualización acumulativa.
• Intente identificar índices y / u otras optimizaciones para mejorar el rendimiento de la consulta. Usted menciona que inputbuf no está lleno, pero es posible que pueda identificar la consulta en juego a través de sqlhandle en el gráfico XML. Si no obtiene nada de eso, intente realizar un seguimiento y correlacionar con los tiempos en que se producen estos puntos muertos.
• Reduzca MAXDOPpara esta consulta o intente MAXDOP(1)forzar la ejecución de subproceso único. Tenga en cuenta que puede solucionar los puntos muertos pero introducir un conjunto diferente de problemas de rendimiento al restringir el paralelismo.
• Abra una llamada de soporte con Microsoft. Es posible que a) tengan una revisión no pública para este escenario ob) ya que estos puntos muertos intraconsultas se consideran errores, pueden querer trabajar con usted para encontrar una solución.