Jag har en applikation som kör 1-20 trådar parallelt.

Då och då hittar jag exceptions i logg-filen som refererar till deadlocks och att en viss transaktion blivit vald som offer och kastas ut.

Från min loggfil ser jag vilken transaktion det är som kastas ut, men tyvärr inte vilken transaktion det är som den hamnade i "döden grepp" med.

Har hört om att man kan kolla i ldf-filen, men inte lyckats dra ut något vettigt ur den. Behöver jag någon speciell logg-läsare?

Tacksam för al hjälp.

Har inte provat så mycket själv, men det verkar ska gå att övervaka med SQL Profiler:

Starta SQL Profiler
File->New Trace
Under Events-fliken, plocka bort en massa ointressanta events och lägg i stället till "Locks - Lock:Deadlock"

Starta den och låt den stå och ticka ett tag så borde det (antar jag?) dyka upp lite mer information där.

Ett helt irrelevant inlägg, men deadlocks brukar ofta bero på dålig databasdesign.

Profiler är ett sätt att angripa problemet.

Hur arbetar applikationen?

Det du kan ha med i loggen är started och completed Stmt inom sp och tsql. Du hittar vad jag menar när du konfigurerar loggningen.

Då ser du vilka procedurer och embedded sql som exekveras och vilka som går klart... De som är bara started men inte completed är de som termineras.

Om applikationen enbart arbetar med lagrade procedurer kan du ganska enkelt lösa problemet också...
Läs enkelt med glimten i ögat.

Nu tillbaka till dina deadlocks, du har även activity monitor som kan hjälpa dig i realtid. Där ser du infon i klartext vilken låser vem och varför. är det sql 2005 så har du event notification och server baserade triggers som kan hjälpa dig med lite övervakning...

Om du har trådade transaktioner så får du räkna med att det kan inträffa Deadlocks.
Lösningen är att fånga felet (gör catch på SqlException och undersök vilken felkod du ska trigga på).
När Deadlock inträffar, väntar du t.ex. slumpmässigt 100 - 1000 ms och försöker sedan igen. Upprepa försöket t.ex. 10 ggr innan du ger upp. Om du inte får tappa nåt, då gör du enklast en egen logg på det som ska köras igen senare i stället för att rota i ldf-filer.

Tänk också över om du verkligen tjänar nåt på att tråda om det nu orsakar deadlocks.
Det uppstår ju en hel del overhead när databasen måste ta i tu med detta problem.
Testa med/utan trådning. Skulle vara intressant att få se resultatet, isf :)

Skulle vilja göra inlägg på ditt påstående. Jag skulle hellre vilja säga "dålig kod,eller ingen standard på hur man skall accessa tabellerna, inget sagt nu om designen kan vara dålig också" .

Vad jag vill säga är att du kan skapa en deadlock hur enkelt som helst . Det enda som krävs är i princip 2 procedurer som exekverar samtidigt och accessar tabell A och tabell B i motsatt ordning så fick du dig en deadlock.

Problemet är att hitta detta, därför borde detta ingå som utbildning i ett projekt man hamnar i, hur man skall accessa tabellerna(turordningen alltså) på detta sätt kan man undvika många obehagliga situationer som förr eller senare uppstår men ingen kan lösa.

Vet att detta är ett gammalt ärende, men vill ändå att folk inte skall få en felaktig bild om deadlocks.
Det handlar inte om dålig design utan mer om dålig kod.