Een trage SQL Server in productie is geen bug-hunt, het is triage. Eerst stabiliseren, dan diagnosticeren. Onze freelance SQL DBA's volgen een vast spoor zodat de afspraak met de business voorspelbaar wordt: binnen een uur weet u wat de oorzaak is en wat de fix kost.
Eerste vijf minuten: vaststellen wat klem zit
sp_whoisactive met @get_locks = 1 toont de actuele sessies, blocking-keten en wait-types. Negen van de tien acute incidenten zijn een lange transactie die locks vasthoudt of een runaway-query die een kerntabel scant. Wie de root-sessie kan KILLen, heeft binnen een minuut productie terug, ook al is dat geen permanente fix.
Wait-stats over een kort venster
Niet de cumulative sys.dm_os_wait_stats, want die toont uren oude historie. We snapshotten wait-stats over twee minuten en kijken wat domineert. PAGEIOLATCH wijst op storage of geheugentekort. CXPACKET op parallellisme. LCK_M_X op blocking. RESOURCE_SEMAPHORE op een query die memory grant ophokt. Ieder waittype heeft een ander vervolgonderzoek.
Plan-cache en parameter sniffing
Een query die gisteren in 200ms liep en vandaag 30 seconden, is bijna altijd een plan-cache-issue. sys.dm_exec_query_stats gekoppeld aan sys.dm_exec_query_plan vertelt welke planhash bij welk plan hoort. DBCC FREEPROCCACHE op een specifieke plan_handle is veiliger dan een totale cache-flush.
TempDB en latching
PAGELATCH-waits op pagina 2:1:1 of 2:1:3 wijzen op TempDB-allocatie-contentie. Trace flag 1118, meer datafiles, of in 2019+ memory-optimized TempDB metadata zijn de standaardingrepen. Wij meten of TempDB de bottleneck is voordat we eraan komen, want een verkeerde ingreep maakt het erger.
Storage-throughput valideren
Voordat we naar query-tuning gaan, kijken we naar disk-latency in sys.dm_io_virtual_file_stats. Boven 20ms reads is geen software-probleem maar een infrastructuurprobleem. Een freelance SQL DBA inhuren voor query-tuning op trage storage is geld in een put gooien.
Verwant: Freelance SQL DBA inhuren, SQL Server health check.