Som namnet antyder är TempDB en tillfällig arbetsyta som krävs av SQL Server för att skapa och hålla mellanliggande och temporära objekt.
TempDB är en betydande kugge i den övergripande SQL Server-apparaten och som en tillfällig arbetsyta – den data den innehåller är övergående till sin natur. Med andra ord, din SQL Server-instans återskapar TempDB varje gång den startar om – vilket ger sig själv en ren scratch pad som den kan arbeta med.
- tillfälliga objekt som utlöses av användarförfrågningar
- objekt som krävs av interna systemprocesser
- radversionsinformation
Onödigt att säga att om TempDB inte konfigureras optimalt kan det leda till operativa flaskhalsar och en försämring av prestanda. Det kan få dig att undra varför dina frågor med komplexa sammanfogningar och sorteringsoperationer inte ger resultat så snabbt som förväntat.
Det finns inget enkelt sätt att generalisera om de bästa metoderna för att optimera TempDB, scenarierna är för olika och det som fungerar i en given situation kanske inte fungerar i en annan. Även om din databas har satts i produktion är det alltid en bra idé att fortsätta granska din TempDB-inställning för att säkerställa att den är konfigurerad som den ska vara.
Ett av de allvarligaste problemen med databasprestanda är TempDB-strid. Detta händer när flera resurser kräver TempDB, men det finns bara en enda TempDB-datafil att komma åt.
TempDB-konflikt kan orsaka allvarliga prestandaproblem och missförstås ofta som normal blockering på grund av databaslås. Många gånger är det faktiskt låst argument på allokeringssidorna av samtidiga processer. Detta kan leda till flaskhalsar när varje process väntar på sin tur. Eftersom svängen inte kommer tillräckligt snabbt, måste de underliggande anslutningarna timeout och processerna deallokeras.
Vad får du? En virtuell trafikstockning av blockerade processer.
Hur löser man TempDB-konflikter och optimerar SQL Server-prestanda? Låt oss ta en titt på grunderna och arbeta oss därifrån.
Antal datafiler – Hur många ska jag ha?
När du ställer in SQL Server och behåller standardkonfigurationen har du bara en enda datafil för TempDB. Nöj dig inte med den här konfigurationen.
En av de ofta utpekade tumreglerna är en enda datafil per kärna. Men fortsätt med försiktighet i det här fallet, om din server har 12 kärnor, använd inte 12 TempDB-datafiler om det inte motiveras av applikations- och belastningskraven.
Det bästa alternativet, med tanke på dagens hårdvarukonfigurationer, är att börja med 8 lika stora primära datafiler och se om konfliktproblemet är löst. Arbeta dig uppåt och lägg till ytterligare fyra filer om det behövs. Installations- och installationsguiden för SQL Server 2016 har en inbyggd funktion som säkerställer att du har ett tillräckligt antal TempDB-datafiler genom att detektera antalet CPU-kärnor och automatiskt skapa rätt antal TempDB-datafiler.
Storleken spelar roll – Hur ska datafilerna konfigureras för storlek?
Nu när vi har täckt antalet filer, låt oss ta en titt på den rekommenderade storleken på varje fil. Standardstorleken är 8 MB, vilket ger SQL Server totalt 64 MB TempDB-utrymme, vilket är otillräckligt för de flesta produktionsmiljöer. Att behålla Autogrowth är också ett alternativ, men SQL Server kommer att behöva pausa och allokera mer diskutrymme för TempDB-filerna när det behövs – vilket lägger till betydande overhead till SQL Server under en produktionskörning.
Rekommenderad praxis är att behålla filer och det initiala utrymmet som krävs för varje fil att vara ungefär 80 till 90 % av volymen som TempDB lagras på. 10 till 20 % diskutrymme finns kvar för OS-baserat virtuellt minne.
Med andra ord, förstorleksanpassa datafilerna under installationen eller ändra storleken på filerna i produktionsmiljön. Detta säkerställer att tillräckligt med diskutrymme allokeras för TempDB. Att behålla alternativet Autogrowth på rekommenderas alltid vid denna tidpunkt, men helst försök att se till att SQL Server inte behöver allokera ytterligare diskutrymme i farten för ofta.
Ett intressant faktum, före SQL Server 2017 var det inte möjligt att allokera mer än 1 GB per TempDB-datafil vid installationstillfället. Med den senaste versionen är det möjligt att allokera så mycket som 256 GB för en TempDB-datafil under installationen.
Vilket för oss till nästa fråga:
Var förvarar jag TempDB-datafilerna?
Före SQL Server 2012, i fallet med en klustrad miljö, måste TempDB finnas på diskar som delas mellan den klustrade miljön, som ett lagringsnätverk (SAN). Från och med SQL Server 2012 är det möjligt att behålla TempDB-datafilerna på SSD-baserad lokal lagring. Detta skär ner på vad som skulle ha varit mycket trafik mellan det delade SAN och SQL Server-instansen.
I de flesta fall är det bästa alternativet för TempDB-placering en dedikerad lokal SSD. Om det inte är möjligt bör det lösa troliga prestandaproblem att hålla den på en dedikerad volym för sig, med tillräckligt med diskutrymme förtilldelat. Se till att du ständigt övervakar diskens hälsa så att diskläsningar och skrivningar utförs på en optimal nivå.
Helst bör media vara snabbast möjliga med tanke på serverkonfigurationen, applikationskraven och sist men inte minst den tilldelade budgeten.
Nu när vi har tagit en titt på grunderna, låt oss titta på relevanta och välkomna tillägg till olika SQL Server-tillägg efter SQL Server 2012.
Vad mer är nytt?
SQL Server 2016
Särskild flik under installationen
- Med den här utgåvan har SQL Server en dedikerad flik för TempDB-konfiguration under installationsarbetsflödet
- Installations- och installationsguiden för SQL Server 2016 har en inbyggd funktion som säkerställer att du har ett tillräckligt antal TempDB-datafiler när du installerar SQL Server. Den upptäcker antalet CPU-kärnor och skapar automatiskt TempDB-datafiler, med förbehåll för maximalt 8. Du kan öka detta antal efter att ha konfigurerat SQL Server.
Omedelbar filinitiering
- SQL Server måste allokera diskutrymme för TempDB under den första installationen såväl som när filstorleken växer i en produktionskörning. Denna tilldelning kan vara möjlig på två sätt. Det första sättet är att initiera oanvänt diskutrymme genom att skriva nollor innan utrymmet allokeras. Det andra sättet är genom att omedelbart allokera filutrymme för TempDB-tillväxt.
- I den första metoden måste SQL Server utföra en diskintensiv operation genom att initiera varje logiskt diskkluster. I den här metoden kan de processer som körs på servern som behöver TempDB behöva vänta, vilket skapar en flaskhals.
- Om du väljer att omedelbart allokera filutrymme istället, allokerar SQL-servern omedelbart utrymme för Autogrowth utan att initiera diskutrymme. Detta minskar disk-i/o varje gång det finns ett Autogrowth-krav och säkerställer bättre genomströmning och prestanda. Även om det var möjligt att slå på IFI i tidigare utgåvor var det en besvärlig process. I den här utgåvan av SQL Server är det lättare att ställa in IFI vid tidpunkten för serverinstallationen.
- Spårningsflaggor 1117 och 1118 är redundanta
SQL Server 2017
- Före SQL Server 2017 var det inte möjligt att allokera mer än 1 GB per TempDB-datafil vid installationstillfället, vilket innebär att TempDB-filstorleken måste ökas efter att installationen var klar. Med denna version är det möjligt att allokera så mycket som 256 GB för en TempDB-datafil under installationen.
Övervaka TempDB
Att hålla reda på TempDB kan vara svårt. Hur kan du se om du har TempDB-strid? Vad allokeras till användarobjekt, versionslager eller interna objekt? Hur trendar dessa över tid? Vilka sessioner konsumerar TempDB och i vilken grad? Spotlight Cloud gör det enkelt att svara på dessa frågor. Den övervakar alla aspekter av din SQL-serverprestanda 24/7 och tillhandahåller djupgående analytiska arbetsflöden för att hantera alla prestandaproblem. Spåra din TempDB över tid och få automatiserade expertrådgivningar om konfiguration.
Som en SaaS-lösning är Spotlight Cloud lätt att konfigurera och konfigurera. Den behåller upp till ett års prestandadata och ger oslagbara insikter om inställning. Prestandaproblem kan lösas på några sekunder med grundorsaksanalys. Slösa inte mer tid på att gräva igenom komplexa skript – starta din 30-dagars provperiod nu. Övervakning av SQL Server-prestanda i toppklass startar nu.