SQL Server Aktivitetsmonitor: En komplett guide för databaseringsadministratörer [2026]

1. Inledning

1.1 Vad är SQL Server ActivityMonitor?

SQL Server Aktivitetsmonitorn är ett inbyggt diagnostikverktyg i SQL Server Management Studio som visar information om SQL Server processer och deras effekt på serverns prestanda. Det låter dig spåra SQL Server processer, övervaka resursväntningar, analysera dyra frågor och observera I/O-mönster – allt från ett enda gränssnitt.

1.2 Varför använda SQL Server ActivityMonitor?

Aktivitetsmonitorn fungerar som din första försvarslinje vid felsökning av prestandaproblem. Den ger omedelbar insikt i vad som händer på din SQL Server instans utan att kräva komplexa T-SQL-frågor eller verktyg från tredje part.

Verktyget utmärker sig genom att snabbt identifiera vanliga problem som blockerande sessioner, CPU-intensiva frågor, överdrivna frågekörningar och I/O-flaskhalsar. När användare rapporterar att ett program är långsamt eller inte svarar hjälper Aktivitetsövervakning dig att avgöra om databasservern är boven i dramat.

För databasadministratörer som inte arbetar med SQL Server Dagligen erbjuder Aktivitetsövervakning en lättillgänglig ingångspunkt för att förstå serveraktivitet. Även erfarna databasadministratörer använder den som utgångspunkt för prestandaundersökningar.

1.3 Aktivitetsmonitor jämfört med andra övervakningsverktyg

Även om Aktivitetsmonitorn är värdefull är det viktigt att förstå hur den står sig i jämförelse med andra övervakningsalternativ:

Aktivitetsmonitor jämfört med sp_WhoIsActive: Aktivitetsmonitorn har ett grafiskt gränssnitt med flera rutor, medan sp_WhoIsActive är en omfattande lagrad procedur som erbjuder mer detaljerad information i en enda resultatuppsättning. sp_WhoIsActive visar specifika väntetyper som Aktivitetsmonitorn grupperar tillsammans och ger mer detaljerad blockeringsinformation.

Aktivitetsmonitor jämfört med sp_who2: Det traditionella sp_who2-kommandot visar grundläggande sessionsinformation, men Aktivitetsmonitorn går längre genom att visa väntestatistik, dyra frågor och I/O-mätvärden i ett organiserat, visuellt format.

Aktivitetsmonitor kontra tredjepartsverktyg: Kommersiella övervakningslösningar som SolarWinds Database Performance Analyzer erbjuder historisk spårning, varningar och avancerad analys som Activity Monitor saknar. Activity Monitor kräver dock ingen extra kostnad eller installation.

1.4 Viktiga fördelar för databasadministratörer

Aktivitetsmonitorn erbjuder flera fördelar som gör den till ett viktigt DBA-verktyg:

• Nollkostnad: Som en inbyggd SQL Server Management Studio-funktionen, det krävs ingen licensavgift eller distributionsansträngning.
• Realtidsövervakning: Se aktuell serveraktivitet allt eftersom, med konfigurerbara uppdateringsintervaller från 1 sekund till 1 timme.
• Integrerade åtgärder: Högerklicka på processer för att avsluta sessioner, visa frågeinformation eller starta SQL Server Profiler-spår – allt inifrån verktyget.
• Flera perspektiv: Visa serverhälsa från olika vinklar genom fem specialiserade paneler, som var och en fokuserar på specifika prestandaaspekter.
• Snabb felsökning: Identifiera de vanligaste prestandaproblemen inom några minuter, vilket påskyndar din genomsnittliga tid till lösning.
• Låg inträdesbarriär: Inga avancerade kunskaper krävs för att börja använda verktyget effektivt, men djupare SQL Server expertis hjälper till med tolkningen.

2. Komma igång med Aktivitetsmonitorn

Innan du kan använda Aktivitetsmonitorn effektivt måste du förstå förutsättningarna, de behörigheter som krävs och de olika metoderna för att starta verktyget.

2.1 Förutsättningar och systemkrav

Att använda SQL Server Aktivitetsmonitor, du behöver SQL Server Management Studio (SSMS) installerat på din lokala dator eller en hoppserver. Verktyget Aktivitetsövervakning omdesignades avsevärt år SQL Server 2008, så informationen i den här guiden gäller för SQL Server 2008 och senare versioner.

Du måste ha nätverksanslutning till SQL Server instansen du vill övervaka. För molnbaserade databaser behöver du vanligtvis en VPN-anslutning eller korrekt konfigurerade brandväggsregler för att komma åt instansen.

Aktivitetsmonitorn fungerar med alla utgåvor av SQL Server, inklusive Express, Standard och Enterprise. Verktyget i sig körs på din klientdator i SSMS, så serverns resurser påverkas bara av de övervakningsfrågor som den kör.

2.2 Nödvändiga behörigheter

Rätt behörighet är avgörande för att Aktivitetsmonitorn ska fungera korrekt. Utan rätt behörighet kan du se en tom skärm eller få felmeddelanden om nekad åtkomst.

2.2.1 VISA SERVERSTATUS Behörighet

Ocuco-landskapet VISA SERVERSTATUS Åtkomst är det primära kravet för att använda Aktivitetsmonitorn. Denna behörighet på servernivå låter dig se alla aktiva processer och deras tillhörande mätvärden.

För att bevilja denna behörighet kan en serveradministratör utföra:

GRANT VIEW SERVER STATE TO [YourLoginName];

Utan VISA SERVERSTATUS kan Aktivitetsmonitorn öppnas men ingen data visas i någon av sina rutor.

2.2.2 Behörigheter på databasnivå

För att visa information i rutan Datafil-I/O behöver du ytterligare behörigheter. Mer specifikt måste du ha en av följande kombinationer:

• SKAPA DATABAS tillstånd, eller
• ÄNDRA VALFRI DATABAS tillstånd, eller
• VISA VALFRI DEFINITION tillstånd

Dessa behörigheter måste kombineras med VISA SERVERSTATUS för fullständig aktivitetsmonitorfunktionalitet.

2.2.3 Felsökning av behörigheter

Om Aktivitetsmonitorn öppnas men inte visar några data är behörigheter den vanligaste orsaken. Kontrollera att din inloggning har VISA SERVERSTATUS beviljad på servernivå. Du kan verifiera dina behörigheter genom att köra:

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

Leta efter 'VIEW SERVER STATE' i kolumnen permission_name. Om den saknas, kontakta din databasadministratör för att få den beviljad.

2.3 Hur man öppnar Aktivitetsmonitorn i SSMS

SQL Server Management Studio erbjuder fyra olika metoder för att starta Aktivitetsmonitorn, vilket ger dig flexibilitet baserat på dina arbetsflödesinställningar.

2.3.1 Metod 1: Från verktygsfältet

Det snabbaste sättet att öppna Aktivitetsmonitorn är att använda verktygsfältsikonen:

1. Anslut till din SQL Server exempel i SQL Server ManagementStudio.
2. Leta reda på aktivitetsmonitorikonen i standardverktygsfältet (den liknar ett stapeldiagram med en grön uppspelningsknapp).
3. Klicka på ikonen för att starta Aktivitetsmonitorn.

Den här metoden är snabbast när du redan arbetar i SSMS och snabbt behöver kontrollera serveraktiviteten.

2.3.2 Metod 2: Från Objektutforskaren

Du kan också starta Aktivitetsmonitorn direkt från Objektutforskaren:

1. I Objektutforskaren, leta reda på SQL Server instans du vill övervaka.
2. Högerklicka på instansnamnet.
3. Välja Aktivitetskontroll från snabbmenyn.

Den här metoden är användbar när du ansluter till flera servrar, eftersom den säkerställer att du övervakar rätt instans.

2.3.3 Metod 3: Använda kortkommandon

För tangentbordsfokuserade användare, SQL Server Management Studio tillhandahåller en dedikerad genväg:

1. Se till att SSMS är det aktiva fönstret och att du är ansluten till en instans.
2. Klicka ctrl + andra + A.
3. Aktivitetsmonitorn öppnas för den valda instansen i Object Explorer.

Observera att Aktivitetsmonitorn kommer att ansluta till vilken serverinstans du än har valt i Object Explorer, så se till att du har valt rätt instans innan du använder den här genvägen.

2.3.4 Metod 4: Från alternativmenyn (startkonfiguration)

Om du ofta använder Aktivitetsmonitorn kan du konfigurera SSMS så att det startas automatiskt varje gång du startar programmet:

1. In SQL Server Management Studio, navigera till Verktyg -> Montering.
2. I dialogrutan Alternativ expanderar du MiljöOch väljer sedan Startup.
3. Från Vid uppstart rullgardinsmenyn, välj Öppna Objektutforskaren och Aktivitetsmonitorn.
4. Välja OK.

Nästa gång du startar SSMS och ansluter till en server öppnas Aktivitetsmonitorn automatiskt tillsammans med Object Explorer.

3. Förstå aktivitetsmonitorns rutor

Aktivitetsövervakningen organiserar informationen i fem expanderbara rutor, som var och en ger ett unikt perspektiv på serveraktiviteten. Att förstå vad varje ruta visar är avgörande för effektiv felsökning.

3.1 Översiktsruta

Översiktsfönstret visar fyra realtidsgrafer som ger dig en snabb ögonblicksbild av din hälsa. SQL Server exempel. Dessa grafer uppdateras med ett konfigurerbart intervall och hjälper dig att identifiera onormala mönster med en snabb blick.

3.1.1 % processortid

Det här diagrammet visar den procentuella andelen tid som processorn spenderar på att köra trådar som inte är vilolägnade för SQL Server instans över alla processorer. Värdet representerar SQL Servers processoranvändning, inte hela serverns CPU-användning.

Om du konsekvent ser processortiden på eller nära 100 % är din server CPU-bunden. Detta kan tyda på ineffektiva frågor, saknade index eller otillräcklig hårdvarukapacitet. Använd rutan Senaste dyra frågor för att identifiera vilka frågor som förbrukar mest CPU.

3.1.2 Vänteuppgifter

Denna mätvärde visar antalet uppgifter som väntar på att resurser ska frigöras innan de kan fortsätta. Uppgifter kan vänta på CPU, I/O, minne eller lås.

Ett genomgående högt antal väntande uppgifter indikerar resurskonflikter. Rutan Resursväntningar ger mer information om vilka typer av resurser som orsakar väntetider.

3.1.3 Databas-I/O (MB/s)

Denna graf visar dataöverföringshastigheten mellan minne och disk. Den kombinerar både läsningar och skrivningar, mätt i megabyte per sekund.

Toppar i databasens I/O kan indikera frågor som utför stora tabellskanningar, överdriven loggningsaktivitet eller kontrollpunktsåtgärder. I rutan Datafils-I/O delas I/O-aktivitet upp efter databas och fil.

3.1.4 Batchförfrågningar/sek

Denna mätvärde representerar antalet SQL Server batchar som tas emot av instansen per sekund. En batch kan vara en enda sats eller flera satser som skickas in tillsammans.

Det här värdet ger dig en uppfattning om den totala serveraktiviteten. Plötsliga minskningar av batchförfrågningar under normal kontorstid kan tyda på problem med applikationsanslutningen eller problem med användarna.

3.1.5 Ställa in uppdateringsintervall

Du kan anpassa hur ofta Aktivitetsmonitorn uppdaterar sina data:

1. Högerklicka var som helst i översiktspanelen.
2. Välja Uppdateringsintervall.
3. Välj ett intervall från de fördefinierade värdena: 1 sekund, 5 sekunder, 10 sekunder (standard), 30 sekunder, 1 minut eller 1 timme.

