"Doktor, jag är orolig för min SQL Server-prestanda."
Det var inte sånt man hör från de flesta patienter. Men sedan, som betald proffs, har jag utbildats för att hantera allt – även de svåra tiderna att vara databasadministratör.
"Verkligen? Låt oss utforska det, ska vi?”
"Visst, Doc. Jag menar, ibland känns det så överväldigande. Jag trodde att allt bara skulle lösa sig av sig självt när jag väl hade förbundit mig till det. Men innan jag visste ordet av började jag ha prestandaproblem i SQL Server 2012, sedan 2014, sedan 2017. Jag vill inte ens tänka på SQL Server 2019.”
"Jag förstår. Tja, en bra relation med SQL Server sker inte bara av sig själv. Du måste jobba på det. Säg mig, har du arbetat med dina SQL Server-prestandajusteringstekniker?”
"Eh, nej, Doc. Jag kan inte riktigt någon av dessa tekniker.”
"Oroa dig inte. Vi kan jobba på dem. Din SQL Server känner sig förmodligen försummad. Du måste hålla ett öga på det för att se till att du ligger före i spelet. Det kräver SQL Server-övervakning.”
"Övervakning? Hur gör du det?”
"Du måste visa SQL Server att du bryr dig. Du måste vara uppmärksam på vissa mätvärden. Vi kan jobba med det också.”
"OK, Doc. Vad du än säger. Jag är villig att prova vad som helst vid det här laget. Saker och ting kunde inte bli mycket värre än de är nu.”
"Bra då. Låt oss börja."
SQL-serverprestandamätvärden — massor av rörliga delar
Patienten hade rätt:att övervaka din SQL Server-prestanda kan kännas överväldigande. Du kan inte sluta uppmärksamma den när den väl är igång. Du måste fortsätta visa att du bryr dig.
SQL Server har massor av rörliga delar som ständigt genererar mätvärden. Att veta vilka man ska titta på och sedan faktiskt ta sig tid från din hektiska dag för att övervaka dem kan vara mycket jobb för en DBA.
Så jag gick igenom några av huvudområdena för SQL Server-prestandamått med patienten.
Index
En av de första platserna att leta när du har prestandaproblem med SQL Server är indexen. Din data växer alltid, så dina index växer också alltid. Men de är föremål för villkor som fragmentering och siddelning som kan bromsa svaret på frågor.
Vad händer i en databas dag ut och dag in? Användare skapar, redigerar och tar bort poster. Indexen håller jämna steg med var alla delar av posterna finns, men med tiden hämmar indexfragmentering prestanda.
Sedan finns det indexfyllningsfaktor, en parameter som du kan konfigurera i SQL Server för att kontrollera antalet siddelningar och öka frågeeffektiviteten. Men balansen mellan fler och färre siddelningar påverkar prestandan på andra sätt.
Titta på statistik i fyllfaktor , I/O och fragmentering är ett bra sätt att hålla fingrarna på pulsen när det gäller SQL Server index hälsa.
Buffertcache
Låt oss göra det här enkelt:Disk, långsam; buffertcache, snabbt. Buffertcachen är en kopia i minnet av nyligen använda databassidor. Om SQL Server inte hittar det den letar efter där, måste den gå till disk för det, vilket saktar ner prestanda.
SQL Server låter dig specificera mängden systemminne som ska allokeras till buffertcachen, men du byter ut minne som finns kvar för andra uppgifter. Ditt mål är att allokera så mycket du kan utan att hindra SQL Server-prestanda inom andra områden.
Viktigt är också sidans förväntade livslängd, hur lång tid en sida med information från databasen tillbringar i bufferten utan att nås igen. SQL Server vräker ständigt sidor från buffertcachen för att göra plats för mer nyligen använda. Men ju färre användbara sidor den hittar där, desto mer måste den läsa från disken, vilket försämrar prestandan.
Mätvärden som sidans förväntade livslängd och förhållandet mellan lyckade träffar i buffertcachen hjälpa dig att fatta beslut om att vräka sidor mer sällan eller öka storleken på cachen.
T-SQL
SQL Server använder ett frågespråk som heter T-SQL. Istället för att köra SQL-satser ad hoc, försöker SQL Server förbättra prestanda genom att batcha dem, kompilera dem som en exekveringsplan och cachelagra dem. Den försöker också minimera frekvensen av kompilering och återanvändning av genomförandeplaner så ofta som möjligt. Om den inte kan återanvända exekveringsplanen - säg eftersom databasen har förändrats för mycket - kommer den att kompilera om planen. Det är bäst att hålla antalet omkompileringar av SQL-satser så lågt som möjligt, eftersom processen kan förbruka stora mängder CPU och försämra prestanda.
Behovet av att kompilera och omkompilera är en funktion av god kodningspraxis, som att använda lagrade procedurer och parametriseringsfrågor. DBA:er som övervakar mätvärden som frekvensen av SQL-kompilationer och SQL-omkompilationer kan ändra SQL Server-frågetips för att förbättra prestandan.
Låser, väntar och blockerade processer
Det är frustrerande att upptäcka att någon annan ändrar något samtidigt som du gör det. Så databaser låser automatiskt saker som rader och tabeller för att hålla flera kockar borta från köket. Avvägningen för det skyddet är naturligtvis att alla andra användare måste vänta tills resursen är upplåst. Och det är svårt att se till att låsning endast sker på den nivå den behöver.
Med mätvärden som visar hur ofta och hur brett låsningar påverkar andra operationer, kan DBA:er avgöra behovet av mer fysiska systemresurser för att bearbeta transaktioner snabbare. Det kan också vara så att SQL Server låser sig på en onödigt låg nivå. Frekvensen för lås väntar och, mer allmänt, antalet blockerade processer kan hjälpa till att lokalisera flaskhalsar.
Eliminera flaskhalsar med SQL-prestandajustering
"Jösses, Doc, du har rätt när det gäller alla rörliga delar. Nu ser jag hur jag inte bara kan installera SQL Server, ställa in den och glömma den. Jag behöver försörja relationen. Men allt detta känns fortfarande överväldigande. Hur ska jag någonsin kunna hålla så många olika saker rakt och ligga steget före i spelet?”
"Det är den bästa delen. Det finns verktyg som kan hjälpa till med din SQL Server-prestanda. Du behöver inte göra det ensam.”
"Wow! Det är betryggande. Jag visste inte om det.”
"Det är rätt. Verktygen övervakar din SQL-serverprestanda och rapporterar alla dessa mätvärden så att du kan tillämpa dina inställningstekniker och eliminera flaskhalsar.”
"Verkligen?"
"Säker. Och vi kan arbeta med de rätta - oh, herregud, vi har inte tid för den här veckan. Boka gärna en tid med min receptionist så hämtar vi nästa vecka.”
"Pojke, de fyra timmarna gick fort, Doc! Tiden går säkert fort när du tränar prestandaproblem kring fragmentering, resursanvändning och träffförhållande för buffertcache , inte sant?”
"Ja, och jag är säker på att när du väl kommunicerar öppet om dessa problem med din SQL Server, kommer alla dina prestandaproblem att vara historia."
Uppmuntrad av vår session gick patienten. Nästa gång kommer vi att arbeta med att övervaka flaskhalsar i SQL Server-prestanda. Jag kommer att blogga om det, så håll utkik.
Under tiden, lita på mig. Jag är en betald professionell och jag uppmuntrar dig att prova dessa saker i din egen relation med din databas. Få din SQL Server att känna sig önskad. Var uppmärksam på dess prestandamått.
Det är aldrig för sent att försöka.