SQL Server Aktivitetsmåler: En komplett guide for databaseadministratorer [2026]

1. Innledning

1.1 Hva er SQL Server Activity Monitor?

SQL Server Aktivitetsmonitor er et innebygd diagnostikkverktøy i SQL Server Management Studio som viser informasjon om SQL Server prosesser og deres effekt på serverytelsen. Det lar deg spore SQL Server prosesser, overvåke ressursventetider, analysere dyre spørringer og observere I/O-mønstre – alt fra ett enkelt grensesnitt.

1.2 Hvorfor bruke SQL Server Activity Monitor?

Aktivitetsmonitor fungerer som din første forsvarslinje når du feilsøker ytelsesproblemer. Den gir umiddelbar innsikt i hva som skjer på din SQL Server instans uten å kreve komplekse T-SQL-spørringer eller tredjepartsverktøy.

Verktøyet utmerker seg ved å hjelpe deg med å raskt identifisere vanlige problemer som blokkering av økter, CPU-intensive spørringer, overdreven kjøring av spørringer og I/O-flaskehalser. Når brukere rapporterer at et program er tregt eller ikke svarer, hjelper Aktivitetsmonitor deg med å finne ut om databaseserveren er synderen.

For databaseadministratorer som ikke jobber med SQL Server Daglig tilbyr Aktivitetsmonitor et tilgjengelig inngangspunkt for å forstå serveraktivitet. Selv erfarne databaseadministratorer bruker det som utgangspunkt for ytelsesundersøkelser.

1.3 Aktivitetsmåler vs. andre overvåkingsverktøy

Selv om Aktivitetsmonitor er verdifull, er det viktig å forstå hvordan den sammenlignes med andre overvåkingsalternativer:

Aktivitetsmåler vs. sp_WhoIsActive: Aktivitetsmonitor har et grafisk grensesnitt med flere ruter, mens sp_WhoIsActive er en omfattende lagret prosedyre som gir mer detaljert informasjon i ett enkelt resultatsett. sp_WhoIsActive viser spesifikke ventetyper som Aktivitetsmonitor grupperer sammen og gir mer detaljert blokkeringsinformasjon.

Aktivitetsmåler vs. sp_who2: Den tradisjonelle sp_who2-kommandoen viser grunnleggende øktinformasjon, men Aktivitetsmonitor går lenger ved å vise ventestatistikk, dyre spørringer og I/O-målinger i et organisert, visuelt format.

Aktivitetsmåler vs. tredjepartsverktøy: Kommersielle overvåkingsløsninger som SolarWinds Database Performance Analyzer tilbyr historisk sporing, varsler og avansert analyse som Activity Monitor mangler. Activity Monitor krever imidlertid ingen ekstra kostnader eller installasjon.

1.4 Viktige fordeler for databaseadministratorer

Aktivitetsmonitoren tilbyr flere fordeler som gjør den til et viktig DBA-verktøy:

• Null kostnad: Som en innebygd SQL Server Management Studio-funksjonen, det kreves ingen lisensavgift eller implementeringsinnsats.
• Sanntidsovervåking: Se gjeldende serveraktivitet mens den skjer, med konfigurerbare oppdateringsintervaller fra 1 sekund til 1 time.
• Integrerte handlinger: Høyreklikk på prosesser for å avslutte økter, vise spørringsdetaljer eller starte SQL Server Profiler-spor – alt fra verktøyet.
• Flere perspektiver: Se serverhelse fra forskjellige vinkler gjennom fem spesialiserte ruter, som hver fokuserer på spesifikke ytelsesaspekter.
• Rask feilsøking: Identifiser de vanligste ytelsesproblemene i løpet av minutter, og få raskere løsningstid.
• Lav adgangsbarriere: Ingen avansert kunnskap kreves for å begynne å bruke verktøyet effektivt, men dypere SQL Server ekspertise hjelper med tolkning.

2. Komme i gang med Aktivitetsmåler

Før du kan bruke Aktivitetsmonitor effektivt, må du forstå forutsetningene, nødvendige tillatelser og ulike metoder for å starte verktøyet.

2.1 Forutsetninger og systemkrav

Å bruke SQL Server Aktivitetsmåler, du trenger SQL Server Management Studio (SSMS) installert på din lokale maskin eller en jump-server. Aktivitetsmonitorverktøyet ble betydelig redesignet i SQL Server 2008, så informasjonen i denne veiledningen gjelder for SQL Server 2008 og senere versjoner.

Du må ha nettverkstilkobling til SQL Server instansen du vil overvåke. For skybaserte databaser trenger du vanligvis en VPN-tilkobling eller riktig konfigurerte brannmurregler for å få tilgang til instansen.

Aktivitetsmonitor fungerer med alle utgaver av SQL Server, inkludert Express, Standard og Enterprise. Verktøyet kjører i seg selv på klientmaskinen din i SSMS, så serverens ressurser påvirkes bare av overvåkingsspørringene den kjører.

2.2 Nødvendige tillatelser

Riktige tillatelser er avgjørende for at Aktivitetsmonitoren skal fungere riktig. Uten de nødvendige rettighetene kan du se en tom skjerm eller få feilmeldinger om nektet tilgang.

2.2.1 Tillatelse til å vise servertilstand

Ocuco SE SERVERSTATUS Tillatelse er det primære kravet for å bruke Aktivitetsmonitor. Denne tillatelsen på servernivå lar deg se alle aktive prosesser og tilhørende målinger.

For å gi denne tillatelsen kan en serveradministrator utføre:

GRANT VIEW SERVER STATE TO [YourLoginName];

Uten VIS SERVERSTATUS kan Aktivitetsmonitoren åpnes, men ikke vise data i noen av rutene.

2.2.2 Tillatelser på databasenivå

For å vise informasjon i ruten Data File I/O trenger du ytterligere tillatelser. Du må ha én av følgende kombinasjoner:

• LAG DATABASE tillatelse, eller
• ENDRE HVILKEN SOM HELST DATABASE tillatelse, eller
• SE HVILKEN SOM HELST DEFINISJON tillatelse

Disse tillatelsene må kombineres med SE SERVERSTATUS for full Aktivitetsmonitor-funksjonalitet.

2.2.3 Feilsøking av tillatelser

Hvis Aktivitetsmonitor åpnes, men ikke viser noen data, er tillatelser den vanligste årsaken. Sjekk at påloggingsinformasjonen din har VIS SERVERSTATUS gitt på servernivå. Du kan bekrefte tillatelsene dine ved å kjøre:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Se etter «VIS SERVERSTATUS» i kolonnen permission_name. Hvis den mangler, kontakt databaseadministratoren din for å få den innvilget.

2.3 Slik åpner du Aktivitetsmonitor i SSMS

SQL Server Management Studio tilbyr fire forskjellige metoder for å starte Aktivitetsmonitor, noe som gir deg fleksibilitet basert på dine arbeidsflytpreferanser.

2.3.1 Metode 1: Fra verktøylinjen

Den raskeste måten å åpne Aktivitetsmonitoren på er å bruke verktøylinjeikonet:

1. Koble til din SQL Server eksempel i SQL Server ManagementStudio.
2. Finn Aktivitetsmonitor-ikonet i standardverktøylinjen (det ligner et søylediagram med en grønn avspillingsknapp).
3. Klikk på ikonet for å starte Aktivitetsmonitor.

Denne metoden er raskest når du allerede jobber i SSMS og raskt trenger å sjekke serveraktiviteten.

2.3.2 Metode 2: Fra Objektutforsker

Du kan også starte Aktivitetsmonitor direkte fra Objektutforskeren:

1. I Objektutforsker finner du SQL Server forekomsten du ønsker å overvåke.
2. Høyreklikk på forekomstnavnet.
3. Velg Aktivitetsmonitor fra kontekstmenyen.

Denne metoden er nyttig når du kobler til flere servere, da den sikrer at du overvåker riktig instans.

2.3.3 Metode 3: Bruk av hurtigtast

For brukere som fokuserer på tastaturet, SQL Server Management Studio tilbyr en dedikert snarvei:

1. Sørg for at SSMS er det aktive vinduet og at du er koblet til en instans.
2. Press Ctrl + andre + A.
3. Aktivitetsmonitoren åpnes for den gjeldende valgte forekomsten i Objektutforsker.

Merk at Aktivitetsmonitor vil koble til den serverinstansen du har valgt i Objektutforsker, så sørg for at du har valgt riktig instans før du bruker denne snarveien.

2.3.4 Metode 4: Fra alternativmenyen (oppstartskonfigurasjon)

Hvis du bruker Aktivitetsmonitor ofte, kan du konfigurere SSMS til å starte det automatisk hver gang du starter programmet:

1. In SQL Server Management Studio, naviger til verktøy -> alternativer.
2. I dialogboksen Alternativer utvider du Miljø, Og velg deretter oppstart.
3. Fra Ved oppstart rullegardinliste, velg Åpne Objektutforsker og Aktivitetsmonitor.
4. Velg OK.

Neste gang du starter SSMS og kobler til en server, åpnes Aktivitetsmonitor automatisk sammen med Objektutforsker.

3. Forstå aktivitetsmonitorruter

Aktivitetsmonitoren organiserer informasjon i fem utvidbare ruter, som hver gir et ulikt perspektiv på serveraktivitet. Å forstå hva hver rute viser er avgjørende for effektiv feilsøking.

3.1 Oversiktsrute

Oversiktsruten presenterer fire sanntidsgrafer som gir deg et raskt øyeblikksbilde av helsen din. SQL Server for eksempel. Disse grafene oppdateres med konfigurerbare intervaller og hjelper deg med å identifisere unormale mønstre med et raskt blikk.

3.1.1 % prosessortid

Denne grafen viser prosentandelen av tiden prosessoren bruker på å kjøre ikke-inaktive tråder for SQL Server forekomst på tvers av alle CPU-er. Verdien representerer SQL Serverprosessorutnyttelsen, ikke hele serverens CPU-bruk.

Hvis du konsekvent ser prosessortid på eller nær 100 %, er serveren din CPU-bundet. Dette kan tyde på ineffektive spørringer, manglende indekser eller utilstrekkelig maskinvarekapasitet. Bruk ruten Nylig brukte spørringer for å identifisere hvilke spørringer som bruker mest CPU.

3.1.2 Venteoppgaver

Denne målingen viser antall oppgaver som venter på at ressurser skal frigjøres før de kan fortsette. Oppgaver kan vente på CPU, I/O, minne eller låser.

Et gjennomgående høyt antall ventende oppgaver indikerer ressurskonflikt. Ruten Ressursventinger gir mer informasjon om hvilke typer ressurser som forårsaker ventetider.

3.1.3 Database I/O (MB/s)

Denne grafen viser dataoverføringshastigheten mellom minne og disk. Den kombinerer både lesing og skriving, målt i megabyte per sekund.

Topper i database-I/O kan indikere spørringer som utfører store tabellskanninger, overdreven loggaktivitet eller kontrollpunktsoperasjoner. Datafil-I/O-ruten deler opp I/O-aktivitet etter database og fil.

3.1.4 Batchforespørsler/sek

Denne målingen representerer antallet SQL Server batcher mottatt av instansen per sekund. En batch kan være en enkelt setning eller flere setninger som sendes inn sammen.

Denne verdien gir deg en følelse av den generelle serveraktiviteten. Plutselige fall i batchforespørsler i løpet av vanlig åpningstid kan tyde på problemer med applikasjonstilkoblingen eller problemer med brukeren.

3.1.5 Angi oppdateringsintervaller

Du kan tilpasse hvor ofte Aktivitetsmonitor oppdaterer dataene sine:

1. Høyreklikk hvor som helst i Oversikt-ruten.
2. Velg Oppdater intervall.
3. Velg et intervall fra de forhåndsdefinerte verdiene: 1 sekund, 5 sekunder, 10 sekunder (standard), 30 sekunder, 1 minutt eller 1 time.

Hvis du setter oppdateringsintervaller på under 10 sekunder, øker overvåkingskostnadene på serveren din. For produksjonssystemer under høy belastning bør du vurdere å bruke intervaller på 30 sekunder eller lengre for å minimere påvirkningen.

3.2 Prosessrute

