Som alle, der administrerer databaser, ved alt for godt, er SQL Server-ydeevnejustering en afgørende funktion for at sikre optimal ydeevne. Da ydeevnen afhænger af forskellige faktorer såsom hukommelse, konfiguration, forespørgselsdesign og ressourceforbrug, er det ikke en lille opgave at isolere den grundlæggende årsag til ydeevneforringelse.
I stedet for at vente på, at ydeevneproblemer opstår, vil proaktiv tuning af SQL Server sikre, at dine SQL-sætninger kører så effektivt som muligt ved at hjælpe SQL med at finde den hurtigste rute ind og ud for at levere dine forespørgselsresultater.
Hvis du kæmper med træg ydeevne - eller du ikke bare venter på, at der opstår problemer - er her tre nøgleområder, hvor du kan fokusere din SQL Server-ydeindstilling for at opnå optimal ydeevne og sundere systemer.
Tip #1:Optimer din TempDB
Forkert konfigureret TempDB er en almindelig synder, når man ser på ydeevneforringelse. Hvis du ofte fylder din TempDB op, er det tid til at tage et kig på, hvad der skal ændres.
Tjek først TempDB-størrelsen. Der er ingen fast og hurtig regel om, hvor stor den skal være, men en god tommelfingerregel er at holde TempDB på 25 procent af din største database eller samme størrelse som dit største indeks. Dette forhindrer at skulle øge TempDB under genopbygninger.
Med TempDB, jo hurtigere drevet jo bedre. Når TempDB placeres på et langsomt drev eller det samme drev som operativsystemet, er du sikker på at se databaseydeevneproblemer. Hvis det er muligt, behold TempDB på en dedikeret lokal SSD. Hvis det ikke er muligt, er din næstbedste mulighed at beholde den på sin egen dedikerede diskenhed med tilstrækkelig forudtildelt diskplads.
Det er også vigtigt at holde data og logfiler adskilt og at indstille en stor fast værdi for TempDB autogrowth. Ellers vil du blive ramt af unødvendig overhead, hver gang TempDB fyldes op.
Styring af antallet af TempDB-datafiler bidrager til TempDB-optimering. Men det store spørgsmål er, hvor mange TempDB-datafiler har du brug for? Ideelt set vil du have én TempDB-datafil for hver logisk CPU, men ikke mere end otte i alt (med nogle undtagelser). For eksempel, hvis du har fire logiske CPU'er, har du brug for fire TempDB-datafiler. Hvis du har 12 logiske CPU'er, kan du have otte TempDB-datafiler.
Tip 2:Undgå flaskehalse i ydeevnen
Der er tre hovedtyper af flaskehalse i SQL-serverens ydeevne, der bidrager til dårlig ydeevne:CPU, hukommelse og I/O. Årsagerne, symptomerne og diagnostikken varierer efter typen af flaskehals, så her er en hurtig guide til, hvad du skal være opmærksom på:
CPU-flaskehalse
Årsag: Utilstrækkelige hardwareressourcer
Symptomer: Konstant højt processorforbrug
Metrics at overvåge: % Processortid, batchanmodninger/sek., SQL-kompileringer/sek. og SQL-genkompileringer/sek.
Hukommelsesflaskehalse
Årsag: Begrænsninger i tilgængelig hukommelse og hukommelsestryk forårsaget af SQL Server, system eller anden applikationsaktivitet
Symptomer: Langsom applikationsrespons, generel systemnedgang og applikationsnedbrud
Metrics at overvåge: Tilgængelig hukommelse (KB), Total Server Memory (KB), Target Server Memory (KB), Pages/Sec, Checkpoint Pages/Sec, Lazy Writes/Sec og Buffer Cache Hit Ratio
I/O-flaskehalse
Årsag: Overdreven læsning og skrivning af databasesider fra og til disk
Symptomer: Lange svartider, langsommere programmer og timeouts for opgaver
Metrics at overvåge: Gennemsnitlig diskkølængde, gennemsnitlig disksek./læs, gennemsnitlig disksek./skrivning, %disktid, gennemsnitlig disklæsning/sek. og gennemsnitlig diskskrivning/sek.
Tip #3:Sørg for, at indekser er korrekt designet
Indekser er en fantastisk måde at fremskynde visse SQL Server-operationer på, men kun hvis de er godt designet. Dårligt designede indekser har den modsatte effekt og er en sikker måde at dræbe din SQL Server-ydeevne på.
Korrekt opsætning af disse fire områder kan hjælpe med at sikre indekser er korrekt designet og hjælpe i stedet for at skade SQL Server-ydeevne.
Tabelstørrelse
Ikke alle tabeller er en god kandidat til indeksering. Faktisk, hvis en tabel er for lille, er det langt mere effektivt for SQL Server at søge i hele tabellen i stedet for at skulle søge gennem indekser. Selvfølgelig er det modsatte tilfældet for store borde, så du skal afveje potentielle overhead, når du beslutter, hvilke tabeller der ville have gavn af indekser.
Indekstyper
Teknisk set kan hver databasetabel have ét klynget indeks og et uendeligt antal ikke-klyngede indekser, men du ved, hvad de siger om "Bare fordi du kan gøre noget"...
For mange ikke-klyngede indekser kan sænke indsætnings- og opdateringsoperationer betydeligt, så det er et langt bedre designvalg at holde sig til ét klynget indeks og det mindste antal absolut essentielle ikke-klyngede indekser.
Indekslagring
Under designfasen er det afgørende for I/O-ydeevnen at vælge de rigtige lagringskriterier for indekser. Partitionerede klyngede indekser og ikke-klyngede indekser kan gemmes i den samme filgruppe som hovedtabellen, eller de kan gemmes i en anden filgruppe. Lagring af et ikke-klynget indeks i en filgruppe placeret på et andet diskdrev kan forbedre ydeevnen af forespørgsler, der bruger det, fordi det ikke påvirkes af den samtidige læsning af data og SQL-indekssider på forskellige diskdrev.
FYLDNINGSFAKTOR
FILLFACTOR angiver den procentdel af plads, der vil blive fyldt på hver dataside, når der oprettes et indeks. FILLFACTOR-værdier kan variere fra 0 procent (ingen af datasiden er udfyldt) til 100 procent (datasiden er fuldstændig udfyldt). Når du designer dit indeks, skal du vælge en FILLFACTOR-værdi, der optimerer sidebrug og samtidig minimerer risikoen for overdreven indeksfragmentering.
At gøre SQL Server-ydeevnejustering til en del af din standardrutine er en glimrende måde at sikre, at dine databaser kører med maksimal ydeevne. At inkorporere disse tre enkle trin i dine almindelige SQL Server-vedligeholdelsesplaner vil mærkbart forbedre hastigheden og ydeevnen for dine brugere.