Deadlocks zijn zelden een database-bug en bijna altijd een access-pattern dat twee transacties op elkaar laat wachten. Deze pagina is voor lead-DBA's en developers die deadlock-graphs willen leren lezen, en voor IT-managers die een freelance SQL DBA willen inhuren om de root cause te slechten.
Deadlocks vangen met Extended Events
Sinds 2012 is xml_deadlock_report op de system_health-sessie standaard aanwezig. Wij maken een dedicated XE-sessie die naar disk schrijft en filteren op database_id. Trace flags 1204 en 1222 zijn legacy en geven minder bruikbare output dan de XE-graph.
De graph lezen: process en resource
Een deadlock-graph heeft processes (sessies) en resources (locks). De pijlen tussen ze tonen wie op wat wacht. SSMS rendert de graph visueel, maar de XML zelf bevat meer detail: input buffer, isolation level, transaction depth en wait time. Welke sessie deadlock victim wordt is een kostenbeslissing van de optimizer, niet random.
Volgorde van resources gelijktrekken
De klassieke fix: zorg dat elke transactie tabellen in dezelfde volgorde aanraakt. Tabel A voor B, altijd. In de praktijk werkt dat zelden zonder code-review. Soms is een covering index, een UPDLOCK-hint of een SERIALIZABLE-downgrade naar READ COMMITTED SNAPSHOT effectiever dan de transactie herschrijven.
Read Committed Snapshot Isolation als hefboom
RCSI op database-niveau elimineert reader-writer-deadlocks volledig. De prijs is meer TempDB-druk. Voor OLTP-systemen met veel rapportage tegelijk is dit vaak de beste structurele ingreep. We meten TempDB-headroom voordat we de switch maken.
Retry-patroon in de applicatielaag
Sommige deadlocks zijn niet 100 procent te vermijden, alleen te minimaliseren. Een retry-patroon (driemaal, exponential backoff) op deadlock victim-fouten (1205) hoort bij robuust applicatie-design. We adviseren de developers waar de retry-logica precies hoort.
Verwant: Senior SQL DBA, Blocking chain analyse.