TempDB is een gedeelde bron die door elke sessie aangeraakt wordt: snapshot isolation, hash spills, sort spills, table variables, temp tables en versioning. Op moderne servers met tientallen cores wordt TempDB-allocatie de bottleneck voordat I/O of CPU dat zijn. Een freelance MSSQL DBA pakt dit gestructureerd aan.
Hoeveel datafiles en hoe groot
Vuistregel: één datafile per logical CPU tot acht, daarna in stappen van vier evalueren. Alle bestanden gelijk groot, met identieke autogrowth-instellingen. Trace flag 1117 en 1118 zijn sinds SQL Server 2016 standaardgedrag voor TempDB; voor oudere versies expliciet zetten.
Memory-optimized TempDB metadata
Sinds SQL Server 2019 is metadata-tabellen in TempDB als memory-optimized configureerbaar. Dit elimineert PAGELATCH-contentie op systeemtabellen volledig. De prijs is extra werkgeheugen en een instance-restart om aan en uit te zetten. Voor zware multi-tenant of OLTP-workloads is dit het verschil tussen klem en soepel.
Sizing en autogrowth
TempDB elke nacht laten autogrowthen kost zeroing-tijd (instant file initialization helpt op MDF maar niet op LDF). Pre-size TempDB op de verwachte piekomvang plus marge. Voor een grote ETL-nacht is dat soms 100 GB of meer. Te klein scheelt geheugen, te groot kost niets behalve disk.
Wat in TempDB hoort en wat niet
Table variables onder een paar duizend rijen blijven vaak in geheugen. Tabellen erboven kun je beter als #temp_table aanmaken; die krijgen statistics en betere plans. Cursors, recursieve CTE's en grote sort-operaties vreten TempDB. We reviewen de top TempDB-consumers met sys.dm_db_session_space_usage.
Monitoring en alerting
Een alerting op PAGELATCH_UP-waits op TempDB-pagina 2:1:1 of 2:1:3 vangt contentie voordat de business klaagt. We zetten dat standaard mee als wij beheer overnemen. Een wakende DBA voorkomt een nachtelijke escalatie.
Verwant: SQL DBA inhuren, SQL Server health check.