Prosesser-ruten viser informasjon om økter som kjører på enheten din. SQL Server for eksempel. Denne ruten er viktig for å identifisere hvem som gjør hva og oppdage blokkeringsproblemer.

3.2.1 Forståelse av prosessinformasjon

Hver rad i Prosesser-ruten representerer en aktiv økt på serveren. Ruten viser økter fra alle databaser og alle brukere, noe som gir deg en omfattende oversikt over serveraktivitet.

Informasjonen som vises inkluderer påloggingsnavn, programnavn, vertsnavn, databasen som åpnes og gjeldende kommando. Dette hjelper deg med å korrelere databaseaktivitet med bestemte brukere eller applikasjoner.

3.2.2 Forklaring av nøkkelkolonner

Å forstå nøkkelkolonnene hjelper deg med å tolke prosessinformasjon effektivt:

• Øktnummer: En unik identifikator for hver tilkobling. Systemprosesser bruker negative økt-ID-er.
• Brukerprosess: Angir om dette er en brukerøkt (Ja) eller en systemprosess (Nei).
• Logg inn: Ocuco SQL Server pålogging eller Windows-konto som er knyttet til økten.
• Database: Gjeldende databasekontekst for økten.
• Oppgavestatus: Viser hva økten gjør for øyeblikket (KJØRER, I PÅHOLDNING, SOVENDE osv.).
• Command: Typen kommando som utføres (SELECT, INSERT, UPDATE osv.).
• Påføring: Navnet på applikasjonen som opprettet tilkoblingen.
• Ventetid: Hvor lenge (i millisekunder) økten har ventet på ressurser.
• Ventetype: Den spesifikke typen ressurs økten venter på.
• CPU-tid: Total CPU-tid brukt av denne økten siden den koblet til.
• Minnebruk: Mengde minne (i KB) som for øyeblikket er tildelt økten.

3.2.3 Filtrerings- og sorteringsprosesser

Prosesser-ruten inneholder kraftige filtreringsfunksjoner som hjelper deg med å fokusere på relevante økter:

1. Klikk på rullegardinpilen i en hvilken som helst kolonneoverskrift.
2. Filteret viser tilgjengelige verdier for den kolonnen, inkludert Alle, blanksog Ikke-blanke felt.
3. Velg spesifikke verdier for å filtrere visningen til bare disse øktene.

For eksempel kan du filtrere Oppgavestatus for å vise bare KJØRENDE økter, eller filtrere Database for å se aktivitet mot en spesifikk database.

Du kan også sortere etter en hvilken som helst kolonne ved å klikke på overskriften. Klikk én gang for stigende rekkefølge, to ganger for synkende rekkefølge.

3.2.4 Identifisering av blokkerende og blokkerte økter

Prosesser-ruten hjelper deg med å identifisere blokkeringsscenarier der én økt hindrer andre i å fortsette:

• Blokkert av: Viser økt-ID-en til økten som blokkerer denne økten. Hvis denne kolonnen inneholder en verdi, venter økten på en lås som holdes av en annen økt.
• Hodeblokker: Viser '1' hvis denne økten blokkerer andre, men ikke selv er blokkert. Dette er den underliggende årsaken til en blokkeringskjede.

For å undersøke et blokkeringsproblem, identifiser først hovedblokkeringen (økten merket med '1' i Hovedblokkering-kolonnen), undersøk deretter hva den gjør og avgjør om du vil la den fullføre eller avslutte den.

3.2.5 Prosesshandlinger (avslutning, detaljer, sporing)

Med Aktivitetsmonitoren kan du utføre handlinger på individuelle økter:

1. Høyreklikk på en hvilken som helst økt i Prosesser-ruten.
2. Du vil se flere alternativer:
   • detaljer: Viser den siste kommandoen som ble utført av denne økten.
   • Drepeprosess: Avslutter økten (bruk med forsiktighet).
   • Sporingsprosess i SQL Server Profiler: Lanserer SQL Server Profiler og filtrerer automatisk for kun å vise aktivitet fra denne økten.

Detaljer-alternativet viser deg kommandoteksten, men merk at dette er siste kommandoen er utført – den kjører kanskje ikke fortsatt. Sporingsalternativet er spesielt nyttig når du trenger å se hele sekvensen av kommandoer som en økt kjører.

3.3 Ressursventer-ruten

Ruten Ressursventing oppsummerer ventestatistikk og viser hvilke typer ressursøkter som venter på oftest. Denne informasjonen er avgjørende for å diagnostisere ytelsesflaskehalser.

3.3.1 Forstå ventestatistikk

Når SQL Server Hvis ikke en ressursforespørsel umiddelbart kan innvilges (for eksempel en lås, CPU-tid eller minne), går den forespørrende oppgaven inn i en ventetilstand. Ventestatistikk sporer disse venteperiodene og hjelper deg å forstå hvor serveren bruker tid på å vente i stedet for å jobbe.

Ressursventetider-ruten samler inn data fra dynamiske systemadministrasjonsvisninger som sys.dm_os_wait_stats og sys.dm_exec_requests. Ved hvert oppdateringsintervall beregner den differansen mellom gjeldende og forrige øyeblikksbilde, og viser deg akkumuleringshastigheten for hver ventetype.

3.3.2 Ventekategorier

Aktivitetsmonitor grupperer hundrevis av individuelle ventetyper i bredere kategorier for å forenkle tolkningen:

• CPU: Oppgaver som venter på at CPU-tid skal bli tilgjengelig.
• Bufferlås: Venter på kortsiktige synkroniseringsobjekter som beskytter tilgang til datasider i minnet. Denne kategorien inkluderer ventetider for sidelås (PAGELATCH_*).
• Lås: Ventetider forårsaket av økter som inneholder låser som andre økter trenger.
• Minne: Venter på minnetildelinger som trengs av operasjoner som sortering og hashing.
• Nettverks-I/O: Venter på å sende data til eller motta data fra klienter.
• SQL CLR: Ventetider relatert til kjøring av Common Language Runtime.

Selv om denne grupperingen forenkler visningen, skjuler den også viktige detaljer. For eksempel kan «Buffer Latch» gruppere ventetidene PAGELATCH_SH, PAGELATCH_UP og PAGELATCH_EX, som har forskjellige implikasjoner for ytelsen.

3.3.3 Tolkning av ventetid og venteoppgaver

Ventetider i ressurser viser to viktige målinger for hver ventekategori:

• Kumulativ ventetid (ms): Totalt antall millisekunder akkumulert i løpet av gjeldende oppdateringsintervall for denne ventekategorien.
• Venteoppgaver: Antall oppgaver som for øyeblikket venter på ressurser i denne kategorien.

Ventetidsverdien er spesielt interessant. Hvis du har et oppdateringsintervall på 10 sekunder og ser 20 000 ms ventetid for en kategori, indikerer det flere samtidige ventetider (20 000 ms / 10 000 ms = gjennomsnitt av 2 samtidige ventetider i løpet av intervallet).

3.3.4 Identifisering av ytelsesflaskehalser

Bruk ruten Ressursventing til å identifisere hvor serveren din bruker mest tid på å vente:

1. Utvid ruten Ressursventinger.
2. Observer ventekategoriene som akkumulerer de høyeste ventetidene.
3. Sorter etter Kumulativ ventetid for å se hvilke ressurser som er mest begrensede.

Venting med høy bufferlås indikerer ofte strid om datasider i minnet, noe som kan tyde på I/O-flaskehalser eller tempdb-strid. Venting med høy lås peker på blokkeringsproblemer. Venting med høy minnebelastning tyder på utilstrekkelige minnetildelinger for spørreoperasjoner.

3.4 I/O-rute for datafiler

Datafil-I/O-ruten viser diskaktivitet for hver databasefil på serveren din, noe som hjelper deg med å identifisere I/O-flaskehalser og forstå diskutnyttelsesmønstre.

3.4.1 Forstå I/O-målinger

Datafil I/O-ruten viser flere målinger for hver databasefil:

• Database: Navnet på databasen.
• Filtype: Enten data (inkludert tabeller og indekser) eller logg (transaksjonslogg).
• Logisk navn: Det logiske filnavnet som definert i SQL Server.
• MB/sek Lesing: Hastigheten på dataene som leses fra denne filen.
• MB/sek Skrevet: Hastigheten på dataene som skrives til denne filen.
• Responstid (ms): Gjennomsnittlig responstid for I/O-operasjoner på denne filen.

Disse målingene oppdateres med samme intervall som oversiktsruten, noe som gir deg sanntidsinnsikt i diskaktivitet.

3.4.2 Identifisering av I/O-flaskehalser

Se etter disse mønstrene som indikerer problemer med I/O-ytelse:

• Høy responstid: Responstider som konsekvent er over 15–20 ms tyder på trege diskundersystemer. Responstider over 50 ms indikerer alvorlige I/O-flaskehalser.
• Ubalansert belastning: Hvis én datafil viser betydelig høyere I/O-hastigheter enn andre i samme database, kan det være nyttig å legge til flere filer for å fordele belastningen.
• Overdreven Tempdb-aktivitet: Høye I/O-rater på tempdb-filer indikerer ofte at spørringer oppretter store mellomliggende resultatsett eller bruker ineffektive utførelsesplaner.

3.4.3 Analyse av databasefiler

Bruk ruten Datafil I/O for å forstå hvordan databasene dine bruker diskressurser:

1. Utvid ruten Datafil I/O.
2. Sorter etter MB/sek Lesing or MB/sek Skrevet for å identifisere de mest aktive filene.
3. Legg merke til eventuelle filer med gjennomgående høy aktivitet eller lange responstider.
4. Kryssreferer denne informasjonen med ruten Nylig brukte dyre spørringer for å identifisere hvilke spørringer som driver I/O-belastningen.

3.5 Ruten for nylige dyre søk

Ruten Nylig brukte dyre spørringer er ofte den mest verdifulle ruten for feilsøking av problemer med applikasjonsytelse. Den viser spørringer som bruker betydelige serverressurser, og hjelper deg med å identifisere optimaliseringsmuligheter.

3.5.1 Forstå spørremålinger

Aktivitetsmonitor viser flere målinger for hver dyre spørring:

• Henrettelser/min: Hvor mange ganger spørringen ble utført i løpet av siste minutt.
• CPU (ms/sek): CPU-tid brukt av denne spørringen per sekund.
• Fysiske avlesninger/sek: Antall fysiske disklesninger per sekund for denne spørringen.
• Logiske skrivinger/sek: Antall logiske skrivinger (til bufferbuffer) per sekund.
• Logiske lesninger/sek: Antall logiske lesninger (fra bufferbufferen) per sekund.
• Gjennomsnittlig varighet (ms): Gjennomsnittlig utførelsestid for denne spørringen.
• Antall planer: Antall utførelsesplaner i hurtigbufferen for denne spørringen.

Disse beregningene hjelper deg med å forstå ikke bare hvilke søk som er dyre, men hvorfor de er dyre og hvor ofte de kjører.

3.5.2 Sorteringsalternativer

Du kan sortere ruten Nylige dyre søk etter forskjellige målinger for å finne forskjellige typer problemer:

1. Klikk på en hvilken som helst kolonneoverskrift for å sortere etter den beregningen.
2. Vanlige sorteringsstrategier inkluderer:
   • Sorter etter CPU: Finn spørringer som bruker mest prosessortid.
   • Sorter etter Henrettelser/min: Identifiser spørringer som kjører for ofte.
   • Sorter etter fysiske avlesninger: Finn spørringer som forårsaker mest disk-I/O.
   • Sorter etter gjennomsnittlig varighet: Finn langvarige spørringer.

Når du feilsøker et ytelsesproblem, kan du prøve å sortere etter flere kolonner for å få ulike perspektiver. En spørring med moderat CPU-bruk, men ekstremt høye antall kjøringer per minutt, kan være det virkelige problemet.

3.5.3 Vise spørretekst

For å se den faktiske SQL-setningen bak en dyr spørring:

1. Høyreklikk på spørreraden i ruten Nylige dyre spørringer.
2. Velg Rediger spørretekst.
   
3. Et nytt spørrevindu åpnes som viser hele SQL-setningen.
   

Dette lar deg undersøke spørrelogikken og identifisere potensielle optimaliseringsmuligheter. Du kan deretter kopiere spørreteksten for å teste endrede versjoner.