Om du ställer in uppdateringsintervaller på under 10 sekunder ökar övervakningskostnaden på din server. För produktionssystem under hög belastning bör du överväga att använda intervaller på 30 sekunder eller längre för att minimera påverkan.

3.2 Processrutan

Processfönstret visar information om pågående sessioner på din SQL Server exempel. Den här rutan är viktig för att identifiera vem som gör vad och upptäcka blockerande problem.

3.2.1 Förstå processinformation

Varje rad i rutan Processer representerar en aktiv session på servern. Rutan visar sessioner från alla databaser och alla användare, vilket ger dig en heltäckande bild av serveraktiviteten.

Informationen som visas inkluderar inloggningsnamn, programnamn, värdnamn, databas som används och aktuellt kommando. Detta hjälper dig att korrelera databasaktivitet med specifika användare eller program.

3.2.2 Förklaring av nyckelkolumner

Att förstå nyckelkolumnerna hjälper dig att tolka processinformation effektivt:

• Sessions-ID: En unik identifierare för varje anslutning. Systemprocesser använder negativa sessions-ID:n.
• Användarprocess: Anger om detta är en användarsession (Ja) eller en systemprocess (Nej).
• Logga in: Ocuco-landskapet SQL Server inloggning eller Windows-konto som är kopplat till sessionen.
• Databas: Den aktuella databaskontexten för sessionen.
• Uppgiftsstatus: Visar vad sessionen gör för närvarande (KÖRS, PÅ AVSTÅND, SOVANDE, etc.).
• kommando: Typen av kommando som körs (SELECT, INSERT, UPDATE, etc.).
• Ansökan: Namnet på programmet som skapade anslutningen.
• Väntetid: Hur länge (i millisekunder) sessionen har väntat på resurser.
• Väntetyp: Den specifika typ av resurs som sessionen väntar på.
• CPU-tid: Total CPU-tid som förbrukats av den här sessionen sedan den anslöts.
• Minnesanvändning: Mängd minne (i KB) som för närvarande är allokerat till sessionen.

3.2.3 Filtrerings- och sorteringsprocesser

Processpanelen innehåller kraftfulla filtreringsfunktioner som hjälper dig att fokusera på relevanta sessioner:

1. Klicka på rullgardinspilen i valfri kolumnrubrik.
2. Filtret visar tillgängliga värden för den kolumnen, inklusive Alla, Blanksoch Icke-blanka.
3. Välj specifika värden för att filtrera visningen till endast dessa sessioner.

Till exempel kan du filtrera Uppgiftsstatus för att bara visa PÅGÅENDE sessioner, eller filtrera Databas för att se aktivitet mot en specifik databas.

Du kan också sortera efter valfri kolumn genom att klicka på dess rubrik. Klicka en gång för stigande ordning, två gånger för fallande ordning.

3.2.4 Identifiera blockerande och blockerade sessioner

Processfönstret hjälper dig att identifiera blockeringsscenarier där en session hindrar andra från att fortsätta:

• Blockerad av: Visar sessions-ID för den session som blockerar den här sessionen. Om den här kolumnen innehåller ett värde väntar sessionen på ett lås som innehas av en annan session.
• Huvudblockerare: Visar '1' om den här sessionen blockerar andra men inte själv är blockerad. Detta är grundorsaken till en blockeringskedja.

För att undersöka ett blockeringsproblem, identifiera först huvudblockeraren (sessionen markerad med '1' i kolumnen Huvudblockerare), undersök sedan vad den gör och bestäm om du ska låta den slutföra eller avsluta den.

3.2.5 Processåtgärder (Avsluta, Detaljer, Spåra)

Med Aktivitetsmonitorn kan du vidta åtgärder för enskilda sessioner:

1. Högerklicka på valfri session i rutan Processer.
2. Du kommer att se flera alternativ:
   • Detaljer: Visar det senaste kommandot som kördes av den här sessionen.
   • Dödningsprocess: Avslutar sessionen (använd med försiktighet).
   • Spåra processen i SQL Server profilerare: Lanserar SQL Server Profiler och filtrerar automatiskt för att endast visa aktivitet från den här sessionen.

Alternativet Detaljer visar kommandotexten, men observera att detta är den sista kommandot körts – det kanske inte fortfarande körs. Alternativet Spåra är särskilt användbart när du behöver se hela sekvensen av kommandon som en session kör.

3.3 Rutan Resursväntningar

Rutan Resursväntningar sammanfattar väntestatistik och visar vilka typer av resurssessioner som oftast väntar på. Denna information är avgörande för att diagnostisera prestandaflaskhalsar.

3.3.1 Förstå väntestatistik

När SQL Server inte omedelbart kan bevilja en resursbegäran (t.ex. ett lås, CPU-tid eller minne), försätts den begärande uppgiften i ett vänteläge. Väntestatistik spårar dessa väntetider och hjälper dig att förstå var servern spenderar tid med att vänta snarare än att arbeta.

Rutan Resursväntningar samlar in data från dynamiska systemhanteringsvyer som sys.dm_os_wait_stats och sys.dm_exec_requests. Vid varje uppdateringsintervall beräknas skillnaden mellan den aktuella och föregående ögonblicksbilden, vilket visar ackumuleringshastigheten för varje väntetyp.

3.3.2 Väntekategorier

Aktivitetsmonitorn grupperar hundratals individuella väntetyper i bredare kategorier för att förenkla tolkningen:

• CPU: Uppgifter som väntar på att CPU-tid ska bli tillgänglig.
• Buffertlås: Väntar på kortsiktiga synkroniseringsobjekt som skyddar åtkomst till datasidor i minnet. Denna kategori inkluderar sidlåsningsväntningar (PAGELATCH_*).
• Lås: Väntetider orsakade av sessioner som innehåller lås som andra sessioner behöver.
• Minne: Väntar på minnestilldelningar som behövs av operationer som sortering och hashing.
• Nätverks-I/O: Väntar på att skicka data till eller ta emot data från klienter.
• SQL CLR: Väntetider relaterade till Common Language Runtime-körning.

Även om denna gruppering förenklar vyn, döljer den också viktiga detaljer. Till exempel kan "Buffer Latch" gruppera väntetiderna PAGELATCH_SH, PAGELATCH_UP och PAGELATCH_EX, vilka har olika konsekvenser för prestandan.

3.3.3 Tolkning av väntetid och vänteuppgifter

Rutan Resursväntningar visar två viktiga mätvärden för varje väntekategori:

• Kumulativ väntetid (ms): Det totala antalet millisekunder som ackumulerats under det aktuella uppdateringsintervallet för denna väntekategori.
• Vänteuppgifter: Antalet uppgifter som för närvarande väntar på resurser i den här kategorin.

Väntetidsvärdet är särskilt intressant. Om du har ett uppdateringsintervall på 10 sekunder och ser 20 000 ms väntetid för en kategori, indikerar det flera samtidiga väntetider (20 000 ms / 10 000 ms = genomsnitt av 2 samtidiga väntetider under intervallet).

3.3.4 Identifiera flaskhalsar i prestanda

Använd rutan Resursväntningar för att identifiera var din server tillbringar mest tid med att vänta:

1. Expandera rutan Resursväntningar.
2. Observera de väntekategorier som har de högsta väntetiderna.
3. Sortera efter Kumulativ väntetid för att se vilka resurser som är mest begränsade.

Väntetider med hög buffertlåsning indikerar ofta konkurrens om datasidor i minnet, vilket kan tyda på I/O-flaskhalsar eller tempdb-konflikt. Väntetider med hög låsning pekar på blockeringsproblem. Väntetider med hög minneskapacitet tyder på otillräckliga minnestillgångar för frågeåtgärder.

3.4 Datafil I/O-ruta

Rutan Datafil-I/O visar diskaktivitet för varje databasfil på din server, vilket hjälper dig att identifiera I/O-flaskhalsar och förstå diskanvändningsmönster.

3.4.1 Förstå I/O-mått

Rutan Datafil I/O visar flera mätvärden för varje databasfil:

• Databas: Databasens namn.
• Filtyp: Antingen Data (inklusive tabeller och index) eller Logg (transaktionslogg).
• Logiskt namn: Det logiska filnamnet som det definieras i SQL Server.
• MB/sek Läst: Hastigheten för data som läses från den här filen.
• MB/sek Skrivet: Hastigheten för data som skrivs till den här filen.
• Svarstid (ms): Genomsnittlig svarstid för I/O-operationer på den här filen.

Dessa mätvärden uppdateras med samma intervall som översiktsfönstret, vilket ger dig realtidsinsikt i diskaktivitet.

3.4.2 Identifiera I/O-flaskhalsar

Håll utkik efter dessa mönster som indikerar problem med I/O-prestanda:

• Hög svarstid: Svarstider som konsekvent ligger över 15–20 ms tyder på långsamma disksystem. Svarstider över 50 ms indikerar allvarliga I/O-flaskhalsar.
• Obalanserad belastning: Om en datafil visar betydligt högre I/O-hastigheter än andra i samma databas kan du dra nytta av att lägga till ytterligare filer för att fördela belastningen.
• Överdriven Tempdb-aktivitet: Höga I/O-hastigheter på tempdb-filer indikerar ofta att frågor skapar stora mellanliggande resultatmängder eller använder ineffektiva exekveringsplaner.

3.4.3 Analys av databasfiler

Använd rutan Datafil I/O för att förstå hur dina databaser använder diskresurser:

1. Expandera rutan Datafil-I/O.
2. Sortera efter MB/sek Läsning or MB/sek Skrivet för att identifiera de mest aktiva filerna.
3. Notera alla filer med genomgående hög aktivitet eller långa svarstider.
4. Korsreferera den här informationen med rutan Senaste dyra frågor för att identifiera vilka frågor som driver I/O-belastningen.

3.5 Rutan för senaste dyra frågor

Rutan Nyligen dyra frågor är ofta den mest värdefulla rutan för felsökning av programprestandaproblem. Den visar frågor som förbrukar betydande serverresurser, vilket hjälper dig att identifiera optimeringsmöjligheter.

3.5.1 Förstå frågestatistik

Aktivitetsmonitorn visar flera mätvärden för varje dyr fråga:

• Avrättningar/min: Hur många gånger frågan kördes under sista minuten.
• CPU (ms/sek): CPU-tid som förbrukas av denna fråga per sekund.
• Fysiska avläsningar/sek: Antal läsningar från fysiska diskar per sekund för den här frågan.
• Logiska skrivningar/sek: Antal logiska skrivningar (till buffrad cache) per sekund.
• Logiska läsningar/sek: Antal logiska läsningar (från buffertcachen) per sekund.
• Genomsnittlig varaktighet (ms): Genomsnittlig körningstid för den här frågan.
• Planantal: Antal körningsplaner i cachen för den här frågan.

Dessa mätvärden hjälper dig att förstå inte bara vilka frågor som är dyra, utan varför de är dyra och hur ofta de körs.

3.5.2 Sorteringsalternativ

Du kan sortera rutan Senaste dyra frågor efter olika mätvärden för att hitta olika typer av problem:

1. Klicka på valfri kolumnrubrik för att sortera efter den mätvärdena.
2. Vanliga sorteringsstrategier inkluderar:
   • Sortera efter CPU: Hitta frågor som förbrukar mest processortid.
   • Sortera efter Exekveringar/min: Identifiera frågor som körs alltför ofta.
   • Sortera efter fysiska avläsningar: Hitta frågor som orsakar mest disk-I/O.
   • Sortera efter genomsnittlig varaktighet: Leta reda på långvariga frågor.

När du felsöker ett prestandaproblem kan du prova att sortera efter flera kolumner för att få olika perspektiv. En fråga med måttlig CPU-användning men extremt höga körningar per minut kan vara ditt verkliga problem.

3.5.3 Visa frågetext

