Hvad nu hvis du gjorde alt besværet med at implementere eller opgradere til en ny SQL Server for at få en bedre oplevelse for dine kunder – og de klagede over, at tingene faktisk var værre?
Ville du ikke blive ked af det, hvis du sprang gennem alle de forretningsmæssige og tekniske rammer for at få bedre SQL Server-ydeevne, og så ikke gjorde det?
Måske skulle du have udført nogle SQL Server-ydelsestest, før du gik i produktion. Så ville du have vidst, om din præstation ville blive bedre, forblive den samme eller, værst af alt, falde.
Men du ville i det mindste ikke være blevet ubehageligt overrasket.
SQL Server-ydelsesbroen krydser vi alle
Uanset om det drejer sig om at skifte fra en anden database til SQL Server eller opgradere fra en ældre version af SQL Server til en nyere, måtte du krydse ydeevnebroen til sidst.
"Kommer det virkelig til at køre bedre end før?" spurgte din chef.
"Åh, selvfølgelig," sagde du. "Med datavirtualisering i SQL Server 2019 kan vi køre forespørgsler uden at flytte eller replikere data. Og der er automatisk tuning med Intelligence Query Processing for at opskalere forespørgsler. Dataene vil flyve ud af servere." Du var så sikker, at du skrev "FLY".
Så hvordan kunne du have testet din præstation bedre?
4 måder at teste ydeevne på. . .
Brent Ozar, SQL Server maven extraordinaire, fortæller dig, hvordan du kontrollerer ydeevnen på en ny SQL Server:
- den nemme måde, sammenligne før- og eftertider på en fuld backup og CHECKDB
- den nemme, men forkerte måde, med en syntetisk arbejdsbyrde og TPC-C i HammerDB
- den sværere måde, test af individuelle forespørgsler med sp_BlitzCache, hans plan-cache-analysescript
- den virkelig hårde måde, at køre de samme forespørgsler, som du udfører i produktionen
Men som Brent gør det klart, er det kun begyndelsen at overvåge din SQL-serverydelse og finde ud af, at den er faldet med X procent; du skal stadig finde ud af, hvor hittet kommer fra.
Det betyder, at man leder efter tendenser i præstationsdata over hele uger og måneder, ikke kun over de sidste par timer.
Jo flere datapunkter og historik du har, jo bedre billede kan du samle af, hvad der foregår inde i, under og omkring dit SQL Server-miljø.
Og jo mere beregning du kan kaste på alle disse data, jo hurtigere kan du analysere dem.
SQL Server-ydeevneovervågning:Lyder som et job for skyen
Jep. Det er et job for skyen, det eneste sted, du kan skalere langt nok ud til at indsamle og analysere alle de data for at få et bredt, dybt billede af, hvordan SQL Server bruger ressourcer. Og hvordan det har brugt disse ressourcer over tid. For eksempel:
- På bestemte tidspunkter af dagen eller måneden skal hyppigt kørte forespørgsler læse fra disken i stedet for fra buffercachen, som er kopien i hukommelsen af nyligt brugte databasesider. Har du brug for at allokere mere hukommelse til din buffercache? Kan du spare mere hukommelse til det?
- Samme for sidelevetid. Hvis den er lav, er det sandsynligvis fordi SQL Server fjerner sider fra buffercachen for ofte og skal køre opslag fra lageret i stedet for fra hukommelsen. Det hæmmer ydeevnen.
- Bliver den maksimale I/O-ventetid for høj? Hvordan er det trending? Det er et tip om, at I/O-enheden kan være mættet.
- Hvor lang er processorkøen nu? Hvor lang er den normalt? For mange tråde, der konstant venter, kan indikere overbelastning af processoren.
- Kører CPU'en imod de grænser, din server kan håndtere? Hvad hvis du ikke kan skalere serveren op længere? Hvis du er sikker på, at dine forespørgsler er veljusterede, og at dine andre systemressourcer er tilstrækkelige, skal du muligvis tilføje en socket til fysisk hardware eller vCPU'er til dine VM'er.
- Fragmenterede indekser er langsomme indekser, men du ved ikke, at de er synderen, før du tjekker fragmenteringsniveauer. At se virkningerne af omorganisering og genopbygning over tid kan hjælpe dig med at etablere en pålidelig indeksvedligeholdelsesproces.
At finde problemer som dem i alle dine lokale og cloud-databaser bliver nemmere og hurtigere, når du kan overvåge din SQL-serverydelse fra skyen. Det bedste af det hele er, at du kan overvåge fra et hvilket som helst sted i den kendte galakse, når al beregning, lagring og analyse er i skyen, og du kun er et par klik væk i enhver browser.
Begynd at teste din SQL Server-ydeevne i skyen
Hos Quest behøver ingen at fortælle os to gange, at vores kunder ønsker cloud-baserede værktøjer, hvad enten det er til cloud-migrering, præstationsovervågning eller Office 365. Vi gør flere af vores produkter tilgængelige som cloud-tilbud, fordi teknologier og markeder trækker dem derhen.
Så hvordan kører du ydelsestest på dine nye eller opgraderede SQL-servere?
- Jeg kører CHECKDB.
- Jeg kører HammerDB.
- Jeg kører Brent Ozars værktøjer.
- Jeg tester med produktionsbelastninger.
- Jeg kaster terningerne og venter, indtil brugerne klager.
- Jeg har folk, der gør det for mig.
- Jeg bruger Spotlight Cloud fra Quest. Det burde du også.