SQL Server wachtstatistieken lezen: waar wacht je server op?
Een database die hapert, wacht altijd ergens op. SQL Server houdt zelf bij waarop en hoe lang. Hier lees je hoe je die wachtstatistieken ophaalt, hoe je ze leest en wat je daarna als eerste aanpakt.
Wachtstatistieken in SQL Server laten zien waar de server op wacht: schijf, geheugen, CPU of een geblokkeerde query. Je vraagt ze op via sys.dm_os_wait_stats, een overzicht dat optelt sinds de laatste herstart of reset. Vergelijk twee metingen en kijk welke wachttypen in die periode de meeste wachttijd opleveren.
Wat zijn wachtstatistieken in SQL Server?
Wachtstatistieken zijn de boekhouding die SQL Server bijhoudt over zijn eigen wachttijd. Elke keer dat een taak moet wachten, legt SQL Server vast waarop en hoe lang. Eenvoudig gezegd: het is de lijst die laat zien of je database vooral wacht op de schijf, het geheugen, de processor of op andere gebruikers.
Je vindt ze in de systeemweergave sys.dm_os_wait_stats. Volgens de documentatie op Microsoft Learn (geraadpleegd op 20 oktober 2026) staat er per wachttype één regel in, met onder meer deze kolommen.
De kolommen die je nodig hebt:
wait_type: de naam van het wachttype.
waiting_tasks_count: hoe vaak er op dit type is gewacht.
wait_time_ms: de totale wachttijd in milliseconden. Daar zit signal_wait_time_ms al in.
signal_wait_time_ms: de tijd tussen het moment dat een taak verder mag en het moment dat hij echt weer draait.
Twee dingen moet je weten voordat je de cijfers leest. Ten eerste zijn ze cumulatief: ze tellen op sinds de laatste herstart van SQL Server, of sinds iemand ze heeft gereset met DBCC SQLPERF. Wanneer de instantie is gestart, lees je af aan sqlserver_start_time in sys.dm_os_sys_info. Ten tweede toont het overzicht alleen afgeronde waits. Wat op dit moment nog wacht, staat er niet in.
Voor een SQL Server die onder serverbeheer valt, is dit een van de eerste plekken om te kijken als gebruikers klagen.
Hoe haal je de wachtstatistieken op en wat heb je nodig?
Je hebt een account met de juiste rechten nodig en twee metingen met tijd ertussen. Eén losse meting neemt alle geschiedenis sinds de herstart mee en zegt dus weinig over het probleem van vandaag.
Zo pak je het aan:
Regel de rechten. Op SQL Server 2019 en ouder heb je VIEW SERVER STATE nodig. Vanaf SQL Server 2022 is dat VIEW SERVER PERFORMANCE STATE.
Controleer de uptime. Draait de instantie pas kort, dan is er nog weinig gemeten.
Meet tijdens de drukte. Maak een momentopname, wacht een paar minuten en maak er nog een. Het verschil laat zien waar de server in die periode op wachtte.
Filter achtergrondwaits. Sommige processen slapen bewust of wachten op werk. Hun tellers lopen hard op, maar ze houden niemand op.
-- Wanneer is SQL Server gestart?
SELECT sqlserver_start_time FROM sys.dm_os_sys_info;
-- Meting 1: momentopname
SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
INTO #wait_t1
FROM sys.dm_os_wait_stats;
WAITFOR DELAY '00:05:00'; -- meet tijdens de drukte
-- Meting 2: verschil per wachttype
WITH delta AS (
SELECT w.wait_type,
w.waiting_tasks_count - t.waiting_tasks_count AS waits,
w.wait_time_ms - t.wait_time_ms AS wait_ms,
w.signal_wait_time_ms - t.signal_wait_time_ms AS signal_ms
FROM sys.dm_os_wait_stats AS w
JOIN #wait_t1 AS t ON t.wait_type = w.wait_type
WHERE w.wait_type NOT IN (
N'SLEEP_TASK', N'LAZYWRITER_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
N'WAITFOR', N'BROKER_TASK_STOP', N'XE_TIMER_EVENT',
N'REQUEST_FOR_DEADLOCK_SEARCH', N'CHECKPOINT_QUEUE',
N'LOGMGR_QUEUE', N'DIRTY_PAGE_POLL')
)
SELECT TOP (10) wait_type, waits, wait_ms, signal_ms,
CAST(100.0 * wait_ms / NULLIF(SUM(wait_ms) OVER (), 0) AS decimal(5,2)) AS pct_van_totaal
FROM delta
WHERE wait_ms > 0
ORDER BY wait_ms DESC;
DROP TABLE #wait_t1;Je krijgt per wachttype het aantal waits, de wachttijd, de signal-tijd en het aandeel in de totale wachttijd van die meetperiode. De filterlijst is een startpunt. Kom je een onbekende naam tegen, zoek hem dan eerst op in de lijst "Types of waits" op Microsoft Learn voordat je hem wegfiltert.
Welke wachttypen kom je het vaakst tegen en wat betekenen ze?
De naam van een wachttype vertelt op welk soort resource SQL Server wachtte. De tabel zet zes veelvoorkomende SQL Server wait types om in gewone taal.
Wachttype | Wat het betekent | Waar je als eerste kijkt |
|---|---|---|
PAGEIOLATCH_* | SQL Server wacht tot een datapagina van schijf in het geheugen is geladen | schijflatentie en of het geheugen groot genoeg is |
WRITELOG | SQL Server wacht tot het transactielog naar schijf is geschreven | de schijf waarop het logbestand staat |
LCK_M_* | een taak wacht op een lock die een andere taak vasthoudt | blokkerende sessies en lange transacties |
SOS_SCHEDULER_YIELD | een taak geeft de processor vrijwillig op en wacht op een nieuwe beurt | CPU-belasting en zware queries |
CXPACKET / CXCONSUMER | onderdelen van een parallel queryplan wachten op elkaar; een deel daarvan is normaal | instellingen voor parallellisme en de queryplannen |
RESOURCE_SEMAPHORE | een query wacht op werkgeheugen voordat hij mag starten | geheugentoewijzing en queries met grote sorteringen |
Kijk daarnaast naar het aandeel van signal_wait_time_ms. Dat is de tijd tussen "klaar om te draaien" en "echt draaien". Is dat aandeel groot, dan staan taken in de rij voor de processor: een aanwijzing voor CPU-druk.
Eén wachttype is geen oordeel, maar een richting. PAGEIOLATCH bovenaan kan op een trage schijf wijzen, maar ook op te weinig geheugen of op een query die een hele tabel leest. Zie je veel LCK_M-waits, lees dan ook SQL-deadlocks oplossen.
Wat doe je met de uitkomst?
Koppel het wachttype aan één waarschijnlijke oorzaak en één vervolgstap. Verander daarna één ding en meet opnieuw.
Van wachttype naar vervolgstap:
Schijf (PAGEIOLATCH, WRITELOG): Microsoft beschrijft in Troubleshoot slow SQL Server performance caused by I/O issues (geraadpleegd op 20 oktober 2026) hoe je met deze wachttypen en sys.dm_io_virtual_file_stats per databasebestand de latentie bepaalt. Volgens die handleiding geldt I/O als knelpunt wanneer deze waits structureel boven 10 à 15 milliseconden uitkomen. Het gemiddelde per wait reken je uit met wait_ms gedeeld door waits uit de query hierboven.
Geheugen of CPU (RESOURCE_SEMAPHORE, SOS_SCHEDULER_YIELD, hoge signal-tijd): controleer of de server goed gedimensioneerd is met SQL Server sizing: hoeveel RAM, CPU en opslag. Draait SQL Server op een virtuele machine, kijk dan ook naar het geheugen van een Hyper-V-host.
Blokkades (LCK_M_*): zoek uit welke sessies elkaar ophouden. De deadlock-post laat zien hoe.
Onderhoud: veel schijfwerk terwijl de hardware in orde is? Kijk of indexen en statistieken worden bijgehouden. Lees waarom database-onderhoud zo belangrijk is.
Eén trage query: gebruik Query Store. Volgens Microsoft Learn (geraadpleegd op 20 oktober 2026) houdt Query Store sinds SQL Server 2017 (14.x) wachtstatistieken per query bij.
ALTER DATABASE [jouw_database]
SET QUERY_STORE = ON (WAIT_STATS_CAPTURE_MODE = ON);Verander één ding tegelijk en meet daarna opnieuw. Anders weet je niet welke aanpassing het verschil maakte.
Na een grote wijziging kun je de tellers resetten met DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR), zodat oude cumulatieve waarden het effect niet verbergen. Overleg dat eerst met wie de server bewaakt. Wil je eerst snelle verbeteringen proberen? Begin dan met 5 quick wins voor een trage SQL Server.
Wanneer zijn wachtstatistieken niet het juiste startpunt?
Wachtstatistieken zijn een sterk hulpmiddel, maar niet altijd de eerste stap. In vier situaties kijk je beter ergens anders.
Kijk eerst ergens anders als:
Je software geen SQL Server gebruikt. Dan valt er niets te meten. Unit4 Multivers draait bijvoorbeeld op SQLBase en heeft Microsoft SQL Server niet nodig, al wordt het vaak toch geïnstalleerd.
Eén query of rapport traag is. De cijfers voor de hele server laten één query verdwijnen tussen al het andere werk. Kijk dan eerst naar het queryplan of naar Query Store.
De server net herstart is. De cijfers tellen op sinds de laatste herstart. Na korte tijd zeggen ze nog weinig.
De vertraging buiten de database zit. Ligt het probleem op de werkplek, in het netwerk of in de applicatie zelf, dan vind je het hier niet.
Hoe pakken wij dit aan voor bedrijven in Dordrecht en de Drechtsteden?
Wij nemen het grijze gebied tussen IT-beheer en softwareleverancier op ons. Wijzen de cijfers naar blokkades in een applicatie, dan leggen we bijvoorbeeld deadlock-grafieken bij de leverancier neer. Zo blijft het niet bij naar elkaar wijzen.
Bij accountantskantoren zien we dat onder Financial Data Suite vaak een te zware SQL Server staat. Multivers draait op SQLBase en heeft helemaal geen SQL Server nodig. Meer daarover lees je in IT voor accountantskantoren.
We werken voor organisaties in Dordrecht, Zwijndrecht, Papendrecht, Sliedrecht en de rest van de Drechtsteden. Hoe we servers beheren, lees je op serverbeheer. Meer over onze werkwijze in de regio vind je bij IT-beheer in Dordrecht.
Veelgestelde vragen
Wat is het verschil tussen wait_time_ms en signal_wait_time_ms?
wait_time_ms is de totale wachttijd, inclusief de signal-tijd. signal_wait_time_ms is alleen het deel tussen het vrijkomen van de resource en het moment dat de taak weer draait. Dat deel gaat dus over wachten op de processor.
Blijven wachtstatistieken bewaard na een herstart?
Nee. sys.dm_os_wait_stats begint opnieuw bij elke herstart van SQL Server en na een reset met DBCC SQLPERF.
Kan ik wachtstatistieken ook per query zien?
Ja, via Query Store vanaf SQL Server 2017. Je zet het per database aan met WAIT_STATS_CAPTURE_MODE = ON.
Welke rechten heb ik nodig?
VIEW SERVER STATE op SQL Server 2019 en ouder. Vanaf SQL Server 2022 is dat VIEW SERVER PERFORMANCE STATE.
Wat Sennin-IT voor jouw organisatie doet
Wij zorgen voor IT die gewoon werkt: veilig, stabiel en zonder gedoe. Geen helpdeskgedoe en geen standaardoplossingen, wel directe communicatie met iemand die je omgeving kent, en maatwerk dat past bij je software. Weet je niet zeker of de vertraging in de database, op de werkplek of in het netwerk zit? Dan zoeken we dat samen met je uit.
Opmerkingen