"Doc, ik maak me zorgen over mijn SQL Server-prestaties."
Het was niet het soort dat je van de meeste patiënten hoort. Maar als betaalde professional ben ik getraind om met alles om te gaan - zelfs de moeilijke tijden als databasebeheerder.
"Echt? Laten we dat onderzoeken, zullen we?”
'Natuurlijk, dok. Ik bedoel, soms voelt het zo overweldigend. Ik dacht dat alles vanzelf zou komen als ik me eraan had toegewijd. Maar voordat ik het wist, kreeg ik prestatieproblemen in SQL Server 2012, toen 2014 en daarna 2017. Ik wil niet eens nadenken over SQL Server 2019."
"Ik zie. Welnu, een goede relatie met SQL Server ontstaat niet vanzelf. Je moet eraan werken. Vertel eens, heb je gewerkt aan de technieken voor het afstemmen van SQL Server-prestaties?”
'Eh, nee, dokter. Ik ken die technieken niet echt.”
"Maak je geen zorgen. We kunnen eraan werken. Uw SQL Server voelt zich waarschijnlijk verwaarloosd. Je moet het in de gaten houden om ervoor te zorgen dat je voorop blijft lopen. Dat vereist SQL Server-monitoring.”
"Toezicht houden? Hoe doe je dat?”
“Je moet SQL Server laten zien dat je om hem geeft. Je moet letten op bepaalde metrics. Daar kunnen we ook aan werken.”
'Oké, dokter. Wat je ook zegt. Ik ben bereid om op dit moment alles te proberen. De dingen kunnen niet veel erger worden dan ze nu zijn.”
"Goed dan. Laten we beginnen."
SQL Server prestatiestatistieken — Veel bewegende delen
De patiënt had gelijk:het monitoren van uw SQL Server-prestaties kan overweldigend zijn. Je kunt er niet mee stoppen er aandacht aan te besteden als het eenmaal in gebruik is. Je moet blijven laten zien dat je om je geeft.
SQL Server heeft veel bewegende delen die constant statistieken genereren. Weten welke je moet bekijken en dan daadwerkelijk de tijd nemen om ze te controleren, kan veel werk zijn voor een DBA.
Dus nam ik een aantal van de belangrijkste gebieden van de prestatiestatistieken van SQL Server door met de patiënt.
Indexen
Een van de eerste plaatsen waar u moet kijken als u prestatieproblemen met SQL Server ondervindt, zijn de indexen. Uw gegevens groeien altijd, dus uw indexen groeien ook altijd. Maar ze zijn onderhevig aan voorwaarden zoals fragmentatie en paginasplitsingen die de reactie op vragen kunnen vertragen.
Wat gebeurt er dag in dag uit in een database? Gebruikers maken, bewerken en verwijderen records. De indexen houden bij waar alle stukken van de records zich bevinden, maar na verloop van tijd belemmert indexfragmentatie de prestaties.
Dan is er nog de indexvulfactor, een parameter die u in SQL Server kunt configureren om het aantal paginasplitsingen te regelen en de query-efficiëntie te verhogen. Maar de balans tussen meer en minder paginasplitsingen beïnvloedt de prestaties op andere manieren.
Statistieken bekijken in vulfactor , I/O en fragmentatie is een goede manier om uw vingers aan de pols te houden van de SQL Server-indexgezondheid.
Buffercache
Laten we dit eenvoudig maken:schijf, langzaam; buffercache, snel. De buffercache is een in-memory kopie van recent gebruikte databasepagina's. Als SQL Server daar niet vindt wat het zoekt, moet het ervoor naar de schijf gaan, wat de prestaties vertraagt.
Met SQL Server kunt u de hoeveelheid systeemgeheugen specificeren die aan de buffercache moet worden toegewezen, maar u moet inruilen voor geheugen dat overblijft voor andere taken. Uw doel is om zoveel mogelijk toe te wijzen zonder de prestaties van SQL Server op andere gebieden te belemmeren.
Ook belangrijk is de levensverwachting van een pagina, de hoeveelheid tijd die een pagina met informatie uit de database in de buffer doorbrengt zonder opnieuw te worden geopend. SQL Server verwijdert voortdurend pagina's uit de buffercache om ruimte te maken voor recenter gebruikte pagina's. Maar hoe minder nuttige pagina's het daar vindt, hoe meer het van de schijf moet lezen, wat de prestaties vertraagt.
Statistieken zoals levensverwachting pagina en verhouding van succesvolle hits in de buffercache helpen u beslissingen te nemen over het minder vaak verwijderen van pagina's of het vergroten van de cache.
T-SQL
SQL Server gebruikt een querytaal genaamd T-SQL. In plaats van ad hoc SQL-instructies uit te voeren, probeert SQL Server de prestaties te verbeteren door ze te batchen, ze als een uitvoeringsplan te compileren en ze in de cache op te slaan. Het probeert ook de frequentie van het opstellen en hergebruiken van uitvoeringsplannen zo vaak mogelijk te minimaliseren. Als het het uitvoeringsplan niet kan hergebruiken, bijvoorbeeld omdat de database te veel is veranderd, zal het het plan opnieuw compileren. Het is het beste om het aantal hercompilaties van SQL-instructies zo laag mogelijk te houden, omdat het proces grote hoeveelheden CPU kan verbruiken en de prestaties kan verminderen.
De noodzaak om te compileren en opnieuw te compileren is een functie van goede codeerpraktijken, zoals het gebruik van opgeslagen procedures en het parametriseren van queries. DBA's die statistieken controleren, zoals de snelheid van SQL-compilaties en SQL-hercompilaties kan SQL Server-queryhints wijzigen om de prestaties te verbeteren.
Vergrendelt, wacht en blokkeerde processen
Het is frustrerend om te ontdekken dat iemand anders iets aan het wijzigen is op hetzelfde moment als jij. Dus databases vergrendelen automatisch dingen zoals rijen en tabellen om meerdere koks uit de keuken te houden. De wisselwerking voor die bescherming is natuurlijk dat alle andere gebruikers moeten wachten tot de bron is ontgrendeld. En het is moeilijk om ervoor te zorgen dat de vergrendeling alleen plaatsvindt op het niveau dat nodig is.
Met statistieken die laten zien hoe vaak en hoe breed vergrendelingen andere bewerkingen beïnvloeden, kunnen DBA's bepalen of er meer fysieke systeembronnen nodig zijn om transacties sneller te verwerken. Het kan ook zijn dat SQL Server op een onnodig laag niveau blokkeert. De frequentie van lock waits en, meer in het algemeen, het aantal geblokkeerde processen kan helpen bij het lokaliseren van knelpunten.
Knelpunten elimineren met afstemming van SQL-prestaties
'Goh, Doc, je hebt gelijk over alle bewegende delen. Nu zie ik hoe ik SQL Server niet zomaar kan installeren, instellen en vergeten. Ik moet de relatie koesteren. Maar dit alles voelt nog steeds overweldigend. Hoe kan ik ooit zoveel verschillende dingen recht houden en voorop blijven lopen?”
“Dat is het beste deel. Er zijn hulpprogramma's die u kunnen helpen met uw SQL Server-prestaties. Je hoeft het niet alleen te doen."
“Wauw! Dat is geruststellend. Dat wist ik niet.”
"Dat klopt. De tools bewaken de prestaties van uw SQL-server en rapporteren al deze statistieken, zodat u uw afstemmingstechnieken kunt toepassen en knelpunten kunt elimineren."
"Echt?"
"Zeker. En daar kunnen we aan werken - oh my, we hebben geen tijd meer voor deze week. Maak dan een afspraak met mijn receptioniste en we halen volgende week op.”
'Jongen, die vier uur gingen snel voorbij, dokter! De tijd vliegt zeker als je prestatieproblemen rond fragmentatie, resourcegebruik . oplost en buffer cache hit ratio , nietwaar?”
"Ja, en ik weet zeker dat als je eenmaal openlijk over die problemen met je SQL Server communiceert, al je prestatieproblemen verleden tijd zullen zijn."
Gesterkt door onze sessie vertrok de patiënt. De volgende keer zullen we werken aan het monitoren van knelpunten in de prestaties van SQL Server. Ik zal erover bloggen, dus houd het in de gaten.
Ondertussen, geloof me. Ik ben een betaalde professional en ik moedig je aan om deze dingen te proberen in je eigen relatie met je database. Laat uw SQL Server zich gewild voelen. Let op de prestatiestatistieken.
Het is nooit te laat om het te proberen.