3.5.4 Analysere utførelsesplaner

Utførelsesplaner viser deg hvordan SQL Server utfører en spørring, og avslører ineffektivitet som manglende indekser eller upassende sammenføyningstyper:

1. Høyreklikk på spørreraden i ruten Nylige dyre spørringer.
2. Velg Vis utførelsesplan.
   
3. SQL Server Management Studio viser en grafisk fremstilling av hvordan spørringen kjøres.
   

Se etter operasjoner som bruker opp store prosentandeler av spørrekostnaden, advarsler om manglende statistikk eller indekser, og uventede tabellskanningsoperasjoner. Disse indikerer ofte hvor optimaliseringsarbeidet bør fokuseres.

3.5.5 Identifisering av problematiske spørringer

Se etter disse mønstrene i ruten Nylige dyre søk:

• Overdrevne henrettelser: En spørring som kjøres tusenvis av ganger per minutt kan indikere et N+1 spørreproblem der applikasjonskoden kaller databasen i en løkke.
• Høye fysiske avlesninger: Spørringer med høy fysisk lesehastighet treffer disken ofte, noe som tyder på manglende indekser eller dårlig skrevet spørringer.
• Høy CPU med lav varighet: Mange raske spørringer som bruker mye CPU samlet sett kan påvirke serverytelsen like mye som noen få trege spørringer.
• Flere plantellinger: Spørringer med mange utførelsesplaner kan ha problemer med parametersniffing eller ikke-parametriserte spørringer som forårsaker oppblåsthet i planbufferen.

4. Bruk av aktivitetsmåler for feilsøking av ytelse

Aktivitetsmonitoren kommer virkelig til sin rett når du bruker den systematisk til å diagnostisere og løse ytelsesproblemer. Denne delen dekker vanlige feilsøkingsscenarioer og hvordan du skal håndtere dem.

4.1 Diagnostisering av overdreven kjøring av spørringer

Et av de vanligste ytelsesproblemene er spørringer som kjøres mye oftere enn nødvendig, ofte på grunn av problemer med applikasjonsdesign.

4.1.1 Identifisering av gjentatte spørringer

Slik finner du spørringer som kjøres for ofte:

1. Åpne Aktivitetsmonitor og utvid Nylige dyre søk ruten.
2. Sorter etter Henrettelser/min (utførelser per minutt).
3. Se etter søk øverst med utførelsestellinger som virker urimelig høye.
4. Høyreklikk på den mistenkelige spørringen og velg Rediger spørretekst for å undersøke SQL-setningen.

Hvis du for eksempel ser en enkel SELECT-setning kjøres 37 000 ganger per minutt, bør du stille spørsmål ved om applikasjonen virkelig trenger å kalle denne spørringen så ofte. De fleste spørringer som kjøres mer enn noen få tusen ganger per minutt, fortjener en undersøkelse.

4.1.2 Grunnårsaksanalyse

Overdreven kjøring av spørringer stammer vanligvis fra disse problemene:

• N+1-spørringsproblem: Applikasjonskoden henter en liste over elementer, og utfører deretter en separat spørring for hvert element for å hente relaterte data. Dette oppretter N ekstra spørringer der N er antall elementer.
• Manglende mellomlagring: Applikasjonen spør databasen etter data som sjelden endres, i stedet for å mellomlagre dem i programminnet.
• Avstemningsløkker: Kode spør databasen gjentatte ganger etter tilstandsendringer i stedet for å bruke endringsvarsler eller meldingskøer.
• ORM-ineffektivitet: Entity Framework og lignende verktøy genererer noen ganger ineffektive spørremønstre når utviklere ikke forstår hvordan koden deres oversettes til SQL.

For å finne rotårsaken, spor spørringen tilbake til programkoden. Merk deg Søknad og Login kolonner i Prosesser-ruten når spørringen kjøres. Du kan også høyreklikke på prosessen og velge Sporingsprosess i SQL Server Profiler for å se ringemønsteret.

4.1.3 Løsninger og beste praksis

Når du har identifisert overdreven kjøring av spørringer, bør du vurdere disse løsningene:

• Batchbehandling: Endre applikasjonskode for å hente flere elementer i én spørring ved hjelp av sammenføyninger eller IN-klausuler i stedet for å kjøre separate spørringer i en løkke.
• Resultatbuffering: Hurtigbuffer åpnes ofte, endrer sjelden data i applikasjonsminnet med passende utløpstider.
• Ivrig lasting: Konfigurer ORM-er til å bruke strategier for ivrig lasting som henter relaterte data i færre, mer effektive spørringer.
• Spørringsparameterisering: Sørg for at spørringer bruker parametere i stedet for å sammenkoble verdier, noe som forbedrer gjenbruk av planbufferen og reduserer kompileringsoverhead.

4.2 Undersøke blokkeringsproblemer

Blokkering oppstår når én økt har låser som hindrer andre økter i å fortsette. Dette manifesterer seg som trege responstider for applikasjoner og frustrerte brukere.

4.2.1 Identifisering av blokkeringskjeder

For å oppdage og analysere blokkering:

1. Åpne Aktivitetsmonitor og utvid prosesser ruten.
2. Se etter økter med verdier i Blokkert av kolonne – disse venter på låser som holdes av andre økter.
3. Finn økter med '1' i Hodeblokker kolonne – dette er den underliggende årsaken til blokkering av kjeder.
4. Legg merke til Øktnummer av hodeblokkeren.
5. Høyreklikk på hodeblokkeringsøkten og velg Detaljer for å se hvilken kommando den utfører.

Det er avgjørende å forstå blokkeringskjeden. Det er hodeblokkeren du må undersøke, ikke de blokkerte øktene nedstrøms.

4.2.2 Forstå låstyper

Ocuco Ventetype Kolonnen i Prosesser-ruten angir hvilken type lås blokkerte økter venter på:

• LCK_M_X: Eksklusiv låsevent, vanligvis forårsaket av UPDATE-, DELETE- eller INSERT-operasjoner.
• LCK_M_S: Delt låsventing, vanligvis SELECT-setninger som venter på at eksklusive låser skal frigjøres.
• LCK_M_U: Vent på oppdateringslås, en mellomliggende låsetype som brukes under oppdateringer.
• LCK_M_IX: Intent-eksklusiv låsevent, som indikerer låsekonflikt på side- eller radnivå.

Ocuco Vente ressurs Kolonnen viser hvilket databaseobjekt som låses, noe som hjelper deg å forstå hvilken tabell eller indeks som er involvert i konflikten.

4.2.3 Løse blokkeringsproblemer

Når du har identifisert blokkeringsøkten og hva den gjør, har du flere alternativer:

1. Vent på fullføring: Hvis headblockeren kjører en legitim spørring som snart vil fullføres, kan det være best å la den fullføres naturlig.
2. Drep økten: Hvis headblockeren sitter fast eller kjører en spørring som bør avbrytes:
   • Høyreklikk på økten i Prosesser-ruten.
   • Velg Drep prosessen.
   • Bekreft handlingen i dialogboksen.
3. Optimaliser spørringer: Hvis blokkering gjentas med de samme spørringene, optimaliser dem for å redusere låsevarigheten.
4. Juster isolasjonsnivåer: Vurder å bruke READ COMMITTED SNAPSHOT ISOLATION for å redusere blokkering i lesetunge arbeidsbelastninger.
5. Indeksjustering: Legg til indekser for å øke hastigheten på spørringer, og redusere hvor lenge de holder låser.

4.3 Analysere høy CPU-bruk

Når oversiktsruten viser en prosessortid konsekvent på eller nær 100 %, må du identifisere hvilke spørringer som er ansvarlige og avgjøre om de kan optimaliseres.

4.3.1 Identifisering av CPU-intensive spørringer

Slik finner du spørringer som bruker mye CPU:

1. Åpne Nylige dyre søk ruten.
2. Sorter etter CPU (ms/sek) for å vise spørringer som bruker mest CPU-tid.
3. Undersøk de vanligste søkene i listen.
4. Høyreklikk på spørringer med høy CPU og velg Rediger spørretekst for å se SQL-setningen.
5. Velg Vis utførelsesplan for å forstå hvordan spørringen utføres.

Vær ikke bare oppmerksom på CPU-bruken til den enkelte spørringen, men også på Henrettelser/min kolonne. En spørring som bruker moderat CPU per utførelse, men som kjører tusenvis av ganger per minutt, kan være den største CPU-forbrukeren.

4.3.2 Teknikker for spørringsoptimalisering

Vanlige metoder for å redusere CPU-forbruket inkluderer:

• Legg til manglende indekser: Indekssøk bruker mye mindre CPU enn tabellskanninger. Se etter manglende indeksanbefalinger i utførelsesplaner.
• Skriv om ineffektive spørringer: Erstatt markører med settbaserte operasjoner, fjern unødvendige funksjoner i WHERE-klausuler og fjern overflødige koblinger.
• Oppdater statistikk: Utdatert statistikk forårsaker SQL Server å velge ineffektive utførelsesplaner. Kjør OPPDATER STATISTIKK på berørte tabeller.
• Reduser datavolum: Legg til WHERE-klausuler for å filtrere data tidligere, bruk TOP eller OFFSET/FETCH for paginering, og unngå SELECT *.
• Fiks parametersniffing: Bruk OPTION (RECOMPILE), spørretips eller planleggingsveiledninger når parametersniffing forårsaker problemer.

4.4 Undersøke minneproblemer

Minnebelastning kan føre til at spørringer overføres til disken, noe som reduserer ytelsen betydelig. Aktivitetsmonitor hjelper deg med å identifisere minnekrevende operasjoner.

4.4.1 Forstå minnemålinger

Ocuco Minnebruk Kolonnen i Prosesser-ruten viser minne som er tildelt hver økt i kilobyte. Høyt minneforbruk av en enkelt økt indikerer ofte:

• Store sorterings- eller hash-operasjoner som ikke fikk plass i det opprinnelig tildelte minnet
• Spørringer som henter enorme resultatsett
• Overdreven parallellisme som skaper mange kopier av utførelsesplanoperatorer
• Minnelekkasjer i lagrede prosedyrer eller funksjoner i CLR

Ruten Ressursventinger kan vise Minneventinger når spørringer ikke kan få tilstrekkelig minnetildeling og må vente på at minnet blir tilgjengelig.

4.4.2 Identifisering av minnekrevende spørringer

Slik finner du spørringer som forårsaker minnebelastning:

1. på prosesser rute, sorter etter Minnebruk for å se øktene som bruker mest minne.
2. Høyreklikk på økter med høy minnebruk og velg Detaljer for å se spørsmålene deres.
3. på Nylige dyre søk rute, se etter spørringer med høy Logiske lesninger or Logiske skrivinger, da disse ofte korrelerer med minnebruk.
4. Undersøk utførelsesplaner for sorterings- og hash-match-operatorer, som bruker minnetildelinger.

Spørringer som viser advarsler om «Minnetildeling» i utførelsesplaner eller advarsler om spill, indikerer problemer med minnetrykk.

4.5 Oppdage problemer med applikasjonsytelse

Når brukere rapporterer treg responstid for programmer, hjelper Aktivitetsmonitor deg med å finne ut om databasen er flaskehalsen.

4.5.1 Korrelere aktivitetsmåleren med programproblemer

For å undersøke hvor treg applikasjonen er:

1. Noter nøyaktig når brukere rapporterer problemer og hvilke applikasjoner som er berørt.
2. Åpne Aktivitetsmonitoren og sjekk Oversikt ruten for ressurstopper på det tidspunktet.
3. på prosesser rute, filtrer etter Søknad for å bare vise tilkoblinger fra det berørte programmet.
4. Se etter høye Ventetid verdier, som indikerer databaseforsinkelser.
5. Sjekk Nylige dyre søk ruten for spørringer fra det programmet som bruker betydelige ressurser.

Hvis databasen ikke viser noen uvanlig aktivitet mens brukerne opplever treghet, ligger problemet sannsynligvis i applikasjonskoden, nettverksforsinkelsen eller klientsidens ytelse.

4.5.2 Identifisering av ineffektive applikasjonsmønstre

Aktivitetsmonitor avslører flere antimønstre i applikasjonsdesign:

