Varför är SQL-prestandajustering så viktig för databashantering?
För det kan spara dig pengar big time. Håll ut med mig så får du se hur.
SQL-prestandajustering och databashantering — kopplar ihop punkterna
De flesta databasproffs ägnar sin tid åt att hålla lamporna tända. De investerar det mesta av sin ansträngning för att säkerställa drifttid genom att hålla ett öga på resurser som minne, lagring och nätverksgenomströmning. Det är en stor del av databashantering, men i takt med att fler företag flyttar sina databaser till nästan gränslösa molnresurser som AWS och Azure, har andra aspekter blivit viktigare.
SQL-prestandajustering är en av dessa aspekter. När lamporna väl är tända och du flyttar uppåt i behovshierarkin inom databashantering, är nästa sak du vill ha bättre prestanda, och det kräver justering.
Första frågorna att ställa vid prestandajustering i SQL
Förr eller senare befinner sig många databasproffs framför en SQL Server som de inte byggde. Det finns inte många guider för den situationen. SQL-prestandajustering är en övning i att gräva i, ta reda på vad som är fel och sedan iterativt åtgärda det.
I dina första korrigeringar kanske du inte ens rör SQL-satser alls. Vissa databasproffs börjar på användar-/sessionsnivå. De går dit användarna är missnöjda, lyssnar på hur deras klagomål låter och ställer frågor.
- Vilka skärmar eller sidor tar för lång tid att rendera?
- Är programmet långsammare när de skapar en ny biljett eller öppnar en befintlig?
- Tar det lång tid att spara en post?
- Hur länge är "en lång tid?"
När de har de svaren går de och ser vad i databasen som orsakar det.
Det är bättre än att sitta ner på dag ett och bestämma sig för att ta itu med något som fragmentering, som kanske inte påverkar användarna alls. Poängen är att börja med vad användarna bryr sig om.
Tänk också på instans-/databasnivån. I Microsoft-världen, till exempel, är SQL Server Agent-jobb ett bra ställe att börja. De är en serie åtgärder som vanligtvis definierar en administrativ uppgift som du kan övervaka för framgång eller misslyckande. De är tänkta att vara bekväma, men som många andra saker inom databashantering, tenderar de att ackumuleras när människor glömmer hur de uppstod och vad de gör.
Du kan hitta flera jobb som gör samma sak, som att köra olika versioner av ett indexskript eller, ännu värre, att arbeta mot varandra. Undersök de redan konfigurerade jobben i ljuset av två frågor:"Vad gör det här jobbet?" och, ännu viktigare, "Om jag slutar med det jobbet, kommer något dåligt att hända?"
Vilka faktorer ska du titta efter?
När du väl kommer till nivån för prestandajustering av SQL, tar den sina ledtrådar för beteende från flera faktorer. Som beskrivits under vår Ask the Experts:Database Performance Roundtable webcast kan du lägga mindre tid på att justera själva SQL om du hittar och korrekt tolkar faktorer som dessa:
- Blockering — Om servern blockerar är det som en tickande bomb. Anta att ett skript startar en transaktion och inte stänger den; som kan leda till en loggfil som bara växer och växer tills utrymmet tar slut. Blockering är dåliga nyheter för prestanda, så leta efter det direkt.
- Agenter — Apropos SQL Server Agent-jobb har administratörer varit kända för att oavsiktligt slå in prestationsförsämrande uppgifter i jobb. De kan utföra transaktioner eller bygga om index i ett jobb, eller krympa databasen i en transaktion. I ett sådant fall, överväg att inaktivera agenten tillfälligt för att stänga av alla associerade jobb. Det är en aggressiv teknik, men om den förbättrar prestandan vet du varför.
- Väntestatistik — Fråga dig själv, "Vad väntar servern på just nu?" Mätvärden som förväntad sidlivslängd och diskkölängd har några svar, men de erbjuder bara en snäv vy. Väntestatistik visar dig allt genom linsen av väntetyper och väntekategorier, så att du kan fokusera på de fem eller så väntande händelserna som tar mest tid. Brent Ozars sp_BlitzFirst är en välbetrodd lagrad procedur för att upptäcka vad dina SQL Server-frågor väntar på just nu. När du sedan vill studera långsiktiga mönster i väntanstatistik för din server, titta på ett prestationsövervakningsverktyg.
- Administratörsaktivitet — Detta är också känt som "pilotfel", eftersom vissa prestationsproblem uppstår på grund av vad du själv gör. Anta att du kör både SQL Server Activity Monitor och SQL Server Profiler på samma gång och försöker lära sig Query Store. Du kan inte köra ifrån observatörseffekten. när du spårar allt sånt ber du bara om att databasen ska sakta ner.
- Index — För något som är tänkt att vara fördelaktigt kan index säkert ge dig ont i nacken. Faktum är att de förtjänar mer än bara en kula. Läs vidare.
Inställning av SQL-prestanda innebär att man tittar noga på index
Till stor del kokar justering av SQL-prestanda ner till indexjustering. Lyckligtvis, om du behärskar det för lokal databashantering, kan dina kunskaper enkelt överföras till databashantering i molnet.
Indexjustering blir allt viktigare på grund av det växande utbudet av index: klustrade, icke-klustrade, unika, filtrerade, columnstore, hash, minnesoptimerade icke-klustrade, XML, rumslig och fulltext, för att nämna några. Men en sak som aldrig har förändrats är den första kolumnen i indexet, som driver de indexbeslut som tas av databasmotorn.
Många leverantörer säljer och distribuerar applikationer med massor av välmenande index som till slut aldrig kommer att användas eller, ännu värre, faktiskt hämmar prestandan. Om du undersöker de oanvända indexskripten eller indexförbrukningsskripten i vissa mjukvaruprodukter, kommer du att hitta ett överflöd av index på en främmande nyckel. Om produkten använder t.ex. 20 främmande nycklar kan leverantörerna skicka så många som 20 index, plus tio enkolumnsindex, plus ytterligare tio index på ett unikt klustrat index, och så vidare.
Närhelst du har möjlighet är det bättre sättet att närma dig databasarkitektur att börja med ett klustrat index som du tror bäst representerar tabellen. Låt sedan systemet köra sig själv ett tag. Om och när du behöver fler index, skapa dem. Att lägga till index är en övning för att byta ut bättre prestanda här med problem som att fylla upp diskutrymme och låsa där borta. Det blir svårt att se hur varje ytterligare index påverkar systemet överlag.
För den delen, överväg att eliminera index - så som en person med allergier skulle eliminera livsmedelsgrupper - för att se hur prestandan förändras. Försök att släppa varje index på din dev-instans och se vilka som påverkar dina fem vanligaste frågor.
Prestandanställning i SQL Server – verktyg som medföljer
Observera att du inte är ensam i denna strävan. SQL Server innehåller funktioner som är utformade för att förbättra prestanda.
Planguider låter dig ändra hur SQL Server kör en viss fråga, och även om det inte är ren SQL-prestandajustering påverkar det prestanda. Många applikationer innehåller SQL-frågor skrivna av en extern leverantör, och även om dessa frågor orsakar dålig prestanda är vissa databasproffs förståeligt nog ovilliga att ändra dem. Med planguider kan du bifoga en frågetips eller en fast plan till frågan och påverka hur den körs.
Men nackdelen med planguider är att även om de inte förändras över tiden, gör miljön runt dem det. Som en tryckt färdplan kan de fungera bra på kort sikt och bli föråldrade inom kort, så om du ska förlita dig på dem är det bättre att du besöker dem igen då och då.
Relaterat till planguider är Query Store, en funktion i SQL Server som hjälper dig att identifiera och ställa in de frågor som förbrukar mest resurser i ditt system. Query Store är inte aktiverat som standard för nya SQL Server- och Azure Synapse Analytics-databaser (SQL DW). Men det är aktiverat som standard i nya Azure SQL-databaser.
I allmänhet är det inte svårt att aktivera Query Store, men inte alla SQL Server behöver det från början. Vissa administratörer känner inte till Query Store, och vissa vet om det men har ännu inte tagit sig tid att utforska det ordentligt; de är bättre att lämna den inaktiverad. Senare, när de förstår hur Query Store fungerar, kan de använda den för att hitta prestandaskillnader som orsakas av ändringar i frågeplanen.
Slutligen analyserar Database Engine Tuning Advisor arbetsbelastningar och rekommenderar index eller partitioneringsstrategier för att förbättra frågeprestanda. Att köra Tuning Advisor på din databas är en bra idé; kör bara inte för tidigt. Se till att din databas innehåller tillräckligt med data så att indexrekommendationer är giltiga. När du först bygger din applikation kanske du bara har tusen rader i varje tabell. Tuning Advisors rekommendationer är mer användbara när databasen har vuxit.
Visa mig pengarna
Som jag nämnde i början, är SQL-prestandajustering viktig för databashantering eftersom det kan spara pengar. Hur?
Speciellt i molnet, där skalning med kreditkort är populärt, tar IT-team reda på hur dyr månadslagring verkligen kan vara. Dessutom börjar de förstå att att köra dåligt skrivna frågor och låta AWS och Azure hantera sina index ökar deras kostnader för cloud computing. Långsamma frågor och dåliga index kostar dig pengar.
Inställning av SQL-prestanda handlar om att få alla dessa saker rätt. På så sätt behåller du kontrollen över dina utgifter, oavsett om du stannar kvar i den lokala OpEx-världen eller migrerar till molnets CapEx-värld.