För att se det faktiska SQL-uttrycket bakom en dyr fråga:

1. Högerklicka på frågeraden i rutan Senaste dyra frågor.
2. Välja Redigera frågetext.
   
3. Ett nytt frågefönster öppnas och visar hela SQL-satsen.
   

Detta gör att du kan undersöka frågelogiken och identifiera potentiella optimeringsmöjligheter. Du kan sedan kopiera frågetexten för att testa modifierade versioner.

3.5.4 Analysera genomförandeplaner

Utförandeplaner visar dig hur SQL Server kör en fråga och avslöjar ineffektivitet som saknade index eller olämpliga kopplingstyper:

1. Högerklicka på frågeraden i rutan Senaste dyra frågor.
2. Välja Visa utförandeplan.
   
3. SQL Server Management Studio visar en grafisk representation av hur frågan körs.
   

Leta efter åtgärder som förbrukar stora andelar av frågekostnaden, varningar om saknad statistik eller index och oväntade tabellsökningsåtgärder. Dessa indikerar ofta var optimeringsinsatserna bör fokuseras.

3.5.5 Identifiera problematiska frågor

Håll utkik efter dessa mönster i rutan Senaste dyra sökfrågor:

• Överdrivna avrättningar: En fråga som körs tusentals gånger per minut kan indikera ett N+1-frågeproblem där applikationskod anropar databasen inuti en loop.
• Höga fysiska avläsningar: Frågor med höga fysiska läshastigheter träffar disken ofta, vilket tyder på saknade index eller dåligt skrivna frågor.
• Hög CPU med låg varaktighet: Många snabba frågor som förbrukar mycket processorkraft tillsammans kan påverka serverns prestanda lika mycket som ett fåtal långsamma frågor.
• Flera planräkningar: Frågor med många körningsplaner kan drabbas av problem med parametersniffning eller icke-parametriserade frågor som orsakar överbelastning av plancachen.

4. Använda Aktivitetsmonitorn för felsökning av prestanda

Aktivitetsmonitorn blir verkligen bra när du använder den systematiskt för att diagnostisera och lösa prestandaproblem. Det här avsnittet behandlar vanliga felsökningsscenarier och hur man hanterar dem.

4.1 Diagnostisera överdrivet antal frågekörningar

Ett av de vanligaste prestandaproblemen är frågor som körs mycket oftare än nödvändigt, ofta på grund av problem med applikationsdesignen.

4.1.1 Identifiera upprepade frågor

Så här identifierar du frågor som körs för ofta:

1. Öppna Aktivitetsmonitorn och expandera Nyligen dyra sökfrågor rutan.
2. Sortera efter Avrättningar/min (avrättningar per minut).
3. Leta efter frågor högst upp med körningsantal som verkar orimligt höga.
4. Högerklicka på den misstänkta frågan och välj Redigera frågetext för att undersöka SQL-satsen.

Om du till exempel ser en enkel SELECT-sats köras 37 000 gånger per minut, fråga dig om programmet verkligen behöver anropa den här frågan så ofta. De flesta frågor som körs mer än några tusen gånger per minut kräver en undersökning.

4.1.2 Analys av grundorsaker

Överdriven körning av frågor beror vanligtvis på dessa problem:

• N+1-frågeproblem: Programkod hämtar en lista med objekt och kör sedan en separat fråga för varje objekt för att hämta relaterad data. Detta skapar N ytterligare frågor där N är antalet objekt.
• Saknad cachning: Applikationen frågar databasen efter data som sällan ändras istället för att cacha den i applikationsminnet.
• Röstningsslingor: Koden frågar upprepade gånger databasen efter tillståndsändringar istället för att använda ändringsmeddelanden eller meddelandeköer.
• ORM-ineffektivitet: Entity Framework och liknande verktyg genererar ibland ineffektiva frågemönster när utvecklare inte förstår hur deras kod översätts till SQL.

För att fastställa grundorsaken, spåra frågan tillbaka till programkoden. Observera Ansökan och Logga in kolumner i rutan Processer när frågan körs. Du kan också högerklicka på processen och välja Spåra processen i SQL Server Profiler för att se samtalsmönstret.

4.1.3 Lösningar och bästa praxis

När du har identifierat överdrivet många frågekörningar kan du överväga dessa lösningar:

• Satsvis bearbetning: Ändra programkod för att hämta flera objekt i en enda fråga med hjälp av kopplingar eller IN-klausuler istället för att köra separata frågor i en loop.
• Resultatcachning: Cache som används ofta, ändrar sällan data i programminnet med lämpliga utgångstider.
• Ivrig laddning: Konfigurera ORM:er för att använda strategier för snabb inläsning som hämtar relaterad data i färre, mer effektiva frågor.
• Frågeparametrisering: Säkerställ att frågor använder parametrar snarare än att sammanfoga värden, vilket förbättrar återanvändning av plancache och minskar kompileringskostnader.

4.2 Undersökning av blockeringsproblem

Blockering inträffar när en session har låsningar som hindrar andra sessioner från att fortsätta. Detta manifesterar sig som långsamma svarstider för applikationer och frustrerade användare.

4.2.1 Identifiera blockerande kedjor

För att upptäcka och analysera blockering:

1. Öppna Aktivitetsmonitorn och expandera Processer rutan.
2. Leta efter sessioner med värden i Blockerad av kolumn – dessa väntar på lås som innehas av andra sessioner.
3. Hitta sessioner med '1' i Huvudblockerare kolumn – dessa är grundorsaken till blockerande kedjor.
4. Notera Session ID av huvudblockeraren.
5. Högerklicka på huvudblockeringssessionen och välj Detaljer för att se vilket kommando den kör.

Att förstå blockeringskedjan är avgörande. Det är huvudblockeraren som är den session du behöver undersöka, inte de blockerade sessionerna efteråt.

4.2.2 Förstå låstyper

Ocuco-landskapet Väntetyp Kolumnen i rutan Processer anger vilken typ av lås som blockerade sessioner väntar på:

• LCK_M_X: Exklusiv låsväntan, vanligtvis orsakad av UPDATE-, DELETE- eller INSERT-operationer.
• LCK_M_S: Delad låsväntan, vanligtvis SELECT-satser som väntar på att exklusiva lås ska frigöras.
• LCK_M_U: Väntetid för uppdateringslås, en mellanliggande låstyp som används under uppdateringar.
• LCK_M_IX: Intent-exklusiv låsväntan, som indikerar låskonflikt på sid- eller radnivå.

Ocuco-landskapet Vänteresurs Kolumnen visar vilket databasobjekt som låses, vilket hjälper dig att förstå vilken tabell eller vilket index som är involverat i konkurrensen.

4.2.3 Lösa blockeringsproblem

När du har identifierat den blockerande sessionen och vad den gör har du flera alternativ:

1. Vänta på slutförande: Om huvudblockeraren kör en legitim fråga som snart kommer att slutföras kan det vara bäst att låta den slutföras naturligt.
2. Döda sessionen: Om huvudblockeraren har fastnat eller kör en fråga som bör avbrytas:
   • Högerklicka på sessionen i rutan Processer.
   • Välja Döda Process.
   • Bekräfta åtgärden i dialogrutan.
3. Optimera frågor: Om blockering återkommer med samma frågor, optimera dem för att minska deras låsningsvaraktighet.
4. Justera isoleringsnivåer: Överväg att använda READ COMMITTED SNAPSHOT ISOLATION för att minska blockering i lästunga arbetsbelastningar.
5. Indexjustering: Lägg till index för att snabba upp frågor, vilket minskar hur länge de håller lås.

4.3 Analysera hög CPU-användning

När översiktsfönstret visar en processortid konsekvent på eller nära 100 % måste du identifiera vilka frågor som är ansvariga och avgöra om de kan optimeras.

4.3.1 Identifiera CPU-intensiva frågor

För att hitta frågor som förbrukar mycket CPU:

1. Öppna Nyligen dyra sökfrågor rutan.
2. Sortera efter CPU (ms/sek) för att visa frågor som använder mest CPU-tid.
3. Granska de vanligaste frågorna i listan.
4. Högerklicka på frågor med hög CPU och välj Redigera frågetext för att visa SQL-satsen.
5. Välja Visa utförandeplan för att förstå hur frågan exekveras.

Var uppmärksam inte bara på CPU-användningen för enskilda frågor utan även på Avrättningar/min kolumn. En fråga som använder måttlig CPU per körning men körs tusentals gånger per minut kan vara din största CPU-förbrukare.

4.3.2 Tekniker för frågeoptimering

Vanliga metoder för att minska CPU-förbrukningen inkluderar:

• Lägg till saknade index: Indexsökningar använder betydligt mindre CPU än tabellsökningar. Leta efter saknade indexrekommendationer i körningsplaner.
• Skriv om ineffektiva frågor: Ersätt markörer med setbaserade operationer, eliminera onödiga funktioner i WHERE-klausuler och ta bort redundanta kopplingar.
• Uppdatera statistik: Föråldrad statistik orsakar SQL Server att välja ineffektiva exekveringsplaner. Kör UPDATE STATISTICS på berörda tabeller.
• Minska datavolymen: Lägg till WHERE-klausuler för att filtrera data tidigare, använd TOP eller OFFSET/FETCH för paginering och undvik SELECT *.
• Åtgärda parametersniffning: Använd OPTION (RECOMPILE), frågetips eller planeringsguider när parametersniffning orsakar problem.

4.4 Undersökning av minnesproblem

Minnesbelastning kan orsaka att frågor spills till disken, vilket försämrar prestandan avsevärt. Aktivitetsövervakning hjälper dig att identifiera minnesintensiva operationer.

4.4.1 Förstå minnesmätvärden

Ocuco-landskapet Minnesanvändning Kolumnen i Processpanelen visar minne som allokerats till varje session i kilobyte. Hög minnesanvändning av en enskild session indikerar ofta:

• Stora sorterings- eller hash-operationer som inte fick plats i det ursprungligen beviljade minnet
• Frågor som hämtar enorma resultatmängder
• Överdriven parallellism skapar många kopior av exekveringsplanoperatorer
• Minnesläckor i lagrade CLR-procedurer eller funktioner

Rutan Resursväntningar kan visa Minnesväntningar när frågor inte kan få tillräckligt med minnestilldelningar och måste vänta på att minne blir tillgängligt.

4.4.2 Identifiera minnesintensiva frågor

För att hitta frågor som orsakar minnesbelastning:

1. I Processer ruta, sortera efter Minnesanvändning för att se sessioner som förbrukar mest minne.
2. Högerklicka på sessioner med hög minnesanvändning och välj Detaljer för att se deras frågor.
3. I Nyligen dyra sökfrågor ruta, leta efter frågor med hög Logiska läsningar or Logiska skrivningar, eftersom dessa ofta korrelerar med minnesanvändning.
4. Undersök exekveringsplaner för sorterings- och hashmatchningsoperatorer, som använder minnestilldelningar.

Frågor som visar varningar om "Memory Grant" i körningsplaner eller spillvarningar indikerar problem med minnesbelastning.

4.5 Upptäcka problem med programprestanda

När användare rapporterar långsamma svarstider för applikationer hjälper Aktivitetsövervakning dig att avgöra om databasen är flaskhalsen.

4.5.1 Korrelera Aktivitetsmonitorn med programproblem

För att undersöka applikationens långsamhet:

1. Notera den exakta tidpunkten då användarna rapporterar problem och vilka applikationer som berörs.
2. Öppna Aktivitetsmonitorn och kontrollera Översikt rutan för resurstoppar vid den tidpunkten.
3. I Processer ruta, filtrera efter Ansökan för att endast visa anslutningar från det berörda programmet.
4. Leta efter höga Väntetid värden, som indikerar databasfördröjningar.
5. Kontrollera Nyligen dyra sökfrågor rutan för frågor från det programmet som förbrukar betydande resurser.

