Чому на графіку тупикових ситуацій є записи без жертв?

Я намагаюся навчитися аналізувати графік тупикової ситуації 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>

** редагувати ** За запитом, ось запит, який використовується для ідентифікації запиту його 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. Можливо, що а) у них є непублічне виправлення для цього сценарію або б) оскільки ці тупикові запити внутрішньої запиту вважаються помилками, вони можуть захотіти співпрацювати з вами, щоб знайти виправлення.