Brent Ozar ved alt om at køre hurtigt – han kører biler, og han sætter gang i SQL-servere med betagende resultater i databasen hver dag. I sin webcast "How to measure SQL Server" for Quest's Database Training Days-serie, Brent mindede os om, at ydeevne handler om måling.
Virder op for ydeevne
Brent benyttede lejligheden til at øve social distancering og klædte delen på ved at iføre sig en hel racerdragt og hjelm. I nogle pre-webcast drillerier fandt vi ud af, at han skulle tilslutte en mikrofon i hjelmen og tape øretelefonerne til sine ører! Men vi afviger. Webcasten handlede udelukkende om ydeevne, og der var masser af bilanalogier at gå rundt om.
For at forbedre SQL Server-ydeevnen er præmisserne:
- Vælg metrics for at fokusere på at forbedre
- Mål ydeevne før og efter at have foretaget begrænsede ændringer (grundlæggende videnskabelig metode)
- Forstå, når du har det forkerte udstyr til det, du forsøger at opnå
Metrics for justering af databaseydeevne
En længere diskussion af Ford F150-lastbiler, Ford Fiestas og nogle andre interessante køretøjer illustrerede, at der er forskellige måder at forbedre den tid, det tager at køre fra 0 til 60 miles i timen. Du kan reducere køretøjets vægt, tilføje en større motor eller begynde at fjerne ikke-nødvendige ting - som en forrude. Der vil være et kompromis mellem ydeevne og nytte. Databaser er ligesom dette - de bliver ofte indlæst. Det er her, der er behov for tilpasset ydelsesjustering, hvilket kræver at kende og forbedre metrics.
Brent hævder, at der er tre primære målinger, du har brug for til at justere biler og databaser med ydeevne:vægt, hastighedsbenchmark (som 0 til 60), og hvor hårdt motoren (serveren) arbejder.
Måler databasestørrelse
Vægt for SQL Server oversættes til den samlede databasestørrelse og hvor meget data du har. Dette måles normalt i gigabyte eller terabyte. Fra omkring 1-150 GB burde SQL Server Standard Edition være tilstrækkelig. Fra 150-500 GB er en nem belastning for Enterprise Edition. Ud over 500 GB begynder det at være ligegyldigt, om det er aktive data, og hvordan der tilgås dem. Og alt over 1 TB OLTP-data kan være meget udfordrende.
Sporing af ydeevnehastighed
Hastighedsmålet i biler er nemt – MPH. For databasen er det batch-anmodninger pr. sekund, men dette skal trendes hver time i forskellige tidsperioder. Jo flere forespørgsler der er, jo langsommere vil ydeevnen være afhængigt af hardwaren.
Vurdering af forespørgselsarbejdsbelastninger
Til sidst, for at forstå, hvor hårdt databasen arbejder, skal du forstå, hvilke forespørgsler der kører i øjeblikket, og hvad der venter i køen. Dette vil give dig et ventetidsforhold - dybest set hvor længe venter opgaver på, at andre skal fuldføre. Dit ventetidsforhold vil blive udtrykt som timers ventetid pr. time (eller sekunders ventetid pr. sekund) - bland ikke dine måleenheder. Når du har et godt styr på disse statistikker over tid, kan du se, hvad der påvirker ventetiden, for eksempel hvis der er flere eller færre batch-anmodninger, bedre eller dårligere tunede forespørgsler osv. Så kan du løse disse problemer.
Se optagelsen af on-demand-webinaret for alle Brents vismandsråd og humor.