• Pratfulle applikasjoner: Mange små spørringer i stedet for færre, mer effektive spørringer. Identifisert ved høyt antall tilkoblinger og en rekke enkle spørringer i Nylige dyre spørringer.
• N+1-spørringer: Én spørring etterfulgt av N ytterligere spørringer for relaterte data. Vises som en enkel spørring med ekstremt høye utførelsesfrekvenser per minutt.
• Store resultatsett: Applikasjoner som henter langt mer data enn nødvendig. Se etter høye Logiske lesninger kombinert med enkle SELECT*-spørringer.
• Manglende tidsavbrudd: Programmer som ikke angir tidsavbrudd for kommandoer, kan la tilkoblinger være åpne på ubestemt tid, synlige som langvarige økter i Prosesser-ruten.

5. Alternative metoder: Henting av aktivitetsmonitordata via T-SQL

Selv om Aktivitetsmonitor har et praktisk grafisk grensesnitt, må du noen ganger hente tilsvarende informasjon programmatisk eller lage tilpassede overvåkingsløsninger.

5.1 Bruk av dynamiske administrasjonsvisninger (DMV-er)

SQL Server eksponerer aktivitetsinformasjon gjennom dynamiske administrasjonsvisninger, som Aktivitetsmonitor spør etter i bakgrunnen.

5.1.1 Viktige DMV-er for aktivitetsovervåking

De viktigste DMV-ene for å replikere Aktivitetsmonitor-funksjonaliteten inkluderer:

• sys.dm_exec_requests: Viser forespørsler som for øyeblikket utføres med CPU-, I/O- og venteinformasjon.
• sys.dm_exec_sessions: Inneholder informasjon på øktnivå som påloggingsnavn, vertsnavn og programnavn.
• sys.dm_os_wait_stats: Gir kumulativ ventestatistikk for hele forekomsten.
• sys.dm_exec_query_stats: Inneholder samlet ytelsesstatistikk for hurtigbufrede spørringer.
• sys.dm_io_virtual_file_stats: Returnerer I/O-statistikk for data og loggfiler.
• sys.dm_exec_sql_tekst: Henter SQL-teksten for en gitt sql_handle eller plan_handle.
• sys.dm_exec_query_plan: Returnerer utførelsesplanen for en hurtigbufret spørring.

5.1.2 Eksempelspørringer for prosessinformasjon

For å replikere funksjonaliteten i Prosesser-ruten kan du spørre:

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Eksempelspørringer for ventestatistikk

Slik ser du ventestatistikk som ligner på Ressursventetider-ruten:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 Bruk av sp_WhoIsActive

sp_WhoIsActive er en kraftig lagret prosedyre laget av fellesskapet som gir mer detaljert informasjon enn Aktivitetsmonitor i ett enkelt resultatsett.

5.2.1 Installere sp_WhoIsActive

For å installere sp_WhoIsActive:

1. Last ned den siste versjonen fra http://whoisactive.com.
2. Nedlastingen er et SQL-skript som inneholder prosedyredefinisjonen.
3. Åpne skriptet i SQL Server ManagementStudio.
4. Koble til din SQL Server forekomst.
5. Kjør skriptet for å opprette prosedyren i hoveddatabasen.
6. Gi utførelsestillatelser til aktuelle brukere.

Fordi sp_WhoIsActive er installert i master, er den tilgjengelig fra enhver databasekontekst.

5.2.2 Eksempler på grunnleggende bruk

Den enkleste måten å bruke sp_WhoIsActive på er:

EXEC sp_WhoIsActive;

Dette returnerer et resultatsett som viser alle aktive økter med spørringer, ventetyper, blokkeringsinformasjon og ressursbruk.

For et 10-sekunders utvalg som viser aktivitet i løpet av den perioden:

EXEC sp_WhoIsActive @delta_interval = 10;

Dette beregner deltaer for målinger som CPU og avlesninger, og viser hva som skjedde i løpet av disse 10 sekundene.

5.2.3 Avanserte parametere

sp_WhoIsActive støtter en rekke parametere for tilpasning:

• @filter: Filtrer resultater til bestemte økter, databaser eller pålogginger.
• @filtertype: Spesifiser hva filteret gjelder for (økt, database, pålogging osv.).
• @få_planer: Inkluder utførelsesplaner i resultatene (sett til 1).
• @get_locks: Vis detaljert låsinformasjon (satt til 1).
• @hent_transaction_info: Vis transaksjonsdetaljer (sett til 1).
• @sort_order: Sorter resultater etter ulike målinger (CPU, lesninger, varighet osv.).
• @destinasjonstabell: Sett inn resultater i en tabell for historisk sporing.

Eksempel som viser planer sortert etter CPU:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Bruk av systemlagrede prosedyrer

SQL Server inkluderer tradisjonelle lagrede prosedyrer for overvåking av aktivitet, selv om de gir mindre informasjon enn DMV-er eller Aktivitetsmonitor.

5.3.1 sp_who og sp_who2

sp_who-prosedyren viser grunnleggende informasjon om økten:

EXEC sp_who;

sp_who2-prosedyren gir litt mer detaljer:

EXEC sp_who2;

Begge prosedyrene viser økt-ID-er, påloggingsnavn, CPU-tid og blokkeringsinformasjon. De mangler imidlertid den omfattende detaljrikdommen som er tilgjengelig gjennom DMV-er eller Aktivitetsmonitor. De er mest nyttige for raske kontroller når du trenger minimal informasjon raskt.

5.3.2 Andre nyttige systemprosedyrer

Ytterligere systemprosedyrer for overvåking inkluderer:

• sp_lock: Viser låsinformasjon (utdatert; bruk sys.dm_tran_locks i stedet).
• sp_monitor: Viser statistikk om SQL Server aktivitet.
• sp_hjelp: Viser objektdefinisjoner og metadata.
• DBCC SQLPERF: Viser plassbruk og ventestatistikk for transaksjonsloggen.

5.4 Opprette tilpassede overvåkingsskript

For miljøer som krever spesifikk overvåking utover det Aktivitetsmonitor tilbyr, kan du bygge tilpassede løsninger ved hjelp av DMV-er.

5.4.1 Komplett skript tilsvarende aktivitetsmåler

Her er et omfattende skript som gjenskaper mesteparten av Aktivitetsmonitor-funksjonaliteten:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 Automatisere overvåking med SQL Agent-jobber

Du kan planlegge tilpassede overvåkingsskript ved hjelp av SQL Server Middel:

1. Opprett en tabell for å lagre overvåkingsresultater.
2. Endre overvåkingsskriptet ditt for å sette inn resultater i denne tabellen.
3. In SQL Server Ledelsestudio, utvid SQL Server Agent i Objektutforskeren.
4. Høyreklikk Jobb og velg Ny jobb.
5. Konfigurer jobben til å kjøre overvåkingsskriptet med jevne mellomrom.
6. Sett opp varsler eller rapporter basert på de innsamlede dataene.

Denne tilnærmingen muliggjør historisk sporing og trendanalyse som Aktivitetsmonitor ikke tilbyr.

6. Begrensninger og hensyn knyttet til aktivitetsmåleren

Selv om Aktivitetsmonitor er verdifull, hjelper det deg å bruke den på riktig måte og supplere den med andre verktøy når det er nødvendig.

6.1 Forstå overheadkostnadene for aktivitetsmåleren

Aktivitetsmonitor er ikke gratis – den bruker serverressurser for å samle inn og vise informasjon. Å forstå denne overheaden hjelper deg med å bruke den ansvarlig.

6.1.1 Innvirkning på serverressurser

Aktivitetsmonitor kjører spørringer mot system-DMV-er hver gang den oppdateres. Disse spørringene bruker CPU, genererer logiske lesninger og kan midlertidig holde låser på systemtabeller. På travle servere kan denne overheaden påvirke ytelsen.

Rutene Prosesser og Nylig dyre spørringer er spesielt dyre, ettersom de må skanne potensielt store DMV-er og hurtigbuffertabeller. På servere med tusenvis av hurtigbufrede spørreplaner kan det ta flere sekunder å oppdatere Nylig dyre spørringer.

Microsofts dokumentasjon advarer om at oppdateringsintervaller under 10 sekunder kan påvirke serverytelsen merkbart, spesielt på systemer som allerede er lastet inn.

6.1.2 Beste praksis for oppdateringsintervaller

Velg oppdateringsintervaller som passer for din situasjon:

• 1-5 sekunder: Kun for umiddelbar feilsøking av kritiske problemer på servere med lav belastning. Ikke la Aktivitetsmonitor kjøre i disse intervallene.
• 10 sekunder (standard): Rimelig for de fleste feilsøkingsscenarioer og generell overvåking.
• 30-60 sekunder: Bedre valg for produksjonsservere under tung belastning eller ved overvåking over lengre perioder.
• Kun manuell oppdatering: For situasjoner der du vil sjekke gjeldende status av og til uten kontinuerlig avspørring.

Lukk alltid Aktivitetsmonitoren når du er ferdig med å undersøke. Ikke la den kjøre kontinuerlig, spesielt ikke hvis den kjører flere ganger fra forskjellige brukere.

6.2 Problemer med gruppering av ventetyper

Aktivitetsmonitorens tilnærming til kategorisering av ventetider kan tilsløre viktig diagnostisk informasjon, samtidig som den forenkler visningen.

6.2.1 Hvordan aktivitetsmåleren grupperer ventetider

SQL Server sporer hundrevis av forskjellige ventetyper, som hver indikerer en spesifikk ressurs eller tilstand. Aktivitetsmonitor grupperer disse i brede kategorier som «Bufferlås», «Lås» og «Minne».

For eksempel inkluderer kategorien «Buffer Latch» PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX og flere andre spesifikke ventetyper. Selv om de alle er relatert til sidetilgang, har de forskjellige årsaker og løsninger.

Microsoft dokumenterer ikke nøyaktig hvilke ventetyper som tilordnes til hvilke kategorier, noe som gjør det vanskelig å forstå hva du egentlig ser.

6.2.2 Manglende ventetyper

Aktivitetsmonitoren viser ikke alle ventetyper. Mest bemerkelsesverdig er at den ofte utelater CXPACKET-ventinger, som indikerer parallell utførelse av spørringer. CXPACKET-ventinger er vanlige og vanligvis ikke problematiske, men å vite at de er til stede hjelper deg å forstå arbeidsbelastningens egenskaper.

Når Aktivitetsmonitor viser «Bufferlås» som din viktigste ventetid, men andre verktøy viser at CXPACKET dominerer, kommer avviket fra Aktivitetsmonitorens filtrerings- og grupperingslogikk.

6.2.3 Hvorfor spesifikke ventetyper er viktige

Det er viktig å vite den spesifikke ventetypen for feilsøking:

• PAGELATCH_EX: Indikerer ofte tempdb-konflikt på tildelingssider. Løsningen innebærer å legge til flere tempdb-datafiler.
• PAGELATCH_SH: Kan tyde på aktive sider i brukertabeller. Løsningen innebærer partisjonering eller omorganisering av indeksen.
• PAGELATCH_UP: Vanlig under oppdateringer. Kan tyde på normal drift snarere enn et problem.

Aktivitetsmonitoren grupperer alle disse under «Bufferlås», noe som gjør diagnosen vanskeligere. Verktøy som sp_WhoIsActive og DMV-spørringer viser spesifikke ventetyper.

6.3 Datanøyaktighet og aktualitet

Aktivitetsmåleren gir en visning i nær sanntid, men «nær» er det viktigste ordet. Å forstå datainnsamlingsmetoden hjelper deg med å tolke resultatene riktig.

6.3.1 Øyeblikksbilde kontra kontinuerlig overvåking

Aktivitetsmonitoren viser øyeblikksbilder tatt på bestemte tidspunkter ved hvert oppdateringsintervall. Hendelser som oppstår mellom øyeblikksbildene registreres ikke. Hvis en spørring kjører i 2 sekunder og du oppdaterer hvert 10. sekund, kan det hende du ser den én gang eller ikke i det hele tatt, avhengig av tidspunktet.

Dette betyr at Aktivitetsmonitor utmerker seg på å finne vedvarende problemer (blokkering av varige minutter, gjennomgående høy CPU), men kan overse forbigående problemer (korte vranglåser, sporadiske spørretopper).