Om databasen inte visar någon ovanlig aktivitet medan användarna upplever långsamhet ligger problemet troligen i programkoden, nätverkslatensen eller prestandan på klientsidan.

4.5.2 Identifiera ineffektiva applikationsmönster

Aktivitetsmonitorn avslöjar flera antimönster i applikationsdesign:

• Pratiga applikationer: Många små frågor istället för färre, mer effektiva frågor. Identifieras genom höga anslutningsantal och många enkla frågor i Nyligen dyra frågor.
• N+1-frågor: En fråga följt av N ytterligare frågor för relaterad data. Visas som en enkel fråga med extremt höga körningar per minut.
• Stora resultatuppsättningar: Applikationer hämtar mycket mer data än nödvändigt. Leta efter höga Logiska läsningar kombinerat med enkla SELECT*-frågor.
• Saknade tidsgränser: Program som inte anger tidsgränser för kommandon kan lämna anslutningar öppna på obestämd tid, synliga som långvariga sessioner i rutan Processer.

5. Alternativa metoder: Hämta aktivitetsmonitordata via T-SQL

Även om Aktivitetsmonitorn har ett bekvämt grafiskt gränssnitt, behöver du ibland hämta motsvarande information programmatiskt eller skapa anpassade övervakningslösningar.

5.1 Använda dynamiska hanteringsvyer (DMV)

SQL Server exponerar aktivitetsinformation genom dynamiska hanteringsvyer, som Aktivitetsövervakningen frågar efter bakom kulisserna.

5.1.1 Viktiga DMV:er för aktivitetsövervakning

De viktigaste DMV:erna för att replikera Aktivitetsmonitorns funktioner inkluderar:

• sys.dm_exec_requests: Visar för närvarande exekverande förfrågningar med CPU-, I/O- och vänteinformation.
• sys.dm_exec_sessions: Innehåller information på sessionsnivå som inloggningsnamn, värdnamn och programnamn.
• sys.dm_os_wait_stats: Tillhandahåller kumulativ väntestatistik för hela instansen.
• sys.dm_exec_query_stats: Innehåller aggregerad prestandastatistik för cachade frågor.
• sys.dm_io_virtual_file_stats: Returnerar I/O-statistik för data och loggfiler.
• sys.dm_exec_sql_text: Hämtar SQL-texten för en given sql_handle eller plan_handle.
• sys.dm_exec_query_plan: Returnerar körningsplanen för en cachad fråga.

5.1.2 Exempel på frågor om processinformation

För att replikera funktionen i Processpanelen kan du fråga:

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 Exempelfrågor för väntestatistik

Så här ser du väntestatistik som liknar den i rutan Resursväntningar:

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 Använda sp_WhoIsActive

sp_WhoIsActive är en kraftfull lagrad procedur skapad av community-användare som ger mer detaljerad information än Aktivitetsmonitorn i en enda resultatuppsättning.

5.2.1 Installera sp_WhoIsActive

För att installera sp_WhoIsActive:

1. Ladda ner den senaste versionen från http://whoisactive.com.
2. Nedladdningen är ett SQL-skript som innehåller procedurens definition.
3. Öppna skriptet i SQL Server ManagementStudio.
4. Anslut till din SQL Server exempel.
5. Kör skriptet för att skapa proceduren i huvuddatabasen.
6. Ge körbehörigheter till lämpliga användare.

Eftersom sp_WhoIsActive är installerat i mastern är det tillgängligt från alla databaskontexter.

5.2.2 Grundläggande användningsexempel

Det enklaste sättet att använda sp_WhoIsActive är:

EXEC sp_WhoIsActive;

Detta returnerar en resultatuppsättning som visar alla aktiva sessioner med deras frågor, väntetyper, blockeringsinformation och resursanvändning.

För ett 10-sekunders urval som visar aktivitet under den perioden:

EXEC sp_WhoIsActive @delta_interval = 10;

Detta beräknar delta för mätvärden som CPU och läsningar, och visar vad som hände under dessa 10 sekunder.

5.2.3 Avancerade parametrar

sp_WhoIsActive stöder ett flertal parametrar för anpassning:

• @filtrera: Filtrera resultat till specifika sessioner, databaser eller inloggningar.
• @filtertyp: Ange vad filtret gäller för (session, databas, inloggning etc.).
• @get_plans: Inkludera utförandeplaner i resultaten (sätt till 1).
• @get_locks: Visa detaljerad låsinformation (inställd på 1).
• @get_transaction_info: Visa transaktionsdetaljer (sätt till 1).
• @sort_order: Sortera resultaten efter olika mätvärden (CPU, läsningar, varaktighet etc.).
• @destinationstabell: Infoga resultat i en tabell för historisk spårning.

Exempel som visar planer sorterade efter CPU:

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

5.3 Använda systemlagrade procedurer

SQL Server innehåller traditionella lagrade procedurer för att övervaka aktivitet, även om de ger mindre information än DMV:er eller Aktivitetsmonitor.

5.3.1 sp_who och sp_who2

Proceduren sp_who visar grundläggande sessionsinformation:

EXEC sp_who;

Proceduren sp_who2 ger lite mer detaljer:

EXEC sp_who2;

Båda procedurerna visar sessions-ID:n, inloggningsnamn, CPU-tid och blockeringsinformation. De saknar dock den rika detaljrikedom som finns tillgänglig via DMV:er eller Aktivitetsmonitor. De är mest användbara för snabba kontroller när du behöver minimal information snabbt.

5.3.2 Andra användbara systemprocedurer

Ytterligare systemprocedurer för övervakning inkluderar:

• sp_lock: Visar låsinformation (föråldrad; använd sys.dm_tran_locks istället).
• sp_monitor: Visar statistik om SQL Server aktivitet.
• sp_hjälp: Visar objektdefinitioner och metadata.
• DBCC SQLPERF: Visar utrymmesanvändning och väntestatistik för transaktionsloggen.

5.4 Skapa anpassade övervakningsskript

För miljöer som kräver specifik övervakning utöver vad Aktivitetsövervakning tillhandahåller kan du bygga anpassade lösningar med hjälp av DMV:er.

5.4.1 Komplett skript motsvarande aktivitetsmonitor

Här är ett omfattande skript som replikerar de flesta funktionerna i Aktivitetsmonitorn:

-- 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 Automatisera övervakning med SQL Agent-jobb

Du kan schemalägga anpassade övervakningsskript med hjälp av SQL Server Ombud:

1. Skapa en tabell för att lagra övervakningsresultat.
2. Ändra ditt övervakningsskript för att infoga resultat i den här tabellen.
3. In SQL Server Management Studio, expandera SQL Server Recensioner i Objektutforskaren.
4. Högerklicka Lediga jobb och välj Nya jobb.
5. Konfigurera jobbet så att det kör ditt övervakningsskript med jämna mellanrum.
6. Ställ in varningar eller rapporter baserat på insamlad data.

Den här metoden möjliggör historisk spårning och trendanalys som Aktivitetsövervakning inte tillhandahåller.

6. Begränsningar och överväganden för aktivitetsmonitorn

Även om Aktivitetsmonitorn är värdefull, hjälper förståelsen av dess begränsningar dig att använda den på rätt sätt och komplettera den med andra verktyg vid behov.

6.1 Förstå aktivitetsmonitorns omkostnader

Aktivitetsmonitorn är inte gratis – den förbrukar serverresurser för att samla in och visa information. Att förstå denna omkostnad hjälper dig att använda den ansvarsfullt.

6.1.1 Påverkan på serverresurser

Aktivitetsövervakningen kör frågor mot system-DMV:er varje gång den uppdateras. Dessa frågor förbrukar CPU, genererar logiska läsningar och kan tillfälligt hålla lås på systemtabeller. På servrar som är upptagna kan denna overhead påverka prestandan.

Fönstren Processer och Senaste dyra frågor är särskilt dyra, eftersom de måste skanna potentiellt stora DMV:er och cache-tabeller. På servrar med tusentals cachade frågeplaner kan det ta flera sekunder att uppdatera Senaste dyra frågor.

Microsofts dokumentation varnar för att uppdateringsintervall under 10 sekunder kan påverka serverns prestanda märkbart, särskilt på redan laddade system.

6.1.2 Bästa praxis för uppdateringsintervall

Välj uppdateringsintervall som är lämpliga för din situation:

• 1-5 sekunder: Endast för omedelbar felsökning av kritiska problem på lågt belastade servrar. Låt inte Aktivitetsmonitorn vara igång vid dessa intervall.
• 10 sekunder (standard): Rimligt för de flesta felsökningsscenarier och allmän övervakning.
• 30-60 sekunder: Bättre val för produktionsservrar under hög belastning eller vid övervakning under längre perioder.
• Endast manuell uppdatering: För situationer där du vill kontrollera aktuellt tillstånd då och då utan kontinuerlig pollning.

Stäng alltid Aktivitetsmonitorn när du är klar med undersökningen. Låt den inte köras kontinuerligt, särskilt inte om den körs flera gånger från olika användare.

6.2 Problem med gruppering av väntetyper

Aktivitetsmonitorns tillvägagångssätt för att kategorisera väntetider kan, samtidigt som det förenklar vyn, dölja viktig diagnostisk information.

6.2.1 Hur Aktivitetsmonitorn grupperar väntetider

SQL Server spårar hundratals olika väntetyper, som var och en indikerar en specifik resurs eller ett specifikt tillstånd. Aktivitetsövervakning grupperar dessa i breda kategorier som "Buffertlås", "Lås" och "Minne".

Till exempel inkluderar kategorin ”Buffer Latch” PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX och flera andra specifika väntetyper. Även om de alla är relaterade till sidingång har de olika orsaker och lösningar.

Microsoft dokumenterar inte exakt vilka väntetyper som mappas till vilka kategorier, vilket gör det svårt att förstå vad man egentligen ser.

6.2.2 Saknade väntetyper

Aktivitetsövervakningen visar inte alla väntetyper. Framför allt utelämnar den ofta CXPACKET-väntningar, vilket indikerar parallell frågekörning. CXPACKET-väntningar är vanliga och vanligtvis inte problematiska, men att veta att de finns hjälper dig att förstå arbetsbelastningens egenskaper.

När Aktivitetsmonitorn visar "Buffertlås" som din främsta väntepunkt men andra verktyg visar att CXPACKET dominerar, kommer skillnaden från Aktivitetsmonitorns filtrerings- och grupperingslogik.

6.2.3 Varför specifika väntetyper är viktiga

Det är viktigt att känna till den specifika väntetypen för felsökning:

• PAGELATCH_EX: Indikerar ofta tempdb-konflikter på allokeringssidor. Lösningen innebär att lägga till fler tempdb-datafiler.
• PAGELATCH_SH: Kan tyda på att det finns aktiva sidor i användartabeller. Lösningen innebär partitionering eller omorganisation av index.
• PAGELATCH_UP: Vanligt vid uppdateringar. Kan tyda på normal drift snarare än ett problem.

Aktivitetsövervakningen grupperar alla dessa under "Buffertlås", vilket gör diagnosen svårare. Verktyg som sp_WhoIsActive och DMV-frågor visar specifika väntetyper.

6.3 Datanoggrannhet och aktualitet

Aktivitetsmonitorn ger en vy i nära realtid, men "nära" är det avgörande ordet. Att förstå dess datainsamlingsmetod hjälper dig att tolka resultaten korrekt.

6.3.1 Ögonblicksbild kontra kontinuerlig övervakning

Aktivitetsmonitorn visar ögonblicksbilder tagna vid varje uppdateringsintervall. Händelser som inträffar mellan ögonblicksbilderna registreras inte. Om en fråga körs i 2 sekunder och du uppdaterar var 10:e sekund kan du se den en gång eller inte alls, beroende på tidpunkten.

