Sono tutti deadlock causati da una query errata

Question

"La transazione (ID processo 63) era bloccata su lock | risorse del buffer di comunicazione con un altro processo ed è stata scelta come vittima del deadlock. Rieseguire la transazione.". Possibili cause di errore: problemi con la query, proprietà "ResultSet" non impostata correttamente, parametri non impostati correttamente o connessione non stabilita correttamente. "

Questo deadlock potrebbe essere causato da qualcosa che il proc memorizzato utilizza come la posta SQL? ha sempre causato qualcosa di simile a due applicazioni che accedono contemporaneamente alla stessa tabella?

Answer 1

Due tabelle che accedono alla stessa tabella contemporaneamente si verificano sempre in un'applicazione. Generalmente ciò non causerà un deadlock. Un deadlock si verifica in genere quando si dice che il processo 'A' tenta di aggiornare la Tabella 1 e quindi la Tabella 2 e quindi la Tabella 3 e si ha il processo 'B' che tenta di aggiornare la Tabella 3, quindi la Tabella 2 e quindi la Tabella 1. Processo ' A 'avrà una risorsa bloccata per quel processo' B 'e il processo' B 'ha un processo di risorsa' A 'necessario. SQL Server lo rileva come un deadlock e ripristina uno dei processi come transazione non riuscita.

La linea di fondo è che ci sono due processi che tentano di aggiornare le stesse tabelle allo stesso tempo, ma non nello stesso ordine. Questo porterà spesso a deadlock.

Un modo semplice per gestirlo nell'applicazione consiste nel gestire la transazione non riuscita e semplicemente rieseguire la transazione. Funzionerà quasi sempre con successo. Una soluzione migliore è assicurarsi che i processi stiano aggiornando le tabelle nello stesso ordine, il più possibile.

Answer 2

Gli indici mancanti sono un'altra causa comune di deadlock .Se una query selezionata può ottenere le informazioni necessarie da un indice anziché dalla tabella di base, quindi

Per sapere con certezza, utilizzare il profiler SQL per tracciare gli eventi "Grafico deadlock", che ti mostrerà il dettaglio del deadlock stesso.

Answer 3

In base a this, non penso che SQL Mail stesso sarebbe direttamente essere il colpevole. Dico "direttamente" perché non so cosa stai facendo con esso. Tuttavia, I assume SQL Mail è probabilmente lento rispetto al resto dei tuoi SQL ops, quindi se stai facendo molto con quello, potrebbe indirettamente creare un collo di bottiglia che porta a un deadlock se stai trattenendo i tavoli mentre invio di SQL Mail.

È difficile consigliare una strategia specifica senza avere troppe informazioni specifiche su ciò che si sta facendo. In breve, dovresti considerare se c'è un modo per rompere la dipendenza dal tenere sul tavolo mentre stai facendo questo, ad esempio usando NOLOCK, usando una tabella temporanea o una tabella di "mantenimento" non temporanea o semplicemente rifattorizzando la SP sta facendo la chiamata.