6.3.2 Aggregering og utvalg

Ruten Nylig brukte dyre spørringer viser data som er samlet siden spørreplanene ble lagt i hurtigbufferen. To identiske spørringer med forskjellige parameterverdier vises som én rad hvis de deler en plan. Denne aggregeringen kan maskere problemer med bestemte parameterkombinasjoner (parametersniffingsproblemer).

Ventetider i ressursruten beregner rater ved å sammenligne øyeblikksbilder. Hvis ventestatistikken nullstilles mellom øyeblikksbilder (sjeldent, men mulig), kan de beregnede ratene være feil.

6.4 Når du IKKE skal bruke aktivitetsmåleren

Aktivitetsmonitoren er ikke passende for alle overvåkingsscenarier. Finn ut når alternative verktøy er bedre valg.

6.4.1 Krav til historisk analyse

Aktivitetsmonitor viser bare gjeldende eller nylig aktivitet. Den lagrer ikke historiske data. Hvis du trenger å analysere trender over dager eller uker, sammenligne gjeldende ytelse med grunnlinjer eller generere rapporter om ytelsesmønstre, er ikke Aktivitetsmonitor tilstrekkelig.

For historisk analyse, bruk SQL Servers innebygde ytelsesdashbord, utvidede hendelser med filmål eller tredjeparts overvåkingsløsninger.

6.4.2 Behov for detaljert ventestatistikk

Når du trenger presis informasjon om ventetype for avansert finjustering, gjør grupperingen og filtreringen i Aktivitetsmonitoren det utilstrekkelig. Bruk DMV-spørringer direkte eller sp_WhoIsActive i stedet.

For omfattende analyse av ventestatistikk, spør sys.dm_os_wait_stats direkte og filtrer ut godartede ventetider manuelt.

6.4.3 Hensyn knyttet til produksjonsserveren

På produksjonsservere under høy belastning kan overhead i Aktivitetsmonitor være problematisk. Flere databaseadministratorer bør ikke kjøre Aktivitetsmonitor samtidig på samme server.

For produksjonsovervåking bør du vurdere lette alternativer som planlagte DMV-øyeblikksbilder lagret i en overvåkingsdatabase, eller bruke skrivebeskyttet ruting for å overvåke sekundære replikaer i Always On-konfigurasjoner.

7. Beste fremgangsmåter for bruk av aktivitetsmåler

Ved å følge beste praksis sikrer du at du får maksimalt utbytte av Aktivitetsmonitoren samtidig som du minimerer negative konsekvenser for serverne dine.

7.1 Når du skal bruke aktivitetsmåleren

Aktivitetsmåleren er utmerket i spesifikke situasjoner. Bruk den når styrkene samsvarer med dine behov.

7.1.1 Problemer med ytelse i sanntid

Aktivitetsmonitoren er ideell når brukere opplever problemer for øyeblikket, og du må diagnostisere problemet umiddelbart. Sanntidsvisningen hjelper deg med å se hva som skjer akkurat nå.

Når du får en oppringning om at «applikasjonen er treg», bør du åpne Aktivitetsmonitoren. Du kan raskt finne ut om databasen er opptatt, blokkert eller inaktiv.

7.1.2 Undersøkelse av treghet i applikasjonen

Når et bestemt program slutter å reagere, hjelper Aktivitetsmonitor deg med å finne ut om databaseproblemer er årsaken. Filtrer Prosesser-ruten etter programnavn for å bare se programmets databaseaktivitet.

Hvis applikasjonen ikke viser noen databaseaktivitet mens brukere rapporterer problemer, ligger problemet et annet sted i stakken. Hvis du ser omfattende blokkering eller dyre spørringer, har du funnet synderen.

7.1.3 Raske helsesjekker

Aktivitetsmonitoren er et utmerket dashbord for raske helsesjekker under rutinemessig administrasjon. Åpne den, se på oversiktsgrafene, og bekreft at ingenting ser unormalt ut.

Denne overfladiske sjekken tar sekunder og kan avdekke problemer før de blir kritiske. Gjør det til en del av din daglige rutine.

7.2 Optimale konfigurasjonsinnstillinger

Å konfigurere Aktivitetsmonitoren på riktig måte forbedrer både nytten og ressursforbruket.

7.2.1 Anbefalte oppdateringsintervaller

Tilpass oppdateringsintervallet til formålet ditt:

• Aktiv feilsøking: 10 sekunder gir god responstid med rimelig overhead.
• Utvidet overvåking: 30–60 sekunder reduserer serverpåvirkningen under lengre observasjonsperioder.
• Diagnose av kritisk problem: 5 sekunder gir høy granularitet når hvert sekund teller, men bruk kort.
• Regelmessige helsesjekker: Manuell oppdatering (1 times intervall) når du ikke ser aktivt på.

Husk å lukke Aktivitetsmonitoren når du er ferdig. Å sette den til et langt intervall og glemme å gjøre det sløser med serverressurser.

7.2.2 Filtreringsstrategier

Bruk filtre for å fokusere på relevant informasjon og redusere kognitiv belastning:

• Filtrer prosesser etter Database for å bare se aktivitet mot bestemte databaser.
• Filtrer etter Login å spore en spesifikk brukers aktivitet.
• Filtrer etter Oppgavestatus = KJØRER for å skjule inaktive økter.
• Filtrer etter Søknad for å isolere trafikk fra bestemte programmer.
• Vis bare ikke-blanke felt i Blokkert av å bare se blokkerende situasjoner.

7.2.3 Kolonnevalg og sortering

Utvikle en systematisk tilnærming til gjennomgang av Aktivitetsmonitor-data:

1. Start med oversikt: Sjekk grafene for åpenbare topper eller avvik.
2. Sjekk prosesser for blokkering: Sorter etter økt-ID, og ​​se deretter etter verdier for blokkert av.
3. Gjennomgang av ressursventetider: Sorter etter kumulativ ventetid for å identifisere ressursflaskehalser.
4. Analyser dyre søk: Sorter etter ulike målinger (CPU, utførelse, lesninger) for å finne ulike problemtyper.
5. Bekreft med I/O-ruten: Bekreft om I/O-intensive spørringer korrelerer med høy diskaktivitet.

7.3 Integrasjon med andre verktøy

Aktivitetsmonitor fungerer best som en del av et bredere verktøysett i stedet for som en frittstående løsning.

7.3.1 Bruk med SQL Server Profiler

Aktivitetsmåler og SQL Server Profiler utfyller hverandre godt. Når du identifiserer en problematisk økt i Aktivitetsmonitor, høyreklikker du på den og velger Sporingsprosess i SQL Server Profiler.

Dette starter Profiler med filtre som allerede er konfigurert til å fange opp bare aktiviteten i den økten. Du ser den komplette sekvensen av utførte setninger, tidsinformasjon og feilmeldinger – detaljer som Aktivitetsmonitor ikke gir.

For å lære mer om SQL Server Profileringsfunksjoner og avanserte sporingsteknikker, se vår omfattende SQL Server Profiler-guide.

7.3.2 Supplering med utvidede hendelser

Utvidede hendelser tilbyr detaljert overvåking med lav administrasjonskostnad som fanger opp informasjon som Aktivitetsmonitor går glipp av. Opprett utvidede hendelsesøkter for å spore spesifikke hendelser som vranglåser, langvarige spørringer eller overdreven rekompilering.

Bruk Aktivitetsmonitor for umiddelbar undersøkelse og Utvidede hendelser for kontinuerlig overvåking og historisk analyse. De to verktøyene dekker ulike behov.

For å lære mer om SQL Server Utvidede hendelsesfunksjoner og avanserte overvåkingsteknikker, se vår omfattende SQL Server Utvidet arrangementsguide.

7.3.3 Tredjeparts overvåkingsløsninger

Kommersielle verktøy som SolarWinds Database Performance Analyzer, Redgate SQL Monitor og Quest Spotlight tilbyr funksjoner som Activity Monitor mangler: varsling, historisk trendanalyse, kapasitetsplanlegging og automatisert diagnostikk.

Disse verktøyene er verdifulle tillegg til Aktivitetsmonitor, ikke erstatninger. Aktivitetsmonitor er fortsatt nyttig for raske kontroller og undersøkelser selv når sofistikerte overvåkingsverktøy er tilgjengelige.

7.4 vanlige feil å unngå

Å forstå vanlige feil i Aktivitetsmonitoren hjelper deg med å bruke den mer effektivt.

7.4.1 La aktivitetsmåleren kjøre kontinuerlig

Den vanligste feilen er å åpne Aktivitetsmonitor og la den kjøre på ubestemt tid. Dette sløser med serverressurser og gir liten verdi siden du ikke aktivt ser på.

Lukk Aktivitetsmonitoren når du ikke bruker den aktivt. Hvis du trenger kontinuerlig overvåking, bør du i stedet implementere en skikkelig overvåkingsløsning med planlagt datainnsamling.

7.4.2 Overdreven avhengighet av aktivitetsmåleren alene

Aktivitetsmonitor gir ett perspektiv på serverhelse. Ikke stol utelukkende på den. Suppler med Windows Performance Monitor for OS-nivåmålinger, utvidede hendelser for detaljert sporing og analyse av utførelsesplaner for spørrejustering.

Aktivitetsmonitor hjelper deg med å identifisere problemer, men å løse dem krever ofte flere verktøy og dypere analyse.

Lær mer om SQL Server ytelsesmåler i vår komplett guide.

7.4.3 Ignorering av historiske trender

Aktivitetsmonitoren viser gjeldende status, men ytelsesproblemer har ofte mønstre som bare er synlige over tid. Implementer historisk datainnsamling slik at du kan sammenligne gjeldende målinger med grunnlinjer og identifisere trender.

Uten historisk kontekst er det ikke sikkert at du er klar over at dagens «normale» CPU-bruk er 30 % høyere enn forrige måneds grunnlinje, noe som indikerer en gradvis forringelse.

8. Feilsøking av problemer med aktivitetsmåleren

Aktivitetsmåleren opplever noen ganger problemer. Å vite hvordan man feilsøker disse problemene forhindrer frustrasjon.

8.1 Aktivitetsmåleren åpnes ikke eller viser ingen data

Når Aktivitetsmonitor åpnes, men viser tomme ruter eller ikke åpnes i det hele tatt, kan flere faktorer være ansvarlige.

8.1.1 Problemer med tillatelser

Den vanligste årsaken til problemer med Aktivitetsmonitoren er utilstrekkelige tillatelser. Slik bekrefter og løser du dette:

1. Sjekk tillatelsene dine på servernivå:

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Hvis ingen rader returneres, mangler du tillatelse til å VIS SERVERSTATUS.
3. Be en serveradministrator om å gi det:

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Lukk og åpne Aktivitetsmonitoren på nytt etter at tillatelser er gitt.

8.1.2 Problemer med versjonskompatibilitet

Bruker en gammel versjon av SQL Server Management Studio for å koble til en nyere SQL Server versjonen kan forårsake feil i Aktivitetsmonitoren. Verktøyet forstår kanskje ikke nye ventetyper eller systemvisningskolonner.

Bruk alltid SSMS-versjon som samsvarer med eller er nyere enn din SQL Server versjon. Microsoft tilbyr den nyeste SSMS som gratis nedlasting separat fra SQL Server selv.

8.1.3 Problemer med brannmur og nettverk

Aktivitetsmåleren krever tilkobling til SQL Server forekomst på standardporter (1433 som standard). Hvis du kan koble til via Object Explorer, men Aktivitetsmonitor mislykkes, kan det hende at brannmurregler blokkerer bestemte tilkoblinger.

Bekreft at klienten din kan nå SQL Server maskinen på alle nødvendige porter. Sjekk både Windows-brannmuren og eventuelle nettverksbrannmurer mellom klienten og serveren.

8.2 Aktivitetsmåler permanent satt på pause

Et vanlig problem, spesielt i SQL Server 2019, åpnes Aktivitetsmonitoren i pausetilstand og nekter å gjenopptas.

8.2.1 Forståelse av pausetilstanden

Når Aktivitetsmonitoren settes på pause, viser alle rutene statusen «Pauset» med en gjenopptaksknapp som kanskje ikke fungerer. Dette hindrer deg i å se serveraktivitet.

