Почему на графике тупиковых ситуаций есть записи без жертв?

Я пытаюсь научиться анализировать график взаимоблокировок в SQL Server 2008 и нахожу множество записей с пустым <victim-list>узлом. Я не понимаю, что представляют собой эти записи: если нет жертвы, как я могу определить ресурс ожидания, который вызывает тупик? Что означают эти записи?

Вот быстрый пример записей, которые я вижу:

<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 ** По запросу, вот запрос, используемый для идентификации запроса по его 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 предполагает, что вы столкнулись с тем, что Барт Дункан также называет досадно-громоздким термином: «тупики внутри параллельных потоков» .

Большинство взаимных блокировок параллелизма внутри запросов считаются ошибками, хотя некоторые из них могут быть рискованными ошибками, поэтому исправление может оказаться невозможным. Если вы столкнулись с одним из них и уже пользуетесь последним пакетом обновлений SQL, лучшим вариантом может стать поиск обходных путей.

Таким образом, вы можете сделать немногое, кроме:

• Убедитесь, что вы используете последний пакет обновления и накопительное обновление.
• Попробуйте определить индексы и / или другие оптимизации для повышения производительности запроса. Вы упомянули, что inputbuf не заполнен, но вы можете определить запрос в действии через sqlhandle в графе XML. Если вы ничего не получите от этого, попробуйте выполнить трассировку и сопоставить ее со временем возникновения этих блокировок.
• Сократите MAXDOPдля этого запроса или попробуйте MAXDOP(1)принудительно выполнить однопоточное выполнение. Имейте в виду, что вы можете устранить взаимоблокировки, но представьте другой набор проблем с производительностью, ограничив параллелизм
• Откройте службу поддержки в Microsoft. Возможно, что а) у них есть закрытое исправление для этого сценария или б) поскольку эти взаимные блокировки внутри запроса считаются ошибками, они могут захотеть работать с вами, чтобы найти исправление.