Att underhålla högpresterande SQL Server-instanser är en stor del av en DBA:s arbetsansvar. Underlåtenhet att upptäcka och korrigera ovanlig aktivitet kan påverka den interna verksamheten och skada företagets resultat.
Om du märker toppaktivitetsförändringar eller avvikelser i en SQL Server-instans finns här tre ställen att börja söka efter svar på.
Sidlivslängd
En instanss förväntade livslängd på sidan (PLE) bör bibehålla ett ganska konsekvent värdeintervall. Om det värdet sjunker och förblir lågt är det ett tecken på att buffertpoolen upplever ökad efterfrågan.
Innan du tar slut och får upp minnet, ta en titt på arbetsbelastningsaktiviteten. Om arbetsbelastningen har ökat skulle det förklara det extra trycket på buffertpoolen. Men om arbetsbelastningen inte har förändrats måste du titta närmare för att identifiera vad som använder det extra minnet.
Möjliga orsaker till en minskning av PLE inkluderar aktivt körande underhållsjobb, indexombyggnader eller statistikuppdateringar, DBCC-operationer och ändringar i frågeplanen.
Om du märker en minskning av PLE som inte är förknippad med en ökad arbetsbelastning, finns det några saker du kan försöka förbättra en instanss PLE:
- Släpp oanvända index
- Slå samman dubbletter av index
- Se upp för stora frågor
- Defragmentera
- Rensa data
WRITELOG Väntetid
När WRITELOG väntetiden är en för stor andel av den totala väntetiden, har du förmodligen en flaskhals på din SQL Server-instans. Flaskhalsen orsakas sannolikt antingen av ett problem på disken där transaktionsloggen lagras eller av att data överförs ineffektivt.
För att avgöra vilken typ av flaskhals du har att göra med, börja med att analysera antalet SQL-satser som väntar på WRITELOG-händelsen. Om det är många uttalanden som väntar har du en diskflaskhals. Om det bara finns ett fåtal uttalanden som väntar, begås data förmodligen för ofta.
Det finns flera sätt att lösa hög WRITELOG väntetid när du har räknat ut om din flaskhals är diskrelaterad eller commit-relaterad:
- Lägg till I/O-bandbredd på disken där transaktionsloggen är lagrad
- Flytta icke-transaktionslogg I/O från disken
- Flytta transaktionsloggen till en mindre upptagen disk
- Minska storleken på transaktionsloggen
- Se till att COMMIT-satsen är placerad i koden så att data inte committeras för ofta
TempDB
TempDB är en tillfällig arbetsyta i SQL Server som innehåller tillfälliga objekt. Eftersom objekten i TempDB är övergående, återskapar en SQL Server-instans TempDB varje gång den startas om. Detta gör optimering av TempDB avgörande för att upprätthålla prestanda och undvika operativa flaskhalsar.
TempDB-påståenden är en av de främsta orsakerna till prestandaförsämring. Tvist uppstår när flera resurser behöver åtkomst till TempDB men det finns bara en TempDB-datafil. Detta orsakar en flaskhals eftersom processer inte kan komma åt TempDB tillräckligt snabbt, vilket leder till att anslutningarna tar slut och att processerna deallokeras.
Lyckligtvis kan TempDB-flaskhalsar lösas ganska enkelt genom att justera antalet och storleken på TempDB-filer. Vid installationen är standardinställningen för SQL Server en TempDB-datafil. Om du märker att konflikter uppstår, rekommenderar vi att du lägger till åtta nya datafiler och avgör om det löser problemet. Om problemet inte är löst kan du försöka lägga till ytterligare datafiler i multipler av fyra tills prestandan är återställd.
Även om det är bra att veta var du ska börja leta när du upplever prestandaproblem, kan var och en av problemen ovan och de resulterande flaskhalsarna mildras eller undvikas helt och hållet genom att implementera en hård och snabb regel:Övervakning av prestandamått är inte valfritt. Här är några exempel på viktiga mätvärden att spåra:
Sidans förväntade livslängd:Spåra PLE med kontinuerlig övervakning och var proaktiv när den sjunker och stannar under det typiska värdet för en viss SQL Server-instans.
WRITELOG väntetider:Övervaka mätvärden som loggtillväxt, loggkrympning, procent logg som används och loggspolningsväntningar/sekund.
TempDB-ineffektivitet:Övervaka vad som allokeras till användarobjekt, versionslager eller interna objekt. Spåra hur de trendar över tiden och bestäm sedan vilka sessioner som förbrukar TempDB och hur mycket.
Det finns några utmärkta funktionsrika, prisvärda SQL Server-prestandaövervakningsverktyg på marknaden som kan hjälpa dig att hålla dig inför prestandaförsämrande problem. Gör dig själv till företagets DBA MVP genom att proaktivt undersöka lösningar som håller både inåtriktade verksamheter och utåtriktade affärstjänster igång på topp.