Pauset tilstand oppstår vanligvis på grunn av tillatelsesproblemer, begrensninger i eksterne tilkoblinger eller feil i SSMS-versjonen, snarere enn en forsettlig pausehandling.

8.2.2 Vanlige årsaker

Aktivitetsmonitoren kan gå inn i permanent pausetilstand på grunn av:

• Mangler tillatelse til å VIS SERVERSTATUS i nyere ruter som er lagt til i det siste. SQL Server versjoner
• Eksterne tilkoblinger deaktivert på SQL Server f.eks
• Autentiseringsfeil for spesifikke systemforespørsler
• Feil i spesifikke SSMS-bygg, spesielt 18.0 til 18.3
• Tilkoblingsproblemer mellom klient og server

8.2.3 Løsningstrinn

Slik løser du problemer med pausetilstanden til Aktivitetsmonitoren:

1. Oppdater SSMS: Last ned og installer det siste SQL Server Management Studio-versjonen fra Microsofts nettsted. Mange feil med midlertidig stans ble rettet i senere utgivelser.
2. Bekreft tillatelser: Sørg for at du har tillatelsene VIS SERVERSTATUS og VIS ALLE DEFINITIONER.
3. Sjekk eksterne tilkoblinger: Bekreft at SQL Server instansen tillater eksterne tilkoblinger:

   EXEC sp_configure 'remote access';
   

   Hvis verdien er 0, be en administrator om å aktivere den.

4. Start SSMS på nytt: Noen ganger er det bare å lukke alle vinduer og starte på nytt SQL Server Management Studio løser problemet.
5. Koble til med Windows-autentisering: Hvis du bruker SQL-autentisering, kan du prøve Windows-autentisering i stedet, da det noen ganger omgår problemer med pausering relatert til autentisering.

8.3 Ytelsesproblemer ved bruk av aktivitetsmåler

Hvis Aktivitetsmonitoren i seg selv blir treg eller forårsaker forringelse av serverytelsen, er det nødvendig med justering.

8.3.1 Redusere overvåkingskostnader

Slik minimerer du virkningen fra Aktivitetsmåleren:

1. Øk oppdateringsintervallet til 30 sekunder eller 1 minutt.
2. Lukk ruter du ikke bruker aktivt ved å klikke på skjul-knappen.
3. Når ruter er skjult, spør ikke Aktivitetsmonitor etter data for dem.
4. Unngå å kjøre flere Aktivitetsmonitor-instanser samtidig.
5. Lukk Aktivitetsmonitoren helt når du ikke aktivt undersøker problemer.

8.3.2 Alternative metoder for lett overvåking

Hvis Aktivitetsmonitoren er for ressurskrevende for miljøet ditt, bør du vurdere alternativer:

• Spør DMV-er direkte: Skriv spesifikke T-SQL-spørringer som bare henter informasjonen du trenger.
• Bruk sp_WhoIsActive: Denne lagrede prosedyren er svært optimalisert og har vanligvis lavere overhead enn Aktivitetsmonitor.
• Implementer prøvetaking: Planlegg SQL Agent-jobber som tar øyeblikksbilder av DMV-data med jevne mellomrom, og lagrer resultater i tabeller for senere analyse.
• Overvåk sekundære replikaer: In Alltid på tilgjengelighetsgrupper, kjør Aktivitetsmonitor mot en lesbar sekundær i stedet for den primære.

8.4 Unøyaktig eller manglende informasjon

Noen ganger viser Aktivitetsmonitoren informasjon som virker feil eller ufullstendig.

8.4.1 Verifisering av data med DMV-er

Når resultater fra Aktivitetsmonitoren virker mistenkelige, kan du bekrefte dem ved å spørre de underliggende DMV-ene direkte. Hvis for eksempel Prosesser-ruten ikke viser noen blokkering, men brukere rapporterer det, kan du spørre:

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Hvis denne spørringen viser blokkering som Aktivitetsmonitoren gikk glipp av, har du bekreftet et skjermproblem.

8.4.2 Forståelse av tidspunkt for dataoppdatering

Husk at Aktivitetsmonitor viser øyeblikksbilder. En spørring som kjørte mellom oppdateringsintervaller vil ikke vises i Nylig dyre spørringer med mindre utførelsesplanen forblir i hurtigbufferen.

På samme måte gjenspeiler ventestatistikk i Ressursventetider-ruten akkumulering siden siste øyeblikksbilde. Arbeidsbelastninger som endrer seg raskt kan vise forskjellige mønstre ved hver oppdatering.

9. Avanserte aktivitetsmålerteknikker

Erfarne databaseadministratorer bruker Aktivitetsmonitor på sofistikerte måter for å utvinne maksimal diagnostisk verdi.

9.1 Kombinere flere ruter for rotårsaksanalyse

Den virkelige kraften til Aktivitetsmonitor kommer til syne når du korrelerer informasjon på tvers av flere ruter for å forstå komplekse ytelsesproblemer.

9.1.1 Korrelering av ventetider med prosesser

Når ruten Ressursventinger viser lange ventetider i en kategori, bruker du ruten Prosesser til å identifisere hvilke økter som opplever disse ventetidene:

1. Legg merke til ventekategorien med høy kumulativ ventetid (f.eks. «Lås»).
2. Bytt til Prosesser-ruten.
3. Sorter etter Ventetype for å gruppere økter etter gjeldende ventetid.
4. Se etter økter som viser ventetyper i problematisk kategori.
5. For disse øktene, undersøk Vente ressurs kolonnen for å se hvilke databaseobjekter som er involvert.
6. Høyreklikk og velg Detaljer for å se spørreteksten.

Denne korrelasjonen hjelper deg med å gå fra «vi har låsevents» til «denne spesifikke spørringen venter på låser på denne tabellen».

9.1.2 Koble dyre spørringer til I/O-problemer

Når ruten Data File I/O viser høy diskaktivitet på en bestemt database:

1. Legg merke til hvilke databasefiler som har høye lese- eller skrivehastigheter på MB/sek.
2. Bytt til nylige dyre søk.
3. Sorter etter Fysiske avlesninger/sek for å identifisere spørringer som leser mye fra disken.
4. Filtrer eller identifiser visuelt spørringer som kjører mot databasen med høy I/O.
5. Undersøk utførelsesplanene for disse spørringene for tabellskanninger eller manglende indekser som forårsaker overdreven I/O.

Denne flerpanelsanalysen kobler symptomer (høy disk-I/O) med årsaker (spesifikke ineffektive spørringer).

9.2 Bruk av aktivitetsmåler for kapasitetsplanlegging

Selv om Aktivitetsmonitor ikke lagrer historiske data, kan du bruke den strategisk til observasjoner av kapasitetsplanlegging.

9.2.1 Identifisering av bruksmønstre ved høye forbruksmengder

Overvåk serveraktivitet på forskjellige tider av døgnet for å identifisere bruksmønstre:

1. Åpne Aktivitetsmonitoren i kjente rushtider.
2. Legg merke til toppverdiene i grafen for % prosessortid.
3. Registrer det maksimale antallet ventende oppgaver.
4. Observer batchforespørsler/sek i rushtiden.
5. Dokumenter de travleste databasene i Prosesser-ruten.
6. Gjenta utenom rushtiden for sammenligning.

Hvis prosessortiden i topptiden konsekvent overstiger 80 %, nærmer du deg CPU-kapasitetsgrensene. På samme måte indikerer økende ventetid økende ressurskonkurranse.

9.2.2 Analyse av ressurstrender

Selv om Aktivitetsmonitor viser gjeldende status, kan du bruke den til stikkprøvekontroll av trender ved å registrere viktige beregninger over tid:

• Ta skjermbilder av oversiktsruten på samme tid hver dag
• Registrer toppverdier fra hver graf
• Sammenlign uke for uke for å identifisere veksttrender
• Vær oppmerksom på gradvise økninger i gjennomsnittlig prosessortid eller I/O-hastigheter

Denne manuelle trendanalysen supplerer mer sofistikerte overvåkingsløsninger og bidrar til å rettferdiggjøre kapasitetsutvidelse.

9.3 Dokumentasjon av ytelsesgrunnlinjer

Å etablere grunnleggende ytelsesmålinger hjelper deg med å gjenkjenne når ytelsen forringes.

9.3.1 Registrering av grunnlinjemålinger

I perioder med kjent god ytelse, dokumenter Aktivitetsmonitor-målinger:

1. Åpne Aktivitetsmonitoren under normal forretningsdrift (ikke i travle timer eller utenom travle dager).
2. Verdier i ruten Oversikt over oppføringer:
   • Typisk % Prosessor Tidsområde
   • Gjennomsnittlig antall ventende oppgaver
   • Normal database I/O-hastighet
   • Typiske batchforespørsler/sek
3. Merk deg kategoriene i Ressursventetider som viser lengst ventetid.
4. Dokumenter antallet aktive prosesser vanligvis i Prosesser-ruten.
5. Registrer representative spørrekjøringsmålinger fra nylig dyre spørringer.

Ta vare på denne grunnleggende dokumentasjonen for fremtidig referanse når du undersøker ytelsesproblemer.

9.3.2 Sammenligning av nåværende vs. grunnlinjeytelse

Når det oppstår ytelsesproblemer, sammenlign gjeldende Aktivitetsmonitor-avlesninger med den dokumenterte grunnlinjen:

• Er prosessortiden betydelig høyere enn grunnlinjen? Fokuser på CPU-intensive spørringer.
• Er ventetiden for oppgaver 2–3 ganger høyere enn grunnlinjen? Undersøk ventetidene for ressurser.
• Er I/O betydelig høyere? Sjekk ruten for datafil-I/O og dyre spørringer.
• Er antall batchforespørsler lavere enn grunnlinjen i rushtiden? Se etter blokkering eller tilkoblingsproblemer.

Denne sammenligningen hjelper deg med å identifisere hva som er endret og fokusere feilsøkingsarbeidet på riktig måte.

9.4 Opprette tilpassede overvåkingsarbeidsflyter

Utvikle systematiske arbeidsflyter for vanlige etterforskningsscenarier for å sikre grundig og repeterbar analyse.

9.4.1 Steg-for-steg-undersøkelsesprosess

Når brukere rapporterer ytelsesproblemer, følg en konsekvent arbeidsflyt:

1. Rask helsesjekk: Åpne Aktivitetsmonitoren og skann grafene i Oversiktsruten for åpenbare avvik.
2. Sjekk for blokkering: Utvid Prosesser-ruten, filtrer etter Ikke-tomme felt i Blokkert av-kolonnen.
3. Identifiser ressurskonflikter: Se gjennom ruten Ressursventinger sortert etter ventetid.
4. Finn dyre søk: Undersøk nylige dyre spørringer sortert etter CPU, deretter kjøringer og deretter lesninger.
5. Korreler I/O-mønstre: Kryssreferer dyre spørringer med aktivitet i datafil-I/O-ruten.
6. Dokumentfunn: Ta skjermbilder og registrer relevante økt-ID-er, ventetyper og spørringsdetaljer.
7. Dypdykk: Bruk Profiler-spor, analyse av utførelsesplaner og DMV-spørringer for detaljert undersøkelse av identifiserte problemer.

9.4.2 Kriterier for eskalering

Etabler kriterier for når problemer skal eskaleres kontra videre etterforskning:

• Eskaler umiddelbart: Blokkeringskjeder som varer i >5 minutter, prosessortid på 100 % i >2 minutter, kritiske systemprosesser viser SUSPENDED-tilstand.
• Eskaler med analyse: Gjentakende dyre spørringer som bruker >50 % av CPU-en, gjennomgående høye I/O-responstider >50 ms, minnetildelinger mislykkes gjentatte ganger.
• Undersøk videre: Midlertidig ventetid som løses i løpet av minutter, spørringer med suboptimale planer, men akseptabel ytelse, mindre blokkering <30 sekunders varighet.

10. Aktivitetsmåler i forskjellige SQL Server versjoner

Aktivitetsmonitoren har utviklet seg på tvers av SQL Server versjoner, der hver utgivelse bringer forbedringer og av og til nye problemer.

10.1 Aktivitetsmåler i SQL Server 2008 og senere

