Hvorfor er justering af SQL-ydelse så vigtig for databasestyring?
For det kan spare dig store penge. Bær over med mig, og du vil se hvordan.
SQL-ydeevneindstilling og databasestyring — forbinder prikkerne
De fleste databaseprofessionelle bruger deres tid på at holde lyset tændt. De investerer det meste af deres indsats i at sikre oppetid ved at holde øje med ressourcer som hukommelse, lager og netværksgennemstrømning. Det er en stor del af databasestyring, men efterhånden som flere virksomheder flytter deres databaser til næsten grænseløse cloud-ressourcer som AWS og Azure, er andre aspekter blevet vigtigere.
SQL-ydelsesjustering er et af disse aspekter. Når først lysene er tændt, og du bevæger dig op i hierarkiet af behov i databasestyring, er den næste ting, du ønsker, bedre ydeevne, og det kræver justering.
Første spørgsmål at stille, når du justerer ydeevnen i SQL
Før eller siden står mange databaseprofessionelle foran en SQL Server, som de ikke har bygget. Der er ikke mange vejledninger til den situation. Tuning af SQL-ydelse er en øvelse i at grave i, finde ud af, hvad der er galt og derefter iterativt rette det.
I dine første rettelser berører du muligvis slet ikke SQL-sætninger. Nogle databaseprofessionelle starter på bruger/sessionsniveau. De går derhen, hvor brugerne er utilfredse, lytter til, hvordan deres klager lyder og stiller spørgsmål.
- Hvilke skærme eller sider tager for lang tid at gengive?
- Er applikationen langsommere, når de opretter en ny billet eller åbner en eksisterende?
- Tager det lang tid at gemme en post?
- Hvor længe er "lang tid?"
Når de har disse svar, går de og ser, hvad i databasen forårsager det.
Det er bedre end at sætte sig ned på dag ét og beslutte sig for at håndtere noget som fragmentering, som måske slet ikke påvirker brugerne. Pointen er at starte med, hvad brugerne interesserer sig for.
Tænk også på instans-/databaseniveauet. I Microsoft-verdenen er SQL Server Agent-job for eksempel et godt sted at starte. De er en række handlinger, der normalt definerer en administrativ opgave, du kan overvåge for succes eller fiasko. De er beregnet til at være praktiske, men ligesom mange ting inden for databasestyring har de en tendens til at akkumulere, når folk glemmer, hvordan de opstod, og hvad de gør.
Du kan finde flere job, der udfører det samme, som at køre forskellige versioner af et indeksscript eller, værre endnu, at arbejde mod hinanden. Undersøg de allerede konfigurerede job i lyset af to spørgsmål:"Hvad gør dette job?" og endnu vigtigere:"Hvis jeg stopper det job, sker der så noget dårligt?"
Hvilke faktorer skal du kigge efter?
Når du kommer til niveauet for præstationsindstilling af SQL, tager det sine spor for adfærd fra flere faktorer. Som beskrevet under vores Spørg eksperterne:Roundtable-webcast for databaseydelser, kan du bruge mindre tid på at tune selve SQL’en, hvis du finder og fortolker faktorer som disse korrekt:
- Blokering — Hvis serveren blokerer, er det som en tikkende bombe. Antag, at et script starter en transaktion og ikke lukker den; der kan føre til en logfil, der bare vokser og vokser, indtil pladsen løber tør. Blokering er dårlige nyheder for ydeevnen, så kig efter det med det samme.
- Agenter — I forhold til SQL Server Agent-job har administratorer været kendt for utilsigtet at indpakke præstationshæmmende opgaver i job. De kan udføre transaktioner eller genopbygge indekser i et job eller krympe databasen i en transaktion. I sådan et tilfælde kan du overveje at deaktivere agenten midlertidigt for at lukke alle tilknyttede jobs. Det er en aggressiv teknik, men hvis den forbedrer ydeevnen, ved du hvorfor.
- Ventestatistik — Spørg dig selv:"Hvad venter serveren på lige nu?" Målinger som sidelevetid og diskkølængde har nogle svar, men de giver kun en snæver visning. Ventestatistikker viser dig alt gennem linsen af ventetyper og ventekategorier, så du kan fokusere på de omkring fem ventebegivenheder, der bruger mest tid. Brent Ozars sp_BlitzFirst er en velbetroet lagret procedure til at opdage, hvad dine SQL Server-forespørgsler venter på lige nu. Når du derefter vil studere langsigtede mønstre i ventestatistikker for din server, skal du kigge på et værktøj til overvågning af ydeevne.
- Administratoraktivitet — Dette er også kendt som "pilotfejl", fordi nogle præstationsproblemer opstår ud af, hvad du selv laver. Antag, at du kører både SQL Server Activity Monitor og SQL Server Profiler på samme tid og prøver at lære Query Store. Du kan ikke overgå observatøreffekten. når du sporer alt sådan, beder du bare om, at databasen bliver langsommere.
- Indekser — For noget, der formodes at være gavnligt, kan indekser helt sikkert give dig ondt i nakken. Faktisk fortjener de mere end blot én kugle. Læs videre.
SQL-ydeevnejustering betyder, at man tager et grundigt kig på indekser
For en stor dels vedkommende koger SQL-ydeevnejustering ned til indeksjustering. Heldigvis, hvis du mestrer det til on-premises database management, kan dine færdigheder nemt overføres til database management i skyen.
Indeksjustering får stadig større betydning på grund af den udviklende række af indekser: klyngede, ikke-klyngede, unikke, filtrerede, columnstore, hash, hukommelsesoptimeret ikke-klyngede, XML, rumlig og fuldtekst, for at nævne nogle få. Men én ting, der aldrig har ændret sig, er den første kolonne i indekset, som driver de indeksbeslutninger, der træffes af databasemotoren.
Mange leverandører sælger og implementerer applikationer med masser af velmenende indekser, der ender med aldrig at blive brugt eller, værre endnu, faktisk hæmmer ydeevnen. Hvis du undersøger de ubrugte indeksscripts eller indeksforbrugsscripts i nogle softwareprodukter, vil du finde et væld af indekser på en fremmednøgle. Hvis produktet bruger f.eks. 20 fremmednøgler, kan leverandørerne sende så mange som 20 indekser plus ti enkeltkolonneindekser plus yderligere ti indekser på et unikt klynget indeks og så videre.
Når du har muligheden, er den bedre måde at nærme sig databasearkitektur på at starte med et klynget indeks, som du mener bedst repræsenterer tabellen. Lad derefter systemet køre sig selv i et stykke tid. Hvis og efterhånden som du har brug for flere indekser, skal du oprette dem. Tilføjelse af indekser er en øvelse i at udligne bedre ydeevne her med problemer som at fylde diskplads op og låse derovre. Det bliver svært at se, hvordan hvert ekstra indeks påvirker systemet generelt.
Overvej for den sags skyld at eliminere indekser - sådan som en person med allergi ville eliminere fødevaregrupper - for at se, hvordan ydeevnen ændrer sig. Prøv at droppe hvert indeks på din dev-instans og se, hvilke der påvirker dine top fem forespørgsler.
Ydeevnejustering i SQL Server – værktøjer, der følger med
Bemærk, at du ikke er alene i denne bestræbelse. SQL Server indeholder funktioner designet til at forbedre ydeevnen.
Planvejledninger lader dig ændre, hvordan SQL Server kører en given forespørgsel, og selvom det ikke er ren SQL-ydeevnejustering, påvirker det ydeevnen. Mange applikationer indeholder SQL-forespørgsler skrevet af en ekstern leverandør, og selvom disse forespørgsler forårsager dårlig ydeevne, er nogle databaseprofessionelle forståeligt nok tilbageholdende med at ændre dem. Med planvejledninger kan du vedhæfte et forespørgselstip eller en fast plan til forespørgslen og påvirke, hvordan den kører.
Men ulempen ved planvejledninger er, at selvom de ikke ændrer sig over tid, gør miljøet omkring dem det. Som en trykt køreplan kan de fungere godt på kort sigt og blive forældede inden længe, så hvis du vil stole på dem, må du hellere besøge dem en gang imellem.
Relateret til planvejledninger er Query Store, en funktion i SQL Server, der hjælper dig med at identificere og justere de forespørgsler, der bruger flest ressourcer i dit system. Query Store er ikke aktiveret som standard for nye SQL Server- og Azure Synapse Analytics-databaser (SQL DW). Men det er aktiveret som standard i nye Azure SQL-databaser.
Generelt er det ikke svært at aktivere Query Store, men ikke alle SQL-servere har brug for det fra starten. Nogle administratorer kender ikke til Query Store, og nogle kender til det, men har endnu ikke taget sig tid til at udforske det tilstrækkeligt; det er bedre at lade det være deaktiveret. Senere, når de forstår, hvordan Query Store fungerer, kan de bruge det til at finde ydeevneforskelle forårsaget af ændringer i forespørgselsplanen.
Endelig analyserer Database Engine Tuning Advisor arbejdsbelastninger og anbefaler indekser eller partitioneringsstrategier for at forbedre forespørgselsydeevnen. Det er en god idé at køre Tuning Advisor på din database; bare ikke køre det for tidligt. Sørg for, at din database indeholder nok data, så indeksanbefalinger er gyldige. Når du først bygger din applikation, har du muligvis kun tusind rækker i hver tabel. Tuning Advisors anbefalinger er mere nyttige, når databasen er vokset.
Vis mig pengene
Som jeg nævnte i starten, er justering af SQL-ydelse vigtig for databasestyring, fordi det kan spare dig penge. Hvordan?
Især i skyen, hvor skalering med kreditkort er populært, er it-teams ved at finde ud af, hvor dyrt månedlig lagerplads i virkeligheden kan være. Hvad mere er, er de begyndt at forstå, at det at køre dårligt skrevne forespørgsler og lade AWS og Azure administrere deres indekser øger deres cloud computing-omkostninger. Langsomme forespørgsler og dårlige indekser koster dig penge.
SQL-ydelsesjustering handler om at få alle disse ting rigtigt. På den måde bevarer du kontrollen over dit forbrug, uanset om du bliver i OpEx-verdenen på stedet eller migrerer til skyens CapEx-verden.