Come vengono rilevati e riportati i deadlock in un RDBMS?


8

Mi è stata data questa domanda tipo di saggio durante un'intervista, ma non ho ottenuto il lavoro. La domanda completa era la seguente:

Come vengono rilevati e riportati i deadlock in un RDBMS? Cosa sono responsabili del proprietario della transazione e dello sviluppatore dell'applicazione per garantire sia in scenari di rilevamento che di prevenzione?

Risposte:


13

In SQL Server è presente un thread separato che periodicamente (impostazione predefinita 5 secondi, intervallo inferiore se è stato appena rilevato un deadlock) controlla un elenco di attese per eventuali cicli. Cioè identifica la risorsa che un thread sta aspettando, quindi trova il proprietario di quella risorsa e trova ricorsivamente quale risorsa quel thread sta a sua volta aspettando, identificando così i thread che sono in attesa di ogni altra risorsa.

Se viene trovato un deadlock, viene scelta una vittima da uccidere usando questo algoritmo:

  1. Identificare i thread che non sono invendibili (ad es. Un thread che sta eseguendo il rollback di una transazione non è compilabile).
  2. Trova il thread con la priorità di deadlock più bassa.
  3. Scegli quello che è il più economico da ripristinare, ovvero quello che finora ha fatto meno lavoro.

È possibile trovare ulteriori informazioni sul rilevamento dei deadlock dei server SQL qui: http://msdn.microsoft.com/en-us/library/ms178104.aspx



Il proprietario della transazione / lo sviluppatore dell'applicazione è responsabile della riduzione al minimo dei rischi di deadlock e delle operazioni da eseguire che dovrebbero:

  1. Assicurati di mantenere le transazioni il più brevi possibile. Ad esempio, non mostrare un modulo di accesso dopo aver avviato una transazione e attendere l'input dell'utente, invece raccogliere tutte le informazioni necessarie e quindi eseguire la transazione.
  2. Utilizzare il livello di isolamento più basso possibile, ad es. Non impostare la serializzazione quando si desidera mostrare temporaneamente alcuni valori all'utente. Si noti che l'impostazione del livello di isolamento corretto è una scienza in sé e fuori portata in questa risposta.
  3. Se sei vittima di un deadlock, ovvero si ottiene l'errore n. 1205, quindi rieseguire la transazione in modo trasparente per l'utente. Dal momento che l'altra transazione, in competizione, ha ora sperato di aver acquisito le risorse che stava aspettando e terminato, non è scemo che incontrerai di nuovo lo stesso deadlock.

4. Acquisire risorse ed eseguire aggiornamenti / eliminazioni / inserimenti di schemi nello stesso ordine in modo coerente in tutta l'applicazione.
ErikE,

3
@ErikE spesso non è possibile / fattibile "eseguire l'aggiornamento / eliminare / inserire modelli nello stesso ordine in modo coerente in tutta l'applicazione", sebbene questo consiglio discutibile sia molto popolare sul Web. Dettagli qui: sqlblog.com/blogs/alexander_kuznetsov/archive/2010/01/15/…
AK,

1
Punti buoni. Ma continuo a pensare che lo sforzo valga la pena, purché non ci si illuda che sarà sempre possibile o risolvere sempre il problema. La cosa genitore / figlio è interessante, che ne dici di eliminare in cascata o acquisire prima un blocco di aggiornamento sulle righe principali? E se si uniscono senza MERGE, perché non essere coerenti? Faccio cancellare-> aggiorna-> inserisco personalmente.
ErikE,

1
@AlexKuznetsov: non è un proiettile risolutore ma non dovrebbe essere respinto. In questo modo ho ridotto (non eliminato) i deadlock in questo modo: tramite l'analisi statica del codice eseguito di frequente che si bloccava ogni giorno o 7. Suggerirei di applicare l'ottimizzazione prematura, ecc.
gbn

Non sono d'accordo con la raccomandazione numero 3. Quando riproviamo dopo deadlock, è molto probabile che sovrascriviamo le modifiche di altri processi. Dobbiamo essere consapevoli che molto probabilmente qualcun altro ha modificato i dati che intendevamo modificare. Soprattutto se tutti i lettori funzionano in isolamento, allora i lettori non possono essere coinvolti in deadlock, il che significa che tutte le parti coinvolte in un deadlock sono scrittori, modificati o tentati di modificare gli stessi dati. Se rileviamo l'eccezione e riproviamo automaticamente, possiamo sovrascrivere le modifiche di qualcun altro. Questo si chiama aggiornamenti persi e di solito è sbagliato.
AK,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.