Det här betyder att Aktivitetsmonitorn utmärker sig på att hitta ihållande problem (blockera varaktiga minuter, genomgående hög CPU-belastning) men kan missa övergående problem (korta låsningar, enstaka frågetoppar).

6.3.2 Aggregering och urval

Rutan Senaste dyra frågor visar data som aggregerats sedan frågeplanerna hamnade i cachen. Två identiska frågor med olika parametervärden visas som en rad om de delar en plan. Denna aggregering kan maskera problem med specifika parameterkombinationer (parameteravläsningsproblem).

Rutan Resursväntningar beräknar hastigheter genom att jämföra ögonblicksbilder. Om väntestatistiken återställs mellan ögonblicksbilder (sällsynt men möjligt) kan de beräknade hastigheterna vara felaktiga.

6.4 När Aktivitetsmonitorn INTE ska användas

Aktivitetsmonitorn är inte lämplig för alla övervakningsscenarier. Identifiera när alternativa verktyg är bättre val.

6.4.1 Krav för historisk analys

Aktivitetsmonitorn visar endast aktuell eller nyligen genomförd aktivitet. Den lagrar inte historisk data. Om du behöver analysera trender över dagar eller veckor, jämföra aktuell prestanda med baslinjer eller generera rapporter om prestandamönster, räcker inte Aktivitetsmonitorn.

För historisk analys, använd SQL Servers inbyggda prestandaöversikt, utökade händelser med filmål eller övervakningslösningar från tredje part.

6.4.2 Behov av detaljerad väntestatistik

När du behöver exakt information om väntetyp för avancerad finjustering, gör Aktivitetsmonitorns gruppering och filtrering det otillräckligt. Använd DMV-frågor direkt eller sp_WhoIsActive istället.

För omfattande analys av väntestatistik, fråga sys.dm_os_wait_stats direkt och filtrera bort godartade väntetider manuellt.

6.4.3 Att tänka på vid produktionsserver

På produktionsservrar under hög belastning kan Aktivitetsövervakningens overhead vara problematiskt. Flera databasadministratörer bör inte köra Aktivitetsövervakning samtidigt på samma server.

För produktionsövervakning, överväg lättviktiga alternativ som schemalagda DMV-ögonblicksbilder lagrade i en övervakningsdatabas, eller använd skrivskyddad routning för att övervaka sekundära repliker i Always On-konfigurationer.

7. Bästa praxis för att använda Aktivitetsmonitorn

Genom att följa bästa praxis får du maximalt ut av Aktivitetsmonitorn samtidigt som du minimerar negativ påverkan på dina servrar.

7.1 När ska man använda aktivitetsmonitorn

Aktivitetsmonitorn är utmärkt i specifika situationer. Använd den när dess styrkor överensstämmer med dina behov.

7.1.1 Problem med prestanda i realtid

Aktivitetsmonitorn är idealisk när användare upplever problem och du behöver diagnostisera problemet omedelbart. Realtidsvyn hjälper dig att se vad som händer just nu.

När du får ett samtal om att "applikationen är långsam" bör ett av dina första steg vara att öppna Aktivitetsmonitorn. Du kan snabbt avgöra om databasen är upptagen, blockerad eller inaktiv.

7.1.2 Undersökning av programförsämring

När ett specifikt program slutar svara hjälper Aktivitetsövervakningen dig att avgöra om databasproblem är orsaken. Filtrera rutan Processer efter programnamn för att bara se det programmets databasaktivitet.

Om applikationen inte visar någon databasaktivitet medan användare rapporterar problem, ligger problemet någon annanstans i stacken. Om du ser omfattande blockeringar eller dyra frågor har du hittat boven i dramat.

7.1.3 Snabba hälsokontroller

Aktivitetsmonitorn är en utmärkt instrumentpanel för snabba hälsokontroller under rutinmässig administration. Öppna den, titta på översiktsgraferna och kontrollera att ingenting ser onormalt ut.

Denna ytliga kontroll tar några sekunder och kan avslöja problem innan de blir kritiska. Gör det till en del av din dagliga rutin.

7.2 Optimala konfigurationsinställningar

Att konfigurera Aktivitetsmonitorn på lämpligt sätt förbättrar både dess användbarhet och dess resursförbrukning.

7.2.1 Rekommenderade uppdateringsintervall

Anpassa ditt uppdateringsintervall till ditt syfte:

• Aktiv felsökning: 10 sekunder ger bra responstid med rimlig overhead.
• Utökad övervakning: 30–60 sekunder minskar serverpåverkan under längre observationsperioder.
• Diagnos av kritiskt problem: 5 sekunder ger hög granularitet när varje sekund räknas, men använd kort.
• Regelbundna hälsokontroller: Manuell uppdatering (1 timmes intervall) när du inte aktivt tittar.

Kom ihåg att stänga Aktivitetsmonitorn när du är klar. Att ställa in den på ett långt intervall och glömma bort den slösar bort serverresurser.

7.2.2 Filtreringsstrategier

Använd filter för att fokusera på relevant information och minska kognitiv belastning:

• Filtrera processer efter Databas för att endast se aktivitet mot specifika databaser.
• filtrera efter Logga in för att spåra en specifik användares aktivitet.
• filtrera efter Uppgiftsstatus = RUNNING för att dölja inaktiva sessioner.
• filtrera efter Ansökan för att isolera trafik från specifika program.
• Visa endast icke-tomma objekt i Blockerad av att bara se blockerande situationer.

7.2.3 Kolumnval och sortering

Utveckla en systematisk metod för att granska data från Aktivitetsmonitorn:

1. Börja med översikt: Kontrollera graferna för uppenbara toppar eller avvikelser.
2. Kontrollera processer för blockering: Sortera efter sessions-ID och leta sedan efter värden för Blockerad av.
3. Granska resursväntningar: Sortera efter kumulativ väntetid för att identifiera resursflaskhalsar.
4. Analysera dyra frågor: Sortera efter olika mätvärden (CPU, körningar, läsningar) för att hitta olika problemtyper.
5. Verifiera med I/O-rutan: Bekräfta om I/O-intensiva frågor korrelerar med hög diskaktivitet.

7.3 Integration med andra verktyg

Aktivitetsmonitorn fungerar bäst som en del av en bredare verktygslåda snarare än som en fristående lösning.

7.3.1 Användning med SQL Server Profiler

Aktivitetsmonitor och SQL Server Profiler kompletterar varandra väl. När du identifierar en problematisk session i Aktivitetsmonitorn högerklickar du på den och väljer Spåra processen i SQL Server Profiler.

Detta startar Profiler med filter som redan är konfigurerade för att endast fånga aktiviteten för den sessionen. Du ser den fullständiga sekvensen av körda kommandon, tidsinformation och felmeddelanden – detaljer som Aktivitetsövervakningen inte tillhandahåller.

Om du vill veta mer om SQL Server Profileringsfunktioner och avancerade spårningstekniker, se vår omfattande SQL Server Profiler-guide.

7.3.2 Komplettering med utökade händelser

Utökade händelser erbjuder detaljerad övervakning med låg omkostnad som samlar in information som Aktivitetsövervakaren missar. Skapa utökade händelsesessioner för att spåra specifika händelser som dödlägen, långvariga frågor eller överdrivna omkompileringer.

Använd Aktivitetsövervakning för omedelbar undersökning och Utökade händelser för kontinuerlig övervakning och historisk analys. De två verktygen tillgodoser olika behov.

Om du vill veta mer om SQL Server Utökade händelsefunktioner och avancerade övervakningstekniker, se vår omfattande SQL Server Guide för utökad händelse.

7.3.3 Övervakningslösningar från tredje part

Kommersiella verktyg som SolarWinds Database Performance Analyzer, Redgate SQL Monitor och Quest Spotlight erbjuder funktioner som Activity Monitor saknar: aviseringar, historiska trender, kapacitetsplanering och automatiserad diagnostik.

Dessa verktyg är värdefulla tillägg till Aktivitetsmonitorn, inte ersättningar. Aktivitetsmonitorn är fortfarande användbar för snabba kontroller och undersökningar även när sofistikerade övervakningsverktyg finns tillgängliga.

7.4 vanliga misstag att undvika

Att förstå vanliga misstag i Aktivitetsmonitorn hjälper dig att använda den mer effektivt.

7.4.1 Låta Aktivitetsmonitorn vara igång kontinuerligt

Det vanligaste misstaget är att öppna Aktivitetsmonitorn och låta den köras på obestämd tid. Detta slösar bort serverresurser och ger lite värde eftersom du inte aktivt tittar.

Stäng Aktivitetsmonitorn när du inte aktivt använder den. Om du behöver kontinuerlig övervakning, implementera istället en lämplig övervakningslösning med schemalagd datainsamling.

7.4.2 Att förlita sig för mycket på enbart aktivitetsmonitorn

Aktivitetsövervakning ger ett perspektiv på serverhälsa. Förlita dig inte enbart på den. Komplettera med Windows Performance Monitor för mätvärden på operativsystemnivå, utökade händelser för detaljerad spårning och analys av körningsplaner för frågejustering.

Aktivitetsmonitorn hjälper dig att identifiera problem, men att lösa dem kräver ofta ytterligare verktyg och djupare analys.

Läs mer om SQL Server prestandamätare i vår komplett guide.

7.4.3 Ignorera historiska trender

Aktivitetsmonitorn visar aktuellt tillstånd, men prestandaproblem har ofta mönster som bara syns över tid. Implementera historisk datainsamling så att du kan jämföra aktuella mätvärden med baslinjer och identifiera trender.

Utan historisk kontext kanske du inte inser att dagens "normala" CPU-användning är 30 % högre än förra månadens baslinje, vilket indikerar en gradvis försämring.

8. Felsökning av problem med aktivitetsmonitorn

Aktivitetsmonitorn själv upplever ibland problem. Att veta hur man felsöker dessa problem förhindrar frustration.

8.1 Aktivitetsmonitorn öppnas inte eller visar inga data

När Aktivitetsmonitorn öppnas men visar tomma rutor eller inte öppnas alls kan flera faktorer vara ansvariga.

8.1.1 Behörighetsproblem

Den vanligaste orsaken till problem med Aktivitetsmonitorn är otillräckliga behörigheter. För att verifiera och lösa:

1. Kontrollera dina behörigheter på servernivå:

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

2. Om inga rader returnerar saknar du behörighet att VISA SERVERTILLSTÅND.
3. Be en serveradministratör att bevilja det:

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

4. Stäng och öppna Aktivitetsmonitorn igen efter att behörigheter har beviljats.

8.1.2 Problem med versionskompatibilitet

Använder en gammal version av SQL Server Management Studio för att ansluta till en nyare SQL Server versionen kan orsaka fel i Aktivitetsmonitorn. Verktyget kanske inte förstår nya väntetyper eller systemvykolumner.

Använd alltid en SSMS-version som matchar eller är nyare än din SQL Server version. Microsoft tillhandahåller den senaste SSMS som gratis nedladdning separat från SQL Server själv.

8.1.3 Brandväggs- och nätverksproblem

Aktivitetsmonitorn kräver anslutning till SQL Server instans på standardportar (1433 som standard). Om du kan ansluta via Object Explorer men Aktivitetsmonitorn misslyckas, kan brandväggsregler blockera specifika anslutningar.

Kontrollera att din klient kan nå SQL Server maskinen på alla nödvändiga portar. Kontrollera både Windows-brandväggen och eventuella nätverksbrandväggar mellan klienten och servern.

8.2 Aktivitetsmonitor permanent pausad

Ett vanligt problem, särskilt i SQL Server 2019, öppnas Aktivitetsmonitorn i pausat läge och vägrar att återupptas.

