SQL Server Aktivitetsovervågning: En komplet guide til databaseadministratorer [2026]

1. Introduktion

1.1 Hvad er SQL Server ActivityMonitor?

SQL Server Aktivitetsovervågning er en indbygget diagnosefunktionostic-værktøj indeni SQL Server Management Studio, der viser oplysninger om SQL Server processer og deres effekt på serverens ydeevne. Det giver dig mulighed for at spore SQL Server processer, overvåge ressourceventetider, analysere dyre forespørgsler og observere I/O-mønstre – alt sammen fra en enkelt grænseflade.

1.2 Hvorfor bruge SQL Server ActivityMonitor?

Aktivitetsovervågning fungerer som din første forsvarslinje, når du fejlfinder problemer med ydeevnen. Den giver øjeblikkelig indsigt i, hvad der sker på din SQL Server instans uden at kræve komplekse T-SQL-forespørgsler eller tredjepartsværktøjer.

Værktøjet udmærker sig ved hurtigt at hjælpe dig med at identificere almindelige problemer såsom blokering af sessioner, CPU-intensive forespørgsler, overdreven udførelse af forespørgsler og I/O-flaskehalse. Når brugere rapporterer, at et program er langsomt eller ikke reagerer, hjælper Aktivitetsovervågning dig med at afgøre, om databaseserveren er synderen.

For databaseadministratorer, der ikke arbejder med SQL Server Dagligt tilbyder Aktivitetsovervågning et tilgængeligt indgangspunkt til at forstå serveraktivitet. Selv erfarne databaseadministratorer bruger det som deres starudgangspunkt for præstationsundersøgelser.

1.3 Aktivitetsovervågning vs. andre overvågningsværktøjer

Selvom Aktivitetsovervågning er værdifuld, er det vigtigt at forstå, hvordan den er sammenlignet med andre overvågningsmuligheder:

Aktivitetsovervågning vs. sp_WhoIsActive: Aktivitetsovervågning har en grafisk brugerflade med flere ruder, mens sp_WhoIsActive er en omfattende lagret procedure, der tilbyder mere detaljerede oplysninger i et enkelt resultatsæt. sp_WhoIsActive viser specifikke ventetyper, som Aktivitetsovervågning grupperer sammen, og giver mere detaljerede blokeringsoplysninger.

Aktivitetsmåler vs. sp_who2: Den traditionelle sp_who2-kommando viser grundlæggende sessionsoplysninger, men Aktivitetsovervågning går endnu længere ved at vise ventestatistik, dyre forespørgsler og I/O-målinger i et organiseret, visuelt format.

Aktivitetsovervågning vs. tredjepartsværktøjer: Kommercielle overvågningsløsninger som SolarWinds Database Performance Analyzer tilbyder historisk sporing, advarsler og avanceret analyse, som Activity Monitor mangler. Activity Monitor kræver dog ingen yderligere cost eller installation.

1.4 Vigtigste fordele for databaseadministratorer

Aktivitetsovervågning tilbyder adskillige fordele, der gør det til et vigtigt DBA-værktøj:

• Nul Cost: Som en indbygget SQL Server Management Studio-funktionen kræver ingen licensgebyrer eller implementeringsindsats.
• Realtidsovervågning: Se den aktuelle serveraktivitet, mens den sker, med konfigurerbare opdateringsintervaller fra 1 sekund til 1 time.
• Integrerede handlinger: Højreklik på processer for at afslutte sessioner, se forespørgselsdetaljer eller starte SQL Server Profiler-spor – alt sammen indefra værktøjet.
• Flere perspektiver: Se serverens tilstand fra forskellige vinkler gennem fem specialiserede ruder, der hver især fokuserer på specifikke aspekter af ydeevnen.
• Hurtig fejlfinding: Identificer m'etost almindelige ydeevneproblemer inden for få minutter, hvilket fremskynder din gennemsnitlige løsningstid.
• Lav adgangsbarriere: Ingen avanceret viden kræves for at begynde at bruge værktøjet effektivt, dog dybere SQL Server ekspertise hjælper med fortolkning.

2. At få Starmed Aktivitetsovervågning

Før du kan udnytte Aktivitetsovervågning effektivt, skal du forstå forudsætningerne, de nødvendige tilladelser og de forskellige metoder til at starte værktøjet.

2.1 Forudsætninger og systemkrav

At bruge SQL Server Aktivitetsmåler, du har brug for SQL Server Management Studio (SSMS) installeret på din lokale maskine eller en jump-server. Aktivitetsovervågningsværktøjet blev markant redesignet i SQL Server 2008, så oplysningerne i denne vejledning gælder for SQL Server 2008 og senere versioner.

Du skal have netværksforbindelse til SQL Server den instans, du vil overvåge. For cloud-hosted-databaser, skal du typisk bruge en VPN-forbindelse eller korrekt konfigurerede firewallregler for at få adgang til instansen.

Aktivitetsovervågning fungerer med alle udgaver af SQL Server, inklusive Express, Standard og Enterprise. Selve værktøjet kører på din klientmaskine i SSMS, så serverens ressourcer påvirkes kun af de overvågningsforespørgsler, den udfører.

2.2 Nødvendige tilladelser

De korrekte tilladelser er afgørende for, at Aktivitetsovervågning fungerer korrekt. Uden de nødvendige rettigheder kan du muligvis se en tom skærm eller modtage fejlmeddelelser om adgang nægtet.

2.2.1 Tilladelse til at se servertilstand

SE SERVERSTATUS Tilladelsen er det primære krav for at bruge Aktivitetsovervågning. Denne tilladelse på serverniveau giver dig mulighed for at se alle aktive processer og deres tilhørende målinger.

For at give denne tilladelse kan en serveradministrator udføre:

GRANT VIEW SERVER STATE TO [YourLoginName];

Uden VIS SERVERSTAND kan Aktivitetsovervågningen åbne, men ingen data vises i nogen af ​​dens ruder.

2.2.2 Tilladelser på databaseniveau

For at se oplysninger i ruden Datafil I/O skal du have yderligere tilladelser. Du skal specifikt have en af ​​følgende kombinationer:

• OPRET DATABASE tilladelse, eller
• ÆNDRE ENHVER DATABASE tilladelse, eller
• SE ENHVER DEFINITION tilladelse

Disse tilladelser skal kombineres med SE SERVERSTATUS for fuld Aktivitetsovervågningsfunktionalitet.

2.2.3 Fejlfinding af tilladelser

Hvis Aktivitetsovervågning åbnes, men ikke viser nogen data, er tilladelserne deaktiveret.ost almindelig årsag. Kontroller, at dit login har VIS SERVERSTATUS givet på serverniveau. Du kan bekræfte dine tilladelser ved at køre:

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

Søg efter 'VIS SERVERSTATUS' i kolonnen permission_name. Hvis den mangler, skal du kontakte din databaseadministrator for at få den tildelt.

2.3 Sådan åbner du Aktivitetsovervågning i SSMS

SQL Server Management Studio tilbyder fire forskellige metoder til at starte Aktivitetsovervågning, hvilket giver dig fleksibilitet baseret på dine arbejdsgangspræferencer.

2.3.1 Metode 1: Fra værktøjslinjen

Den hurtigste måde at åbne Aktivitetsovervågning på er ved at bruge værktøjslinjeikonet:

1. Opret forbindelse til din SQL Server eksempel i SQL Server ManagementStudio.
2. Find ikonet Aktivitetsovervågning i standardværktøjslinjen (det ligner et søjlediagram med en grøn afspilningsknap).
3. Klik på ikonet for at starte Aktivitetsovervågning.

Denne metode er hurtigst, når du allerede arbejder i SSMS og hurtigt har brug for at tjekke serveraktivitet.

2.3.2 Metode 2: Fra Objekt Explorer

Du kan også starte Aktivitetsovervågning direkte fra Objektstifinderen:

1. I Objektstifinder skal du finde SQL Server eksempel, du vil overvåge.
2. Højreklik på instansnavnet.
3. Type Activity Monitor fra kontekstmenuen.

Denne metode er nyttig, når du opretter forbindelse til flere servere, da den sikrer, at du overvåger den korrekte instans.

2.3.3 Metode 3: Brug af tastaturgenvej

For brugere med fokus på tastatur, SQL Server Management Studio tilbyder en dedikeret genvej:

1. Sørg for, at SSMS er det aktive vindue, og at du har forbindelse til en instans.
2. Presse Ctrl + andre + A.
3. Aktivitetsovervågning åbnes for den aktuelt valgte instans i Objektstifinder.

Bemærk, at Aktivitetsovervågning opretter forbindelse til den serverinstans, du har valgt i Object Explorer, så sørg for, at du har valgt den korrekte instans, før du bruger denne genvej.

