sql >> Database teknologi >  >> RDS >> Sqlserver

Forbedre justering af SQL Server-ydeevne med disse 3 tips

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.


  1. Integrering af ServiceNow med Oracle Identity Cloud Service (IDCS)

  2. Sådan finder du ASCII-koden for en given karakter i MySQL

  3. Hvordan laver man en case-sensitiv søgning i WHERE-klausulen (jeg bruger SQL Server)?

  4. Oracle SQL - max() med NULL-værdier