8.2.1 Förstå pausläget

När Aktivitetsmonitorn pausar visar alla rutor statusen "Pausad" med en återupptagningsknapp som kanske inte fungerar. Detta förhindrar att du ser någon serveraktivitet.

Pausläget uppstår vanligtvis på grund av behörighetsproblem, begränsningar i fjärranslutningar eller SSMS-versionsfel snarare än en avsiktlig pausåtgärd.

8.2.2 Vanliga orsaker

Aktivitetsmonitorn kan försättas i permanent pausläge på grund av:

• Saknar behörighet för att visa servertillstånd i nyare rutor som lagts till nyligen SQL Server versioner
• Fjärranslutningar inaktiverade på SQL Server exempel
• Autentiseringsfel för specifika systemfrågor
• Buggar i specifika SSMS-versioner, särskilt 18.0 till 18.3
• Anslutningsproblem mellan klient och server

8.2.3 Lösningssteg

Så här löser du problem med pausat tillstånd för Aktivitetsmonitorn:

1. Uppdatera SSMS: Hämta och installera det senaste SQL Server Management Studio-versionen från Microsofts webbplats. Många buggar i pausat tillstånd har åtgärdats i senare versioner.
2. Verifiera behörigheter: Se till att du har behörigheterna VISA SERVERSTATUS och VISA ALLA DEFINITIONER.
3. Kontrollera fjärranslutningar: Verifiera att SQL Server instansen tillåter fjärranslutningar:

   EXEC sp_configure 'remote access';
   

   Om värdet är 0, be en administratör att aktivera det.

4. Starta om SSMS: Ibland stänger man helt enkelt alla fönster och startar om SQL Server Management Studio löser problemet.
5. Anslut med Windows-autentisering: Om du använder SQL-autentisering, prova Windows-autentisering istället, eftersom det ibland kringgår autentiseringsrelaterade pausproblem.

8.3 Prestandaproblem vid användning av aktivitetsmonitorn

Om Aktivitetsmonitorn i sig blir långsam eller orsakar försämrad serverprestanda krävs justeringar.

8.3.1 Minska övervakningskostnader

Så här minimerar du Aktivitetsmonitorns påverkan:

1. Öka uppdateringsintervallet till 30 sekunder eller 1 minut.
2. Stäng rutor som du inte aktivt använder genom att klicka på knappen "Minimera".
3. När rutor är hopfällda frågar Aktivitetsmonitorn inte efter data för dem.
4. Undvik att köra flera Aktivitetsmonitor-instanser samtidigt.
5. Stäng Aktivitetsmonitorn helt när du inte aktivt undersöker problem.

8.3.2 Alternativa lättviktiga övervakningsmetoder

Om Aktivitetsmonitorn är för resurskrävande för din miljö, överväg alternativ:

• Fråga DMV direkt: Skriv specifika T-SQL-frågor som bara hämtar den information du behöver.
• Använd sp_WhoIsActive: Den här lagrade proceduren är mycket optimerad och har vanligtvis lägre omkostnader än Aktivitetsmonitorn.
• Implementera provtagning: Schemalägg SQL Agent-jobb som samlar in ögonblicksbilder av DMV-data med jämna mellanrum och lagrar resultaten i tabeller för senare analys.
• Övervaka sekundära repliker: In Alltid på-tillgänglighetsgrupper, kör Aktivitetsmonitorn mot en läsbar sekundär snarare än den primära.

8.4 Felaktig eller saknad information

Ibland visar Aktivitetsmonitorn information som verkar felaktig eller ofullständig.

8.4.1 Verifiera data med DMV:er

När resultat från Aktivitetsmonitorn verkar misstänkta, verifiera dem genom att fråga de underliggande DMV:erna direkt. Om till exempel rutan Processer inte visar någon blockering men användare rapporterar det, fråga:

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

Om den här frågan visar att Aktivitetsmonitorn har missat en blockering har du bekräftat ett visningsproblem.

8.4.2 Förstå tidpunkten för datauppdatering

Kom ihåg att Aktivitetsmonitorn visar ögonblicksbilder. En fråga som körts mellan uppdateringsintervall visas inte i Senaste dyra frågor om inte dess körningsplan finns kvar i cachen.

På samma sätt visar väntestatistiken i rutan Resursväntningar ackumuleringen sedan den senaste ögonblicksbilden. Snabbt föränderliga arbetsbelastningar kan visa olika mönster vid varje uppdatering.

9. Avancerade tekniker för aktivitetsövervakning

Erfarna databasadministratörer använder Aktivitetsövervakning på sofistikerade sätt för att utvinna maximalt diagnostiskt värde.

9.1 Kombinera flera rutor för rotorsaksanalys

Den verkliga kraften i Aktivitetsmonitorn framträder när du korrelerar information över flera rutor för att förstå komplexa prestandaproblem.

9.1.1 Korrelera väntetider med processer

När rutan Resursväntningar visar höga väntetider i en kategori, använd rutan Processer för att identifiera vilka sessioner som har dessa väntetider:

1. Observera väntekategorin med hög kumulativ väntetid (t.ex. ”Lås”).
2. Växla till rutan Processer.
3. Sortera efter Väntetyp för att gruppera sessioner efter deras nuvarande väntetid.
4. Leta efter sessioner som visar väntetyper i den problematiska kategorin.
5. För dessa sessioner, undersök Vänteresurs kolumnen för att se vilka databasobjekt som är inblandade.
6. Högerklicka och välj Detaljer för att se frågetexten.

Denna korrelation hjälper dig att gå från "vi har låsväntningar" till "denna specifika fråga väntar på lås i den här tabellen".

9.1.2 Koppla dyra frågor till I/O-problem

När rutan Data File I/O visar hög diskaktivitet på en specifik databas:

1. Observera vilka databasfiler som har höga läs- eller skrivhastigheter på MB/s.
2. Växla till Senaste dyra sökfrågor.
3. Sortera efter Fysiska läsningar/sek för att identifiera frågor som läser mycket från disken.
4. Filtrera eller identifiera visuellt frågor som körs mot databasen med hög I/O.
5. Undersök dessa frågors körningsplaner för tabellskanningar eller saknade index som orsakar överdriven I/O.

Denna flerpanelsanalys kopplar samman symptom (hög disk-I/O) med orsaker (specifika ineffektiva frågor).

9.2 Använda aktivitetsmonitor för kapacitetsplanering

Även om Aktivitetsövervakningen inte lagrar historisk data kan du använda den strategiskt för observationer av kapacitetsplanering.

9.2.1 Identifiera mönster för användningstoppar

Övervaka serveraktivitet vid olika tider på dygnet för att identifiera användningsmönster:

1. Öppna Aktivitetsmonitorn under kända arbetstider.
2. Notera toppvärdena i grafen för % processortid.
3. Registrera det maximala antalet väntande uppgifter.
4. Observera batchförfrågningar/sek vid högtrafik.
5. Dokumentera de mest hektiska databaserna i rutan Processer.
6. Upprepa under lågtrafik för jämförelse.

Om processortiden under högsta timme konsekvent överstiger 80 % närmar du dig processorkapacitetsgränserna. På samma sätt indikerar ökande väntetider ökande resurskonkurrens.

9.2.2 Analys av resurstrend

Medan Aktivitetsmonitorn visar aktuell status kan du använda den för att stickprovskontrollera trender genom att registrera viktiga mätvärden över tid:

• Ta skärmdumpar av översiktspanelen vid samma tidpunkt varje dag
• Registrera toppvärden från varje graf
• Jämför vecka för vecka för att identifiera tillväxttrender
• Var uppmärksam på gradvisa ökningar av genomsnittlig processortid eller I/O-hastigheter

Denna manuella trendanalys kompletterar mer sofistikerade övervakningslösningar och hjälper till att motivera kapacitetsutökning.

9.3 Dokumentera prestandabaslinjer

Att fastställa grundläggande prestandamått hjälper dig att identifiera när prestandan försämras.

9.3.1 Insamling av baslinjemätvärden

Under perioder med känd bra prestanda, dokumentera Aktivitetsmonitorns mätvärden:

1. Öppna Aktivitetsmonitorn under normal affärsverksamhet (ej högtrafik eller lågtrafik).
2. Värden i fönstret Postöversikt:
   • Typiskt % Processortidsintervall
   • Genomsnittligt antal väntande uppgifter
   • Normal databas-I/O-hastighet
   • Typiska batchförfrågningar/sek
3. Observera att de kategorier i fönstret Resursväntningar som visar längst väntetid.
4. Dokumentera antalet aktiva processer vanligtvis i rutan Processer.
5. Registrera representativa frågekörningsmått från senaste dyra frågor.

Spara denna grundläggande dokumentation för framtida referens när du undersöker prestandaproblem.

9.3.2 Jämförelse av nuvarande prestanda kontra baslinjeprestanda

När prestandaproblem uppstår, jämför aktuella aktivitetsmonitoravläsningar med din dokumenterade baslinje:

• Är processortiden betydligt högre än baslinjen? Fokusera på CPU-intensiva frågor.
• Är väntetiderna 2–3 gånger högre än baslinjenivåerna? Undersök resursväntetiderna.
• Är I/O betydligt högre? Kontrollera rutan för datafilens I/O och dyra frågor.
• Är batchförfrågningar färre än baslinjen under rusningstid? Leta efter blockerings- eller anslutningsproblem.

Den här jämförelsen hjälper dig att identifiera vad som har ändrats och fokusera felsökningsinsatser på lämpligt sätt.

9.4 Skapa anpassade övervakningsarbetsflöden

Utveckla systematiska arbetsflöden för vanliga utredningsscenarier för att säkerställa grundlig och repeterbar analys.

9.4.1 Steg-för-steg-utredningsprocess

När användare rapporterar prestandaproblem, följ ett konsekvent arbetsflöde:

1. Snabb hälsokontroll: Öppna Aktivitetsmonitorn och skanna översiktsrutans grafer efter uppenbara avvikelser.
2. Kontrollera om det finns blockering: Expandera rutan Processer, filtrera efter Icke-tomma fält i kolumnen Blockerad av.
3. Identifiera resurskonflikter: Granska rutan Resursväntningar sorterad efter väntetid.
4. Hitta dyra frågor: Granska de senaste dyra frågorna sorterade efter CPU, sedan körningar och sedan läsningar.
5. Korrelera I/O-mönster: Korsreferera dyra frågor med aktivitet i fönstret Data File I/O.
6. Dokumentfynd: Ta skärmdumpar och registrera relevanta sessions-ID:n, väntetyper och frågedetaljer.
7. Djupdykning: Använd Profiler-spårningar, analys av körningsplaner och DMV-frågor för detaljerad undersökning av identifierade problem.

9.4.2 Eskaleringskriterier

Fastställ kriterier för när ärenden ska eskaleras kontra fortsatt utredning:

• Eskalera omedelbart: Blockeringskedjor som varar >5 minuter, processortid på 100 % i >2 minuter, kritiska systemprocesser visar tillståndet AVSTÅNDAT.
• Eskalera med analys: Återkommande dyra frågor som förbrukar >50 % av CPU-kapaciteten, genomgående höga I/O-svarstider >50 ms, minnestilldelningar misslyckas upprepade gånger.
• Undersök vidare: Tillfälliga väntetider som löses inom några minuter, frågor med suboptimala planer men acceptabel prestanda, mindre blockering <30 sekunders varaktighet.

10. Aktivitetsmonitor i olika SQL Server versioner

Aktivitetsmonitorn har utvecklats över hela SQL Server versioner, där varje utgåva medför förbättringar och ibland nya problem.

10.1 Aktivitetsmonitor i SQL Server 2008 och senare

