"Doc, jeg er bekymret for min SQL Server-ydelse."
Det var ikke den slags, man hører fra de fleste patienter. Men så, som betalt professionel, er jeg blevet trænet til at håndtere det hele - selv de svære tider med at være databaseadministrator.
"Virkelig? Lad os undersøge det, skal vi?”
"Selvfølgelig, Doc. Jeg mener, nogle gange føles det så overvældende. Jeg troede, at alt bare ville løse sig af sig selv, når jeg først havde forpligtet mig til det. Men før jeg vidste af det, begyndte jeg at have problemer med ydeevnen i SQL Server 2012, derefter 2014, derefter 2017. Jeg vil ikke engang tænke på SQL Server 2019."
"Jeg ser. Nå, et godt forhold til SQL Server sker ikke kun af sig selv. Du skal arbejde på det. Fortæl mig, har du arbejdet på dine SQL Server-ydelsesjusteringsteknikker?”
"Øh, nej, Doc. Jeg kender ikke rigtig nogen af de teknikker.”
"Bare rolig. Vi kan arbejde på dem. Din SQL Server føler sig sandsynligvis forsømt. Du skal holde øje med det for at sikre, at du er på forkant med spillet. Det kræver SQL Server-overvågning.”
"Overvågning? Hvordan gør du det?”
“Du skal vise SQL Server, at du holder af. Du skal være opmærksom på visse målinger. Det kan vi også arbejde på.”
"OK, Doc. Hvad end du siger. Jeg er villig til at prøve hvad som helst på dette tidspunkt. Tingene kunne ikke blive meget værre, end de er nu.”
"Godt så. Lad os begynde."
SQL Server-ydeevnemålinger — Masser af bevægelige dele
Patienten havde ret:Overvågning af din SQL Server-ydelse kan føles overvældende. Du kan ikke stoppe med at være opmærksom på det, når det først er oppe at køre. Du skal blive ved med at vise det, at du holder af.
SQL Server har masser af bevægelige dele, der konstant genererer metrikker. Det kan være meget arbejde for en DBA at vide, hvilke man skal se og så rent faktisk tage sig tid til at overvåge dem.
Så jeg gennemgik nogle af hovedområderne for SQL Server-ydeevnemålinger med patienten.
Indekser
Et af de første steder at se, når du har problemer med ydeevnen med SQL Server, er indekserne. Dine data vokser altid, så dine indekser vokser også altid. Men de er underlagt betingelser som fragmentering og sideopdelinger, der kan bremse svaret på forespørgsler.
Hvad sker der i en database dag ud og dag ind? Brugere opretter, redigerer og sletter poster. Indeksene holder trit med, hvor alle dele af posterne er, men over tid hæmmer indeksfragmentering ydeevnen.
Så er der indeksfyldningsfaktor, en parameter du kan konfigurere i SQL Server for at kontrollere antallet af sideopdelinger og øge forespørgselseffektiviteten. Men balancen mellem flere og færre sideopdelinger påvirker ydeevnen på andre måder.
Se metrics i fyldfaktor , I/O og fragmentering er en god måde at holde fingrene på pulsen for SQL Server-indekssundhed.
Buffercache
Lad os gøre dette enkelt:Disk, langsom; buffer cache, hurtig. Buffercachen er en kopi i hukommelsen af nyligt brugte databasesider. Hvis SQL Server ikke finder det, den leder efter der, skal den gå til disk for det, hvilket sænker ydeevnen.
SQL Server giver dig mulighed for at angive mængden af systemhukommelse, der skal allokeres til buffercachen, men du afvejer hukommelse tilbage til andre opgaver. Dit mål er at allokere så meget som muligt uden at hæmme SQL Server-ydelsen på andre områder.
Også vigtig er sidelevetiden, hvor lang tid en side med information fra databasen tilbringer i bufferen uden at blive tilgået igen. SQL Server fjerner løbende sider fra buffercachen for at give plads til nyere brugte. Men jo færre nyttige sider den finder der, jo mere skal den læse fra disken, hvilket forsinker ydeevnen.
Metrics som sidelevetid og forholdet mellem vellykkede hits i buffercachen hjælpe dig med at træffe beslutninger om at fjerne sider sjældnere eller øge størrelsen af cachen.
T-SQL
SQL Server bruger et forespørgselssprog kaldet T-SQL. I stedet for at køre SQL-sætninger ad hoc, forsøger SQL Server at forbedre ydeevnen ved at samle dem, kompilere dem som en eksekveringsplan og cache dem. Det forsøger også at minimere hyppigheden af kompilering og genbrug af eksekveringsplaner så ofte som muligt. Hvis den ikke kan genbruge eksekveringsplanen - for eksempel fordi databasen har ændret sig for meget - så vil den genkompilere planen. Det er bedst at holde antallet af SQL-sætnings-genkompileringer så lavt som muligt, fordi processen kan forbruge store mængder CPU og forringe ydeevnen.
Behovet for at kompilere og genkompilere er en funktion af god kodningspraksis, som at bruge lagrede procedurer og parametrisering af forespørgsler. DBA'er, der overvåger metrics som frekvensen af SQL-kompilationer og SQL-genkompilationer kan ændre SQL Server-forespørgselstip for at forbedre ydeevnen.
Låser, venter og blokerede processer
Det er frustrerende at opdage, at en anden ændrer noget på samme tid, som du er. Så databaser låser automatisk ting som rækker og tabeller for at holde flere kokke ude af køkkenet. Afvejningen for den beskyttelse er selvfølgelig, at alle andre brugere skal vente, indtil ressourcen er låst op. Og det er svært at sikre sig, at låsning kun finder sted på det niveau, det skal.
Med målinger, der viser, hvor ofte og hvor bredt låse påvirker andre operationer, kan DBA'er bestemme behovet for flere fysiske systemressourcer til at behandle transaktioner hurtigere. Det kan også være, at SQL Server låser på et unødvendigt lavt niveau. Hyppigheden af lås venter og mere generelt antallet af blokerede processer kan hjælpe med at lokalisere flaskehalse.
Eliminér flaskehalse med justering af SQL-ydelse
"Goh, Doc, du har ret med hensyn til alle de bevægelige dele. Nu kan jeg se, hvordan jeg ikke bare kan installere SQL Server, indstille den og glemme den. Jeg har brug for at nære forholdet. Men det hele føles stadig overvældende. Hvordan skal jeg nogensinde holde så mange forskellige ting ved lige og være på forkant med spillet?”
"Det er den bedste del. Der er værktøjer, der kan hjælpe med din SQL Server-ydelse. Du behøver ikke gå alene.”
"Puha! Det er betryggende. Det vidste jeg ikke om."
"Det er rigtigt. Værktøjerne overvåger din SQL-serverydelse og rapporterer alle disse målinger, så du kan anvende dine tuning-teknikker og eliminere flaskehalse."
"Virkelig?"
"Jo da. Og vi kan arbejde på dem rigtigt - åh, vi har ikke tid til denne uge. Aftal venligst en aftale med min receptionist, så henter vi i næste uge.”
"Dreng, de fire timer gik hurtigt, Doc! Tiden flyver sikkert, når du træner ydeevneproblemer omkring fragmentering, ressourceforbrug og buffercache-hitforhold , gør det ikke?”
"Ja, og jeg er sikker på, at når du kommunikerer åbent om disse problemer med din SQL Server, vil alle dine ydeevneproblemer være historie."
Opmuntret af vores session gik patienten. Næste gang arbejder vi på at overvåge flaskehalse i SQL Server-ydelse. Jeg vil blogge om det, så hold øje.
I mellemtiden, tro mig. Jeg er en betalt professionel, og jeg opfordrer dig til at prøve disse ting i dit eget forhold til din database. Få din SQL Server til at føle sig ønsket. Vær opmærksom på dens præstationsmålinger.
Det er aldrig for sent at prøve.