SQL Server 2008 introduserte det moderne Aktivitetsmonitor-designet som stort sett er uendret i dag.

10.1.1 Nye funksjoner introdusert i SQL Server 2008

Ocuco SQL Server Den nye versjonen av Aktivitetsmonitoren i 2008 førte til betydelige forbedringer:

• Grafisk dashbord med sanntidsdiagrammer i oversiktsruten
• Utvidbart/skjulbart rutegrensesnitt som erstatter den gamle rutenettvisningen
• Ruten Nylige dyre spørringer som viser samlede ytelsesdata for spørringen
• Datafil I/O-rute for overvåking av diskaktivitet per fil
• Forbedret ressursventepanel med ventekategorisering
• Høyreklikk på kontekstmenyer for prosesshandlinger som å avslutte økter og starte Profiler
• Konfigurerbare oppdateringsintervaller fra 1 sekund til 1 time

Disse endringene forvandlet Aktivitetsmonitor fra en enkel prosessliste til et omfattende overvåkingsdashbord.

10.1.2 Endringer fra SQL Server 2005

SQL Server Aktivitetsmonitoren fra 2005 var langt mer begrenset:

• Tilgjengelig via Administrasjonsmappen i Objektutforsker i stedet for verktøylinjen
• Enkelt rutenett som viser prosessliste med grunnleggende informasjon
• Ingen grafiske diagrammer eller flere ruter
• Ingen dyre spørringer eller I/O-overvåking
• Begrenset informasjon om ventestatistikk

Redesignet i 2008 representerte en fullstendig nytolkning snarere enn en trinnvis forbedring.

10.2 Aktivitetsmåler i SQL Server 2014/2016

SQL Server 2014 og 2016 gjorde trinnvise forbedringer av Aktivitetsmonitorens underliggende datainnsamling, men få visuelle endringer.

10.2.1 Forbedringer og forbedringer

Viktige forbedringer i disse versjonene inkluderte:

• Bedre ytelse ved overvåking av servere med tusenvis av hurtigbufrede planer
• Forbedrede filtreringsmuligheter i Prosesser-ruten
• Forbedret nøyaktighet i aggregering av ventestatistikk
• Bedre håndtering av kolonnesortering og filtrering med store resultatsett
• Mer effektive DMV-spørringer reduserer overvåkingskostnader

Kjernegrensesnittet forble konsistent med SQL Server 2008, og opprettholder kjennskap til administratorer.

10.3 Aktivitetsmåler i SQL Server 2019/2022

Nylig SQL Server versjoner fortsetter utviklingen av Aktivitetsmonitor med fokus på ytelse og stabilitet.

10.3.1 Nyeste funksjoner og muligheter

SQL Server Aktivitetsmåleren for 2019 og 2022 inkluderer:

• Støtte for nye ventetyper introdusert i disse versjonene
• Forbedret gjengivelsesytelse i SSMS ved bruk av WPF-teknologi
• Bedre håndtering av et stort antall aktive økter
• Forbedret kompatibilitet med skybaserte SQL-plattformer
• Mer nøyaktige CPU- og I/O-målinger

10.3.2 Kjente problemer i nyere versjoner

SQL Server 2019 introduserte flere feil i Aktivitetsmonitoren:

• Permanent pausetilstand: Aktivitetsmåleren går ofte i pausemodus og fortsetter ikke, spesielt i SSMS 18.0–18.3. Rettet i senere SSMS-versjoner.
• Feil med fjerntilkobling: Enkelte konfigurasjoner hindrer Aktivitetsmonitor i å åpnes på eksterne instanser. Midlertidige løsninger inkluderer aktivering av spesifikke sporingsflagg eller bruk av nyere SSMS-bygg.
• Tillatelsesproblemer: Nye systemvisninger krever ytterligere tillatelser som ikke er tydelig dokumentert, noe som forårsaker tomme skjermer selv med VIS SERVERSTATUS.

Bruk alltid den nyeste SSMS-versjonen når du arbeider med SQL Server 2019 og 2022 for å unngå disse problemene.

11. Praktiske brukstilfeller og eksempler

Eksempler fra den virkelige verden viser hvordan man bruker Aktivitetsmonitor effektivt i vanlige feilsøkingsscenarioer.

11.1 Casestudie: Diagnostisering av en treg webapplikasjon

Et utviklingsteam rapporterer at webapplikasjonen deres har blitt uakseptabelt treg, med sideinnlastinger som tar 20–30 sekunder i stedet for de vanlige 2–3 sekundene.

11.1.1 Innledende undersøkelse med oversiktsrute

Åpne Aktivitetsmonitoren og undersøk Oversikt-panelet:

1. Grafen for % prosessortid viser en CPU-bruk på 85–95 %, betydelig høyere enn den normale grunnlinjen på 30–40 %.
2. Ventetid varierer mellom 10–20 oppgaver, mot en normal grunnlinje på 0–3.
3. Database I/O viser moderat aktivitet rundt 50 MB/s.
4. Batchforespørsler/sek er lavere enn forventet på 100/sek, mot typiske 300–400/sek i arbeidstiden.

Dette mønsteret tyder på en CPU-flaskehals med ressurskonflikt som forårsaker redusert gjennomstrømning. Serveren jobber hardt, men behandler ikke mange forespørsler.

11.1.2 Identifisering av problematisk spørring

Utvid ruten Nylige dyre spørringer og sorter etter Utførelser/min:

1. Den øverste spørringen viser 15 000 utførelser per minutt.
2. Høyreklikk og velg Rediger spørretekst å undersøke spørringen.
3. Spørringen er en enkel SELECT-setning som henter en enkelt brukerpost: SELECT * FROM Users WHERE UserId = @UserId.
4. Denne spørringen skal ikke kjøres 15 000 ganger per minutt ved normal bruk av programmet.

Høyreklikk på spørringen og velg Vis utførelsesplanPlanen viser en tabellskanning på Brukere-tabellen med en advarsel om en manglende indeks i Bruker-ID-kolonnen.

Filtrer Prosesser-ruten etter program for å bare vise webapplikasjonens tilkoblinger. Flere økter viser at den samme spørringen kjører gjentatte ganger.

11.1.3 Løsning og verifisering

Problemet stammer fra to ting: overdreven utførelse av spørringer og en manglende indeks. Løsningstrinn:

1. Opprett den manglende indeksen:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Kontakt utviklingsteamet om de overdrevne utføringene. Undersøkelsen avdekker et N+1-spørringsproblem i applikasjonskoden der en løkke henter brukerdetaljer for hvert element i en liste.
3. Endre applikasjonen å gruppere brukeroppslagene i én enkelt spørring ved hjelp av en IN-klausul eller en tabellverdiparameter.
4. Bekreft løsningen ved å overvåke Aktivitetsmonitoren etter utrulling. CPU-bruken faller til 35–40 %, antall kjøringer per minutt reduseres til 200–300, og applikasjonsresponstiden går tilbake til det normale.

11.2 Casestudie: Løsning av et blokkeringsproblem

Brukere rapporterer at ordreregistreringssystemet med jevne mellomrom fryser i 30–60 sekunder før det gjenopptar normal drift.

11.2.1 Oppdage blokkeringskjeden

Åpne Aktivitetsmonitor under en av disse frysehendelsene og utvid Prosesser-ruten:

1. Sorter etter Øktnummer for å se alle øktene organiserte.
2. Flere økter viser verdier i Blokkert av kolonne, alle peker til økt-ID 73.
3. Økt 73 viser '1' i Hodeblokker kolonne, som bekrefter at det er den underliggende årsaken.
4. Ocuco Ventetype For blokkerte økter vises LCK_M_X, som indikerer at de venter på eksklusive låser.
5. Ocuco Vente ressurs Kolonnen viser at blokkeringen er på ordretabellen.

11.2.2 Analyse av årsaken

Høyreklikk på Økt 73 og velg Detaljer for å se kommandoen:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Denne oppdateringen er en del av en batchbehandlingsjobb som kjører hver time. Kontrollerer Login Kolonnen bekrefter at økten tilhører kontoen for batchbehandlingstjenesten.

Spørringen holder låser på ordretabellen mens den behandler tusenvis av ordrer. Ventetid for blokkerte økter øker jevnt og trutt, noe som bekrefter at denne langvarige operasjonen er problemet.

11.2.3 Implementering av løsningen

Kortsiktig løsning:

1. Dokumentdetaljer for økt 73, inkludert spørretekst og varighet.
2. La oppdateringen fullføres naturlig, siden det er legitim batchbehandling.
3. Etter at det er fullført, bekreft at blokkerte økter er fjernet og at normal drift gjenopptas.

Langsiktige løsninger implementert:

1. Planlegg batchjobben på nytt å kjøre utenom rushtiden (2–4 i stedet for i arbeidstiden).
2. Endre batchbehandlingen å oppdatere ordrer i mindre grupper på 100 poster om gangen, og dermed frigjøre låser mellom grupper.
3. Legg til en indeks i OrderId-kolonnen for å fremskynde oppdateringsoperasjonen.
4. Vurder SNAPSHOT-isolering for leseoperasjoner for å redusere blokkeringspåvirkningen.

11.3 Casestudie: Identifisering av overdreven kjøring av spørringer

Databaseovervåking viser at CPU-bruken gradvis har økt den siste måneden, men det har ikke skjedd noen åpenbare endringer i applikasjonskoden.

11.3.1 Oppdage antall unormale henrettelser

Åpne Aktivitetsmonitor og undersøk ruten Nylige dyre søk:

1. Sorter etter Henrettelser/min for å se de hyppigst utførte spørringene.
2. Den øverste spørringen viser 37 000 utførelser per minutt – langt høyere enn noen annen spørring.
3. Høyreklikk og velg Rediger spørretekst.
4. Spørringen henter informasjon om produktkategori:

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Denne enkle spørringen skal være rask og mellomlagrbar, men den kjøres titusenvis av ganger i minuttet.

11.3.2 Sporing til applikasjonskode

I Prosesser-ruten finner du økter som kjører denne spørringen:

1. Legg merke til Søknad Kolonnen viser «ProductCatalogService».
2. Høyreklikk på en av disse øktene og velg Sporingsprosess i SQL Server Profiler.
3. SQL Profiler avslører at spørringen kjøres gjentatte ganger i rask rekkefølge med forskjellige CategoryId-verdier.
4. Kontakt utviklingsteamet som administrerer ProductCatalogService for kodegjennomgang.

Kodegjennomgang avslører problemet: en nylig endring henter produktlister med kategorier. For hvert produkt i resultatsettet (ofte 1,000+ produkter) foretar koden et separat databasekall for å hente kategoriinformasjon – et klassisk N+1-spørreproblem.

11.3.3 Optimalisering av applikasjonen

Implementer en skikkelig løsning:

1. Endre søknadsspørringen for å bruke en JOIN som henter produkter og deres kategorier i et enkelt databasekall:

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. Distribuer den oppdaterte koden og overvåk Aktivitetsmonitor.
3. Bekreft rettelsen: Utførelser per minutt for kategorispørringen faller fra 37 000 til under 100, og den totale CPU-bruken reduseres med 40 %.
4. Dokumenter lærdommen og del med utviklingsteamet for å forhindre lignende problemer i fremtidige kodeendringer.

12. Oppdag potensiell databasekorrupsjon

Selv om Aktivitetsmonitor ikke er spesielt utviklet for å oppdage databasefeil, kan visse mønstre i visningen tyde på underliggende problemer med feil som krever videre undersøkelse.

12.1 Symptomer på potensiell databasekorrupsjon

Hvis det finnes en skadet database og den blir åpnet, kan du av og til se:

1. I prosessruten:

• Økter sitter fast i SUSPENDED-tilstand med uvanlige ventetyper
• Prosesser som viser feiltilstander
• Søk som mislykkes gjentatte ganger

2. I ruten Ressursventing:

• Uvanlige I/O-relaterte ventetyper som kan indikere diskproblemer (selv om dette mer sannsynlig indikerer maskinvareproblemer snarere enn logisk korrupsjon)

3. I nylige dyre søk:

• Spørringer med unormalt høye fysiske lesninger hvis de gjentatte ganger prøver å lese ødelagte sider

12.2 Videre sjekk med DBCC CHECKDB

