Dlaczego na wykresie zakleszczenia są wpisy bez ofiar?

Próbuję nauczyć się analizować wykres zakleszczenia programu SQL Server 2008 i znajduję wiele wpisów z pustym <victim-list>węzłem. Nie rozumiem, co reprezentują te wpisy: jeśli nie ma ofiary, jak mogę zidentyfikować źródło oczekiwania, które powoduje impas? Co oznaczają te wpisy?

Oto szybki przykład wpisów, które widzę:

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

** edytuj ** Zgodnie z żądaniem, oto zapytanie używane do identyfikacji zapytania na podstawie jego 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

z RyanBoyer.net

ExchangeEvent i e_waitPipeNewRow sugerują, że natknąłeś się na to, co Bart Duncan określa również jako irytująco nieporęczny termin: „Zakleszczenia wątków równoległych w zapytaniu” .

Większość zakleszczeń równoległości wewnątrz zapytania jest uważanych za błędy, chociaż niektóre z nich mogą być ryzykownymi błędami do naprawienia, więc naprawa może być niemożliwa. Jeśli natrafisz na jeden z nich i korzystasz już z najnowszego dodatku Service Pack SQL, najlepszym rozwiązaniem może być zbadanie obejść.

Tak więc niewiele możesz zrobić poza:

• Upewnij się, że korzystasz z najnowszego dodatku Service Pack i aktualizacji zbiorczej.
• Spróbuj zidentyfikować indeksy i / lub inne optymalizacje, aby poprawić wydajność zapytania. Wspominasz, że inputbuf nie jest wypełniony, ale możesz być w stanie zidentyfikować zapytanie podczas odtwarzania za pomocą sqlhandle na wykresie XML. Jeśli nic z tego nie dostaniesz, spróbuj uruchomić śledzenie i skorelować się z czasami wystąpienia tych zakleszczeń.
• Zmniejsz MAXDOPdla tego zapytania lub spróbuj MAXDOP(1)wymusić wykonanie jednowątkowe. Pamiętaj, że możesz naprawić zakleszczenia, ale wprowadzić inny zestaw problemów z wydajnością poprzez ograniczenie równoległości.
• Otwórz połączenie z pomocą techniczną Microsoft. Możliwe, że a) mają niepubliczną poprawkę dla tego scenariusza lub b) ponieważ zakleszczenia wewnątrz zapytania są uważane za błędy, mogą chcieć współpracować z Tobą w celu znalezienia poprawki.