Zoals de naam al doet vermoeden, is TempDB een tijdelijke werkruimte die SQL Server nodig heeft voor het maken en bewaren van tussenliggende en tijdelijke objecten.
TempDB is een belangrijk radertje in het algehele SQL Server-apparaat en als tijdelijke werkruimte - de gegevens die het bevat, zijn van voorbijgaande aard. Met andere woorden, uw SQL Server-instantie hercreëert TempDB elke keer dat het opnieuw wordt opgestart, waardoor het zichzelf een schoon kladblok geeft waarmee het kan werken.
- tijdelijke objecten geactiveerd door gebruikersverzoeken
- objecten vereist door interne systeemprocessen
- rij versiebeheer informatie
Onnodig te zeggen dat als TempDB niet optimaal is geconfigureerd, dit kan leiden tot operationele knelpunten en een verslechtering van de prestaties. U vraagt zich misschien af waarom uw query's met complexe joins en sorteerbewerkingen niet zo snel resultaten opleveren als verwacht.
Er is geen gemakkelijke manier om te generaliseren over de best practices voor het optimaliseren van TempDB, de scenario's zijn te divers en wat in een bepaalde situatie werkt, werkt mogelijk niet in een andere. Zelfs als uw database in productie is gegaan, is het altijd een goed idee om uw TempDB-configuratie te blijven controleren om er zeker van te zijn dat deze is geconfigureerd zoals het hoort.
Een van de ernstigste problemen met databaseprestaties is de TempDB-conflict. Dit gebeurt wanneer meerdere bronnen TempDB nodig hebben, maar er is slechts één TempDB-gegevensbestand om toegang te krijgen.
TempDB-conflicten kunnen ernstige prestatieproblemen veroorzaken en worden vaak verkeerd begrepen als normale blokkering vanwege databasevergrendelingen. Vaak is het eigenlijk een vergrendelde bewering op de toewijzingspagina's door gelijktijdige processen. Dit kan tot knelpunten leiden omdat elk proces op zijn beurt wacht. Omdat de beurt niet snel genoeg komt, moeten de onderliggende verbindingen en de processen worden opgeheven.
Wat krijg je? Een virtuele verkeersopstopping van geblokkeerde processen.
Hoe lost u TempDB-conflicten op en optimaliseert u de prestaties van SQL Server? Laten we de basis eens bekijken en van daaruit verder werken.
Aantal gegevensbestanden – Hoeveel moet ik hebben?
Wanneer u SQL Server instelt en de standaardconfiguratie behoudt, heeft u slechts één gegevensbestand voor TempDB. Wees niet tevreden met deze configuratie.
Een van de vaak aangeprezen vuistregels is één gegevensbestand per kern. Maar ga voorzichtig te werk in dit geval, als uw server 12 cores heeft, gebruik dan geen 12 TempDB-gegevensbestanden, tenzij dit gerechtvaardigd is door de toepassings- en laadvereisten.
De beste optie, gezien de huidige hardwareconfiguraties, is om te beginnen met 8 primaire gegevensbestanden van gelijke grootte en te kijken of het conflictprobleem is opgelost. Werk naar boven en voeg indien nodig nog vier bestanden toe. De installatie- en configuratiewizard van SQL Server 2016 heeft een ingebouwde functie die ervoor zorgt dat u over een voldoende aantal TempDB-gegevensbestanden beschikt door het aantal CPU-cores te detecteren en automatisch het juiste aantal TempDB-gegevensbestanden te maken.
Grootte doet ertoe - Hoe moeten de gegevensbestanden worden geconfigureerd voor grootte?
Nu we het aantal bestanden hebben behandeld, gaan we eens kijken naar de aanbevolen grootte van elk bestand. De standaardgrootte is 8 MB, waardoor SQL Server in totaal 64 MB TempDB-ruimte heeft, onvoldoende voor de meeste productieomgevingen. Autogrowth behouden is ook een optie, maar SQL Server zal moeten pauzeren en meer schijfruimte moeten toewijzen voor de TempDB-bestanden wanneer dat nodig is, wat aanzienlijke overhead toevoegt aan SQL Server tijdens een productierun.
De aanbevolen praktijk is om bestanden en de initiële ruimte die nodig is voor elk bestand ongeveer 80 tot 90% van het volume te houden waarop de TempDB is opgeslagen. De 10 tot 20% schijfruimte blijft over voor op het besturingssysteem gebaseerd virtueel geheugen.
Met andere woorden, maak de databestanden vooraf op maat tijdens de installatie of wijzig de grootte van de bestanden in de productieomgeving. Dit zorgt ervoor dat er voldoende schijfruimte wordt toegewezen voor TempDB. Het wordt op dit moment altijd aanbevolen om de Autogrowth-optie aan te houden, maar probeer er idealiter voor te zorgen dat SQL Server niet te vaak extra schijfruimte hoeft toe te wijzen.
Een interessant feit, vóór SQL Server 2017 was het niet mogelijk om meer dan 1 GB per TempDB-gegevensbestand toe te wijzen op het moment van installatie. Met de nieuwste versie is het mogelijk om tijdens de installatie maar liefst 256 GB toe te wijzen aan een TempDB-gegevensbestand.
Dat brengt ons bij de volgende vraag:
Waar bewaar ik de TempDB-gegevensbestanden?
Vóór SQL Server 2012 moest TempDB zich in het geval van een geclusterde omgeving bevinden op schijven die werden gedeeld tussen de geclusterde omgeving, zoals een Storage Area Network (SAN). Vanaf SQL Server 2012 is het mogelijk om de TempDB-gegevensbestanden op SSD-gebaseerde lokale opslag te bewaren. Dit vermindert wat veel verkeer zou zijn geweest tussen het gedeelde SAN en de SQL Server-instantie.
In de meeste gevallen is de beste optie voor TempDB-locatie een speciale lokale SSD. Als dat niet mogelijk is, zou het op een eigen speciaal volume houden, met voldoende vooraf toegewezen schijfruimte, waarschijnlijke prestatieproblemen moeten oplossen. Zorg ervoor dat u constant de conditie van de schijf controleert, zodat het lezen en schrijven van de schijf op een optimaal niveau wordt uitgevoerd.
Idealiter zouden de media de snelst mogelijke moeten zijn, gezien de serverconfiguratie, applicatievereisten en last but not least, het toegewezen budget.
Nu we de basis hebben bekeken, gaan we kijken naar relevante en welkome toevoegingen aan verschillende SQL Server-toevoegingen na SQL Server 2012.
Wat is er nog meer nieuw?
SQL Server 2016
Toegewijd tabblad tijdens installatie
- In deze editie heeft SQL Server een speciaal tabblad voor TempDB-configuratie tijdens de installatieworkflow
- De installatie- en configuratiewizard van SQL Server 2016 heeft een ingebouwde functie die ervoor zorgt dat u voldoende TempDB-gegevensbestanden hebt op het moment dat u SQL Server installeert. Het detecteert het aantal CPU-cores en maakt automatisch TempDB-gegevensbestanden aan, met een maximum van 8. U kunt dit aantal verhogen na het instellen van SQL Server.
Directe bestandsinitialisatie
- SQL Server moet schijfruimte toewijzen aan TempDB tijdens de initiële installatie en ook wanneer de bestandsgrootte groeit tijdens een productierun. Deze allocatie kan op twee manieren. De eerste manier is door ongebruikte schijfruimte te initialiseren door nullen te schrijven voordat de ruimte wordt toegewezen. De tweede manier is door direct bestandsruimte toe te wijzen voor TempDB-groei.
- Bij de eerste methode moet SQL Server een schijfintensieve bewerking uitvoeren door elke logische schijfcluster te initialiseren. Bij deze methode moeten de processen die op de server worden uitgevoerd en die TempDB nodig hebben, mogelijk moeten wachten, waardoor een knelpunt ontstaat.
- Als je ervoor kiest om in plaats daarvan direct bestandsruimte toe te wijzen, wijst SQL-server direct ruimte toe voor Autogrowth zonder schijfruimte te initialiseren. Dit vermindert schijf-i/o elke keer dat er een Autogrowth-vereiste is en zorgt voor een betere doorvoer en prestaties. Hoewel het in vorige edities mogelijk was om IFI aan te zetten, was het een omslachtig proces. In deze editie van SQL Server is het eenvoudiger om IFI in te stellen tijdens het instellen van de server.
- Trace-vlaggen 1117 &1118 zijn overbodig
SQL Server 2017
- Vóór SQL Server 2017 was het niet mogelijk om meer dan 1 GB per TempDB-gegevensbestand toe te wijzen op het moment van installatie, wat betekent dat de TempDB-bestandsgrootte moest worden vergroot nadat de installatie was voltooid. Met deze versie is het mogelijk om tijdens de installatie maar liefst 256 GB toe te wijzen aan een TempDB-gegevensbestand.
Bewaking van TempDB
Het bijhouden van TempDB kan moeilijk zijn. Hoe kunt u zien of u TempDB-conflicten heeft? Wat wordt toegewezen aan gebruikersobjecten, versieopslag of interne objecten? Hoe evolueren deze in de loop van de tijd? Welke sessies verbruiken TempDB en in welke mate? Spotlight Cloud maakt het beantwoorden van deze vragen eenvoudig. Het bewaakt alle aspecten van uw SQL-serverprestaties 24/7 en biedt diepgaande analytische workflows om elk prestatieprobleem aan te pakken. Volg uw TempDB in de loop van de tijd en ontvang geautomatiseerd deskundig advies over configuratie.
Als SaaS-oplossing is Spotlight Cloud eenvoudig in te stellen en te configureren. Het behoudt tot wel een jaar aan prestatiegegevens, wat onverslaanbare tuning-inzichten oplevert. Prestatieproblemen kunnen binnen enkele seconden worden opgelost met analyse van de oorzaak. Verspil geen tijd meer aan het doorzoeken van complexe scripts - start nu uw proefperiode van 30 dagen. Eersteklas prestatiebewaking van SQL Server begint nu.