Het onderhouden van goed presterende SQL Server-instanties is een groot deel van de taakverantwoordelijkheden van een DBA. Het niet detecteren en corrigeren van ongebruikelijke activiteiten kan van invloed zijn op de interne bedrijfsvoering en de bedrijfsresultaten schaden.
Als u veranderingen in piekactiviteit of afwijkingen in een SQL Server-instantie opmerkt, zijn hier drie plaatsen om uw zoektocht naar antwoorden te starten.
Levensverwachting pagina
De paginalevensverwachting (PLE) van een instantie moet een redelijk consistent waardebereik behouden. Als die waarde daalt en laag blijft, is dat een teken dat de bufferpool een verhoogde vraag ervaart.
Bekijk de workload-activiteit voordat u het geheugen opraakt. Als de werkdruk is toegenomen, zou dat de extra druk op de bufferpool verklaren. Maar als de werklast niet is veranderd, moet u beter kijken om te bepalen wat het extra geheugen gebruikt.
Mogelijke redenen voor een daling van PLE zijn onder meer het actief uitvoeren van onderhoudstaken, het opnieuw opbouwen van de index of statistische updates, DBCC-bewerkingen en wijzigingen in het queryplan.
Als u een daling in PLE opmerkt die niet gepaard gaat met een toename van de werklast, zijn er een paar dingen die u kunt proberen om de PLE van een instantie te verbeteren:
- Laat ongebruikte indexen vallen
- Dubbele indexen samenvoegen
- Kijk uit voor grote zoekopdrachten
- Defragmenteren
- Gegevens wissen
WRITELOG Wachttijd
Wanneer de WRITELOG-wachttijd een te groot deel van de totale wachttijd is, heeft u waarschijnlijk een knelpunt op uw SQL Server-instantie. Het knelpunt wordt waarschijnlijk veroorzaakt door een probleem op de schijf waar het transactielogboek is opgeslagen of doordat gegevens inefficiënt worden vastgelegd.
Om te bepalen met wat voor soort bottleneck u te maken hebt, begint u met het analyseren van het aantal SQL-instructies dat wacht op de WRITELOG-gebeurtenis. Als er veel statements wachten, heb je een disk-bottleneck. Als er maar een paar statements wachten, worden er waarschijnlijk te vaak gegevens vastgelegd.
Er zijn verschillende manieren om de hoge WRITELOG-wachttijd op te lossen als je eenmaal hebt uitgezocht of je bottleneck schijfgerelateerd of commit-gerelateerd is:
- Voeg I/O-bandbreedte toe aan de schijf waar het transactielogboek is opgeslagen
- Verplaats niet-transactielog I/O van de schijf
- Verplaats het transactielogboek naar een minder drukke schijf
- Verklein de grootte van het transactielogboek
- Zorg ervoor dat de COMMIT-instructie in de code wordt geplaatst, zodat de gegevens niet te vaak worden vastgelegd
TempDB
TempDB is een tijdelijke werkruimte in SQL Server die tijdelijke objecten bevat. Omdat de objecten in TempDB van voorbijgaande aard zijn, maakt een SQL Server-exemplaar TempDB opnieuw aan elke keer dat het opnieuw wordt opgestart. Dit maakt het optimaliseren van TempDB van cruciaal belang om de prestaties te behouden en operationele knelpunten te voorkomen.
TempDB-conflict is een van de belangrijkste boosdoeners van prestatievermindering. Er ontstaat een conflict wanneer meerdere bronnen toegang tot TempDB nodig hebben, maar er is slechts één TempDB-gegevensbestand. Dit veroorzaakt een knelpunt omdat processen niet snel genoeg toegang hebben tot TempDB, wat leidt tot een time-out van verbindingen en het ongedaan maken van de toewijzing van processen.
Gelukkig kunnen TempDB-knelpunten vrij eenvoudig worden opgelost door het aantal en de grootte van TempDB-bestanden aan te passen. Na installatie is de SQL Server-standaard één TempDB-gegevensbestand. Als u constatering opmerkt, is het raadzaam acht nieuwe gegevensbestanden toe te voegen en te bepalen of dit het probleem verhelpt. Als het probleem niet is opgelost, probeer dan extra gegevensbestanden toe te voegen in veelvouden van vier totdat de prestaties zijn hersteld.
Hoewel het goed is om te weten waar u moet beginnen met zoeken wanneer u prestatieproblemen ondervindt, kunnen elk van de bovenstaande problemen en de daaruit voortvloeiende knelpunten worden verminderd of helemaal worden vermeden door één vaste regel te implementeren:het bewaken van prestatiestatistieken is niet optioneel. Hier zijn enkele voorbeelden van belangrijke statistieken om bij te houden:
Levensverwachting van pagina's:volg PLE met continue bewaking en wees proactief wanneer het daalt en onder de typische waarde voor een bepaalde SQL Server-instantie blijft.
WRITELOG-wachttijden:bewaak statistieken zoals loggroei, log-inkrimping, percentage loggebruik en log-flush-wachten/sec.
TempDB-inefficiëntie:controleer wat wordt toegewezen aan gebruikersobjecten, versieopslag of interne objecten. Houd bij hoe ze in de loop van de tijd trending zijn en bepaal vervolgens welke sessies TempDB verbruiken en hoeveel.
Er zijn een aantal uitstekende, betaalbare SQL Server-tools voor prestatiebewaking op de markt die u kunnen helpen prestatieverslechterende problemen het hoofd te bieden. Maak van jezelf de DBA MVP van het bedrijf door proactief onderzoek te doen naar oplossingen die ervoor zorgen dat zowel naar binnen gerichte operaties als naar buiten gerichte zakelijke services topprestaties blijven leveren.