Som alla som hanterar databaser vet alltför väl är SQL Server-prestandajustering en avgörande funktion för att säkerställa optimal prestanda. Med prestanda beroende av olika faktorer som minne, konfiguration, frågedesign och resursanvändning, är det ingen liten bedrift att isolera grundorsaken till prestandaförsämring.
Istället för att vänta på att prestandaproblem ska uppstå kommer en proaktiv justering av SQL Server att säkerställa att dina SQL-satser körs så effektivt som möjligt genom att hjälpa SQL att hitta den snabbaste vägen in och ut för att leverera dina frågeresultat.
Om du kämpar med trög prestanda – eller om du inte bara väntar på att problem uppstår – här är tre nyckelområden för att fokusera din SQL Server-prestandajustering för att uppnå optimal prestanda och hälsosammare system.
Tips #1:Optimera din TempDB
Felaktigt konfigurerad TempDB är en vanlig boven när man tittar på prestandaförsämring. Om du ofta fyller på din TempDB är det dags att ta en titt på vad som behöver ändras.
Kolla först in TempDB-storlek. Det finns ingen hård och snabb regel om hur stor den ska vara, men en bra tumregel är att hålla TempDB på 25 procent av din största databas eller samma storlek som ditt största index. Detta förhindrar att du behöver öka TempDB under ombyggnader.
Med TempDB, ju snabbare enheten är desto bättre. När TempDB placeras på en långsam enhet eller samma enhet som operativsystemet kommer du säkert att se databasprestandaproblem. Om möjligt, håll TempDB på en dedikerad lokal SSD. Om det inte är möjligt är ditt näst bästa alternativ att behålla den på sin egen dedikerade volym med tillräckligt förtilldelat diskutrymme.
Det är också viktigt att hålla data och loggfiler åtskilda och att ställa in ett stort fast värde för TempDB autogrowth. Annars kommer du att drabbas av onödiga omkostnader varje gång TempDB fylls.
Att kontrollera antalet TempDB-datafiler bidrar till TempDB-optimering. Men den stora frågan är, hur många TempDB-datafiler behöver du? Helst kommer du att ha en TempDB-datafil för varje logisk CPU, men inte mer än åtta totalt (med vissa undantag). Till exempel, om du har fyra logiska processorer behöver du fyra TempDB-datafiler. Om du har 12 logiska processorer kan du ha åtta TempDB-datafiler.
Tips #2:Förhindra prestandaflaskhalsar
Det finns tre huvudtyper av flaskhalsar i SQL Server-prestanda som bidrar till dålig prestanda:CPU, minne och I/O. Orsakerna, symtomen och diagnostiken varierar beroende på typen av flaskhals, så här är en snabbguide för vad du ska se upp med:
CPU-flaskhalsar
Orsak: Otillräckliga hårdvaruresurser
Symtom: Ständigt hög processoranvändning
Mätvärden att övervaka: % Processortid, batchförfrågningar/sekund, SQL-kompilationer/sekund och SQL-omkompilering/sekund
Minnesflaskhalsar
Orsak: Begränsningar i tillgängligt minne och minnestryck orsakade av SQL Server, system eller annan applikationsaktivitet
Symtom: Långsam applikationslyhördhet, övergripande systemnedgång och applikationskrascher
Mätvärden att övervaka: Tillgängligt minne (KB), Totalt Serverminne (KB), Målserverminne (KB), Pages/Sec, Checkpoint Pages/Sec, Lazy Writes/Sec och Buffer Cache Hit Ratio
I/O-flaskhalsar
Orsak: Överdriven läsning och skrivning av databassidor från och till disk
Symtom: Långa svarstider, långsamma applikationer och timeouts för uppgifter
Mätvärden att övervaka: Genomsnittlig diskkölängd, genomsnittlig disksek./läs, genomsnittlig disksek./skriv, % disktid, genomsnittlig diskläsning/sekund och genomsnittlig diskskrivning/sek.
Tips #3:Se till att index är korrekt utformade
Index är ett utmärkt sätt att påskynda vissa SQL Server-operationer, men bara om de är väl utformade. Dåligt utformade index har motsatt effekt och är ett säkert sätt att döda din SQL Server-prestanda.
Att korrekt ställa in dessa fyra områden kan hjälpa till att säkerställa index är korrekt utformade och hjälpa snarare än att skada SQL Server-prestanda.
Bordstorlek
Inte alla tabeller är en bra kandidat för indexering. Faktum är att om en tabell är för liten är det mycket mer effektivt för SQL Server att söka i hela tabellen jämfört med att behöva söka igenom index. Naturligtvis är det motsatta för stora tabeller, så du måste väga potentiella omkostnader när du bestämmer vilka tabeller som skulle dra nytta av index.
Indextyper
Tekniskt sett kan varje databastabell ha ett klustrade index och ett oändligt antal icke-klustrade index, men du vet vad de säger om "Bara för att du kan göra något"...
För många icke-klustrade index kan avsevärt bromsa Insert and Update-operationer, så att hålla sig till ett klustrat index och det minsta antalet absolut nödvändiga icke-klustrade index är ett mycket bättre designval.
Indexlagring
Under designfasen är valet av rätt lagringskriterier för index avgörande för I/O-prestanda. Partitionerade klustrade index och icke-klustrade index kan lagras i samma filgrupp som huvudtabellen, eller så kan de lagras i en annan filgrupp. Att lagra ett icke-klustrat index i en filgrupp på en annan diskenhet kan förbättra prestandan för frågor som använder det, eftersom det inte påverkas av den samtidiga läsningen av data och SQL-indexsidor som sker på olika diskenheter.
FYLLFAKTOR
FILLFACTOR anger procentandelen utrymme som kommer att fyllas på varje datasida när ett index skapas. FILLFACTOR-värden kan variera från 0 procent (ingen av datasidan är ifylld) till 100 procent (datasidan är helt ifylld). När du utformar ditt index, välj ett FILLFACTOR-värde som optimerar sidanvändningen och samtidigt minimerar risken för överdriven indexfragmentering.
Att göra inställning av SQL Server-prestanda till en del av din standardrutin är ett utmärkt sätt att säkerställa att dina databaser körs på topp. Att införliva dessa tre enkla steg i dina vanliga SQL Server-underhållsplaner kommer märkbart att förbättra hastigheten och prestanda för dina användare.