Quale potrebbe essere la ragione possibile per questo tipo di deadlock? (non deadlock in generale)
Blocca le risorse del buffer di comunicazione
Questo sistema indicato ha poca memoria e il conteggio dei buffer è esaurito?
Errore dettagliato:
La transazione (ID processo 59) è stata bloccata su risorse buffer di comunicazione blocco con un altro processo ed è stata scelta come vittima del deadlock. Rieseguire la transazione
Risposte:
Il messaggio completo che viene comunemente visualizzato:
La transazione (ID processo 53) è stata bloccata sul blocco | risorse del buffer di comunicazione con un altro processo ed è stato scelto come vittima del deadlock. Rieseguire la transazione.
Questo tipo di blocco viene comunemente visto con le query di deadlock eseguite da SQL Server come parallele, a volte denominate "deadlock parallele all'interno della query". Ho visto alcune affermazioni secondo cui anche questo indica che le risorse di sistema sono scarse, che immagino potrebbero essere coinvolte in piccola parte.
Una linea guida generale che ho notato per determinare se si tratta di deadlock parallelo è quando si estrae il grafico deadlock XML (che può essere fatto con la sessione system_health nel 2008 e versioni successive) si noteranno ID di processo diversi che mostrano lo stesso bit di codice all'interno del stack di esecuzione.
Inoltre, guardando l'elenco delle risorse del grafico deadlock e notando il tipo di evento del cameriere. Più comunemente mostreranno "e_xxxxxx", o qualcosa del genere forse:
<waiter-list>
<waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
<waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>Per provare a risolvere il problema, vari percorsi da intraprendere sono offerti online e nei libri. In genere inizio guardando il piano di esecuzione della query / procedura e mi concentro sulle aree che mostrano l'esecuzione parallela. Quindi da lì passare attraverso il tentativo di ottimizzare prima la query e quindi come ultima risorsa potrebbe iniziare a utilizzare i suggerimenti per la query.
Il suggerimento per le query più comune che vedrai menzionato per risolvere questi deadlock è l'implementazione MAXDOP 1. Tuttavia, prima di farlo, è possibile verificare che cosa sono impostati su MAXDOP e Soglia di costo a livello di server. La Soglia di costo è generalmente impostata su 5 per impostazione predefinita e mi piacerebbe alzarla a 35 o 40 per iniziare, se la query in questione ha un costo basso per quella sezione di codice, potrebbe non essere necessario eseguirla in parallelo. Non mi piace molto usare i suggerimenti per le query MAXDOP, ma ciò non significa che non abbiano il loro posto e il loro scopo. solo la mia opinione.