Neden Deadlock Grafiği'nde Victimless Girişleri var?

SQL Server 2008'in kilitlenme grafiğini analiz etmeyi öğrenmeye çalışıyorum ve boş bir <victim-list>düğümü olan bir sürü giriş buluyorum . Bu girişlerin neyi temsil ettiğini anlamıyorum: kurban yoksa, kilitlenmeye neden olan waitresource'u nasıl belirleyebilirim? Bu kayıtlar ne anlama geliyor?

İşte gördüğüm girişlere hızlı bir örnek:

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

** düzenlemek ** İstendiği gibi, bir sorguyu sqlhandle tarafından tanımlamak için kullanılan sorgu:

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

kimden RyanBoyer.net

ExchangeEvent & e_waitPipeNewRow, Bart Duncan'ın Rahatsız Edici Olarak Kullanılmayan Terim: "Sorgu İçi Paralel İş Parçacığı Kilitlenmeleri" olarak adlandırdığı şeye rastlamanızı önerir .

Çoğu sorgu içi paralellik çıkmazı hata olarak kabul edilir, ancak bazıları düzeltmek için riskli hatalar olabilir, bu nedenle bir düzeltme mümkün olmayabilir. Biriyle karşılaşırsanız ve zaten en son SQL hizmet paketindeyseniz, en iyi seçenek geçici çözümleri araştırmak olabilir.

Yani, yapabileceğiniz pek bir şey yok:

• En son hizmet paketinde ve toplu güncellemede olduğunuzdan emin olun.
• Sorgunun performansını artırmak için dizinleri ve / veya diğer optimizasyonları belirlemeye çalışın. İnputbuf'un doldurulmadığını, ancak grafik XML'deki sqlhandle aracılığıyla oyunda sorguyu tanımlayabileceğinizden bahsediyorsunuz. Bundan bir şey almazsanız, bir iz çalıştırmayı ve bu çıkmazların meydana geldiği zamanlarla ilişkilendirmeyi deneyin.
• MAXDOPBu sorguyu azaltın veya MAXDOP(1)tek iş parçacıklı yürütmeyi zorlamaya çalışın . Kilitlenmeleri düzeltebileceğinizi, ancak paralellikleri kısıtlayarak farklı performans sorunları ortaya koyabileceğinizi unutmayın.
• Microsoft ile bir destek çağrısı açın. A) bu senaryo için halka açık olmayan bir düzeltmeye sahip olmaları veya b) bu ​​sorgu içi kilitlenmelerin bir düzeltme bulmak için sizinle birlikte çalışmak isteyebilecekleri hatalar olarak kabul edilmeleri nedeniyle.