SQL Server 2008 introducerades den moderna designen av aktivitetsmonitorn som i stort sett är oförändrad idag.

10.1.1 Nya funktioner introducerade i SQL Server 2008

Ocuco-landskapet SQL Server Omdesignen av Aktivitetsmonitorn 2008 medförde betydande förbättringar:

• Grafisk instrumentpanel med realtidsdiagram i översiktsfönstret
• Gränssnitt för expanderbart/hopfällbart fönster som ersätter den gamla rutnätsvyn
• Rutan Senaste dyra frågor som visar aggregerade prestandadata för frågor
• Datafil I/O-ruta för övervakning av diskaktivitet per fil
• Förbättrad resursväntningsruta med väntekategorisering
• Högerklicka på kontextmenyer för processåtgärder som att avsluta sessioner och starta Profiler
• Konfigurerbara uppdateringsintervaller från 1 sekund till 1 timme

Dessa förändringar förvandlade Aktivitetsmonitorn från en enkel processlista till en omfattande övervakningsinstrumentpanel.

10.1.2 Ändringar från SQL Server 2005

SQL Server 2005 års Aktivitetsmonitor var betydligt mer begränsad:

• Åtkomst via hanteringsmappen i Object Explorer istället för verktygsfältet
• Enkelt rutnät som visar processlista med grundläggande information
• Inga grafiska diagram eller flera rutor
• Inga dyra frågor eller I/O-övervakning
• Begränsad väntestatistikinformation

2008 års omdesign representerade en fullständig omtolkning snarare än en stegvis förbättring.

10.2 Aktivitetsmonitor i SQL Server 2014/2016

SQL Server 2014 och 2016 gjordes stegvisa förbättringar av Aktivitetsmonitorns underliggande datainsamling men få visuella förändringar.

10.2.1 Förbättringar och förbättringar

Viktiga förbättringar i dessa versioner inkluderade:

• Bättre prestanda vid övervakning av servrar med tusentals cachade abonnemang
• Förbättrade filtreringsfunktioner i rutan Processer
• Förbättrad noggrannhet i aggregering av väntestatistik
• Bättre hantering av kolumnsortering och filtrering med stora resultatmängder
• Effektivare DMV-frågor minskar övervakningskostnader

Kärngränssnittet förblev konsekvent med SQL Server 2008, vilket upprätthåller förtrogenhet för administratörer.

10.3 Aktivitetsmonitor i SQL Server 2019/2022

Senaste SQL Server versionerna fortsätter Aktivitetsmonitorns utveckling med fokus på prestanda och stabilitet.

10.3.1 Senaste funktioner och möjligheter

SQL Server Aktivitetsmonitorn för 2019 och 2022 inkluderar:

• Stöd för nya väntetyper introducerade i dessa versioner
• Förbättrad renderingsprestanda i SSMS med hjälp av WPF-teknik
• Bättre hantering av ett stort antal aktiva sessioner
• Förbättrad kompatibilitet med molnbaserade SQL-plattformar
• Mer exakta CPU- och I/O-mätvärden

10.3.2 Kända problem i nyare versioner

SQL Server 2019 introducerade flera buggar i Aktivitetsmonitorn:

• Permanent pausat tillstånd: Aktivitetsmonitorn försätts ofta i pausläge och återupptas inte, särskilt i SSMS 18.0-18.3. Åtgärdat i senare SSMS-versioner.
• Fel på fjärranslutning: Vissa konfigurationer förhindrar att Aktivitetsövervakningen öppnas på fjärrinstanser. Lösningar inkluderar att aktivera specifika spårningsflaggor eller använda nyare SSMS-versioner.
• Tillståndsproblem: Nya systemvyer kräver ytterligare behörigheter som inte är tydligt dokumenterade, vilket orsakar tomma skärmar även med VISA SERVERTILLSTÅND.

Använd alltid den senaste SSMS-versionen när du arbetar med SQL Server 2019 och 2022 för att undvika dessa problem.

11. Praktiska användningsfall och exempel

Verkliga exempel visar hur man använder Aktivitetsmonitorn effektivt i vanliga felsökningsscenarier.

11.1 Fallstudie: Diagnostisera en långsam webbapplikation

Ett utvecklingsteam rapporterar att deras webbapplikation har blivit oacceptabelt långsam, med sidladdningar som tar 20–30 sekunder istället för normalt 2–3 sekunder.

11.1.1 Inledande undersökning med översiktsruta

Öppna Aktivitetsmonitorn och granska översiktspanelen:

1. Diagrammet för % processortid visar en CPU-användning på 85–95 %, vilket är betydligt högre än den normala baslinjen på 30–40 %.
2. Vänteuppgifter varierar mellan 10–20 uppgifter, jämfört med en normal baslinje på 0–3.
3. Databas-I/O visar måttlig aktivitet runt 50 MB/s.
4. Batchförfrågningar/sek är lägre än förväntat på 100/sek, jämfört med typiska 300–400/sek under kontorstid.

Detta mönster tyder på en flaskhals i CPU:n med resurskonflikter som orsakar minskat dataflöde. Servern arbetar hårt men bearbetar inte många förfrågningar.

11.1.2 Identifiera den problematiska frågan

Expandera rutan Senaste dyra frågor och sortera efter Körningar/min:

1. Den översta frågan visar 15 000 körningar per minut.
2. Högerklicka och välj Redigera frågetext att granska förfrågan.
3. Frågan är en enkel SELECT-sats som hämtar en enskild användarpost: SELECT * FROM Users WHERE UserId = @UserId.
4. Den här frågan bör inte köras 15 000 gånger per minut för normal programanvändning.

Högerklicka på frågan och välj Visa utförandeplanPlanen visar en tabellsökning av tabellen Användare med en varning om ett saknat index i kolumnen Användar-ID.

Filtrera rutan Processer efter program för att endast visa webbprogrammets anslutningar. Flera sessioner visar att samma fråga körs upprepade gånger.

11.1.3 Lösning och verifiering

Problemet härrör från två saker: överdrivet många frågekörningar och ett saknat index. Lösningssteg:

1. Skapa det saknade indexet:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Kontakta utvecklingsteamet om de överdrivna exekveringarna. Undersökningen avslöjar ett N+1-frågeproblem i applikationskoden där en loop hämtar användarinformation för varje objekt i en lista.
3. Ändra applikationen att gruppvisa användarsökningar till en enda fråga med hjälp av en IN-klausul eller tabellvärderad parameter.
4. Verifiera korrigeringen genom att övervaka Aktivitetsmonitorn efter driftsättning. CPU-användningen sjunker till 35–40 %, antalet körningar per minut minskar till 200–300 och programmets svarstider återgår till det normala.

11.2 Fallstudie: Lösning av ett blockeringsproblem

Användare rapporterar att orderregistreringssystemet regelbundet fryser i 30–60 sekunder innan det återgår till normal drift.

11.2.1 Identifiering av blockeringskedjan

Öppna Aktivitetsmonitorn under en av dessa frysningshändelser och expandera rutan Processer:

1. Sortera efter Session ID för att se alla sessioner organiserade.
2. Flera sessioner visar värden i Blockerad av kolumnen, alla pekar på sessions-ID 73.
3. Session 73 visar '1' i Huvudblockerare kolumnen, vilket bekräftar att det är grundorsaken.
4. Ocuco-landskapet Väntetyp För blockerade sessioner visas LCK_M_X, vilket indikerar att de väntar på exklusiva lås.
5. Ocuco-landskapet Vänteresurs Kolumnen visar att blockeringen finns i tabellen Order.

11.2.2 Analysera orsaken

Högerklicka på Session 73 och välj Detaljer för att visa kommandot:

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

Den här uppdateringen är en del av ett batchbearbetningsjobb som körs varje timme. Kontrollerar Logga in Kolumnen bekräftar att sessionen tillhör batchbearbetningstjänstkontot.

Frågan håller lås på ordertabellen medan tusentals ordrar bearbetas. Väntetid för blockerade sessioner ökar stadigt, vilket bekräftar att denna långvariga operation är problemet.

11.2.3 Implementera korrigeringen

Kortsiktig lösning:

1. Dokumentera detaljer för session 73, inklusive frågetext och varaktighet.
2. Låt uppdateringen slutföras naturligt eftersom det är legitim batchbearbetning.
3. När det är klart, verifiera att blockerade sessioner är borta och att normal drift återupptas.

Långsiktiga lösningar implementerade:

1. Schemalägg om batchjobbet att köras under lågtrafik (2-4 på morgonen istället för under kontorstid).
2. Ändra batchbearbetningen för att uppdatera ordrar i mindre omgångar om 100 poster åt gången, vilket frigör lås mellan omgångar.
3. Lägg till ett index i kolumnen OrderId för att påskynda uppdateringsåtgärden.
4. Överväg SNAPSHOT-isolering för läsoperationer för att minska blockeringspåverkan.

11.3 Fallstudie: Identifiera överdrivet många frågekörningar

Databasövervakning visar att CPU-användningen gradvis har ökat under den senaste månaden, men inga uppenbara förändringar har skett i applikationskoden.

11.3.1 Upptäcka onormala exekveringsräkningar

Öppna Aktivitetsmonitorn och granska rutan Senaste dyra frågor:

1. Sortera efter Avrättningar/min för att se de mest frekvent utförda frågorna.
2. Den översta frågan visar 37 000 körningar per minut – betydligt högre än någon annan fråga.
3. Högerklicka och välj Redigera frågetext.
4. Frågan hämtar information om produktkategori:

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

5. Den här enkla frågan borde vara snabb och cachelagrad, men den körs tiotusentals gånger per minut.

11.3.2 Spårning till applikationskod

I rutan Processer hittar du sessioner som kör den här frågan:

1. Notera Ansökan Kolumnen visar ”ProductCatalogService”.
2. Högerklicka på en av dessa sessioner och välj Spåra processen i SQL Server Profiler.
3. SQL Profiler visar att frågan körs upprepade gånger i snabb följd med olika CategoryId-värden.
4. Kontakta utvecklingsteamet som hanterar ProductCatalogService för kodgranskning.

Kodgranskningen avslöjar problemet: en nyligen genomförd ändring hämtar produktlistningar med kategorier. För varje produkt i resultatmängden (ofta 1 000+ produkter) gör koden ett separat databasanrop för att hämta kategoriinformation – ett klassiskt N+1-frågeproblem.

11.3.3 Optimera applikationen

Implementera en korrekt åtgärd:

1. Ändra applikationsfrågan för att använda en JOIN som hämtar produkter och deras kategorier i ett enda databasanrop:

   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. Distribuera den uppdaterade koden och övervaka Aktivitetsmonitorn.
3. Verifiera korrigeringen: Antalet körningar per minut för kategorifrågan minskar från 37 000 till under 100, och den totala CPU-användningen minskar med 40 %.
4. Dokumentera lärdomen och dela med utvecklingsteamet för att förhindra liknande problem vid framtida kodändringar.

12. Upptäck potentiell databaskorruption

Även om Aktivitetsmonitorn inte är specifikt utformad för att upptäcka databaskorruption, kan vissa mönster i dess visning tyda på underliggande problem med korruption som kräver ytterligare undersökning.

12.1 Symtom på potentiell databaskorruption

Om det finns en skadad databas och den används kan du ibland se:

1. I processfönstret:

• Sessioner fastnade i AVSTÄNGT tillstånd med ovanliga väntetyper
• Processer som visar feltillstånd
• Frågor misslyckas upprepade gånger

2. I rutan Resursväntningar:

• Ovanliga I/O-relaterade väntetyper som kan tyda på diskproblem (även om detta mer sannolikt indikerar hårdvaruproblem snarare än logisk korruption)

3. I de senaste dyra sökningarna:

