Een gebruiker meldt dat een boeking mislukt, maar bij de tweede poging lukt hij wel. Je herkent het patroon: zo’n storing komt en gaat, en laat nauwelijks sporen achter. Vaak zit er een deadlock of een lock timeout achter. Een goede deadlock analyse in Business Central begint daarom met één vraag: hoe reproduceer je het probleem op commando? De Deadlock Simulator beantwoordt die vraag. Deze AL-extensie veroorzaakt deadlocks en lock timeouts met opzet, zodat je ze rustig in een sandbox kunt onderzoeken via KQL.
Zo veroorzaak, vind en begrijp je deadlocks en lock timeouts met de Deadlock Simulator.
Wat is een het, en waarom is Deadlock analyse in Business Central zo lastig?
Een deadlock ontstaat wanneer twee sessies elk een record vasthouden dat de ander nodig heeft. Sessie A wacht op sessie B, en sessie B wacht op sessie A. Geen van beide kan verder. SQL Server herkent die cirkel binnen enkele seconden, kiest één sessie als slachtoffer en draait de transactie van dat slachtoffer terug. De andere sessie loopt vervolgens gewoon door.
Daarom is analyse lastig. Het probleem hangt namelijk af van timing: je ziet het alleen wanneer twee processen op precies het verkeerde moment dezelfde records raken. Bovendien meldt de gebruiker alleen een foutmelding, terwijl de oorzaak bij een andere sessie ligt die niemand ziet.
Deadlock of lock timeout: wat is het verschil?
Beide problemen lijken op elkaar, maar ze werken anders.
- Deadlock: twee sessies wachten wederzijds op elkaar. SQL Server grijpt zelf in en breekt één sessie af.
- Lock timeout: één sessie houdt een lock te lang vast, bijvoorbeeld tijdens een trage batchjob. Een tweede sessie wacht tot de lock timeout verloopt (in Business Central online standaard 30 seconden) en krijgt dan een foutmelding.
Beide problemen laten sporen na in de telemetrie. Business Central logt een deadlock als event RT0028, een lock timeout als RT0012 en een lock snapshot als RT0013. Je moet die sporen echter wel kunnen uitlokken en herkennen. Precies daar helpt de simulator. In een andere blog post bekijken we de gegenereerde deadlock en lock timeouts via KQL.
Wat doet de Deadlock Simulator precies?
De Deadlock Simulator is een extensie voor Business Central die opzettelijk vergrendelingsproblemen veroorzaakt. Hij werkt op een eigen testtabel met vijf rijen, dus hij raakt geen standaardtabellen. Je kiest op een pagina een scenario, waarna de extensie meerdere achtergrondsessies start. Elke sessie krijgt een rol en vergrendelt rijen volgens een vast patroon. Vervolgens legt de extensie per sessie vast hoe het afliep en hoe lang het duurde. Foutregels kleuren rood in de log.
De vier scenario’s
| Scenario | Wat de extensie doet | Wat je ziet |
|---|---|---|
| Deadlock | Twee sessies vergrendelen rij 1 en 2 in omgekeerde volgorde | SQL Server kiest een slachtoffer; die sessie krijgt een deadlock-fout |
| Row lock timeout | Sessie A wijzigt rij 1 en houdt de lock vast. Sessie B wil dezelfde rij wijzigen | Sessie B wacht tot de timeout en krijgt een foutmelding |
| Table lock timeout | Sessie A vergrendelt alle rijen met LockTable. Sessie B wil een andere rij wijzigen | Sessie B loopt toch vast, ook al raakt hij een andere rij |
| Blocking chain | Sessie A houdt rij 1 vast terwijl twee andere sessies achter elkaar wachten | Beide wachters lopen tegen de timeout aan, terwijl A de oorzaak blijft |
Bij de timeout-scenario’s houdt de blokkerende sessie de lock standaard 45 seconden vast. Dat is bewust langer dan de timeout van de omgeving. Zo gebeurt het in het echt ook: een transactie duurt te lang, terwijl iemand anders dezelfde data nodig heeft.
Hoe werkt de extensie onder de motorkap?
De extensie volgt een duidelijke volgorde:
- Eerst maakt een beheercodeunit per scenario een aantal taken aan, met een rol, een rij en een vertraging per sessie.
- Daarna start de extensie voor elke taak een achtergrondsessie met
StartSession. - Vervolgens voert elke sessie zijn rol uit: een rij of tabel vergrendelen en vasthouden, op een lock wachten, of twee rijen in een vaste volgorde vergrendelen.
- Ten slotte vangt de sessie een eventuele fout op, meet de duur en schrijft het resultaat naar de log.
De pagina wacht standaard tot alle sessies klaar zijn en toont dan een samenvatting met de eerste fout. Wil je dat liever niet, dan zet je in de setup Wait For Result uit. Daarnaast stel je in de setup de houdtijd, de startvertraging van de wachter en de vertraging in het deadlock-scenario in.
Eigen telemetrie voor zekerheid
De platformtelemetrie toont bij een deadlock alleen het slachtoffer. Daarom stuurt de extensie ook eigen events naar Application Insights, van DL0001 (job gestart) tot DL0006 (lock wordt vastgehouden). Elk event bevat het run-nummer, het scenario, de rol, de sessie en de rij. Hierdoor weet je achteraf precies welke sessie welke rij vastzette, en dus wie de veroorzaker was.
Waarvoor is de Deadlock analyse Simulator in Business Central bedoeld?
De simulator dient uitsluitend voor testen en leren. Je gebruikt hem bijvoorbeeld om:
- telemetrie en alerts te testen: je controleert of je monitoring een deadlock of lock timeout daadwerkelijk opmerkt;
- KQL te oefenen: je draait de analyse-queries op echte events in plaats van op theorie;
- dashboards te valideren: je ziet of een Power BI-rapport over locks de juiste gegevens toont;
- foutafhandeling te testen: je kijkt hoe je eigen code reageert wanneer een transactie mislukt;
- collega’s op te leiden: je laat zien hoe een blocking chain ontstaat, zodat het concept blijft hangen.
De extensie is dus nadrukkelijk niet bedoeld voor productie.
Deadlock analyse in Business Central: zo doe je dat!
Kies eerst een scenario en wacht tot de samenvatting verschijnt. Wacht daarna enkele minuten, want telemetrie komt met vertraging binnen. Open vervolgens in Application Insights de logs en draai de queries.
- Zoek deadlocks op via
RT0028. Dat event toont het slachtoffer, het AL-object en het SQL-statement. - Zoek lock timeouts op via
RT0012en koppel ze via desnapshotIdaanRT0013. Zo zie je welke SQL-sessie de lock vasthield. - Leg daarnaast de eigen events
DL0001tot en metDL0006ernaast. Daarmee bevestig je de veroorzaker.
Zo leer je het verschil tussen een slachtoffer en een veroorzaker. Dat onderscheid is in de praktijk vaak de sleutel tot de oplossing.
Veilig testen: wat je moet weten
- Gebruik de simulator uitsluitend in een sandbox of testomgeving.
- De extensie vergrendelt alleen rijen in zijn eigen tabel, dus andere gebruikers merken er niets van.
- De sessies blijven bij de timeout-scenario’s ongeveer een minuut actief.
- Controleer vooraf het object-ID-bereik. Een conflict met een andere extensie voorkom je door in
app.jsoneen afwijkend bereik te kiezen. - Wijs de permissieset DL SIMULATOR toe aan iedereen die de simulator gebruikt.
Conclusie
Deadlocks en lock timeouts zijn lastig, omdat je ze zelden op het juiste moment ziet. De Deadlock Simulator lost dat op: hij veroorzaakt ze op commando, legt vast wat er gebeurt en levert de telemetrie waarmee je ze leert analyseren. Kortom, wie goede deadlock analyse in Business Central wil doen, oefent eerst in een veilige omgeving en zoekt daarna pas in productie naar de echte oorzaak.
Wil je alvast meer weten over database deadlock trace telemetry, klik dan hier. Wil je alvast meer weten over database lock timeout trace telemetry, klik dan hier. Tot slot als je vragen hebt voor de Digitale Mels, neem dan contact met mij op via de contact pagina.
