Der er mange indflydelsesfaktorer, når det kommer til databasens ydeevne. At kende de normale udsving i din specifikke instans ved at overvåge din SQL-server hjælper dig med at identificere, hvornår adfærd er ved at være ude af kontrol, og at forudse problemer, før de opstår.
Det hjælper dig også med at skelne mellem, hvad der er naturlige vokseværk forårsaget af øget arbejdsbyrde eller sæsonbestemte stigninger, der måske bare kræver flere ressourcer, versus dybere ydeevneproblemer, der kræver kodejustering, indeksoptimering eller konfigurationsjustering.
Når du har oprettet en liste over SQL-servere i dit miljø, vil du gerne stille nogle kritiske spørgsmål:
- Hvor sundt er denne instans?
- Hvornår er det sidst blevet sikkerhedskopieret?
- Har den tilstrækkelig CPU, hukommelse og lagerplads til at opfylde sin SLA?
- Hvilken slags arbejdsbelastninger kører på denne instans?
- Hvilke applikationer og brugere bruger denne instans?
- Hvornår er arbejdsbyrden mest travl?
- Er der en failover-strategi på plads?
- Er dette en missionskritisk instans?
- Behøver det at være tilgængeligt 24/7?
- Hvilken slags præstationsudfordringer har denne instans?
Disse kan virke som indlysende spørgsmål, men hvis du begynder at overvåge dine SQL-server-arbejdsbelastninger for første gang, vil du blive overrasket og muligvis lidt forfærdet over at se, hvor mange af dem der har grundlæggende problemer.
Sæt ydeevnemål for SQL Server-overvågning
Tænk over, hvad du vil opnå med din SQL-serverovervågningsindsats, og prioriter disse mål. Ved at indramme dine aktiviteter i forhold til nøglepræstationsindikatorer gør du det nemmere at formulere værdien af energien og eventuelle nødvendige investeringer. Følgende liste vil få dig i gang.
Høj tilgængelighed
Hvad er dine tilgængelighedsstatistikker? Husk, at utilgængelighed for brugeren er, når de ikke kan få adgang til tjenesten. Dette kan være forårsaget af et fuldstændigt udfald eller af en flaskehals i ydeevnen, der effektivt gør tjenesten utilgængelig. Har du en altid tændt konfiguration på plads? Hvis ja, kender du dens status?
Svartid
Fra det tidspunkt, hvor et problem rapporteres, hvor hurtigt kan du isolere kilden, diagnosticere symptomerne og reagere på de berørte?
Opløsningstid
Hvor hurtigt kan du løse symptomet for at genoprette normal drift? Løsningen med "klæbende gips" er en vigtig start, men bør ikke repræsentere enden på sagen. Har du undersøgt årsagen til problemet? Kan du være sikker på, at du ikke vil se en gentagelse?
Forståelse af omkostningerne ved ejerskab af dine SQL Server-forekomster
Ejerskabsomkostninger er en kritisk faktor, når du skal beslutte, hvor dine SQL-serverforekomster skal ligge. Det er vigtigt at måle de forhåndsinvesteringsomkostninger forbundet med infrastruktur og licensering, de løbende vedligeholdelsesomkostninger og eventuelle forbrugsbaserede omkostninger, der er forbundet med en cloud-baseret arbejdsbyrde.
Hvis du forsøger at bestemme, hvor meget din instans vil koste i skyen, omfatter de kritiske målinger CPU-brug, læse- og skriveaktivitet og lagring. Du bliver nødt til at måle disse over en længere periode for at finde ud af dine arbejdsbelastningsgrænser for at sikre, at du har ressourcer til det spektrum af arbejdsbyrder, du forventer for et bestemt tilfælde.
At blive fortrolig med de særlige karakteristika ved de arbejdsbelastninger, der kører på tværs af dine SQL-serverforekomster, vil sætte dig et meget bedre sted for at sikre, at alt fortsætter, som det skal, og for at opfylde både nuværende og fremtidige behov i din virksomhed.
Undersøg ydeevne over tid med SQL Server-overvågning
Databaser er flydende systemer. Meget få har stabile, gentagne og forudsigelige arbejdsbyrder. Det er langt mere almindeligt at se store variationer over tid, som svinger baseret på antallet af brugere, automatiserede job, antal transaktioner, mængden af data og så videre.
En salgsdatabase bliver optaget i slutningen af måneden. Det vil også se en stigning i aktivitet omkring sæsonbegivenheder eller drevet af marketingkampagner.
At klassificere din præstation baseret på små øjebliksbilleder er ikke en god politik. Jo mere historie du kan samle og analysere, jo mere indsigt kan du få om variationerne og grænserne for hver af dine arbejdsbelastningers karakteristika.
Du bliver nødt til at vurdere, hvor meget historie det er praktisk at beholde, og om du har ressourcerne til at behandle den. Der er konsekvenser for omkostninger og ydeevne at overveje.
Få det komplette billede til din databaseovervågning
Hver database er et komplekst system med mange bevægelige dele. Mange konfigurationskriterier kan have en effekt på dens ydeevne.
Selve databasens design og arkitektur vil påvirke resultaterne. Kodeeffektivitet kan også gøre eller ødelægge ydeevnen. Konfigurationsindstillinger bestemmer, hvordan SQL-serverforekomsten bruger ressourcer, der er tilgængelige for den.
Overvej følgende scenarie:En instans er ved at gå langsommere til at stoppe, og DBA opdager en stigning i CXPACKET eller CXCONSUMER ventetid. Knæfaldsreaktionen er at lukke ned for parallelisme. Ventetiden forsvinder, og den nuværende flaskehals afhjælpes midlertidigt. Nu kører hele instansen langsommere, men DBA ønsker ikke at genaktivere parallelitet. Hvis der var blevet foretaget yderligere undersøgelser, ville det have afsløret, at en forespørgsel kørte særligt langsomt, og årsagen var et manglende indeks.
Overvågning af mange forskellige målinger parallelt hjælper med at identificere årsagen nøjagtigt og undgå dyre fejldiagnosticeringer, der kan forårsage en gentagelse eller endda eskalering af det samme problem.