• Frågor med onormalt höga fysiska läsningar om de upprepade gånger försöker läsa skadade sidor

12.2 Ytterligare kontroll med DBCC CHECKDB

När Aktivitetsövervakningen visar symptom som tyder på potentiell korruption bör du omedelbart köra DBCC CHECKDB för att verifiera databasens integritet. Detta kommando skannar alla databassidor, validerar kontrollsummor och kontrollerar om det finns logiska konsistensfel.

För att lära dig mer om hur du använder DBCC CHECKDB för att kontrollera och åtgärda databasfel, se vår omfattande DBCC CHECKDB-guide.

12.3 Reparation med professionella verktyg

Om DBCC CHECKDB bekräftar databaskorruption har du flera alternativ för reparation:

• Det föredragna tillvägagångssättet är att återställa från en säkerhetskopia som är känd för att fungera. Se vår omfattande guide om hur du säkerhetskopierar och återställer SQL Server databaser.
• Vid mindre korruption kan DBCC CHECKDB med REPAIR_REBUILD lösa problemen.
• För kritiska databaser utan aktuella säkerhetskopior, professionell SQL-återställningsprogram och tjänster kan ofta återställa data som inbyggda reparationsalternativ inte kan.

13. Slutsats

SQL Server Aktivitetsövervakning är ett ovärderligt verktyg för databasadministratörer, vilket ger omedelbar insikt i serverns prestanda och hjälper till att diagnostisera problem snabbt och effektivt.

13.1 Sammanfattning av nyckelpunkter

I den här guiden har vi utforskat hur Aktivitetsmonitorn hjälper dig att förstå och felsöka SQL Server prestanda:

• Aktivitetsövervakning ger realtidsinsyn i processer, väntetider, frågor och I/O genom ett organiserat, grafiskt gränssnitt.
• De fem rutorna – Översikt, Processer, Resursväntningar, Datafils-I/O och Senaste dyra frågor – erbjuder var och en unika perspektiv på serveraktivitet.
• Vanliga felsökningsscenarier som överdriven körning av frågor, blockeringskedjor och hög CPU-användning blir hanterbara med systematisk undersökning av Aktivitetsövervakning.
• Även om Aktivitetsövervakning är kraftfull har den begränsningar, inklusive brist på historisk data, väntetypsgruppering och övervakningsoverhead som påverkar dess tillämpbarhet.
• Att komplettera Aktivitetsmonitorn med DMV-frågor, sp_WhoIsActive, Extended Events och potentiellt verktyg från tredje part skapar en omfattande övervakningsstrategi.
• Genom att följa bästa praxis för uppdateringsintervaller, stänga Aktivitetsmonitorn när den inte används och kombinera flera rutor för korrelation maximeras dess värde samtidigt som effekten minimeras.

13.2 Aktivitetsmonitor som en del av din verktygslåda

Aktivitetsövervakning bör fungera som ditt första verktyg för prestandaundersökningar, inte ditt enda verktyg. Dess styrka ligger i att ge omedelbar insyn under aktiv felsökning, vilket hjälper dig att snabbt avgöra om databasen är flaskhalsen och identifiera vilka specifika aspekter som behöver undersökas djupare.

Tänk på Aktivitetsmonitorn som en analog till instrumentbrädan i din bil – den talar omedelbart om för dig om något är fel och hjälper dig att identifiera det allmänna problemet. Precis som bilens instrumentbräda inte berättar exakt varför motorlampan lyser, pekar Aktivitetsmonitorn mot problem utan att alltid avslöja deras fullständiga orsak. Den djupare analysen kräver ytterligare verktyg och expertis.

Integrera Aktivitetsövervakning i en bredare verktygslåda som inkluderar analys av körningsplaner, spårning av väntestatistik, lösningar för historisk övervakning och bästa praxis för prestanda. Använd den tillsammans med lämpliga indexeringsstrategier, tekniker för frågeoptimering och kapacitetsplanering.

13.3 Fortsätta din läranderesa

Att bemästra Aktivitetsövervakning är bara ett steg i att bli en effektiv databasadministratör. Fortsätt att utveckla dina färdigheter genom att:

• Lära sig att tolka genomförandeplaner och identifiera ineffektiva operationer
• Förståelse SQL Server väntestatistik och dess konsekvenser
• Studera indexdesign och optimeringstekniker
• Utforska SQL Servers arkitektur och hur den bearbetar frågor
• Öva systematiska felsökningsmetoder
• Bygga erfarenhet med utökade händelser för detaljerad spårning
• Förstå transaktionsisoleringsnivåer och deras prestandapåverkan

Varje prestationsundersökning med Aktivitetsmonitor lär dig något nytt om hur SQL Server fungerar och hur applikationer interagerar med databaser. Dokumentera dina resultat, dela kunskap med kollegor och bygg ett bibliotek med lösningar för vanliga problem.

13.4 Ytterligare resurser

Utöka dina kunskaper med dessa värdefulla resurser:

• Öppna Activity Monitor i SQL Server Management Studio (SSMS) : Officiella SQL Server dokumentation om hur man öppnar Aktivitetsmonitorn i SQL Server Management Studio (SSMS).
• Aktivitetskontroll : Officiell SQL Server dokument om hur man använder Aktivitetsmonitorn.

14. Vanliga frågor (FAQ)

F: Vad är SQL Server ActivityMonitor?

A: SQL Server Aktivitetsmonitorn är ett inbyggt verktyg i SQL Server Management Studio som visar information i realtid om processer som körs på en SQL Server instans och deras inverkan på serverresurser. Den tillhandahåller en grafisk instrumentpanel med fem rutor som visar olika aspekter av serveraktivitet, inklusive processoranvändning, vänteuppgifter, I/O-hastigheter, aktiva sessioner och dyra frågor.

F: Hur öppnar jag Aktivitetsmonitorn i SSMS?

A: Du kan öppna Aktivitetsmonitorn med fyra metoder: (1) Klicka på ikonen Aktivitetsmonitor i SSMS-verktygsfältet, (2) Högerklicka på din SQL Server instansnamn i Object Explorer och välj Aktivitetskontroll, (3) Tryck ctrl + andra + A, eller (4) Konfigurera SSMS att starta det automatiskt via Verktyg -> Montering -> Miljö -> Startup.

F: Vilka behörigheter behöver jag för att använda Aktivitetsmonitorn?

A: Du behöver VISA SERVERSTATUS behörighet att se det mesta av aktivitetsmonitorns information. För panelen Data File I/O behöver du också antingen SKAPA DATABAS, ÄNDRA VALFRI DATABAS, eller VISA VALFRI DEFINITION behörigheter. Utan dessa behörigheter kan Aktivitetsmonitorn öppnas men visa tomma rutor.

F: Varför är min aktivitetsmonitor pausad eller fungerar inte?

A: Aktivitetsmonitorn pausar vanligtvis på grund av behörighetsproblem, föråldrade SSMS-versioner eller inaktiverade fjärranslutningar. För att lösa detta: (1) Uppdatera till den senaste SSMS-versionen, (2) Kontrollera att du har behörighet att VISA SERVERSTATUS, (3) Kontrollera att fjärranslutningar är aktiverade på SQL Server till exempel (4) Starta om SSMS, och (5) Försök att ansluta med Windows-autentisering istället för SQL-autentisering om tillämpligt.

F: Vad är skillnaden mellan Aktivitetsmonitorn och sp_WhoIsActive?

A: Aktivitetsmonitor är ett grafiskt verktyg inbyggt i SSMS som tillhandahåller organiserade rutor för olika övervakningsaspekter. sp_WhoIsActive är en gratis lagrad procedur skapad av community-användare som returnerar detaljerad sessionsinformation i en enda resultatuppsättning med mer specifika väntetyper, blockeringsdetaljer och anpassningsalternativ än Aktivitetsmonitor. Aktivitetsmonitor är bättre för visuell utforskning, medan sp_WhoIsActive utmärker sig vid skriptbaserad övervakning och ger mer detaljerad information.

F: Påverkar Aktivitetsmonitorn serverns prestanda?

A: Ja, Aktivitetsmonitorn har mätbara kostnader eftersom den frågar efter system-DMV:er vid varje uppdateringsintervall. Effekten ökar med lägre uppdateringsfrekvenser – Microsoft varnar för att intervall under 10 sekunder kan påverka serverns prestanda. Stäng alltid Aktivitetsmonitorn när du inte aktivt använder den och överväg uppdateringsintervall på 30–60 sekunder på produktionsservrar under hög belastning.

F: Kan jag hämta aktivitetsmonitordata med hjälp av T-SQL?

A: Ja, Aktivitetsövervakningen frågar efter dynamiska systemhanteringsvyer som sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats och sys.dm_exec_query_stats. Du kan fråga dessa DMV:er direkt med T-SQL för att hämta motsvarande information programmatiskt, vilket möjliggör anpassade övervakningsskript och automatiserad datainsamling.

F: Vad är standarduppdateringsintervallet?

A: Standarduppdateringsintervallet är 10 sekunder. Du kan ändra detta genom att högerklicka var som helst i översiktsfönstret och välja Uppdateringsintervalloch välja bland fördefinierade alternativ: 1 sekund, 5 sekunder, 10 sekunder, 30 sekunder, 1 minut eller 1 timme. Lägre intervall ger fler realtidsvyer men ökar övervakningskostnaden.

F: Hur kan jag automatiskt öppna Aktivitetsmonitorn vid uppstart av SSMS?

A: Konfigurera automatisk start via SSMS-alternativ: Navigera till Verktyg -> Montering -> Miljö -> Startup, Välj sedan Öppna Objektutforskaren och Aktivitetsmonitorn från Vid uppstart Aktivitetsmonitorn öppnas automatiskt varje gång du ansluter till en server i SSMS.

F: Vilka är begränsningarna med Aktivitetsmonitorn?

A: Viktiga begränsningar inkluderar: (1) Ingen lagring av historiska data eller trendfunktioner, (2) Väntetyper grupperas i kategorier snarare än visas specifikt, (3) Vissa väntetyper som CXPACKET kanske inte visas, (4) Tidpunktsbilder kan missa tillfälliga problem, (5) Övervakningskostnader kan påverka upptagna servrar, (6) Ingen varningsmekanism för proaktiv övervakning, och (7) Kan inte aggregera data över flera SQL Server instanser. För dessa behov, komplettera Aktivitetsmonitorn med utökade händelser, datainsamlingsuppsättningar eller övervakningsverktyg från tredje part.

---

Om författaren

Yuan Sheng är en senior databasadministratör (DBA) med över 10 års erfarenhet av SQL Server miljöer och hantering av företagsdatabaser. Han har framgångsrikt löst hundratals scenarier för databasåterställning inom finansiella tjänster, hälso- och sjukvård och tillverkningsorganisationer.

Yuan specialiserar sig på SQL Server databasåterställning, lösningar med hög tillgänglighetoch prestandaoptimering. Hans omfattande praktiska erfarenhet inkluderar hantering av databaser på flera terabyte, implementering av Always On Availability Groups och utveckling av automatiserade säkerhetskopierings- och återställningsstrategier för verksamhetskritiska affärssystem.

Genom sin tekniska expertis och praktiska tillvägagångssätt fokuserar Yuan på att skapa omfattande guider som hjälper databasadministratörer och IT-proffs att lösa komplexa problem. SQL Server utmaningar effektivt. Han håller sig uppdaterad med det senaste SQL Server utgåvor och Microsofts ständigt föränderliga databastekniker, och testar regelbundet återställningsscenarier för att säkerställa att hans rekommendationer återspeglar bästa praxis i verkligheten.

Har frågor om SQL Server återställning eller behöver du ytterligare vägledning om felsökning av databasen? Yuan välkomnar feedback och förslag för att förbättra dessa tekniska resurser.