Det finns många påverkande faktorer när det kommer till databasprestanda. Att känna till de normala fluktuationerna för just din instans genom att övervaka din SQL-server hjälper dig att identifiera när beteendet är utom kontroll och att förutse problem innan de uppstår.
Det hjälper dig också att skilja mellan vad som är naturliga växtvärk orsakade av ökad arbetsbelastning eller säsongsmässiga toppar som kanske bara kräver mer resurser jämfört med djupare prestandaproblem som kräver kodjustering, indexoptimering eller konfigurationsjustering.
När du väl har upprättat en lista över SQL-servrar i din miljö vill du ställa några kritiska frågor:
- Hur hälsosam är den här instansen?
- När säkerhetskopierades det senast?
- Har den tillräckligt med CPU, minne och lagring för att uppfylla sin SLA?
- Vilken typ av arbetsbelastningar körs på den här instansen?
- Vilka applikationer och användare använder den här instansen?
- När är arbetsbelastningen som störst?
- Finns det en failover-strategi på plats?
- Är detta en verksamhetskritisk instans?
- Behöver den vara tillgänglig 24/7?
- Vilken typ av prestandautmaningar har den här instansen?
Dessa kan verka som självklara frågor, men om du börjar övervaka dina SQL-serverarbetsbelastningar för första gången kommer du att bli förvånad och kanske lite förskräckt över att se hur många av dem som har grundläggande problem.
Sätt in prestandamål för SQL Server-övervakning
Fundera på vad du vill uppnå med dina SQL-serverövervakningsinsatser och prioritera dessa mål. Genom att rama in dina aktiviteter i termer av nyckeltal gör du det lättare att formulera värdet av energin och eventuella investeringar som krävs. Följande lista hjälper dig att komma igång.
Hög tillgänglighet
Vad är din tillgänglighetsstatistik? Kom ihåg att otillgänglighet för användaren är när de inte kan komma åt tjänsten. Detta kan orsakas av ett fullständigt avbrott eller av en prestandaflaskhals som effektivt gör tjänsten otillgänglig. Har du en alltid-på-konfiguration på plats? Om så är fallet, vet du dess status?
Svarstid
Från den tidpunkt då ett problem rapporteras, hur snabbt kan du isolera källan, diagnostisera symtomen och svara på de drabbade?
Upplösningstid
Hur snabbt kan du lösa symtomet för att återställa normal drift? Lösningen "klibbigt gips" är en viktig början, men bör inte representera slutet på saken. Har du utforskat grundorsaken till problemet? Kan du vara säker på att du inte kommer att se en upprepning?
Förstå ägandekostnaden för dina SQL Server-instanser
Ägandekostnad är en kritisk faktor när du bestämmer var dina SQL-serverinstanser ska finnas. Det är viktigt att mäta investeringskostnaderna i förväg förknippade med infrastruktur och licensiering, de löpande underhållskostnaderna och eventuella konsumtionsbaserade kostnader som är förknippade med en molnbaserad arbetsbelastning.
Om du försöker bestämma hur mycket din instans kommer att kosta i molnet, inkluderar de kritiska mätvärdena CPU-användning, läs- och skrivaktivitet och lagring. Du kommer att behöva mäta dessa under en längre period för att ta reda på dina arbetsbelastningsgränser för att säkerställa att du har resurser för det spektrum av arbetsbelastning du förväntar dig för en viss instans.
Att bekanta dig med de särskilda egenskaperna hos arbetsbelastningarna som körs över dina SQL-serverinstanser kommer att placera dig på en mycket bättre plats för att se till att allt fortsätter att fungera som det ska och för att möta både nuvarande och framtida behov hos ditt företag.
Studera prestanda över tid med SQL Server-övervakning
Databaser är flytande system. Väldigt få har stadiga, repetitiva och förutsägbara arbetsbelastningar. Det är mycket vanligare att se stora variationer över tid som fluktuerar baserat på antalet användare, automatiserade jobb, antal transaktioner, datavolym och så vidare.
En försäljningsdatabas kommer att bli upptagen i slutet av månaden. Det kommer också att se en ökning av aktiviteten kring säsongsbetonade evenemang eller driven av marknadsföringskampanjer.
Att klassificera ditt resultat baserat på små ögonblicksbilder är inte en bra policy. Ju mer historia du kan samla in och analysera, desto mer insikt kan du få om variationerna och gränserna för var och en av dina arbetsbelastningars egenskaper.
Du måste bedöma hur mycket historia det är praktiskt att behålla och om du har resurserna att bearbeta den. Det finns kostnads- och prestandakonsekvenser att ta hänsyn till.
Få den kompletta bilden för din databasövervakning
Varje databas är ett komplext system med många rörliga delar. Många konfigurationskriterier kan ha en effekt på dess prestanda.
Utformningen och arkitekturen av själva databasen kommer att påverka resultaten. Kodeffektivitet kan också göra eller förstöra prestanda. Konfigurationsalternativ avgör hur SQL-serverinstansen förbrukar resurser som är tillgängliga för den.
Tänk på följande scenario:En instans saktar ner till stopp och DBA upptäcker en topp i CXPACKET eller CXCONSUMER vänta. Knäsakten är att stänga av parallellismen. Väntetiderna försvinner och den nuvarande flaskhalsen lindras tillfälligt. Nu går hela instansen långsammare, men DBA vill inte återaktivera parallellism. Om ytterligare undersökningar hade gjorts, skulle det ha avslöjat att en fråga gick särskilt långsamt och orsaken var ett saknat index.
Att övervaka många olika mätvärden samtidigt hjälper till att exakt identifiera grundorsaken och undvika dyra feldiagnoser som kan orsaka en upprepning eller till och med eskalering av samma problem.