Når Aktivitetsmonitor viser symptomer som tyder på potensiell korrupsjon, bør du umiddelbart kjøre DBCC CHECKDB for å bekrefte databaseintegriteten. Denne kommandoen skanner alle databasesider, validerer sjekksummer og kontrollerer for logiske konsistensfeil.

Hvis du vil vite mer om hvordan du bruker DBCC CHECKDB til å sjekke og rette feil i databasen, kan du se vår omfattende DBCC CHECKDB-guide.

12.3 Reparasjon med profesjonelt verktøy

Hvis DBCC CHECKDB bekrefter databasefeil, har du flere alternativer for reparasjon:

• Den foretrukne tilnærmingen er å gjenopprette fra en sikkerhetskopi som er kjent som fungerende. Se vår omfattende guide om hvordan du sikkerhetskopierer og gjenoppretter SQL Server databaser.
• Ved mindre skader kan DBCC CHECKDB med REPAIR_REBUILD løse problemene.
• For kritiske databaser uten nylige sikkerhetskopier, profesjonell SQL-gjenopprettingsprogramvare og tjenester kan ofte gjenopprette data som innebygde reparasjonsalternativer ikke kan.

13. konklusjon

SQL Server Aktivitetsmonitor er et uvurderlig verktøy for databaseadministratorer, som gir umiddelbar innsikt i serverytelse og hjelper med å diagnostisere problemer raskt og effektivt.

13.1 Sammendrag av nøkkelpunkter

Gjennom denne veiledningen har vi utforsket hvordan Aktivitetsmonitor hjelper deg med å forstå og feilsøke SQL Server opptreden:

• Aktivitetsmonitor gir sanntidsinnsikt i prosesser, ventinger, spørringer og I/O gjennom et organisert, grafisk grensesnitt.
• De fem rutene – Oversikt, Prosesser, Ressursventetider, Datafil-I/O og Nylig brukte dyre spørringer – tilbyr hver unike perspektiver på serveraktivitet.
• Vanlige feilsøkingsscenarier som overdreven kjøring av spørringer, blokkeringskjeder og høy CPU-bruk blir håndterbare med systematisk undersøkelse av Aktivitetsmonitor.
• Selv om Aktivitetsmonitor er kraftig, har den begrensninger, inkludert mangel på historiske data, gruppering av ventetyper og overvåkingskostnader som påvirker anvendeligheten.
• Å supplere Aktivitetsmonitoren med DMV-spørringer, sp_WhoIsActive, Extended Events og potensielt tredjepartsverktøy skaper en omfattende overvåkingsstrategi.
• Ved å følge beste praksis for oppdateringsintervaller, lukke Aktivitetsmonitor når den ikke er i bruk, og kombinere flere ruter for korrelasjon, maksimeres verdien samtidig som effekten minimeres.

13.2 Aktivitetsmåler som en del av verktøysettet ditt

Aktivitetsmonitoren bør fungere som ditt første responsverktøy for ytelsesundersøkelser, ikke ditt eneste verktøy. Styrken ligger i å gi umiddelbar oversikt under aktiv feilsøking, slik at du raskt kan avgjøre om databasen er flaskehalsen og identifisere hvilke spesifikke aspekter som trenger dypere undersøkelse.

Tenk på Aktivitetsmonitor som et analogt dashbord i bilen din – det forteller deg umiddelbart hvis noe er galt og hjelper deg med å identifisere det generelle problemet. Akkurat som bilens dashbord ikke forteller deg nøyaktig hvorfor motorlampen lyser, peker Aktivitetsmonitor deg mot problemer uten alltid å avsløre hele rotårsaken. Den dypere analysen krever ytterligere verktøy og ekspertise.

Integrer Aktivitetsmonitor i et bredere verktøysett som inkluderer analyse av utførelsesplaner, sporing av ventestatistikk, historiske overvåkingsløsninger og beste praksis for ytelse. Bruk det sammen med riktige indekseringsstrategier, teknikker for spørringsoptimalisering og kapasitetsplanlegging.

13.3 Fortsette læringsreisen din

Å mestre Aktivitetsmonitor er bare ett steg i å bli en effektiv databaseadministrator. Fortsett å bygge opp ferdighetene dine ved å:

• Lære å tolke utførelsesplaner og identifisere ineffektive operasjoner
• forståelse SQL Server ventestatistikk og dens implikasjoner
• Studerer indeksdesign og optimaliseringsteknikker
• Utforske SQL Serverarkitekturen og hvordan den behandler spørringer
• Øve på systematiske feilsøkingsmetoder
• Bygge erfaring med utvidede hendelser for detaljert sporing
• Forståelse av transaksjonsisolasjonsnivåer og deres ytelsespåvirkning

Hver ytelsesundersøkelse med Aktivitetsmonitor lærer deg noe nytt om hvordan SQL Server fungerer og hvordan applikasjoner samhandler med databaser. Dokumenter funnene dine, del kunnskap med kolleger og bygg et bibliotek med løsninger for vanlige problemer.

13.4 Ytterligere ressurser

Utvid kunnskapen din med disse verdifulle ressursene:

• Åpne Activity Monitor i SQL Server Management Studio (SSMS) : Offisielt SQL Server dokumentasjon om hvordan du åpner Aktivitetsmonitor i SQL Server Ledelsestudio (SSMS).
• Aktivitetsmonitor : Offisielt SQL Server dokument om hvordan du bruker Aktivitetsmonitor.

14. Ofte stilte spørsmål (FAQ)

Spørsmål: Hva er? SQL Server Activity Monitor?

A: SQL Server Aktivitetsmonitor er et innebygd verktøy i SQL Server Management Studio som viser sanntidsinformasjon om prosesser som kjører på en SQL Server instans og deres innvirkning på serverressurser. Den tilbyr et grafisk dashbord med fem ruter som viser ulike aspekter ved serveraktivitet, inkludert prosessorbruk, ventende oppgaver, I/O-hastigheter, aktive økter og dyre spørringer.

Spørsmål: Hvordan åpner jeg Aktivitetsmonitor i SSMS?

A: Du kan åpne Aktivitetsmonitoren på fire måter: (1) Klikk på Aktivitetsmonitor-ikonet i SSMS-verktøylinjen, (2) Høyreklikk på SQL Server forekomstnavn i Object Explorer og velg Aktivitetsmonitor, (3) Trykk Ctrl + andre + A, eller (4) Konfigurer SSMS til å starte det automatisk via verktøy -> alternativer -> Miljø -> oppstart.

Spørsmål: Hvilke tillatelser trenger jeg for å bruke Aktivitetsmonitor?

A: Du trenger SE SERVERSTATUS tillatelse til å se mesteparten av aktivitetsmonitorinformasjonen. For ruten Datafil I/O trenger du også enten LAG DATABASE, ENDRE HVILKEN SOM HELST DATABASEeller SE HVILKEN SOM HELST DEFINISJON tillatelser. Uten disse tillatelsene kan Aktivitetsmonitor åpnes, men vise tomme ruter.

Spørsmål: Hvorfor er Aktivitetsmåleren min satt på pause eller fungerer ikke?

A: Aktivitetsmonitoren stopper vanligvis på grunn av tillatelsesproblemer, utdaterte SSMS-versjoner eller deaktiverte eksterne tilkoblinger. Slik løser du dette: (1) Oppdater til den nyeste SSMS-versjonen, (2) Bekreft at du har tillatelse til å VIS SERVERSTATUS, (3) Kontroller at eksterne tilkoblinger er aktivert på SQL Server for eksempel (4) Start SSMS på nytt, og (5) Prøv å koble til med Windows-autentisering i stedet for SQL-autentisering hvis aktuelt.

Spørsmål: Hva er forskjellen mellom Aktivitetsmåler og sp_WhoIsActive?

A: Aktivitetsmonitor er et grafisk verktøy innebygd i SSMS som tilbyr organiserte ruter for ulike overvåkingsaspekter. sp_WhoIsActive er en gratis, fellesskapsskapt lagret prosedyre som returnerer detaljert øktinformasjon i et enkelt resultatsett med mer spesifikke ventetyper, blokkeringsdetaljer og tilpasningsalternativer enn Aktivitetsmonitor. Aktivitetsmonitor er bedre for visuell utforskning, mens sp_WhoIsActive utmerker seg ved skriptbasert overvåking og gir mer detaljert informasjon.

Spørsmål: Påvirker Aktivitetsmåler serverytelsen?

A: Ja, Aktivitetsmonitor har målbar overhead fordi den spør etter system-DMV-er ved hvert oppdateringsintervall. Effekten øker med lavere oppdateringsfrekvenser – Microsoft advarer om at intervaller under 10 sekunder kan påvirke serverytelsen. Lukk alltid Aktivitetsmonitor når du ikke bruker den aktivt, og vurder oppdateringsintervaller på 30–60 sekunder på produksjonsservere under høy belastning.

Spørsmål: Kan jeg hente aktivitetsmonitordata ved hjelp av T-SQL?

A: Ja, Aktivitetsmonitor spør etter dynamiske systemadministrasjonsvisninger som sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats og sys.dm_exec_query_stats. Du kan spørre disse DMV-ene direkte ved hjelp av T-SQL for å hente tilsvarende informasjon programmatisk, noe som muliggjør tilpassede overvåkingsskript og automatisert datainnsamling.

Q: Hva er standard oppdateringsintervall?

A: Standard oppdateringsintervall er 10 sekunder. Du kan endre dette ved å høyreklikke hvor som helst i oversiktsruten og velge Oppdater intervall, og velge mellom forhåndsdefinerte alternativer: 1 sekund, 5 sekunder, 10 sekunder, 30 sekunder, 1 minutt eller 1 time. Kortere intervaller gir flere sanntidsvisninger, men øker overvåkingskostnadene.

Spørsmål: Hvordan kan jeg åpne Aktivitetsmonitor automatisk ved oppstart av SSMS?

A: Konfigurer automatisk oppstart via SSMS-alternativer: Naviger til verktøy -> alternativer -> Miljø -> oppstart, velg deretter Åpne Objektutforsker og Aktivitetsmonitor fra Ved oppstart rullegardinmenyen. Aktivitetsmonitoren åpnes automatisk hver gang du kobler til en server i SSMS.

Spørsmål: Hva er begrensningene til Aktivitetsmonitoren?

A: Viktige begrensninger inkluderer: (1) Ingen lagringsmuligheter for historiske data eller trendanalyse, (2) Ventetyper er gruppert i kategorier i stedet for å vises spesifikt, (3) Noen ventetyper som CXPACKET vises kanskje ikke, (4) Tidspunktsbilder kan overse forbigående problemer, (5) Overvåkingskostnader kan påvirke travle servere, (6) Ingen varslingsmekanisme for proaktiv overvåking, og (7) Kan ikke aggregere data på tvers av flere SQL Server tilfeller. For disse behovene, suppler Aktivitetsmonitor med utvidede hendelser, datainnsamlingssett eller tredjeparts overvåkingsverktøy.

---

om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring innen SQL Server miljøer og administrasjon av bedriftsdatabaser. Han har løst hundrevis av databasegjenopprettingsscenarier på tvers av finansielle tjenester, helsevesen og produksjonsorganisasjoner.

Yuan spesialiserer seg på SQL Server gjenoppretting av database, løsninger med høy tilgjengelighet, og ytelsesoptimalisering. Hans omfattende praktiske erfaring inkluderer administrasjon av databaser på flere terabyte, implementering av Always On Availability Groups og utvikling av automatiserte sikkerhetskopierings- og gjenopprettingsstrategier for forretningskritiske forretningssystemer.

Gjennom sin tekniske ekspertise og praktiske tilnærming fokuserer Yuan på å lage omfattende veiledninger som hjelper databaseadministratorer og IT-fagfolk med å løse komplekse SQL Server utfordringer effektivt. Han holder seg oppdatert på det siste SQL Server utgivelser og Microsofts utviklende databaseteknologier, og tester jevnlig gjenopprettingsscenarioer for å sikre at anbefalingene hans gjenspeiler beste praksis i den virkelige verden.

Har spørsmål vedr SQL Server gjenoppretting eller trenger du ytterligere veiledning for feilsøking av databaser? Yuan ønsker velkommen tilbakemeldinger og forslag for å forbedre disse tekniske ressursene.