Som navnet antyder, er TempDB et midlertidigt arbejdsområde, der kræves af SQL Server til at skabe og opbevare mellemliggende og midlertidige objekter.
TempDB er et væsentligt tandhjul i det overordnede SQL Server-apparat og som et midlertidigt arbejdsområde - de data, det rummer, er af forbigående karakter. Med andre ord genskaber din SQL Server-instans TempDB, hver gang den genstarter – og giver sig selv en ren skrabeblokk, som den kan arbejde med.
- midlertidige objekter udløst af brugeranmodninger
- objekter, der kræves af interne systemprocesser
- rækkeversionsoplysninger
Det er overflødigt at sige, at hvis TempDB ikke er konfigureret optimalt, kan det føre til operationelle flaskehalse og en forringelse af ydeevnen. Det kan lade dig undre dig over, hvorfor dine forespørgsler med komplekse sammenføjninger og sorteringsoperationer ikke giver resultater så hurtigt som forventet.
Der er ingen nem måde at generalisere om de bedste praksisser for at optimere TempDB, scenarierne er for forskellige, og det, der virker i en given situation, fungerer muligvis ikke i en anden. Selvom din database er gået i produktion, er det altid en god idé at fortsætte med at gennemgå din TempDB-opsætning for at sikre, at den er konfigureret, som den skal være.
Et af de mest alvorlige problemer i databasens ydeevne er TempDB-strid. Dette sker, når flere ressourcer kræver TempDB, men der kun er en enkelt TempDB-datafil at få adgang til.
TempDB-påstand kan forårsage alvorlige ydeevneproblemer og misforstås ofte som normal blokering på grund af databaselåse. Mange gange er det faktisk låst strid på tildelingssiderne ved samtidige processer. Dette kan føre til flaskehalse, da hver proces venter på sin tur. Da turen ikke kommer hurtigt nok, skal de underliggende forbindelser timeout, og processerne skal deallokeres.
Hvad får du? En virtuel trafikprop af blokerede processer.
Hvordan løser man TempDB-strid og optimerer SQL Server-ydeevne? Lad os tage et kig på det grundlæggende og arbejde os derfra.
Antal datafiler – Hvor mange skal jeg have?
Når du opsætter SQL Server og beholder standardkonfigurationen, har du kun en enkelt datafil til TempDB. Vær ikke tilfreds med denne konfiguration.
En af de ofte omtalte tommelfingerregler er en enkelt datafil pr. kerne. Men fortsæt med forsigtighed i dette tilfælde, hvis din server har 12 kerner, så brug ikke 12 TempDB-datafiler, medmindre det er begrundet i applikations- og indlæsningskravene.
Den bedste mulighed, givet nutidens hardwarekonfigurationer, er at starte med 8 lige store primære datafiler og se, om stridsproblemet er løst. Arbejd dig opad og tilføj flere fire filer, hvis det er nødvendigt. Installations- og opsætningsguiden til SQL Server 2016 har en indbygget funktion, der sikrer, at du har et tilstrækkeligt antal TempDB-datafiler ved at detektere antallet af CPU-kerner og automatisk oprette det passende antal TempDB-datafiler.
Størrelse betyder noget – Hvordan skal datafilerne konfigureres til størrelse?
Nu hvor vi har dækket antallet af filer, lad os tage et kig på den anbefalede størrelse af hver fil. Standardstørrelsen er 8 MB, hvilket giver SQL Server i alt 64 MB TempDB-plads, hvilket er utilstrækkeligt til de fleste produktionsmiljøer. At beholde Autogrowth er også en mulighed, men SQL Server bliver nødt til at holde pause og allokere mere diskplads til TempDB-filerne, når det kræves - hvilket tilføjer betydelige overhead til SQL Server under en produktionskørsel.
Den anbefalede praksis er at holde filer og den indledende plads, der kræves for hver fil, på omkring 80 til 90 % af den volumen, som TempDB er gemt på. De 10 til 20 % diskplads er tilbage til OS-baseret virtuel hukommelse.
Med andre ord, forstørrelse af datafilerne under opsætningen eller ændre størrelsen på filerne i produktionsmiljøet. Dette vil sikre, at der er allokeret nok diskplads til TempDB. At holde Autogrowth-indstillingen aktiveret anbefales altid på dette tidspunkt, men ideelt set prøv at sikre, at SQL Server ikke behøver at allokere ekstra diskplads for ofte.
Et interessant faktum, før SQL Server 2017 var det ikke muligt at allokere mere end 1 GB pr. TempDB-datafil på opsætningstidspunktet. Med den seneste version er det muligt at allokere så meget som 256 GB til en TempDB-datafil under opsætningen.
Hvilket bringer os til det næste spørgsmål:
Hvor opbevarer jeg TempDB-datafilerne?
Før SQL Server 2012, i tilfælde af et klyngemiljø, skulle TempDB være placeret på diske, der blev delt mellem det klyngede miljø, som et storage area network (SAN). Fra og med SQL Server 2012 er det muligt at beholde TempDB-datafilerne på SSD-baseret lokal lagring. Dette skærer ned på, hvad der ville have været meget trafik mellem det delte SAN og SQL Server-instansen.
I de fleste tilfælde er den bedste mulighed for TempDB-placering en dedikeret lokal SSD. Hvis det ikke er muligt, bør det løse sandsynlige problemer med ydeevnen ved at holde den på en dedikeret diskenhed for sig selv med tilstrækkelig diskplads på forhånd. Sørg for konstant at overvåge diskens tilstand, så disklæsninger og -skrivninger udføres på et optimalt niveau.
Ideelt set bør mediet være det hurtigst mulige givet serverkonfigurationen, applikationskravene og sidst men ikke mindst det tildelte budget.
Nu hvor vi har fået et kig på det grundlæggende, lad os se på relevante og velkomne tilføjelser til forskellige SQL Server-tilføjelser efter SQL Server 2012.
Hvad er nyt?
SQL Server 2016
Dedikeret fane under opsætning
- Med denne udgave har SQL Server en dedikeret fane til TempDB-konfiguration under opsætningsworkflowet
- Installations- og opsætningsguiden til SQL Server 2016 har en indbygget funktion, der sikrer, at du har et tilstrækkeligt antal TempDB-datafiler på tidspunktet for installation af SQL Server. Den registrerer antallet af CPU-kerner og opretter automatisk TempDB-datafiler, med forbehold for et maksimum på 8. Du kan øge dette antal efter opsætning af SQL Server.
Øjeblikkelig filinitialisering
- SQL Server skal allokere diskplads til TempDB under den indledende opsætning, såvel som når filstørrelsen vokser i en produktionskørsel. Denne tildeling kan ske på to måder. Den første måde er ved at initialisere ubrugt diskplads ved at skrive nuller før tildeling af pladsen. Den anden måde er ved øjeblikkeligt at allokere filplads til TempDB-vækst.
- I den første metode skal SQL Server udføre en diskintensiv operation ved at initialisere hver logisk diskklynge. I denne metode kan de processer, der kører på serveren, der har brug for TempDB, blive nødt til at vente, hvilket skaber en flaskehals.
- Hvis du vælger at allokere filplads øjeblikkeligt i stedet, allokerer SQL-serveren øjeblikkeligt plads til Autogrowth uden at initialisere diskplads. Dette reducerer disk i/o hver gang der er et Autogrowth-krav og sikrer bedre gennemløb og ydeevne. Selvom det var muligt at slå IFI til i tidligere udgaver, var det en besværlig proces. I denne udgave af SQL Server er det nemmere at opsætte IFI på tidspunktet for serveropsætning.
- Sporingsflag 1117 og 1118 er overflødige
SQL Server 2017
- Før SQL Server 2017 var det ikke muligt at allokere mere end 1 GB pr. TempDB-datafil på opsætningstidspunktet, hvilket betyder, at TempDB-filstørrelsen skulle øges, efter at opsætningen var fuldført. Med denne version er det muligt at allokere så meget som 256 GB til en TempDB-datafil under opsætningen.
Overvågning af TempDB
Det kan være svært at holde styr på TempDB. Hvordan kan du se, om du har TempDB-strid? Hvad bliver allokeret til brugerobjekter, versionslager eller interne objekter? Hvordan trender disse over tid? Hvilke sessioner bruger TempDB og i hvilken grad? Spotlight Cloud gør det nemt at besvare disse spørgsmål. Den overvåger alle aspekter af din SQL-serverydelse 24/7 og giver dybtgående analytiske arbejdsgange til at tackle ethvert ydeevneproblem. Spor din TempDB over tid og få automatiseret ekspertrådgivning om konfiguration.
Som en SaaS-løsning er Spotlight Cloud nem at opsætte og konfigurere. Den bevarer op til et års ydelsesdata, hvilket giver uovertruffen tuning-indsigt. Ydeevneproblemer kan løses på få sekunder med rodårsagsanalyse. Spild ikke mere tid på at grave gennem komplekse scripts - start din 30-dages prøveperiode nu. Førsteklasses SQL Server-ydeevneovervågning starter nu.