2.3.4 Metode 4: Fra menuen Indstillinger (Star(tup-konfiguration)

Hvis du ofte bruger Aktivitetsovervågning, kan du konfigurere SSMS til at starte det automatisk, når du...tarapplikationen:

1. In SQL Server Management Studio, naviger til Værktøjer -> Indstillinger.
2. I dialogboksen Indstillinger skal du udvide Miljø, Og vælg derefter Starrør.
3. På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. På starrør rullemenu, vælg Åbn Objektstifinder og Aktivitetsovervågning.
4. Type OK.

Næste gang du starter SSMS og opretter forbindelse til en server, åbnes Aktivitetsovervågning automatisk sammen med Object Explorer.

3. Forståelse af aktivitetsovervågningsruder

Aktivitetsovervågning organiserer information i fem udvidelige ruder, der hver især giver et forskelligt perspektiv på serveraktivitet. Det er afgørende for effektiv fejlfinding at forstå, hvad hver rude viser.

3.1 Oversigtspanel

Oversigtsruden viser fire realtidsgrafer, der giver dig et hurtigt øjebliksbillede af din sundhed. SQL Server f.eks. Disse grafer opdateres med et konfigurerbart interval og hjælper dig med at identificere unormale mønstre med et hurtigt blik.

3.1.1 % processortid

Denne graf viser den procentdel af tid, som processoren bruger på at udføre ikke-inaktive tråde for SQL Server instans på tværs af alle CPU'er. Værdien repræsenterer SQL Servers processorudnyttelse, ikke hele serverens CPU-forbrug.

Hvis du konsekvent ser processortid på eller nær 100%, er din server CPU-bundet. Dette kan indikere ineffektive forespørgsler, manglende indeks eller utilstrækkelig hardwarekapacitet. Brug ruden Seneste dyre forespørgsler til at identificere, hvilke forespørgsler der bruger most CPU.

3.1.2 Venteopgaver

Denne metrik viser antallet af opgaver, der venter på, at ressourcer frigives, før de kan fortsætte. Opgaver kan vente på CPU, I/O, hukommelse eller låse.

Et konstant højt antal ventende opgaver indikerer ressourcekonflikter. Ruden Ressourceventetider giver flere detaljer om, hvilke typer ressourcer der forårsager ventetider.

3.1.3 Database I/O (MB/s)

Denne graf viser hastigheden for dataoverførsel mellem hukommelse og disk. Den kombinerer både læsning og skrivning, målt i megabyte pr. sekund.

Spikes i database-I/O kan indikere forespørgsler, der udfører store tabelscanninger, overdreven logføringsaktivitet eller kontrolpunktshandlinger. Ruden Datafil-I/O opdeler I/O-aktivitet efter database og fil.

3.1.4 Batchforespørgsler/sek.

Denne måleenhed repræsenterer antallet af SQL Server batches modtaget af instansen pr. sekund. En batch kan være en enkelt sætning eller flere sætninger, der sendes sammen.

Denne værdi giver dig en fornemmelse af den samlede serveraktivitet. Pludselige fald i batchforespørgsler i løbet af normal åbningstid kan være tegn på problemer med programforbindelsen eller brugervendte problemer.

3.1.5 Indstilling af opdateringsintervaller

Du kan tilpasse, hvor ofte Aktivitetsovervågning opdaterer sine data:

1. Højreklik et vilkårligt sted i oversigtsruden.
2. Type Opdateringsinterval.
3. Vælg et interval blandt de foruddefinerede værdier: 1 sekund, 5 sekunder, 10 sekunder (standard), 30 sekunder, 1 minut eller 1 time.

Hvis du indstiller opdateringsintervaller på under 10 sekunder, øges overvågningsomkostningerne på din server. For produktionssystemer under høj belastning bør du overveje at bruge intervaller på 30 sekunder eller længere for at minimere påvirkningen.

3.2 Processer-ruden

Processeruden viser oplysninger om aktuelt kørende sessioner på din SQL Server eksempel. Denne rude er vigtig for at identificere, hvem der gør hvad, og for at opdage blokerende problemer.

3.2.1 Forståelse af procesinformation

Hver række i ruden Processer repræsenterer en aktiv session på serveren. Ruden viser sessioner fra alle databaser og alle brugere, hvilket giver dig et omfattende overblik over serveraktivitet.

De viste oplysninger omfatter loginnavn, programnavn, hostnavn, database der tilgås og aktuel kommando. Dette hjælper dig med at korrelere databaseaktivitet med specifikke brugere eller applikationer.

3.2.2 Forklaring af nøglekolonner

At forstå nøglekolonnerne hjælper dig med at fortolke procesoplysninger effektivt:

• Sessions ID: En unik identifikator for hver forbindelse. Systemprocesser bruger negative sessions-ID'er.
• Brugerproces: Angiver, om dette er en brugersession (Ja) eller en systemproces (Nej).
• Login: SQL Server login eller Windows-konto, der er knyttet til sessionen.
• Database: Den aktuelle databasekontekst for sessionen.
• Opgavestatus: Viser, hvad sessionen foretager sig i øjeblikket (KØRER, I PAUS, SOVENDE osv.).
• Command: Den type kommando, der udføres (SELECT, INSERT, UPDATE osv.).
• Påføring: Navnet på den applikation, der oprettede forbindelsen.
• Ventetid: Hvor længe (i millisekunder) sessionen har ventet på ressourcer.
• Ventetype: Den specifikke type ressource, som sessionen venter på.
• CPU-tid: Samlet CPU-tid forbrugt af denne session siden den oprettede forbindelse.
• Hukommelsesbrug: Mængden af ​​hukommelse (i KB), der i øjeblikket er allokeret til sessionen.

3.2.3 Filtrerings- og sorteringsprocesser

Processeruden indeholder effektive filtreringsfunktioner, der hjælper dig med at fokusere på relevante sessioner:

1. Klik på rullemenuen i en hvilken som helst kolonneoverskrift.
2. Filteret viser tilgængelige værdier for den pågældende kolonne, inklusive Alle, Blanksog Ikke-blanke felter.
3. Vælg specifikke værdier for kun at filtrere visningen til disse sessioner.

For eksempel kan du filtrere Opgavestatus for kun at vise KØRENDE sessioner, eller filtrer Database for at se aktivitet i en specifik database.

Du kan også sortere efter en hvilken som helst kolonne ved at klikke på dens overskrift. Klik én gang for stigende rækkefølge, to gange for faldende rækkefølge.

3.2.4 Identifikation af blokerende og blokerede sessioner

Processeruden hjælper dig med at identificere blokeringsscenarier, hvor én session forhindrer andre i at fortsætte:

• Blokeret af: Viser sessions-ID'et for den session, der blokerer denne session. Hvis denne kolonne indeholder en værdi, venter sessionen på en lås, der holdes af en anden session.
• Hovedblokering: Viser '1', hvis denne session blokerer andre, men ikke selv er blokeret. Dette er den grundlæggende årsag til en blokeringskæde.

For at undersøge et blokeringsproblem skal du først identificere hovedblokereren (sessionen markeret med '1' i kolonnen Hovedblokerer), derefter undersøge, hvad den laver, og beslutte, om den skal fuldføres eller afsluttes.

3.2.5 Proceshandlinger (Afbryd, Detaljer, Sporing)

Aktivitetsovervågning giver dig mulighed for at udføre handlinger på individuelle sessioner:

1. Højreklik på en given session i ruden Processer.
2. Du vil se flere muligheder:
   • Detaljer: Viser den sidst udførte kommando i denne session.
   • Dræbningsproces: Afslutter sessionen (brug med forsigtighed).
   • Sporproces i SQL Server Profiler: Lancerer SQL Server Profiler og filtrerer automatisk for kun at vise aktivitet fra denne session.

Indstillingen Detaljer viser dig kommandoteksten, men bemærk at dette er den sidste kommando udført – den kører muligvis ikke stadig. Sporingsfunktionen er især nyttig, når du har brug for at se den komplette rækkefølge af kommandoer, der udføres i en session.

3.3 Ruden Ressourceventer

Ruden Ressourceventer opsummerer ventestatistikker og viser, hvilke typer ressourcesessioner der venter påost ofte. Disse oplysninger er afgørende for at diagnosticere flaskehalse i ydeevnen.

3.3.1 Forståelse af ventestatistik

Når SQL Server Hvis en ressourceanmodning (f.eks. en lås, CPU-tid eller hukommelse) ikke kan imødekommes med det samme, går den anmodende opgave i ventetilstand. Ventestatistik sporer disse venteperioder og hjælper dig med at forstå, hvor serveren bruger tid på at vente i stedet for at arbejde.

Ruden Ressourceventetider indsamler data fra dynamiske systemstyringsvisninger som sys.dm_os_wait_stats og sys.dm_exec_requests. Ved hvert opdateringsinterval beregnes forskellen mellem det aktuelle og det forrige øjebliksbillede og viser dig akkumuleringshastigheden for hver ventetype.

3.3.2 Ventekategorier

Aktivitetsovervågning grupperer hundredvis af individuelle ventetyper i bredere kategorier for at forenkle fortolkningen:

• CPU: Opgaver, der venter på, at CPU-tid bliver tilgængelig.
• Bufferlås: Venter på kortvarige synkroniseringsobjekter, der beskytter adgang til datasider i hukommelsen. Denne kategori inkluderer ventetider for sidelås (PAGELATCH_*).
• Lås: Ventetider forårsaget af sessioner, der indeholder låse, som andre sessioner har brug for.
• Hukommelse: Venter på hukommelsestildelinger, der er nødvendige for operationer som sortering og hashing.
• Netværks-I/O: Venter på at sende data til eller modtage data fra klienter.
• SQL CLR: Ventetider relateret til Common Language Runtime-udførelse.

Selvom denne gruppering forenkler visningen, skjuler den også vigtige detaljer. For eksempel kan "Buffer Latch" gruppere ventetiderne PAGELATCH_SH, PAGELATCH_UP og PAGELATCH_EX, som har forskellige konsekvenser for ydeevnen.

3.3.3 Fortolkning af ventetid og venteopgaver

Ruden Ressourceventetider viser to nøgleparametre for hver ventekategori:

• Kumulativ ventetid (ms): Det samlede antal millisekunder akkumuleret under det aktuelle opdateringsinterval for denne ventekategori.
• Venteopgaver: Antallet af opgaver, der i øjeblikket venter på ressourcer i denne kategori.

Ventetidsværdien er særligt interessant. Hvis du har et opdateringsinterval på 10 sekunder og ser 20,000 ms ventetid for en kategori, indikerer det flere samtidige ventetider (20,000 ms / 10,000 ms = gennemsnit af 2 samtidige ventetider i løbet af intervallet).

3.3.4 Identifikation af flaskehalse i præstationsevnen

Brug ruden Ressourceventer til at identificere, hvor din server bruger most ventetid:

1. Udvid ruden Ressourceventetider.
2. Observer de ventekategorier, der akkumulerer de højeste ventetider.
3. Sorter efter Kumulativ ventetid for at se hvilke ressourcer der er most indskrænket.

Ventetider med høj bufferlås indikerer ofte begrænsning af datasider i hukommelsen, hvilket kan tyde på I/O-flaskehalse eller tempdb-begrænsning. Ventetider med høj lås peger på blokeringsproblemer. Ventetider med høj hukommelse tyder på utilstrækkelige hukommelsestilladelser til forespørgselshandlinger.

3.4 Datafil I/O-ruden

Ruden Data File I/O viser diskaktivitet for hver databasefil på din server, hvilket hjælper dig med at identificere I/O-flaskehalse og forstå diskudnyttelsesmønstre.

3.4.1 Forståelse af I/O-målinger

Ruden Datafil I/O viser flere metrikker for hver databasefil:

• Database: Navnet på databasen.
• Filtype: Enten data (inklusive tabeller og indeks) eller log (transaktionslog).
• Logisk navn: Det logiske filnavn som defineret i SQL Server.
• MB/sek. Læsning: Hastigheden af ​​data, der læses fra denne fil.
• MB/sek. Skrevet: Hastigheden af ​​data, der skrives til denne fil.
• Svartid (ms): Gennemsnitlig svartid for I/O-operationer på denne fil.

Disse målinger opdateres med samme interval som oversigtsruden, hvilket giver dig overblik over diskaktivitet i realtid.

3.4.2 Identifikation af I/O-flaskehalse

Hold øje med disse mønstre, der indikerer problemer med I/O-ydeevne:

• Høj responstid: Svartider, der konstant ligger over 15-20 ms, tyder på langsomme diskundersystemer. Svartider over 50 ms indikerer alvorlige I/O-flaskehalse.
• Ubalanceret belastning: Hvis én datafil viser betydeligt højere I/O-hastigheder end andre i den samme database, kan du med fordel tilføje yderligere filer for at fordele belastningen.
• Overdreven Tempdb-aktivitet: Høje I/O-hastigheder på tempdb-filer indikerer ofte, at forespørgsler opretter store mellemliggende resultatsæt eller bruger ineffektive udførelsesplaner.

3.4.3 Analyse af databasefiler

Brug ruden Datafil I/O til at forstå, hvordan dine databaser bruger diskressourcer:

1. Udvid ruden Datafil I/O.
2. Sorter efter MB/sek. Læsning or MB/sek. Skrevet at identificere most aktive filer.
3. Bemærk eventuelle filer med konstant høj aktivitet eller lange svartider.
4. Krydsreferer disse oplysninger med ruden Seneste dyre forespørgsler for at identificere, hvilke forespørgsler der driver I/O-belastningen.

3.5 Panelet Seneste dyre forespørgsler

Ruden Seneste dyre forespørgsler er ofte den mestost værdifuld rude til fejlfinding af problemer med applikationers ydeevne. Den viser forespørgsler, der bruger betydelige serverressourcer, hvilket hjælper dig med at identificere optimeringsmuligheder.

3.5.1 Forståelse af forespørgselsmålinger

Aktivitetsovervågning viser flere målinger for hver dyr forespørgsel:

• Henrettelser/min: Hvor mange gange forespørgslen blev udført i løbet af sidste minut.
• CPU (ms/sek): CPU-tid forbrugt af denne forespørgsel pr. sekund.
• Fysiske aflæsninger/sek: Antal læsninger af fysiske diske pr. sekund for denne forespørgsel.
• Logiske skrivninger/sek: Antal logiske skrivninger (til buffercache) pr. sekund.
• Logiske læsninger/sek: Antal logiske læsninger (fra buffercache) pr. sekund.
• Gennemsnitlig varighed (ms): Gennemsnitlig udførelsestid for denne forespørgsel.
• Planantal: Antal udførelsesplaner i cachen for denne forespørgsel.

Disse målinger hjælper dig med at forstå ikke blot hvilke forespørgsler der er dyre, men hvorfor de er dyre, og hvor ofte de kører.

3.5.2 Sorteringsmuligheder

Du kan sortere ruden Seneste dyre forespørgsler efter forskellige målinger for at finde forskellige typer problemer:

1. Klik på en vilkårlig kolonneoverskrift for at sortere efter den pågældende metrik.
2. Almindelige sorteringsstrategier omfatter:
   • Sortér efter CPU: Find forespørgsler, der bruger most processortid.
   • Sortér efter Henrettelser/min: Identificer forespørgsler, der kører for ofte.
   • Sortér efter fysiske aflæsninger: Find forespørgsler, der forårsager most disk I/O.
   • Sortér efter gennemsnitlig varighed: Find langvarige forespørgsler.

Når du foretager fejlfinding af et ydeevneproblem, kan du prøve at sortere efter flere kolonner for at få forskellige perspektiver. En forespørgsel med moderat CPU-forbrug, men ekstremt høje antal udførelser pr. minut, kan være dit egentlige problem.

3.5.3 Visning af forespørgselstekst

Sådan ser du den faktiske SQL-sætning bag en dyr forespørgsel:

1. Højreklik på forespørgselsrækken i ruden Seneste dyre forespørgsler.
2. Type Rediger forespørgselstekst.
   
3. Et nyt forespørgselsvindue åbnes, der viser den komplette SQL-sætning.
   

Dette giver dig mulighed for at undersøge forespørgselslogikken og identificere potentielle optimeringsmuligheder. Du kan derefter kopiere forespørgselsteksten for at teste ændrede versioner.

3.5.4 Analyse af udførelsesplaner

Udførelsesplaner viser dig hvordan SQL Server udfører en forespørgsel og afslører ineffektivitet som manglende indeks eller upassende join-typer:

1. Højreklik på forespørgselsrækken i ruden Seneste dyre forespørgsler.
2. Type Vis udførelsesplan.
   
3. SQL Server Management Studio viser en grafisk repræsentation af, hvordan forespørgslen udføres.
   

Led efter operationer, der bruger store procentdele af forespørgslens cost, advarsler om manglende statistikker eller indekser og uventede tabelscanningshandlinger. Disse indikerer ofte, hvor optimeringsindsatsen bør fokuseres.

3.5.5 Identifikation af problematiske forespørgsler

Hold øje med disse mønstre i ruden Seneste dyre forespørgsler:

• Overdrevne henrettelser: En forespørgsel, der udføres tusindvis af gange i minuttet, kan indikere et N+1-forespørgselsproblem, hvor applikationskoden kalder databasen i en løkke.
• Høje fysiske aflæsninger: Forespørgsler med høje fysiske læsehastigheder rammer disken ofte, hvilket tyder på manglende indeks eller dårligt skrevne forespørgsler.
• Høj CPU med lav varighed: Mange hurtige forespørgsler, der bruger meget CPU samlet set, kan påvirke serverens ydeevne lige så meget som et par langsomme forespørgsler.
• Flere planantal: Forespørgsler med mange udførelsesplaner kan lide af problemer med parametersniffing eller ikke-parametriserede forespørgsler, der forårsager opblussen af ​​plancache.

4. Brug af Aktivitetsovervågning til fejlfinding af ydeevne

Aktivitetsovervågning udmærker sig virkelig, når du bruger den systematisk til at diagnosticere og løse problemer med ydeevnen. Dette afsnit dækker almindelige fejlfindingsscenarier og hvordan du griber dem an.

4.1 Diagnosticering af overdreven forespørgselskørsel

En af demost Almindelige ydeevneproblemer er forespørgsler, der udføres langt oftere end nødvendigt, ofte på grund af problemer med applikationsdesign.

4.1.1 Identifikation af gentagne forespørgsler

Sådan finder du forespørgsler, der udføres for ofte:

1. Åbn Aktivitetsovervågning, og udvid Seneste dyre forespørgsler rude.
2. Sorter efter Henrettelser/min (henrettelser pr. minut).
3. Kig efter forespørgsler øverst med udførelsesantal, der virker urimeligt høje.
4. Højreklik på den mistænkelige forespørgsel, og vælg Rediger forespørgselstekst for at undersøge SQL-sætningen.

Hvis du for eksempel ser en simpel SELECT-sætning udføres 37,000 gange i minuttet, så spørg dig selv, om applikationen virkelig behøver at kalde denne forespørgsel så ofte. Most forespørgsler, der udføres mere end et par tusinde gange i minuttet, berettiger til undersøgelse.

4.1.2 Grundårsagsanalyse

Overdreven udførelse af forespørgsler stammer typisk fra disse problemer:

• N+1 forespørgselsproblem: Applikationskoden henter en liste over elementer og udfører derefter en separat forespørgsel for hvert element for at hente relaterede data. Dette opretter N yderligere forespørgsler, hvor N er antallet af elementer.
• Manglende caching: Applikationen forespørger databasen om data, der rarely ændringer i stedet for at cache det i applikationens hukommelse.
• Afstemningssløkker: Kode forespørger gentagne gange databasen for tilstandsændringer i stedet for at bruge ændringsmeddelelser eller meddelelseskøer.
• ORM-ineffektivitet: Entity Framework og lignende værktøjer genererer nogle gange ineffektive forespørgselsmønstre, når udviklere ikke forstår, hvordan deres kode oversættes til SQL.

For at bestemme den grundlæggende årsag skal du spore forespørgslen tilbage til programkoden. Bemærk Anvendelse og Login kolonner i ruden Processer, når forespørgslen udføres. Du kan også højreklikke på processen og vælge Sporproces i SQL Server Profiler for at se opkaldsmønsteret.

4.1.3 Løsninger og bedste praksis

Når du har identificeret overdreven forespørgselskørsel, kan du overveje disse løsninger:

• Batchbehandling: Rediger programkode for at hente flere elementer i en enkelt forespørgsel ved hjælp af joins eller IN-klausuler i stedet for at udføre separate forespørgsler i en løkke.
• Resultatcachelagring: Cache tilgås ofte, ændrer sjældent data i programhukommelsen med passende udløbstider.
• Ivrig læsning: Konfigurer ORM'er til at bruge strategier for hurtig indlæsning, der henter relaterede data i færre og mere effektive forespørgsler.
• Forespørgselsparametrisering: Sørg for, at forespørgsler bruger parametre i stedet for at sammenkæde værdier, hvilket forbedrer genbrug af plancache og reducerer kompileringsoverhead.

4.2 Undersøgelse af blokeringsproblemer

Blokering opstår, når én session har låse, der forhindrer andre sessioner i at fortsætte. Dette manifesterer sig som langsomme applikationsresponstider og frustrerede brugere.

4.2.1 Identifikation af blokeringskæder

Sådan registrerer og analyserer du blokering:

1. Åbn Aktivitetsovervågning, og udvid Processer rude.
2. Led efter sessioner med værdier i Blokeret af kolonne – disse venter på låse, der er indeholdt af andre sessioner.
3. Find sessioner med '1' i Hovedblokerer kolonne – disse er den grundlæggende årsag til blokerende kæder.
4. Bemærk Sessions ID af hovedblokereren.
5. Højreklik på hovedblokeringssessionen, og vælg Detaljer for at se hvilken kommando den udfører.

Det er afgørende at forstå blokeringskæden. Det er hovedblokereren, der er den session, du skal undersøge, ikke de blokerede sessioner efterfølgende.

4.2.2 Forståelse af låsetyper

Ventetype Kolonnen i ruden Processer angiver, hvilken type lås blokerede sessioner venter på:

• LCK_M_X: Eksklusiv låsevent, typisk forårsaget af UPDATE-, DELETE- eller INSERT-handlinger.
• LCK_M_S: Vent på delt lås, normalt SELECT-sætninger, der venter på, at eksklusive låse frigives.
• LCK_M_U: Opdateringslåsvent, en mellemliggende låsetype, der bruges under opdateringer.
• LCK_M_IX: Intent eksklusiv låsevent, der angiver låsekonflikt på side- eller rækkeniveau.

Vent ressource Kolonnen viser hvilket databaseobjekt der låses, hvilket hjælper dig med at forstå, hvilken tabel eller hvilket indeks der er involveret i konflikten.

4.2.3 Løsning af blokeringsproblemer

Når du har identificeret den blokerende session og hvad den gør, har du flere muligheder:

1. Vent på færdiggørelse: Hvis headblockeren kører en legitim forespørgsel, der snart vil blive afsluttet, kan det være bedst at lade den afslutte naturligt.
2. Dræb sessionen: Hvis headblockeren sidder fast eller kører en forespørgsel, der skal annulleres:
   • Højreklik på sessionen i ruden Processer.
   • Type Kill Process.
   • Bekræft handlingen i dialogboksen.
3. Optimer forespørgsler: Hvis blokering gentages med de samme forespørgsler, skal du optimere dem for at reducere deres låsevarighed.
4. Juster isolationsniveauer: Overvej at bruge READ COMMITTED SNAPSHOT ISOLATION for at reducere blokering i læsetunge arbejdsbelastninger.
5. Indeksjustering: Tilføj indeks for at fremskynde forespørgsler og reducere, hvor længe de holder låse.

4.3 Analyse af højt CPU-forbrug

Når oversigtsruden viser en processortid konsekvent på eller nær 100 %, skal du identificere, hvilke forespørgsler der er ansvarlige, og afgøre, om de kan optimeres.

4.3.1 Identifikation af CPU-intensive forespørgsler

Sådan finder du forespørgsler, der bruger for meget CPU:

1. Åbne Seneste dyre forespørgsler rude.
2. Sorter efter CPU (ms/sek) for at vise forespørgsler ved hjælp af most CPU-tid.
3. Undersøg de mest populære forespørgsler på listen.
4. Højreklik på forespørgsler med høj CPU og vælg Rediger forespørgselstekst for at se SQL-sætningen.
5. Type Vis udførelsesplan for at forstå, hvordan forespørgslen udføres.

Vær ikke kun opmærksom på CPU-forbruget for de enkelte forespørgsler, men også på Henrettelser/min kolonne. En forespørgsel, der bruger moderat CPU pr. udførelse, men kører tusindvis af gange i minuttet, kan være din største CPU-forbruger.

4.3.2 Teknikker til forespørgselsoptimering

Almindelige tilgange til at reducere CPU-forbruget inkluderer:

• Tilføj manglende indekser: Indekssøgninger bruger langt mindre CPU end tabelscanninger. Se efter manglende indeksanbefalinger i udførelsesplaner.
• Omskriv ineffektive forespørgsler: Erstat markører med sætbaserede operationer, fjern unødvendige funktioner i WHERE-klausuler, og fjern redundante joins.
• Opdater statistik: Forældet statistik forårsager SQL Server at vælge ineffektive udførelsesplaner. Kør UPDATE STATISTICS på berørte tabeller.
• Reducer datamængden: Tilføj WHERE-klausuler for at filtrere data tidligere, brug TOP eller OFFSET/FETCH til paginering, og undgå SELECT *.
• Rettelse af parametersniffing: Brug OPTION (RECOMPILE), forespørgselshints eller planlægningsvejledninger, når parametersniffing forårsager problemer.

4.4 Undersøgelse af hukommelsesproblemer

Hukommelsesbelastning kan forårsage, at forespørgsler overføres til disken, hvilket forringer ydeevnen betydeligt. Aktivitetsovervågning hjælper dig med at identificere hukommelsesintensive operationer.

4.4.1 Forståelse af hukommelsesmålinger

Hukommelsesbrug Kolonnen i ruden Processer viser den hukommelse, der er allokeret til hver session, i kilobyte. Højt hukommelsesforbrug i en enkelt session indikerer ofte:

• Store sorterings- eller hash-operationer, der ikke kunne passe ind i den oprindeligt tildelte hukommelse
• Forespørgsler, der henter enorme resultatsæt
• Overdreven parallelisme skaber mange kopier af udførelsesplanoperatorer
• Hukommelseslækager i CLR-lagrede procedurer eller funktioner

Ruden Ressourceventetider kan vise Hukommelsesventetider, når forespørgsler ikke kan opnå tilstrækkelige hukommelsestilladelser og skal vente på, at hukommelse bliver tilgængelig.

4.4.2 Identifikation af hukommelsesintensive forespørgsler

Sådan finder du forespørgsler, der forårsager hukommelsesbelastning:

1. I Processer rude, sorter efter Hukommelsesbrug at se sessioner, der indtager most hukommelse.
2. Højreklik på sessioner med højt hukommelsesforbrug, og vælg Detaljer for at se deres forespørgsler.
3. I Seneste dyre forespørgsler rude, søg efter forespørgsler med høj Logiske læsninger or Logiske skrivninger, da disse ofte korrelerer med hukommelsesforbrug.
4. Undersøg udførelsesplaner for Sort- og Hash Match-operatorer, som bruger hukommelsestildelinger.

Forespørgsler, der viser advarsler om "Memory Grant" i udførelsesplaner eller advarsler om oversvømmelse, indikerer problemer med hukommelsesbelastning.

4.5 Registrering af problemer med applikationens ydeevne

Når brugere rapporterer langsomme svartider i programmer, hjælper Aktivitetsovervågning dig med at afgøre, om databasen er flaskehalsen.

4.5.1 Korrelation af Aktivitetsovervågning med programproblemer

Sådan undersøger du applikationens langsommelighed:

1. Notér det præcise tidspunkt, hvor brugerne rapporterer problemer, og hvilke applikationer der er berørt.
2. Åbn Aktivitetsovervågning og tjek Overblik rude for ressourcestigninger på det tidspunkt.
3. I Processer rude, filtrer efter Anvendelse for kun at vise forbindelser fra den berørte applikation.
4. Kig efter høje Ventetid værdier, som angiver databaseforsinkelser.
5. Tjek Seneste dyre forespørgsler rude for forespørgsler fra det program, der bruger betydelige ressourcer.

Hvis databasen ikke viser nogen usædvanlig aktivitet, mens brugerne oplever langsomhed, ligger problemet sandsynligvis i programkoden, netværkslatensen eller klientsidens ydeevne.

4.5.2 Identifikation af ineffektive applikationsmønstre

Aktivitetsovervågning afslører adskillige antimønstre i applikationsdesign:

• Snakkede applikationer: Mange små forespørgsler i stedet for færre, mere effektive forespørgsler. Identificeret ved et højt antal forbindelser og adskillige simple forespørgsler i Seneste dyre forespørgsler.
• N+1 forespørgsler: Én forespørgsel efterfulgt af N yderligere forespørgsler om relaterede data. Vises som en simpel forespørgsel med ekstremt høje udførelser pr. minut.
• Store resultatsæt: Applikationer henter langt flere data end nødvendigt. Kig efter høje Logiske læsninger kombineret med simple SELECT*-forespørgsler.
• Manglende timeouts: Applikationer, der ikke angiver timeouts for kommandoer, kan lade forbindelser være åbne på ubestemt tid, hvilket er synligt som langvarige sessioner i ruden Processer.

5. Alternative metoder: Hentning af aktivitetsovervågningsdata via T-SQL

Selvom Aktivitetsovervågning har en praktisk grafisk brugerflade, er det nogle gange nødvendigt at hente tilsvarende oplysninger programmatisk eller oprette brugerdefinerede overvågningsløsninger.

5.1 Brug af dynamiske styringsvisninger (DMV'er)

SQL Server eksponerer aktivitetsoplysninger via dynamiske administrationsvisninger, som Aktivitetsovervågning forespørger bag kulisserne.

5.1.1 Vigtige DMV'er til aktivitetsovervågning

Most Vigtige DMV'er til replikering af Aktivitetsovervågningsfunktionalitet inkluderer:

• sys.dm_exec_requests: Viser aktuelt udførende anmodninger med CPU-, I/O- og venteinformation.
• sys.dm_exec_sessions: Indeholder oplysninger på sessionsniveau såsom loginnavn, host navn og programnavn.
• sys.dm_os_wait_stats: Giver kumulativ ventestatistik for hele instansen.
• sys.dm_exec_query_stats: Indeholder samlede præstationsstatistikker for cachelagrede forespørgsler.
• sys.dm_io_virtual_file_stats: Returnerer I/O-statistik for data og logfiler.
• sys.dm_exec_sql_text: Henter SQL-teksten for en given sql_handle eller plan_handle.
• sys.dm_exec_query_plan: Returnerer udførelsesplanen for en cachelagret forespørgsel.

5.1.2 Eksempelforespørgsler til procesinformation

For at replikere funktionaliteten i ruden Processer kan du forespørge:

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 Eksempelforespørgsler til ventestatistik

Sådan ser du ventestatistik svarende til ruden Ressourceventetider:

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 Brug af sp_WhoIsActive

sp_WhoIsActive er en effektiv, fællesskabsoprettet, lagret procedure, der giver mere detaljerede oplysninger end Aktivitetsovervågning i et enkelt resultatsæt.

5.2.1 Installation af sp_WhoIsActive

Sådan installeres sp_WhoIsActive:

1. Download den nyeste version fra http://whoisactive.com.
2. Downloaden er et SQL-script, der indeholder proceduredefinitionen.
3. Åbn scriptet i SQL Server ManagementStudio.
4. Opret forbindelse til din SQL Server instans.
5. Udfør scriptet for at oprette proceduren i masterdatabasen.
6. Giv udførelsestilladelser til de relevante brugere.

Fordi sp_WhoIsActive er installeret i master, er det tilgængeligt fra enhver databasekontekst.

5.2.2 Grundlæggende brugseksempler

Den enkleste måde at bruge sp_WhoIsActive på er:

EXEC sp_WhoIsActive;

Dette returnerer et resultatsæt, der viser alle aktive sessioner med deres forespørgsler, ventetyper, blokeringsoplysninger og ressourceforbrug.

For en 10-sekunders prøve, der viser aktivitet i den periode:

EXEC sp_WhoIsActive @delta_interval = 10;

Dette beregner deltaer for metrikker som CPU og aflæsninger og viser, hvad der skete i løbet af de 10 sekunder.

5.2.3 Avancerede parametre

sp_WhoIsActive understøtter adskillige parametre til tilpasning:

• @filter: Filtrer resultater til bestemte sessioner, databaser eller logins.
• @filtertype: Angiv, hvad filteret gælder for (session, database, login osv.).
• @get_plans: Inkluder udførelsesplaner i resultaterne (sæt til 1).
• @get_locks: Vis detaljerede låseoplysninger (indstil til 1).
• @hent_transaktionsinfo: Vis transaktionsdetaljer (indstil til 1).
• @sort_order: Sorter resultater efter forskellige metrikker (CPU, læsninger, varighed osv.).
• @destination_table: Indsæt resultater i en tabel til historisk sporing.

Eksempel på planer sorteret efter CPU:

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

5.3 Brug af systemlagrede procedurer

SQL Server inkluderer traditionelle lagrede procedurer til overvågning af aktivitet, selvom de giver færre oplysninger end DMV'er eller Aktivitetsovervågning.

5.3.1 sp_who og sp_who2

sp_who-proceduren viser grundlæggende sessionsoplysninger:

EXEC sp_who;

sp_who2-proceduren giver lidt flere detaljer:

EXEC sp_who2;

Begge procedurer viser sessions-ID'er, loginnavne, CPU-tid og blokeringsoplysninger. De mangler dog de mange detaljer, der er tilgængelige via DMV'er eller Aktivitetsovervågning. De er most nyttigt til hurtige kontroller, når du har brug for minimale oplysninger hurtigt.

5.3.2 Andre nyttige systemprocedurer

Yderligere systemprocedurer til overvågning omfatter:

• sp_lock: Viser låseoplysninger (udfaset; brug sys.dm_tran_locks i stedet).
• sp_monitor: Viser statistik om SQL Server aktivitet.
• sp_hjælp: Viser objektdefinitioner og metadata.
• DBCC SQLPERF: Viser pladsforbrug og ventestatistik i transaktionsloggen.

5.4 Oprettelse af brugerdefinerede overvågningsscripts

I miljøer, der kræver specifik overvågning ud over, hvad Aktivitetsovervågning tilbyder, kan du bygge brugerdefinerede løsninger ved hjælp af DMV'er.

5.4.1 Komplet script tilsvarende aktivitetsovervågning

Her er et omfattende script, der replikerer most Aktivitetsovervågningsfunktion:

-- 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 Automatisering af overvågning med SQL Agent-job

Du kan planlægge brugerdefinerede overvågningsscripts ved hjælp af SQL Server Agenter:

1. Opret en tabel til at gemme overvågningsresultater.
2. Rediger dit overvågningsscript for at indsætte resultater i denne tabel.
3. In SQL Server Management Studio, udvid SQL Server Agent i Objekt Explorer.
4. Højreklik Karriere og vælg Nyt job.
5. Konfigurer jobbet til at køre dit overvågningsscript med jævne mellemrum.
6. Opsæt alarmer eller rapporter baseret på de indsamlede data.

Denne tilgang muliggør historisk sporing og trendanalyse, hvilket Aktivitetsovervågning ikke tilbyder.

6. Begrænsninger og overvejelser vedrørende aktivitetsmåleren

Selvom Aktivitetsovervågning er værdifuld, hjælper forståelsen af ​​dens begrænsninger dig med at bruge den korrekt og supplere den med andre værktøjer, når det er nødvendigt.

6.1 Forståelse af aktivitetsmålerens overhead

Aktivitetsovervågning er ikke gratis – det bruger serverressourcer på at indsamle og vise oplysninger. At forstå denne overhead hjælper dig med at bruge den ansvarligt.

6.1.1 Indvirkning på serverressourcer

Aktivitetsovervågning kører forespørgsler mod system-DMV'er, hver gang den opdateres. Disse forespørgsler bruger CPU, genererer logiske læsninger og kan kortvarigt holde låse på systemtabeller. På travle servere kan denne overhead påvirke ydeevnen.

Ruderne Processer og Seneste dyre forespørgsler er særligt dyre, da de skal scanne potentielt store DMV'er og cache-tabeller. På servere med tusindvis af cachelagrede forespørgselsplaner kan det tage flere sekunder at opdatere Seneste dyre forespørgsler.

Microsofts dokumentation advarer om, at opdateringsintervaller på under 10 sekunder kan påvirke serverens ydeevne mærkbart, især på systemer, der allerede er indlæst.

6.1.2 Bedste praksis for opdateringsintervaller

Vælg opdateringsintervaller, der passer til din situation:

• 1-5 sekunder: Kun til øjeblikkelig fejlfinding af kritiske problemer på let belastede servere. Lad ikke Aktivitetsovervågning køre i disse intervaller.
• 10 sekunder (standard): Rimelig for most fejlfindingsscenarier og generel overvågning.
• 30-60 sekunder: Bedre valg til produktionsservere under tung belastning eller ved overvågning i længere perioder.
• Kun manuel opdatering: I situationer hvor du ønsker at kontrollere den aktuelle tilstand lejlighedsvis uden kontinuerlig polling.

Luk altid Aktivitetsovervågning, når du er færdig med at undersøge det. Lad den ikke køre kontinuerligt, især ikke hvis den kører flere gange fra forskellige brugere.

6.2 Problemer med gruppering af ventetyper

Aktivitetsovervågningens tilgang til kategorisering af ventetider kan, samtidig med at den forenkler visningen, skjule vigtige diagnoser.ostic-oplysninger.

6.2.1 Hvordan Aktivitetsovervågning grupperer ventetider

SQL Server sporer hundredvis af forskellige ventetyper, der hver især angiver en specifik ressource eller tilstand. Aktivitetsovervågning grupperer disse i brede kategorier som "Bufferlås", "Lås" og "Hukommelse".

For eksempel omfatter kategorien "Buffer Latch" PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX og adskillige andre specifikke ventetyper. Selvom de alle er relateret til sideadgang, har de forskellige årsager og løsninger.

Microsoft dokumenterer ikke præcis hvilke ventetyper der knyttes til hvilke kategorier, hvilket gør det svært at forstå, hvad man virkelig ser.

6.2.2 Manglende ventetyper

Aktivitetsovervågning viser ikke alle ventetyper. Most Det er især bemærkelsesværdigt, at den ofte udelader CXPACKET-ventetider, hvilket indikerer parallel forespørgselsudførelse. CXPACKET-ventetider er almindelige og normalt ikke problematiske, men at vide, at de er til stede, hjælper dig med at forstå arbejdsbyrdens karakteristika.

Når Aktivitetsovervågning viser "Bufferlås" som din primære ventetid, men andre værktøjer viser CXPACKET som dominerende, stammer uoverensstemmelsen fra Aktivitetsovervågningens filtrerings- og grupperingslogik.

6.2.3 Hvorfor specifikke ventetyper er vigtige

Det er vigtigt at kende den specifikke ventetype i forbindelse med fejlfinding:

• PAGELATCH_EX: Indikerer ofte tempdb-konflikt på allokeringssider. Løsningen involverer at tilføje flere tempdb-datafiler.
• PAGELATCH_SH: Kan indikere aktive sider i brugertabeller. Løsningen involverer partitionering eller indeksreorganisering.
• PAGELATCH_UP: Almindelig under opdateringer. Kan indikere normal drift snarere end et problem.

Aktivitetsovervågning grupperer alle disse under "Bufferlås", hvilket gør diagnosen vanskeligere. Værktøjer som sp_WhoIsActive og DMV-forespørgsler viser specifikke ventetyper.

6.3 Dataenes nøjagtighed og aktualitet

Aktivitetsovervågning giver en næsten realtidsvisning, men "nær" er det afgørende ord. Forståelse af dens dataindsamlingsmetode hjælper dig med at fortolke resultaterne korrekt.

6.3.1 Øjebliksbillede vs. kontinuerlig overvågning

Aktivitetsovervågning viser snapshots taget på et bestemt tidspunkt ved hvert opdateringsinterval. Hændelser, der forekommer mellem snapshots, registreres ikke. Hvis en forespørgsel kører i 2 sekunder, og du opdaterer hvert 10. sekund, kan du muligvis se den én gang eller slet ikke, afhængigt af timingen.

Det betyder, at Aktivitetsovervågning udmærker sig ved at finde vedvarende problemer (blokering af varige minutter, konstant høj CPU-hastighed), men kan overse forbigående problemer (korte fastlåste situationer, lejlighedsvise stigninger i forespørgsler).

6.3.2 Aggregering og stikprøveudtagning

Ruden Seneste dyre forespørgsler viser data, der er aggregeret, siden forespørgselsplaner blev indtastet i cachen. To identiske forespørgsler med forskellige parameterværdier vises som én række, hvis de deler en plan. Denne aggregering kan maskere problemer med specifikke parameterkombinationer (parametersniffing-problemer).

Ruden Ressourceventetider beregner rater ved at sammenligne snapshots. Hvis ventestatistikken nulstilles mellem snapshots (rar(e men muligt), kan de beregnede satser være forkerte.

6.4 Hvornår skal Aktivitetsmåleren IKKE bruges

Aktivitetsovervågning er ikke egnet til alle overvågningsscenarier. Vær opmærksom på, hvornår alternative værktøjer er bedre valg.

6.4.1 Krav til historisk analyse

Aktivitetsovervågning viser kun aktuel eller nylig aktivitet. Den gemmer ikke historiske data. Hvis du har brug for at analysere tendenser over dage eller uger, sammenligne den aktuelle ydeevne med baselines eller generere rapporter om ydeevnemønstre, er Aktivitetsovervågning ikke tilstrækkelig.

Til historisk analyse, brug SQL Server's indbyggede præstationsdashboard, udvidede begivenheder med fil tarfår, eller tredjeparts overvågningsløsninger.

6.4.2 Behov for detaljeret ventestatistik

Når du har brug for præcise oplysninger om ventetiden til avanceret justering, gør grupperingen og filtreringen i Aktivitetsovervågningen det utilstrækkeligt. Brug DMV-forespørgsler direkte eller sp_WhoIsActive i stedet.

For en omfattende analyse af ventestatistik, forespørg sys.dm_os_wait_stats direkte og filtrer godartede ventetider fra manuelt.

6.4.3 Overvejelser vedrørende produktionsserver

På produktionsservere under høj belastning kan Aktivitetsovervågningens overhead være problematisk. Flere databaseadministratorer bør ikke køre Aktivitetsovervågning samtidigt på den samme server.

Til produktionsovervågning bør du overveje lette alternativer som planlagte DMV-snapshots gemt i en overvågningsdatabase, eller bruge skrivebeskyttet routing til at overvåge sekundære replikaer i Always On-konfigurationer.

7. Bedste fremgangsmåder til brug af Aktivitetsovervågning

Ved at følge bedste praksis sikrer du, at du får maksimal værdi ud af Aktivitetsovervågning, samtidig med at du minimerer negative påvirkninger på dine servere.

7.1 Hvornår skal Aktivitetsmåleren bruges

Aktivitetsovervågning er fremragende i specifikke situationer. Brug den, når dens styrker stemmer overens med dine behov.

7.1.1 Problemer med realtidsydelse

Aktivitetsovervågning er ideel, når brugerne oplever problemer i øjeblikket, og du har brug for at diagnosticere problemet med det samme. Realtidsvisningen hjælper dig med at se, hvad der sker lige nu.

Når du får et opkald om, at "applikationen er langsom", bør åbning af Aktivitetsovervågning være et af dine første skridt. Du kan hurtigt afgøre, om databasen er optaget, blokeret eller inaktiv.

7.1.2 Undersøgelse af applikationsforsinkelse

Når et bestemt program ikke reagerer, hjælper Aktivitetsovervågning dig med at afgøre, om databaseproblemer er årsagen. Filtrer ruden Processer efter programnavn for kun at se det pågældende programs databaseaktivitet.

Hvis applikationen ikke viser nogen databaseaktivitet, mens brugerne rapporterer problemer, ligger problemet et andet sted i stakken. Hvis du ser omfattende blokeringer eller dyre forespørgsler, har du fundet din synder.

7.1.3 Hurtige sundhedstjek

Aktivitetsovervågning er et fremragende dashboard til hurtige helbredstjek under rutinemæssig administration. Åbn det, kig på oversigtsgraferne, og bekræft, at intet ser unormalt ud.

Denne overfladiske kontrol tager få sekunder og kan afsløre problemer, før de bliver kritiske. Gør det til en del af din daglige rutine.

7.2 Optimale konfigurationsindstillinger

Konfiguration af Aktivitetsovervågning forbedrer både dens anvendelighed og dens ressourceforbrug.

7.2.1 Anbefalede opdateringsintervaller

Tilpas dit opdateringsinterval til dit formål:

• Aktiv fejlfinding: 10 sekunder giver god responstid med rimelig overhead.
• Udvidet overvågning: 30-60 sekunder reducerer serverpåvirkningen under længere observationsperioder.
• Diagnose af kritisk problem: 5 sekunder giver høj granularitet, når hvert sekund tæller, men brug det kortvarigt.
• Regelmæssige sundhedstjek: Manuel opdatering (1 times interval), når du ikke aktivt ser indhold.

Husk at lukke Aktivitetsovervågning, når du er færdig. Hvis du indstiller den til et langt interval og glemmer alt om den, spilder du serverressourcer.

7.2.2 Filtreringsstrategier

Brug filtre til at fokusere på relevante oplysninger og reducere kognitiv belastning:

• Filtrer processer efter Database for kun at se aktivitet mod bestemte databaser.
• Filtrer efter Login at spore en specifik brugers aktivitet.
• Filtrer efter Opgavestatus = KØRER for at skjule inaktive sessioner.
• Filtrer efter Anvendelse at isolere trafik fra specifikke programmer.
• Vis kun ikke-blanke felter i Blokeret af kun at se blokerende situationer.

7.2.3 Kolonnevalg og sortering

Udvikl en systematisk tilgang til gennemgang af Aktivitetsovervågningsdata:

1. Start med oversigt: Tjek graferne for tydelige udsving eller anomalier.
2. Tjek processer for blokering: Sortér efter sessions-id, og søg derefter efter værdier for blokeret af.
3. Gennemgå ressourceventetider: Sortér efter kumulativ ventetid for at identificere flaskehalse i ressourcer.
4. Analysér dyre forespørgsler: Sortér efter forskellige metrikker (CPU, udførelser, læsninger) for at finde forskellige problemtyper.
5. Bekræft med I/O-panelet: Bekræft, om I/O-intensive forespørgsler korrelerer med høj diskaktivitet.

7.3 Integration med andre værktøjer

Aktivitetsovervågning fungerer bedst som en del af et bredere værktøjssæt snarere end som en selvstændig løsning.

7.3.1 Brug med SQL Server Profiler

Aktivitetsmåler og SQL Server Profiler supplerer hinanden godt. Når du identificerer en problematisk session i Aktivitetsovervågning, skal du højreklikke på den og vælge Sporproces i SQL Server Profiler.

Dette starter Profiler med filtre, der allerede er konfigureret til kun at registrere aktiviteten i den pågældende session. Du ser den komplette rækkefølge af udførte sætninger, tidsoplysninger og fejlmeddelelser – detaljer, som Aktivitetsovervågning ikke leverer.

At lære mere om SQL Server Profiler-funktioner og avancerede sporingsteknikker, se vores omfattende SQL Server Profiler-guide.

7.3.2 Supplementering med udvidede begivenheder

Udvidede begivenheder tilbyder detaljeret overvågning med lav overhead, der indsamler oplysninger, som Aktivitetsovervågningen overser. Opret udvidede begivenhedssessioner for at spore specifikke begivenheder som fastlåste situationer, langvarige forespørgsler eller overdreven genkompilering.

Brug Aktivitetsovervågning til øjeblikkelig undersøgelse og Udvidede Hændelser til løbende overvågning og historisk analyse. De to værktøjer imødekommer forskellige behov.

At lære mere om SQL Server Udvidede hændelsesfunktioner og avancerede overvågningsteknikker, se vores omfattende SQL Server Udvidet begivenhedsguide.

7.3.3 Tredjepartsovervågningsløsninger

Kommercielle værktøjer som SolarWinds Database Performance Analyzer, Redgate SQL Monitor og Quest Spotlight tilbyder funktioner, som Activity Monitor mangler: alarmering, historiske trends, kapacitetsplanlægning og automatiseret diagnose.ostics.

Disse værktøjer er værdifulde tilføjelser til Aktivitetsovervågning, ikke erstatninger. Aktivitetsovervågning er stadig nyttig til hurtige kontroller og undersøgelser, selv når sofistikerede overvågningsværktøjer er tilgængelige.

7.4 almindelige fejl at undgå

At forstå almindelige fejl i Aktivitetsovervågningen hjælper dig med at bruge den mere effektivt.

7.4.1 Lad Aktivitetsmåleren køre kontinuerligt

Most En almindelig fejl er at åbne Aktivitetsovervågning og lade den køre på ubestemt tid. Dette spilder serverressourcer og giver kun ringe værdi, da du ikke aktivt ser med.

Luk Aktivitetsovervågning, når du ikke bruger den aktivt. Hvis du har brug for kontinuerlig overvågning, skal du i stedet implementere en passende overvågningsløsning med planlagt dataindsamling.

7.4.2 Overdreven afhængighed af Aktivitetsmåler alene

Aktivitetsovervågning giver ét perspektiv på serverens tilstand. Stol ikke udelukkende på den. Suppler med Windows Performance Monitor for OS-niveau-målinger, udvidede hændelser for detaljeret sporing og analyse af udførelsesplaner for forespørgselsjustering.

Aktivitetsovervågning hjælper dig med at identificere problemer, men at løse dem kræver ofte yderligere værktøjer og dybere analyse.

Lær mere om SQL Server præstationsmåler i vores komplet vejledning.

7.4.3 Ignorering af historiske tendenser

Aktivitetsovervågning viser den aktuelle tilstand, men ydeevneproblemer har ofte mønstre, der kun er synlige over tid. Implementer historisk dataindsamling, så du kan sammenligne aktuelle målinger med baselines og identificere tendenser.

Uden historisk kontekst er du måske ikke klar over, at dagens "normale" CPU-forbrug er 30 % højere end sidste måneds baseline, hvilket indikerer en gradvis forringelse.

8. Fejlfinding af problemer med aktivitetsovervågning

Aktivitetsovervågningen oplever nogle gange problemer. At vide, hvordan man fejlfinder disse problemer, forhindrer frustration.

8.1 Aktivitetsmåleren åbner ikke eller viser ingen data

Når Aktivitetsovervågning åbnes, men viser tomme ruder eller slet ikke åbner, kan flere faktorer være ansvarlige.

8.1.1 Problemer med tilladelser

Most En almindelig årsag til problemer med Aktivitetsovervågning er utilstrækkelige tilladelser. Sådan verificerer og løser du:

1. Tjek dine tilladelser på serverniveau:

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

2. Hvis der ikke returneres nogen rækker, mangler du tilladelsen VIS SERVERSTATUS.
3. Bed en serveradministrator om at give tilladelse:

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

4. Luk og genåbn Aktivitetsovervågning, når tilladelser er givet.

8.1.2 Problemer med versionskompatibilitet

Brug af en gammel version af SQL Server Management Studio for at oprette forbindelse til en nyere SQL Server versionen kan forårsage fejl i Aktivitetsovervågningen. Værktøjet forstår muligvis ikke nye ventetyper eller systemvisningskolonner.

Brug altid en SSMS-version, der matcher eller er nyere end din SQL Server version. Microsoft tilbyder den nyeste SSMS som gratis download separat fra SQL Server Selv.

8.1.3 Firewall- og netværksproblemer

Aktivitetsovervågning kræver forbindelse til SQL Server instans på standardporte (1433 som standard). Hvis du kan oprette forbindelse via Object Explorer, men Aktivitetsovervågning mislykkes, blokerer firewallregler muligvis bestemte forbindelser.

Bekræft, at din klient kan nå SQL Server maskinen på alle nødvendige porte. Kontroller både Windows Firewall og eventuelle netværksfirewalls mellem din klient og server.

8.2 Aktivitetsovervågning permanent sat på pause

Et almindeligt problem, især i SQL Server 2019, åbner Aktivitetsovervågning i pausetilstand og nægter at genoptage.

8.2.1 Forståelse af pausetilstanden

Når Aktivitetsovervågningen sættes på pause, viser alle ruder statussen "Pauset" med en genoptag-knap, der muligvis ikke fungerer. Dette forhindrer dig i at se nogen serveraktivitet.

Den pausede tilstand opstår normalt på grund af problemer med tilladelser, begrænsninger i fjernforbindelser eller fejl i SSMS-versionen snarere end en bevidst pausehandling.

8.2.2 Almindelige årsager

Aktivitetsovervågningen kan gå i permanent pausetilstand på grund af:

• Manglende tilladelse til at se servertilstand på nyere ruder, der er tilføjet for nylig SQL Server versioner
• Fjernforbindelser deaktiveret på SQL Server instans
• Godkendelsesfejl for specifikke systemforespørgsler
• Fejl i specifikke SSMS-builds, især 18.0 til 18.3
• Forbindelsesproblemer mellem klient og server

8.2.3 Løsningstrin

Sådan løser du problemer med Aktivitetsovervågningens pausetilstand:

1. Opdater SSMS: Download og installer det nyeste SQL Server Management Studio-versionen fra Microsofts hjemmeside. Mange fejl i pausetilstande blev rettet i senere udgivelser.
2. Bekræft tilladelser: Sørg for, at du har tilladelserne VIS SERVERSTATUS og VIS ALLE DEFINITIONER.
3. Tjek fjernforbindelser: Bekræft at SQL Server instansen tillader fjernforbindelser:

   EXEC sp_configure 'remote access';
   

   Hvis værdien er 0, skal du bede en administrator om at aktivere den.

4. Restart SSMS: Nogle gange lukker man bare alle vinduer ogtarTing SQL Server Management Studio løser problemet.
5. Opret forbindelse med Windows-godkendelse: Hvis du bruger SQL-godkendelse, skal du i stedet prøve Windows-godkendelse, da det nogle gange omgår problemer med pausering relateret til godkendelse.

8.3 Ydelsesproblemer ved brug af Aktivitetsovervågning

Hvis Aktivitetsovervågningen i sig selv bliver langsom eller forårsager forringelse af serverens ydeevne, er det nødvendigt med justering.

8.3.1 Reduktion af overvågningsomkostninger

Sådan minimerer du Aktivitetsovervågningens påvirkning:

1. Øg opdateringsintervallet til 30 sekunder eller 1 minut.
2. Luk ruder, du ikke aktivt bruger, ved at klikke på knappen Skjul.
3. Når ruder er skjult, forespørger Aktivitetsovervågning ikke data for dem.
4. Undgå at køre flere Aktivitetsovervågningsinstanser samtidigt.
5. Luk Aktivitetsovervågning helt, når du ikke aktivt undersøger problemer.

8.3.2 Alternative lette overvågningsmetoder

Hvis Aktivitetsovervågning er for ressourcekrævende for dit miljø, kan du overveje alternativer:

• Forespørg DMV'er direkte: Skriv specifikke T-SQL-forespørgsler, der kun henter de oplysninger, du har brug for.
• Brug sp_WhoIsActive: Denne lagrede procedure er stærkt optimeret og har typisk lavere overhead end Aktivitetsovervågning.
• Implementer prøveudtagning: Planlæg SQL Agent-job, der indsamler snapshots af DMV-data med jævne mellemrum og gemmer resultaterne i tabeller til senere analyse.
• Overvåg sekundære replikaer: In Altid til tilgængelighedsgrupper, kør Aktivitetsovervågning mod en læsbar sekundær i stedet for den primære.

8.4 Unøjagtige eller manglende oplysninger

Nogle gange viser Aktivitetsovervågning oplysninger, der virker forkerte eller ufuldstændige.

8.4.1 Bekræftelse af data med DMV'er

Når resultaterne fra Aktivitetsovervågningen virker mistænkelige, skal du verificere dem ved at forespørge direkte på de underliggende DMV'er. Hvis f.eks. ruden Processer ikke viser nogen blokering, men brugerne rapporterer det, skal du forespørge:

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

Hvis denne forespørgsel viser en blokering, som Aktivitetsovervågningen har overset, har du bekræftet et visningsproblem.

8.4.2 Forståelse af timingen for dataopdatering

Husk, at Aktivitetsovervågning viser snapshots. En forespørgsel, der kørte mellem opdateringsintervaller, vises ikke i Seneste dyre forespørgsler, medmindre dens udførelsesplan forbliver i cachen.

På samme måde afspejler ventestatistikker i ruden Ressourceventetider akkumulering siden sidste snapshot. Hurtigt skiftende arbejdsbelastninger kan vise forskellige mønstre ved hver opdatering.

9. Avancerede aktivitetsmålerteknikker

Erfarne databaseadministratorer bruger Aktivitetsovervågning på sofistikerede måder til at udtrække maksimal diagnose.ostic-værdi.

9.1 Kombination af flere ruder til rodårsagsanalyse

Den virkelige kraft i Aktivitetsovervågning fremkommer, når du korrelerer information på tværs af flere ruder for at forstå komplekse ydeevneproblemer.

9.1.1 Korrelation af ventetider med processer

Når ruden Ressourceventetider viser lange ventetider i en kategori, skal du bruge ruden Processer til at identificere, hvilke sessioner der oplever disse ventetider:

1. Bemærk ventekategorien med høj kumulativ ventetid (f.eks. "Lås").
2. Skift til ruden Processer.
3. Sorter efter Ventetype for at gruppere sessioner efter deres nuværende ventetid.
4. Søg efter sessioner, der viser ventetyper i den problematiske kategori.
5. For disse sessioner, undersøg Vent ressource kolonne for at se, hvilke databaseobjekter der er involveret.
6. Højreklik og vælg Detaljer for at se forespørgselsteksten.

Denne korrelation hjælper dig med at gå fra "vi har låseventstider" til "denne specifikke forespørgsel venter på låse i denne tabel".

9.1.2 Forbindelse af dyre forespørgsler med I/O-problemer

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

1. Bemærk hvilke databasefiler der har høje læse- eller skrivehastigheder på MB/sek.
2. Skift til Seneste dyre forespørgsler.
3. Sorter efter Fysiske aflæsninger/sek. at identificere forespørgsler, der læser meget fra disken.
4. Filtrer eller identificer visuelt forespørgsler, der kører mod databasen med høj I/O.
5. Undersøg disse forespørgslers udførelsesplaner for tabelscanninger eller manglende indeks, der forårsager overdreven I/O.

Denne analyse med flere ruder forbinder symptomer (høj disk-I/O) med årsager (specifikke ineffektive forespørgsler).

9.2 Brug af Aktivitetsovervågning til kapacitetsplanlægning

Selvom Aktivitetsovervågning ikke gemmer historiske data, kan du bruge den strategisk til observationer i forbindelse med kapacitetsplanlægning.

9.2.1 Identifikation af spidsbelastningsmønstre

Overvåg serveraktivitet på forskellige tidspunkter af dagen for at identificere brugsmønstre:

1. Åbn Aktivitetsovervågning i kendte spidsbelastningstider.
2. Bemærk de maksimale værdier i grafen for % processortid.
3. Registrer det maksimale antal ventende opgaver.
4. Observer batchforespørgsler/sek. i spidsbelastningsperioder.
5. Dokumentér de mest travle databaser i ruden Processer.
6. Gentag uden for myldretiden for sammenligning.

Hvis processorens spidsbelastningstid konsekvent overstiger 80 %, nærmer du dig CPU-kapacitetsgrænserne. Tilsvarende indikerer stigende ventetider en stigende ressourcekonkurrence.

9.2.2 Analyse af ressourcetendenser

Selvom Aktivitetsovervågning viser den aktuelle status, kan du bruge den til stikprøvekontrol af tendenser ved at registrere nøgletal over tid:

• Tag skærmbilleder af oversigtsruden på samme tidspunkt hver dag
• Registrer topværdier fra hver graf
• Sammenlign uge for uge for at identificere væksttendenser
• Hold øje med gradvise stigninger i gennemsnitlig processortid eller I/O-hastigheder

Denne manuelle trendanalyse supplerer mere sofistikerede overvågningsløsninger og hjælper med at retfærdiggøre kapacitetsudvidelse.

9.3 Dokumentation af præstationsgrundlinjer

Etablering af grundlæggende præstationsmålinger hjælper dig med at genkende, hvornår ydeevnen forringes.

9.3.1 Registrering af baseline-målinger

I perioder med kendt god ydeevne skal du dokumentere Aktivitetsovervågningsmålinger:

1. Åbn Aktivitetsovervågning under normal forretningsdrift (ikke i spidsbelastningsperioder eller uden for spidsbelastningsperioder).
2. Værdier i ruden Oversigt over post:
   • Typisk % processortidsområde
   • Gennemsnitligt antal ventende opgaver
   • Normal database I/O-hastighed
   • Typiske batchforespørgsler/sek.
3. Bemærk kategorierne i ruden Ressourceventer, der viser most ventetid.
4. Dokumenter antallet af aktive processer typisk i ruden Processer.
5. Registrer repræsentative forespørgselsudførelsesmålinger fra nyligt dyre forespørgsler.

Gem denne grundlæggende dokumentation til senere brug, når du undersøger ydeevneproblemer.

9.3.2 Sammenligning af nuværende vs. basisydelse

Når der opstår problemer med ydeevnen, skal du sammenligne de aktuelle Aktivitetsovervågningsaflæsninger med din dokumenterede basislinje:

• Er processortiden betydeligt højere end basislinjen? Fokuser på CPU-intensive forespørgsler.
• Er venteopgaver 2-3 gange så høje som basisniveauet? Undersøg ressourceventetider.
• Er I/O væsentligt højere? Tjek I/O-ruden for datafiler og dyre forespørgsler.
• Er batchanmodninger lavere end baseline i spidsbelastningsperioder? Kig efter blokeringer eller forbindelsesproblemer.

Denne sammenligning hjælper dig med at identificere, hvad der er ændret, og fokusere fejlfindingsindsatsen i den rigtige retning.

9.4 Oprettelse af brugerdefinerede overvågningsworkflows

Udvikle systematiske arbejdsgange til almindelige undersøgelsesscenarier for at sikre grundig og gentagelig analyse.

9.4.1 Trinvis undersøgelsesproces

Når brugere rapporterer problemer med ydeevnen, skal du følge en ensartet arbejdsgang:

1. Hurtigt helbredstjek: Åbn Aktivitetsovervågning, og scan graferne i Oversigtsruden for åbenlyse afvigelser.
2. Tjek for blokering: Udvid ruden Processer, filtrer efter Ikke-tomme felter i kolonnen Blokeret af.
3. Identificer ressourcekonflikter: Gennemgå ruden Ressourceventetider sorteret efter ventetid.
4. Find dyre forespørgsler: Undersøg de seneste dyre forespørgsler sorteret efter CPU, derefter udførelse og derefter læsning.
5. Korrelér I/O-mønstre: Krydsreferencer dyre forespørgsler med aktivitet i datafil I/O-ruden.
6. Dokumentfund: Tag skærmbilleder og registrer relevante sessions-id'er, ventetyper og forespørgselsdetaljer.
7. Dybt dyk: Brug Profiler-spor, analyse af udførelsesplaner og DMV-forespørgsler til detaljeret undersøgelse af identificerede problemer.

9.4.2 Eskaleringskriterier

Fastlæg kriterier for, hvornår problemer skal eskaleres kontra fortsat undersøgelse:

• Eskaler straks: Blokeringskæder, der varer >5 minutter, processortid på 100 % i >2 minutter, kritiske systemprocesser viser SUSPENDED-tilstand.
• Eskalér med analyse: Tilbagevendende dyre forespørgsler, der bruger >50% af CPU'en, konstant høje I/O-responstider >50ms, hukommelsestildelinger mislykkes gentagne gange.
• Undersøg yderligere: Temporary-ventetider, der løses inden for få minutter, forespørgsler med suboptimale planer, men acceptabel ydeevne, mindre blokering <30 sekunders varighed.

10. Aktivitetsmåler i forskellige SQL Server versioner

Aktivitetsovervågning har udviklet sig på tværs af SQL Server versioner, hvor hver udgivelse bringer forbedringer og lejlighedsvis nye problemer.

10.1 Aktivitetsmåler i SQL Server 2008 og senere

SQL Server I 2008 introduceredes det moderne design af Aktivitetsovervågning, der stort set er uændret i dag.

10.1.1 Nye funktioner introduceret i SQL Server 2008

SQL Server Det nye design af Aktivitetsovervågningen i 2008 medførte betydelige forbedringer:

• Grafisk dashboard med realtidsdiagrammer i oversigtsruden
• Udvidelig/skjulbar rudegrænseflade, der erstatter den gamle gittervisning
• Panelet Seneste dyre forespørgsler, der viser samlede data om forespørgselsydelse
• Datafil I/O-rude til overvågning af diskaktivitet pr. fil
• Forbedret ressourceventepanel med ventekategorisering
• Højreklik på kontekstmenuer til proceshandlinger som at afslutte sessioner og starte Profiler
• Konfigurerbare opdateringsintervaller fra 1 sekund til 1 time

Disse ændringer forvandlede Aktivitetsovervågning fra en simpel procesliste til et omfattende overvågningsdashboard.

10.1.2 Ændringer fra SQL Server 2005

SQL Server Aktivitetsovervågningen fra 2005 var langt mere begrænset:

• Adgang via administrationsmappen i Objektstifinder i stedet for værktøjslinjen
• Enkelt gitter, der viser en liste over processer med grundlæggende oplysninger
• Ingen grafiske diagrammer eller flere ruder
• Ingen dyre forespørgsler eller I/O-overvågning
• Begrænset ventestatistikinformation

Redesignet i 2008 repræsenterede en komplet nytænkning snarere end en trinvis forbedring.

10.2 Aktivitetsmåler i SQL Server 2014/2016

SQL Server I 2014 og 2016 blev der foretaget trinvise forbedringer af Aktivitetsovervågningens underliggende dataindsamling, men der blev foretaget få visuelle ændringer.

10.2.1 Forbedringer og forbedringer

Vigtigste forbedringer i disse versioner omfattede:

• Bedre ydeevne ved overvågning af servere med tusindvis af cachelagrede planer
• Forbedrede filtreringsfunktioner i ruden Processer
• Forbedret nøjagtighed af aggregering af ventestatistik
• Bedre håndtering af kolonnesortering og filtrering med store resultatsæt
• Mere effektive DMV-forespørgsler reducerer overvågningsomkostninger

Kernegrænsefladen forblev konsistent med SQL Server 2008, opretholdelse af fortrolighed for administratorer.

10.3 Aktivitetsmåler i SQL Server 2019/2022

Nye SQL Server versioner fortsætter Aktivitetsovervågningens udvikling med fokus på ydeevne og stabilitet.

10.3.1 Seneste funktioner og muligheder

SQL Server Aktivitetsovervågningen for 2019 og 2022 inkluderer:

• Understøttelse af nye ventetyper introduceret i disse versioner
• Forbedret gengivelsesydelse i SSMS ved hjælp af WPF-teknologi
• Bedre håndtering af et stort antal aktive sessioner
• Forbedret kompatibilitet med cloud SQL-platforme
• Mere præcise CPU- og I/O-målinger

10.3.2 Kendte problemer i nyere versioner

SQL Server 2019 introducerede adskillige fejl i Aktivitetsovervågning:

• Permanent pausetilstand: Aktivitetsovervågning går ofte i pausetilstand og genoptages ikke, især i SSMS 18.0-18.3. Rettet i senere SSMS-versioner.
• Fejl ved fjernforbindelse: Nogle konfigurationer forhindrer Aktivitetsovervågning i at åbne på eksterne instanser. Løsninger omfatter aktivering af specifikke sporingsflag eller brug af nyere SSMS-builds.
• Tilladelsesproblemer: Nye systemvisninger kræver yderligere tilladelser, der ikke er tydeligt dokumenteret, hvilket forårsager tomme visninger, selv med VIS SERVERSTAND.

Brug altid den nyeste SSMS-version, når du arbejder med SQL Server 2019 og 2022 for at undgå disse problemer.

11. Praktiske anvendelsesscenarier og eksempler

Eksempler fra den virkelige verden viser, hvordan man effektivt anvender Aktivitetsovervågning i almindelige fejlfindingsscenarier.

11.1 Casestudie: Diagnosticering af en langsom webapplikation

Et udviklingsteam rapporterer, at deres webapplikation er blevet uacceptabelt langsom, med sideindlæsninger, der tager 20-30 sekunder i stedet for de normale 2-3 sekunder.

11.1.1 Indledende undersøgelse med oversigtspanel

Åbn Aktivitetsovervågning, og undersøg oversigtsruden:

1. Grafen for % processortid viser et CPU-forbrug på 85-95%, hvilket er betydeligt højere end den normale basislinje på 30-40%.
2. Venteopgaver svinger mellem 10-20 opgaver, mod en normal basislinje på 0-3.
3. Database I/O viser moderat aktivitet omkring 50 MB/s.
4. Batchanmodninger/sek. er lavere end forventet på 100/sek., sammenlignet med typiske 300-400/sek. i åbningstiden.

Dette mønster tyder på en CPU-flaskehals med ressourcekonflikter, der forårsager reduceret gennemløbshastighed. Serveren arbejder hårdt, men behandler ikke mange anmodninger.

11.1.2 Identifikation af den problematiske forespørgsel

Udvid ruden Seneste dyre forespørgsler og sorter efter Udførelser/min:

1. Den øverste forespørgsel viser 15,000 henrettelser i minuttet.
2. Højreklik og vælg Rediger forespørgselstekst at undersøge forespørgslen.
3. Forespørgslen er en simpel SELECT-sætning, der henter en enkelt brugerpost: SELECT * FROM Users WHERE UserId = @UserId.
4. Denne forespørgsel bør ikke udføres 15,000 gange i minuttet ved normal programbrug.

Højreklik på forespørgslen, og vælg Vis udførelsesplanPlanen viser en tabelscanning af tabellen Brugere med en advarsel om et manglende indeks i kolonnen Bruger-ID.

Filtrer ruden Processer efter Program for kun at vise webapplikationens forbindelser. Flere sessioner viser, at den samme forespørgsel kører gentagne gange.

11.1.3 Løsning og verifikation

Problemet stammer fra to ting: for mange forespørgselsudførelser og et manglende indeks. Løsningstrin:

1. Opret det manglende indeks:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Kontakt udviklingsteamet om de overdrevne udførelser. Undersøgelsen afslører et N+1-forespørgselsproblem i applikationskoden, hvor en løkke henter brugeroplysninger for hvert element på en liste.
3. Rediger applikationen at batchere brugeropslagene i en enkelt forespørgsel ved hjælp af en IN-klausul eller en tabelværdiparameter.
4. Bekræft rettelsen ved at overvåge Aktivitetsovervågning efter implementering. CPU-forbruget falder til 35-40%, antallet af udførelser pr. minut falder til 200-300, og applikationens svartider vender tilbage til det normale.

11.2 Casestudie: Løsning af et blokeringsproblem

Brugere rapporterer, at ordreindtastningssystemet periodisk fryser i 30-60 sekunder, før det genoptager normal drift.

11.2.1 Detektering af blokeringskæden

Åbn Aktivitetsovervågning under en af ​​disse frysehændelser, og udvid ruden Processer:

1. Sorter efter Sessions ID for at se alle organiserede sessioner.
2. Flere sessioner viser værdier i Blokeret af kolonne, der alle peger på sessions-ID 73.
3. Session 73 viser '1' i Hovedblokerer kolonne, der bekræfter, at det er den grundlæggende årsag.
4. Ventetype For blokerede sessioner vises LCK_M_X, hvilket indikerer, at de venter på eksklusive låse.
5. Vent ressource Kolonnen viser, at blokeringen er i tabellen Ordrer.

11.2.2 Analyse af årsagen

Højreklik på Session 73 og vælg Detaljer for at se kommandoen:

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

Denne opdatering er en del af et batchbehandlingsjob, der kører hver time. Kontrol af Login Kolonnen bekræfter, at sessionen tilhører batchbehandlingstjenestens konto.

Forespørgslen holder låse på ordretabellen, mens den behandler tusindvis af ordrer. Ventetid for blokerede sessioner stiger støt, hvilket bekræfter, at denne langvarige operation er problemet.

11.2.3 Implementering af rettelsen

Kortsigtet løsning:

1. Dokument session 73's detaljer, inklusive forespørgselstekst og varighed.
2. Lad opdateringen fuldføres naturligt, da det er legitim batchbehandling.
3. Efter afslutningen skal du kontrollere, at blokerede sessioner er ryddet, og at normal drift genoptages.

Implementerede langsigtede løsninger:

1. Omplanlæg batchjobbet at køre uden for myldretiden (kl. 2-4 om morgenen i stedet for i åbningstiden).
2. Ændr batchbehandlingen at opdatere ordrer i mindre batches på 100 poster ad gangen og dermed frigive låse mellem batches.
3. Tilføj et indeks i OrderId-kolonnen for at fremskynde opdateringshandlingen.
4. Overvej SNAPSHOT-isolering for læseoperationer for at reducere blokeringspåvirkningen.

11.3 Casestudie: Identifikation af overdreven forespørgselskørsel

Databaseovervågning viser, at CPU-forbruget gradvist er steget i løbet af den seneste måned, men der er ikke sket nogen tydelige ændringer i applikationskoden.

11.3.1 Opdagelse af unormale henrettelsestællinger

Åbn Aktivitetsovervågning, og undersøg ruden Seneste dyre forespørgsler:

1. Sorter efter Henrettelser/min at se m'etost ofte udførte forespørgsler.
2. Den øverste forespørgsel viser 37,000 henrettelser i minuttet – langt højere end nogen anden forespørgsel.
3. Højreklik og vælg Rediger forespørgselstekst.
4. Forespørgslen henter oplysninger om produktkategori:

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

5. Denne simple forespørgsel burde være hurtig og cachebar, men den udføres titusindvis af gange i minuttet.

11.3.2 Sporing til applikationskode

I ruden Processer skal du finde sessioner, der udfører denne forespørgsel:

1. Bemærk Anvendelse Kolonnen viser "ProductCatalogService".
2. Højreklik på en af ​​disse sessioner, og vælg Sporproces i SQL Server Profiler.
3. SQL Profiler afslører, at forespørgslen udføres gentagne gange i hurtig rækkefølge med forskellige CategoryId-værdier.
4. Kontakt udviklingsteamet, der administrerer ProductCatalogService, for kodegennemgang.

Kodegennemgang afslører problemet: en nylig ændring henter produktlister med kategorier. For hvert produkt i resultatsættet (ofte 1,000+ produkter) foretager koden et separat databasekald for at hente kategorioplysninger – et klassisk N+1-forespørgselsproblem.

11.3.3 Optimering af applikationen

Implementer en korrekt løsning:

1. Rediger applikationsforespørgslen Sådan bruger du en JOIN til at hente produkter og deres kategorier i et enkelt databasekald:

   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. Implementer den opdaterede kode og overvåg Aktivitetsovervågning.
3. Bekræft rettelsen: Antallet af udførelser pr. minut for kategoriforespørgslen falder fra 37,000 til under 100, og det samlede CPU-forbrug falder med 40 %.
4. Dokumentér den lærte lektie og del med udviklingsteamet for at forhindre lignende problemer i fremtidige kodeændringer.

12. Opdag potentiel databasekorruption

Selvom Aktivitetsovervågning ikke er designet specifikt til at registrere databasekorruption, kan visse mønstre i visningen tyde på underliggende problemer med korruption, der kræver yderligere undersøgelse.

12.1 Symptomer på potentiel databasekorruption

Hvis der er en databasefejl, og den tilgås, kan du lejlighedsvis se:

1. I procesruden:

• Sessioner sidder fast i AFBRYDT tilstand med usædvanlige ventetyper
• Processer, der viser fejltilstande
• Forespørgsler mislykkes gentagne gange

2. I ruden Ressourceventer:

• Usædvanlige I/O-relaterede ventetyper, der kan indikere diskproblemer (selvom dette sandsynligvis indikerer hardwareproblemer snarere end logisk korruption)

3. I de seneste dyre forespørgsler:

• Forespørgsler med unormalt høje fysiske læsninger, hvis de gentagne gange forsøger at læse beskadigede sider

12.2 Yderligere kontrol med DBCC CHECKDB

Når Aktivitetsovervågning viser symptomer, der tyder på potentiel beskadigelse, skal du straks køre DBCC CHECKDB for at verificere databaseintegriteten. Denne kommando scanner alle databasesider, validerer kontrolsummer og kontrollerer for logiske konsistensfejl.

For at lære mere om, hvordan du bruger DBCC CHECKDB til at kontrollere og rette databasefejl, se vores omfattende DBCC CHECKDB-guide.

12.3 Reparation med professionelle værktøjer

Hvis DBCC CHECKDB bekræfter databasekorruption, har du flere muligheder for reparation:

• Den foretrukne fremgangsmåde er at gendanne fra en kendt fungerende sikkerhedskopi. Se vores omfattende guide til sikkerhedskopiering og gendannelse SQL Server databaser.
• Ved mindre beskadigelse kan DBCC CHECKDB med REPAIR_REBUILD muligvis løse problemerne.
• For kritiske databaser uden nylige sikkerhedskopier, professionel SQL-gendannelsessoftware og tjenester kan ofte gendanne data, som indbyggede reparationsmuligheder ikke kan.

13. konklusion

SQL Server Aktivitetsovervågning er et uvurderligt værktøj for databaseadministratorer, der giver øjeblikkelig indsigt i serverens ydeevne og hjælper med at diagnosticere problemer hurtigt og effektivt.

13.1 Sammenfatning af nøglepunkter

Igennem denne guide har vi undersøgt, hvordan Aktivitetsovervågning hjælper dig med at forstå og fejlfinde SQL Server ydeevne:

• Aktivitetsovervågning giver realtidsindsigt i processer, ventetider, forespørgsler og I/O via en organiseret, grafisk brugerflade.
• De fem ruder – Oversigt, Processer, Ressourceventetider, Datafil I/O og Seneste dyre forespørgsler – tilbyder hver især unikke perspektiver på serveraktivitet.
• Almindelige fejlfindingsscenarier som overdreven forespørgselskørsel, blokeringskæder og høj CPU-brug bliver håndterbare med systematisk undersøgelse af Aktivitetsovervågning.
• Selvom Aktivitetsovervågning er kraftfuld, har den begrænsninger, herunder mangel på historiske data, gruppering af ventetyper og overvågningsoverhead, der påvirker dens anvendelse.cability.
• Ved at supplere Aktivitetsovervågning med DMV-forespørgsler, sp_WhoIsActive, Extended Events og potentielt tredjepartsværktøjer skabes en omfattende overvågningsstrategi.
• Ved at følge bedste praksis for opdateringsintervaller, lukke Aktivitetsovervågning, når den ikke er i brug, og kombinere flere ruder for korrelation maksimeres værdien, samtidig med at effekten minimeres.

13.2 Aktivitetsmåler som en del af din værktøjskasse

Aktivitetsovervågning bør fungere som dit første responsværktøj til ydeevneundersøgelser, ikke dit eneste værktøj. Dens styrke ligger i at give øjeblikkelig overblik under aktiv fejlfinding, hvilket hjælper dig med hurtigt at afgøre, om databasen er flaskehalsen, og identificere hvilke specifikke aspekter, der kræver dybere undersøgelse.

Tænk på Aktivitetsovervågning som et analogt instrumentbræt i din bil – det fortæller dig med det samme, hvis noget er galt, og hjælper dig med at identificere det generelle problemområde. Ligesom din bils instrumentbræt ikke fortæller dig præcis, hvorfor motorlampen lyser, peger Aktivitetsovervågning dig mod problemer uden altid at afsløre deres fulde årsag. Den dybere analyse kræver yderligere værktøjer og ekspertise.

Integrer Aktivitetsovervågning i et bredere værktøjssæt, der inkluderer analyse af udførelsesplaner, sporing af ventestatistik, historiske overvågningsløsninger og bedste praksis for ydeevne. Brug det sammen med korrekte indekseringsstrategier, teknikker til forespørgselsoptimering og kapacitetsplanlægning.

13.3 Fortsættelse af din læringsrejse

At mestre Aktivitetsovervågning er blot ét skridt i retning af at blive en effektiv databaseadministrator. Fortsæt med at udvikle dine færdigheder ved at:

• Lære at fortolke udførelsesplaner og identificere ineffektive operationer
• Forståelse SQL Server ventestatistikker og deres konsekvenser
• Studering af indeksdesign og optimeringsteknikker
• Udforskning SQL Server's arkitektur og hvordan den behandler forespørgsler
• Øvelse af systematiske fejlfindingsmetoder
• Opbygning af erfaring med udvidede hændelser til detaljeret sporing
• Forståelse af transaktionsisoleringsniveauer og deres indflydelse på ydeevnen

Hver præstationsundersøgelse med Aktivitetsovervågning lærer dig noget nyt om, hvordan SQL Server fungerer, og hvordan applikationer interagerer med databaser. Dokumenter dine resultater, del viden med kolleger, og byg et bibliotekraraf løsninger på almindelige problemer.

13.4 Yderligere ressourcer

Udvid din viden med disse værdifulde ressourcer:

• Åbn Activity Monitor i SQL Server Management Studio (SSMS) : Officiel SQL Server dokumentation om, hvordan man åbner Aktivitetsovervågning i SQL Server Ledelsesstudie (SSMS).
• Activity Monitor : Officiel SQL Server dokument om, hvordan man bruger Aktivitetsovervågning.

14. Ofte stillede spørgsmål (FAQ)

Q: Hvad er? SQL Server ActivityMonitor?

A: SQL Server Aktivitetsovervågning er et indbygget værktøj i SQL Server Management Studio, der viser information i realtid om processer, der kører på en SQL Server instans og deres indvirkning på serverressourcer. Det indeholder et grafisk dashboard med fem ruder, der viser forskellige aspekter af serveraktivitet, herunder processorforbrug, ventende opgaver, I/O-hastigheder, aktive sessioner og dyre forespørgsler.

Q: Hvordan åbner jeg Aktivitetsovervågning i SSMS?

A: Du kan åbne Aktivitetsovervågning på fire måder: (1) Klik på ikonet Aktivitetsovervågning i SSMS-værktøjslinjen, (2) Højreklik på din SQL Server instansnavn i Object Explorer og vælg Activity Monitor, (3) Tryk Ctrl + andre + A, eller (4) Konfigurer SSMS til at starte det automatisk via Værktøjer -> Indstillinger -> Miljø -> Starrør.

Q: Hvilke tilladelser skal jeg bruge for at bruge Aktivitetsovervågning?

A: Du har brug for SE SERVERSTATUS tilladelse til at se most Oplysninger om aktivitetsovervågning. For ruden Datafil I/O skal du også bruge enten OPRET DATABASE, ÆNDRE ENHVER DATABASE eller SE ENHVER DEFINITION tilladelser. Uden disse tilladelser kan Aktivitetsovervågning åbne, men vise tomme ruder.

Q: Hvorfor er min Aktivitetsovervågning sat på pause eller virker ikke?

A: Aktivitetsovervågningen sætter typisk på pause på grund af problemer med tilladelser, forældede SSMS-versioner eller deaktiverede fjernforbindelser. Sådan løser du problemet: (1) Opdater til den nyeste SSMS-version, (2) Bekræft, at du har tilladelsen VIS SERVERSTAND, (3) Kontroller, at fjernforbindelser er aktiveret på SQL Server eksempel, (4) Restart SSMS, og (5) Prøv at oprette forbindelse med Windows-godkendelse i stedet for SQL-godkendelse, hvis det er relevant.cabdem.

Q: Hvad er forskellen mellem Aktivitetsovervågning og sp_WhoIsActive?

A: Aktivitetsovervågning er et grafisk værktøj indbygget i SSMS, der leverer organiserede ruder til forskellige overvågningsaspekter. sp_WhoIsActive er en gratis, community-oprettet, lagret procedure, der returnerer detaljerede sessionsoplysninger i et enkelt resultatsæt med mere specifikke ventetyper, blokeringsdetaljer og tilpasningsmuligheder end Aktivitetsovervågning. Aktivitetsovervågning er bedre til visuel udforskning, mens sp_WhoIsActive udmærker sig ved scriptet overvågning og giver mere detaljerede oplysninger.

Q: Påvirker Aktivitetsovervågning serverens ydeevne?

A: Ja, Aktivitetsovervågning har målbart overhead, fordi den forespørger system-DMV'er ved hvert opdateringsinterval. Effekten stiger med lavere opdateringshastigheder – Microsoft advarer om, at intervaller under 10 sekunder kan påvirke serverens ydeevne. Luk altid Aktivitetsovervågning, når du ikke aktivt bruger den, og overvej opdateringsintervaller på 30-60 sekunder på produktionsservere under høj belastning.

Q: Kan jeg hente Aktivitetsovervågningsdata ved hjælp af T-SQL?

A: Ja, Aktivitetsovervågning forespørger på dynamiske systemadministrationsvisninger som sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats og sys.dm_exec_query_stats. Du kan forespørge disse DMV'er direkte ved hjælp af T-SQL for at hente tilsvarende oplysninger programmatisk, hvilket muliggør brugerdefinerede overvågningsscripts og automatiseret dataindsamling.

Q: Hvad er standardopdateringsintervallet?

A: Standardopdateringsintervallet er 10 sekunder. Du kan ændre dette ved at højreklikke et vilkårligt sted i oversigtsruden og vælge Opdateringsintervalog vælge mellem foruddefinerede muligheder: 1 sekund, 5 sekunder, 10 sekunder, 30 sekunder, 1 minut eller 1 time. Kortere intervaller giver flere visninger i realtid, men øger overvågningsomkostningerne.

Q: Hvordan kan jeg automatisk åbne Aktivitetsovervågning på SSMS'ertarop?

A: Konfigurer automatisk start via SSMS-indstillinger: Naviger til Værktøjer -> Indstillinger -> Miljø -> Starrør, Vælg derefter Åbn Objektstifinder og Aktivitetsovervågning fra På starrør rullemenuen. Aktivitetsovervågning åbnes automatisk, hver gang du opretter forbindelse til en server i SSMS.

Q: Hvad er begrænsningerne ved Aktivitetsovervågning?

A: Vigtigste begrænsninger inkluderer: (1) Ingen lagring af historiske data eller tendenser, (2) Ventetyper er grupperet i kategorier i stedet for at blive vist specifikt, (3) Nogle ventetyper som CXPACKET vises muligvis ikke, (4) Snapshots på tidspunkter kan overse forbigående problemer, (5) Overvågningsoverhead kan påvirke travle servere, (6) Ingen advarselsmekanisme til proaktiv overvågning, og (7) Kan ikke aggregere data på tværs af flere SQL Server tilfælde. Til disse behov kan Aktivitetsovervågning suppleres med udvidede hændelser, dataindsamlingssæt eller overvågningsværktøjer fra tredjepart.

---

Om forfatteren

Yuan Sheng er en senior databaseadministrator (DBA) med over 10 års erfaring inden for SQL Server miljøer og virksomhedsdatabaseadministration. Han har med succes løst hundredvis af databasegendannelsesscenarier på tværs af finansielle tjenester, sundhedsvæsenet og produktionsorganisationer.

Yuan har specialiseret sig i SQL Server databasegendannelse, løsninger med høj tilgængelighedog ydeevneoptimering. Hans omfattende praktiske erfaring omfatter administration af databaser på flere terabyte, implementering af Always On Availability Groups og udvikling af automatiserede backup- og gendannelsesstrategier til missionskritiske forretningssystemer.

Gennem sin tekniske ekspertise og praktiske tilgang fokuserer Yuan på at skabe omfattende vejledninger, der hjælper databaseadministratorer og IT-professionelle med at løse komplekse SQL Server udfordringer effektivt. Han holder sig opdateret med det nyeste SQL Server udgivelser og Microsofts udviklende databaseteknologier, og tester regelmæssigt gendannelsesscenarier for at sikre, at hans anbefalinger afspejler bedste praksis i den virkelige verden.

Har spørgsmål vedr SQL Server gendannelse eller brug for yderligere vejledning i fejlfinding af databaser? Yuan er velkommen feedback og forslag for at forbedre disse tekniske ressourcer.