Blocking is geen deadlock; bij blocking wacht de ene sessie netjes op de andere. Pas als de wait te lang wordt, klaagt de business. Onze ZZP SQL DBA's onderscheiden incidenteel blocking van structureel blocking en pakken ze anders aan.
Lead blocker vinden
sp_whoisactive met @find_block_leaders = 1 toont de root-sessie van de blocking-keten. Vaak is het een rapportage in een uncommitted transactie of een OPEN TRANSACTION die per ongeluk niet gecommit is. KILL met de session_id breekt de chain in seconden. De keuze tussen kill en wachten hangt af van wat de root-sessie aan het doen is.
Lock escalation begrijpen
Boven ongeveer 5000 rij-locks promoveert SQL Server naar tabellock. Dat is een prestatie-optimalisatie die opeens een hele tabel onbruikbaar maakt voor de duur van de transactie. ALTER TABLE... SET (LOCK_ESCALATION = DISABLE) of WITH (ROWLOCK) is een chirurgische ingreep voor specifieke rapportage- of UPDATE-queries.
Isolation level afstemmen
Default READ COMMITTED zonder snapshot zorgt voor reader-writer-blocking. SET TRANSACTION ISOLATION LEVEL READ COMMITTED SNAPSHOT op database-niveau elimineert dat. Voor transactionele integriteit gebruiken we READ COMMITTED SNAPSHOT plus expliciete UPDLOCK waar het echt nodig is.
Lange transacties opsporen
sys.dm_tran_active_transactions samen met sys.dm_exec_sessions vertelt welke transacties al uren openstaan. Een ORM die per ongeluk niet commit, een interactieve SSMS-sessie van een developer, of een bug in een batch-job: drie veelvoorkomende oorzaken.
Lock timeout als vangnet
SET LOCK_TIMEOUT op applicatie-niveau geeft een nette foutmelding na bijvoorbeeld 30 seconden in plaats van uren wachten. Voor read-replica-rapportages een veilige default. Voor schrijfwerk apart per transactie afwegen.
Verwant: SQL DBA inhuren, Deadlock analyse.