Vedligeholdelse af højtydende SQL Server-instanser er en stor del af en DBAs jobansvar. Manglende opdagelse og korrektion af usædvanlig aktivitet kan påvirke den interne drift samt skade virksomhedens bundlinje.
Hvis du bemærker spidsbelastningsændringer eller uregelmæssigheder i en SQL Server-instans, er her tre steder at starte din søgning efter svar.
Forventet sidelevetid
En forekomsts forventede sidelevetid (PLE) bør opretholde et ret konsistent værdiinterval. Hvis denne værdi falder og forbliver lav, er det et tegn på, at bufferpuljen oplever øget efterspørgsel.
Før du løber tør og op i hukommelsen, skal du tage et kig på arbejdsbelastningsaktiviteten. Hvis arbejdsbyrden er steget, vil det forklare det ekstra pres på bufferpuljen. Men hvis arbejdsbyrden ikke har ændret sig, bliver du nødt til at se nærmere for at identificere, hvad der bruger den ekstra hukommelse.
Mulige årsager til et fald i PLE omfatter aktivt kørende vedligeholdelsesjob, indeksgenopbygninger eller statistiske opdateringer, DBCC-operationer og ændringer af forespørgselsplanen.
Hvis du bemærker et fald i PLE, der ikke er forbundet med en stigning i arbejdsbyrden, er der et par ting, du kan prøve for at forbedre en instans's PLE:
- Slet ubrugte indekser
- Flet dublerede indekser
- Hold øje med store forespørgsler
- Defrag
- Slet data
WRITELOG Ventetid
Når WRITELOG ventetiden er for stor en andel af den samlede ventetid, har du sandsynligvis en flaskehals på din SQL Server-instans. Flaskehalsen skyldes sandsynligvis enten et problem på disken, hvor transaktionsloggen er gemt, eller af data, der er ineffektivt.
For at bestemme, hvilken slags flaskehals du har at gøre med, start med at analysere antallet af SQL-sætninger, der venter på WRITELOG-begivenheden. Hvis der er mange udsagn, der venter, har du en diskflaskehals. Hvis der kun er nogle få udsagn, der venter, bliver data sandsynligvis begået for ofte.
Der er flere måder at løse høj WRITELOG ventetid på, når du har fundet ud af, om din flaskehals er diskrelateret eller commit-relateret:
- Tilføj I/O-båndbredde til den disk, hvor transaktionsloggen er gemt
- Flyt ikke-transaktionslog I/O fra disken
- Flyt transaktionsloggen til en mindre optaget disk
- Reducer størrelsen af transaktionsloggen
- Sørg for, at COMMIT-sætningen er placeret i koden, så dataene ikke begås for ofte
TempDB
TempDB er et midlertidigt arbejdsområde i SQL Server, der rummer midlertidige objekter. Fordi objekterne i TempDB er forbigående, genskaber en SQL Server-instans TempDB, hver gang den genstarter. Dette gør optimering af TempDB afgørende for at opretholde ydeevnen og undgå operationelle flaskehalse.
TempDB-påstanden er en af hovedskyldige i ydeevneforringelse. Strid opstår, når flere ressourcer har brug for adgang til TempDB, men der er kun én TempDB-datafil. Dette forårsager en flaskehals, fordi processer ikke kan få adgang til TempDB hurtigt nok, hvilket fører til, at forbindelser udløber, og processerne bliver deallokeret.
Heldigvis kan TempDB-flaskehalse løses ret nemt ved at justere antallet og størrelsen af TempDB-filer. Efter installationen er SQL Server-standarden én TempDB-datafil. Hvis du bemærker, at der opstår uenighed, anbefales det, at du tilføjer otte nye datafiler og afgør, om det løser problemet. Hvis problemet ikke er løst, kan du prøve at tilføje yderligere datafiler i multipla af fire, indtil ydeevnen er gendannet.
Selvom det er fantastisk at vide, hvor du skal begynde at lede, når du oplever problemer med ydeevnen, kan hvert af ovenstående problemer og de resulterende flaskehalse afbødes eller helt undgås ved at implementere en hård og hurtig regel:Overvågning af ydeevnemålinger er ikke valgfri. Her er nogle eksempler på vigtige metrics at spore:
Sidelevetid:Spor PLE med kontinuerlig overvågning og vær proaktiv, når den falder og forbliver under den typiske værdi for en bestemt SQL Server-instans.
WRITELOG ventetider:Overvåg metrics såsom logvækst, log krympning, procent log brugt og log flush waits/sek.
TempDB-ineffektivitet:Overvåg, hvad der allokeres til brugerobjekter, versionslager eller interne objekter. Spor, hvordan de udvikler sig over tid, og afgør derefter, hvilke sessioner der bruger TempDB og hvor meget.
Der er nogle fremragende funktionsrige, overkommelige SQL Server-ydelsesovervågningsværktøjer på markedet, som kan hjælpe dig med at holde dig foran præstationsnedsættende problemer. Gør dig selv til virksomhedens DBA MVP ved proaktivt at undersøge løsninger, der holder både indadvendte operationer og udadvendte forretningstjenester kørende med toppræstationer.