SQL Server Activiteitenmonitor: een complete gids voor DBA's [2026]

1. Inleiding

1.1 Wat is SQL Server Activiteitenmonitor?

SQL Server Activity Monitor is een ingebouwde diagnose-appostic-tool binnen SQL Server Management Studio die informatie weergeeft over SQL Server processen en hun effect op de serverprestaties. Hiermee kunt u SQL Server processen beheren, resource-wachttijden bewaken, dure query's analyseren en I/O-patronen observeren - allemaal via één interface.

1.2 Waarom gebruiken SQL Server Activiteitenmonitor?

Activity Monitor fungeert als uw eerste verdedigingslinie bij het oplossen van prestatieproblemen. Het biedt direct inzicht in wat er op uw computer gebeurt. SQL Server bijvoorbeeld zonder dat er complexe T-SQL-query's of hulpmiddelen van derden nodig zijn.

De tool is uitstekend geschikt om u te helpen snel veelvoorkomende problemen te identificeren, zoals blokkerende sessies, CPU-intensieve query's, overmatige query-uitvoeringen en I/O-knelpunten. Wanneer gebruikers melden dat een applicatie traag is of niet reageert, helpt Activity Monitor u bepalen of de databaseserver de boosdoener is.

Voor databasebeheerders die niet met SQL Server Dagelijks biedt Activity Monitor een toegankelijke toegang tot inzicht in serveractiviteit. Zelfs ervaren DBA's gebruiken het als hun staraangrijpingspunt voor prestatieonderzoeken.

1.3 Activiteitenmonitor versus andere monitoringtools

Hoewel Activity Monitor waardevol is, is het belangrijk om te begrijpen hoe het zich verhoudt tot andere monitoringopties:

Activiteitenmonitor versus sp_WhoIsActive: Activity Monitor biedt een grafische interface met meerdere deelvensters, terwijl sp_WhoIsActive een uitgebreide opgeslagen procedure is die meer gedetailleerde informatie in één resultatenset biedt. sp_WhoIsActive toont specifieke wachttypen die door Activity Monitor worden gegroepeerd en biedt meer gedetailleerde blokkeringsinformatie.

Activiteitenmonitor versus sp_who2: Met de traditionele sp_who2-opdracht worden basisgegevens van de sessie weergegeven, maar Activity Monitor gaat een stap verder door wachtstatistieken, dure query's en I/O-gegevens weer te geven in een overzichtelijke, visuele indeling.

Activiteitenmonitor versus hulpmiddelen van derden: Commerciële monitoringoplossingen zoals SolarWinds Database Performance Analyzer bieden historische tracking, waarschuwingen en geavanceerde analyses die Activity Monitor niet biedt. Activity Monitor vereist echter geen extra kosten.ost of installatie.

1.4 Belangrijkste voordelen voor databasebeheerders

Activity Monitor biedt diverse voordelen die het tot een essentiële DBA-tool maken:

• Nul Cost: Als ingebouwde SQL Server Dankzij de Management Studio-functie zijn er geen licentiekosten of implementatiekosten verbonden.
• Realtime bewaking: Bekijk de huidige serveractiviteit terwijl deze plaatsvindt, met configureerbare vernieuwingsintervallen van 1 seconde tot 1 uur.
• Geïntegreerde acties: Klik met de rechtermuisknop op processen om sessies te beëindigen, querydetails te bekijken of processen te starten SQL Server Profiler-traceringen – allemaal rechtstreeks vanuit de tool.
• Meerdere perspectieven: Bekijk de serverstatus vanuit verschillende hoeken via vijf gespecialiseerde deelvensters, elk gericht op specifieke aspecten van de prestaties.
• Snelle probleemoplossing: Identificeer de most Los veelvoorkomende prestatieproblemen binnen enkele minuten op, waardoor u sneller een oplossing kunt vinden.
• Lage toetredingsdrempel: Er is geen geavanceerde kennis vereist om de tool effectief te gaan gebruiken, maar wel diepgaandere kennis. SQL Server expertise helpt bij de interpretatie.

2. S krijgentarted met Activity Monitor

Voordat u Activity Monitor effectief kunt gebruiken, moet u inzicht hebben in de vereisten, vereiste machtigingen en verschillende methoden voor het starten van de tool.

2.1 Vereisten en systeemvereisten

Te gebruiken SQL Server Activiteitenmonitor, je hebt nodig SQL Server Management Studio (SSMS) geïnstalleerd op uw lokale machine of een jumpserver. De Activity Monitor-tool is ingrijpend vernieuwd in SQL Server 2008, dus de informatie in deze gids is van toepassing op SQL Server 2008 en latere versies.

U moet een netwerkverbinding hebben met de SQL Server instantie die u wilt monitoren. Voor cloud-hostVoor ed-databases hebt u doorgaans een VPN-verbinding of correct geconfigureerde firewallregels nodig om toegang te krijgen tot de instantie.

Activity Monitor werkt met alle edities van SQL Server, waaronder Express, Standard en Enterprise. De tool zelf draait op uw clientcomputer binnen SSMS, dus de resources van de server worden alleen beïnvloed door de monitoringquery's die deze uitvoert.

2.2 Vereiste machtigingen

De juiste rechten zijn essentieel voor een correcte werking van Activity Monitor. Zonder de juiste rechten ziet u mogelijk een leeg scherm of krijgt u foutmeldingen dat de toegang is geweigerd.

2.2.1 Machtiging SERVERSTATUS BEKIJKEN

De SERVERSTATUS BEKIJKEN Toestemming is de primaire vereiste voor het gebruik van Activity Monitor. Met deze toestemming op serverniveau kunt u alle actieve processen en de bijbehorende statistieken zien.

Om deze toestemming te verlenen, kan een serverbeheerder het volgende uitvoeren:

GRANT VIEW SERVER STATE TO [YourLoginName];

Zonder VIEW SERVER STATE kan Activity Monitor wel worden geopend, maar worden er in geen van de deelvensters gegevens weergegeven.

2.2.2 Machtigingen op databaseniveau

Om informatie in het I/O-venster van het gegevensbestand te bekijken, hebt u aanvullende rechten nodig. U moet specifiek een van de volgende combinaties hebben:

• CREËER DATABASE toestemming, of
• WIJZIG ELKE DATABASE toestemming, of
• BEKIJK ELKE DEFINITIE toestemming

Deze rechten moeten worden gecombineerd met SERVERSTATUS BEKIJKEN voor volledige Activity Monitor-functionaliteit.

2.2.3 Problemen met machtigingen oplossen

Als Activiteitenmonitor wordt geopend maar er geen gegevens worden weergegeven, zijn de machtigingen de most Veelvoorkomende oorzaak. Controleer of uw login de status VIEW SERVER STATE heeft op serverniveau. U kunt uw rechten controleren door het volgende uit te voeren:

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

Zoek naar 'VIEW SERVER STATE' in de kolom permission_name. Als deze ontbreekt, neem dan contact op met uw databasebeheerder om deze te laten verlenen.

2.3 Hoe u Activity Monitor opent in SSMS

SQL Server Management Studio biedt vier verschillende methoden om Activity Monitor te starten, waardoor u flexibiliteit krijgt op basis van uw workflowvoorkeuren.

2.3.1 Methode 1: Vanuit de werkbalk

De snelste manier om Activiteitenweergave te openen is via het pictogram op de werkbalk:

1. Maak verbinding met uw SQL Server bijvoorbeeld in SQL Server Beheer Studio.
2. Zoek het Activiteitenmonitor-pictogram in de standaardwerkbalk (het lijkt op een staafdiagram met een groene afspeelknop).
3. Klik op het pictogram om Activiteitenweergave te starten.

Deze methode is het snelst als u al in SSMS werkt en snel de serveractiviteit wilt controleren.

2.3.2 Methode 2: Vanuit Object Explorer

U kunt Activity Monitor ook rechtstreeks vanuit de Object Explorer starten:

1. Zoek in Object Explorer naar de SQL Server instantie die u wilt bewaken.
2. Klik met de rechtermuisknop op de instantienaam.
3. Kies Activity Monitor vanuit het contextmenu.

Deze methode is handig wanneer u verbinding maakt met meerdere servers, omdat u hiermee zeker weet dat u het juiste exemplaar in de gaten houdt.

2.3.3 Methode 3: Sneltoets gebruiken

Voor gebruikers die zich richten op het toetsenbord, SQL Server Management Studio biedt een speciale snelkoppeling:

1. Zorg ervoor dat SSMS het actieve venster is en dat u verbonden bent met een exemplaar.
2. Druk op Ctrl + anders + A.
3. Activity Monitor wordt geopend voor het momenteel geselecteerde exemplaar in Object Explorer.

Houd er rekening mee dat Activity Monitor verbinding maakt met de serverinstantie die u in Object Explorer hebt geselecteerd. Controleer daarom of u de juiste instantie hebt geselecteerd voordat u deze snelkoppeling gebruikt.

2.3.4 Methode 4: Vanuit het optiesmenu (Startup Configuratie)

Als u Activity Monitor vaak gebruikt, kunt u SSMS zo configureren dat het automatisch wordt gestart wanneer u het programma start.tarbij de toepassing:

1. In SQL Server Management Studio, navigeer naar Tools -> opties.
2. Vouw in het dialoogvenster Opties het selectievakje uit MilieuEn selecteer Startube.
3. Van de Op startube vervolgkeuzelijst, selecteer Open Object Explorer en Activiteitenmonitor.
4. Kies OK.

De volgende keer dat u SSMS opstart en verbinding maakt met een server, wordt Activity Monitor automatisch geopend naast Object Explorer.

3. Inzicht in de deelvensters van de Activiteitenmonitor

Activity Monitor organiseert informatie in vijf uitvouwbare deelvensters, die elk een ander perspectief bieden op serveractiviteit. Begrijpen wat elk deelvenster weergeeft, is cruciaal voor effectieve probleemoplossing.

3.1 Overzichtsvenster

Het Overzicht-venster toont vier realtime grafieken die u een snel overzicht geven van uw gezondheid. SQL Server Bijvoorbeeld. Deze grafieken worden met een instelbaar interval bijgewerkt en helpen u om afwijkende patronen in één oogopslag te identificeren.

3.1.1 % Processortijd

Deze grafiek toont het percentage van de tijd dat de processor besteedt aan het uitvoeren van niet-inactieve threads voor de SQL Server instantie over alle CPU's. De waarde vertegenwoordigt SQL Serverhet processorgebruik van de server, niet het CPU-gebruik van de gehele server.

Als de processortijd constant op of nabij 100% staat, is uw server CPU-gebonden. Dit kan wijzen op inefficiënte query's, ontbrekende indexen of onvoldoende hardwarecapaciteit. Gebruik het deelvenster 'Recente dure query's' om te identificeren welke query's de most CPU.

3.1.2 Wachttaken

Deze statistiek geeft het aantal taken weer dat wacht op het vrijgeven van resources voordat ze verder kunnen gaan. Taken kunnen wachten op CPU, I/O, geheugen of vergrendelingen.

Een constant hoog aantal wachtende taken duidt op resourceconflicten. Het deelvenster Resourcewachttijden biedt meer informatie over welke typen resources wachttijden veroorzaken.

3.1.3 Database-I/O (MB/s)

Deze grafiek toont de snelheid van gegevensoverdracht tussen geheugen en schijf. Het combineert lees- en schrijfbewerkingen, gemeten in megabytes per seconde.

Pieken in database-I/O kunnen wijzen op query's die grote tabelscans uitvoeren, overmatige logactiviteit of controlepuntbewerkingen. Het deelvenster Gegevensbestand-I/O geeft de I/O-activiteit weer per database en bestand.

3.1.4 Batchverzoeken/sec

Deze metriek geeft het aantal weer SQL Server batches die per seconde door de instantie worden ontvangen. Een batch kan bestaan ​​uit één enkele instructie of uit meerdere instructies die tegelijk worden ingediend.

Deze waarde geeft u een idee van de algehele serveractiviteit. Plotselinge dalingen in batchverzoeken tijdens normale kantooruren kunnen wijzen op problemen met de applicatieconnectiviteit of problemen bij de gebruiker.

3.1.5 Vernieuwingsintervallen instellen

U kunt aanpassen hoe vaak Activity Monitor zijn gegevens bijwerkt:

1. Klik met de rechtermuisknop ergens in het Overzicht-venster.
2. Kies Vernieuw interval.
3. Kies een interval uit de vooraf gedefinieerde waarden: 1 seconde, 5 seconden, 10 seconden (standaard), 30 seconden, 1 minuut of 1 uur.

Het instellen van vernieuwingsintervallen van minder dan 10 seconden verhoogt de monitoringoverhead op uw server. Overweeg voor productiesystemen met een zware belasting intervallen van 30 seconden of langer om de impact te minimaliseren.

3.2 Processenvenster

In het deelvenster Processen wordt informatie weergegeven over de sessies die momenteel op uw computer worden uitgevoerd. SQL Server Bijvoorbeeld. Dit paneel is essentieel om te identificeren wie wat doet en om blokkerende problemen op te sporen.

3.2.1 Procesinformatie begrijpen

Elke rij in het deelvenster Processen vertegenwoordigt een actieve sessie op de server. Het deelvenster toont sessies van alle databases en alle gebruikers, waardoor u een compleet overzicht krijgt van de serveractiviteit.

De weergegeven informatie omvat de inlognaam, de applicatienaam, hostnaam, de database die wordt gebruikt en de huidige opdracht. Dit helpt u databaseactiviteit te correleren met specifieke gebruikers of applicaties.

3.2.2 Belangrijke kolommen uitgelegd

Als u de belangrijkste kolommen begrijpt, kunt u procesinformatie effectiever interpreteren:

• Sessie-ID: Een unieke identificatie voor elke verbinding. Systeemprocessen gebruiken negatieve sessie-ID's.
• Gebruikersproces: Geeft aan of dit een gebruikersessie (Ja) of een systeemproces (Nee) is.
• inloggen: De SQL Server login of Windows-account gekoppeld aan de sessie.
• Database: De huidige databasecontext voor de sessie.
• Taakstatus: Geeft weer wat de sessie op dit moment doet (LOPEND, GESUSPENDEERD, SLAPEND, enz.).
• Commando: Het type opdracht dat wordt uitgevoerd (SELECT, INSERT, UPDATE, enz.).
• Toepassing: De naam van de applicatie die de verbinding heeft gemaakt.
• Wacht tijd: Hoe lang (in milliseconden) de sessie wacht op bronnen.
• Wachttype: Het specifieke type bron waarop de sessie wacht.
• CPU-tijd: Totale CPU-tijd die door deze sessie is verbruikt sinds verbinding is gemaakt.
• Geheugengebruik: Hoeveelheid geheugen (in KB) die momenteel aan de sessie is toegewezen.

3.2.3 Filter- en sorteerprocessen

Het deelvenster Processen bevat krachtige filtermogelijkheden waarmee u zich kunt concentreren op relevante sessies:

1. Klik op de vervolgkeuzepijl in een kolomkop.
2. Het filter toont beschikbare waarden voor die kolom, inclusief Alles, blanksen Niet-Blanken.
3. Selecteer specifieke waarden om de weergave te filteren tot alleen die sessies.

U kunt bijvoorbeeld filteren Taakstatus om alleen LOPENDE sessies te tonen, of te filteren Database om de activiteit in een specifieke database te bekijken.

Je kunt ook op een kolom sorteren door op de kolomkop te klikken. Klik één keer voor oplopende volgorde, twee keer voor aflopende volgorde.

3.2.4 Blokkerende en geblokkeerde sessies identificeren

Met het deelvenster Processen kunt u blokkerende scenario's identificeren, waarbij één sessie verhindert dat andere sessies doorgaan:

• Geblokkeerd door: Geeft de sessie-ID weer van de sessie die deze sessie blokkeert. Als deze kolom een ​​waarde bevat, wacht de sessie op een vergrendeling van een andere sessie.
• Hoofdblokkering: Geeft '1' weer als deze sessie andere blokkeert, maar zelf niet geblokkeerd is. Dit is de hoofdoorzaak van een blokkerende keten.

Om een ​​blokkerend probleem te onderzoeken, identificeert u eerst de hoofdblokkering (de sessie gemarkeerd met '1' in de kolom Hoofdblokkering). Vervolgens onderzoekt u wat de sessie doet en beslist u of u de sessie wilt laten voltooien of beëindigen.

3.2.5 Procesacties (Kill, Details, Trace)

Met Activity Monitor kunt u acties ondernemen op individuele sessies:

1. Klik met de rechtermuisknop op een sessie in het deelvenster Processen.
2. U ziet verschillende opties:
   • Details: Geeft de laatste opdracht weer die door deze sessie is uitgevoerd.
   • Doodproces: Beëindigt de sessie (voorzichtig gebruiken).
   • Traceerproces in SQL Server profiler: Lanceert SQL Server Profiler en filtert automatisch zodat alleen de activiteit van deze sessie wordt weergegeven.

Met de optie Details ziet u de opdrachttekst, maar houd er rekening mee dat dit de laatste Opdracht uitgevoerd: deze is mogelijk nog niet actief. De optie Trace is vooral handig wanneer u de volledige reeks opdrachten wilt zien die een sessie uitvoert.

3.3 Bronwachtvenster

In het deelvenster Wachttijd bronnen worden wachtstatistieken samengevat, waarin wordt weergegeven op welke typen bronsessies er wordt gewacht.ost Deze informatie is cruciaal voor het diagnosticeren van prestatieknelpunten.

3.3.1 Wachtstatistieken begrijpen

. SQL Server Als een server niet direct een resourceaanvraag kan honoreren (zoals een vergrendeling, CPU-tijd of geheugen), komt de aanvragende taak in een wachtstatus terecht. Wachtstatistieken houden deze wachttijden bij en helpen u te begrijpen waar de server tijd aan besteedt in plaats van aan werk.

Het deelvenster Resourcewachttijden verzamelt gegevens uit dynamische systeembeheerweergaven zoals sys.dm_os_wait_stats en sys.dm_exec_requests. Bij elk vernieuwingsinterval wordt het verschil tussen de huidige en de vorige momentopname berekend, zodat u de accumulatiesnelheid voor elk wachttype kunt zien.

3.3.2 Wachtcategorieën

Activity Monitor groepeert honderden individuele wachttypen in bredere categorieën om de interpretatie te vereenvoudigen:

• CPU: Taken die wachten tot CPU-tijd beschikbaar is.
• Buffervergrendeling: Wacht op objecten voor kortetermijnsynchronisatie die de toegang tot gegevenspagina's in het geheugen beveiligen. Deze categorie omvat pagina-latchwachttijden (PAGELATCH_*).
• Lock: Wachttijden die worden veroorzaakt doordat sessies vergrendelingen vasthouden die andere sessies nodig hebben.
• Geheugen: Wacht op geheugentoekenningen die nodig zijn voor bewerkingen zoals sorteren en hashing.
• Netwerk I/O: Wacht op het verzenden van gegevens naar of ontvangen van gegevens van clients.
• SQL CLR: Wachttijden gerelateerd aan de uitvoering van Common Language Runtime.

Hoewel deze groepering de weergave vereenvoudigt, verhult het ook belangrijke details. Zo kan "Buffer Latch" bijvoorbeeld de wachttijden PAGELATCH_SH, PAGELATCH_UP en PAGELATCH_EX groeperen, wat verschillende gevolgen heeft voor de prestaties.

3.3.3 Interpretatie van wachttijd en wachttaken

In het deelvenster Resourcewachten worden twee belangrijke statistieken voor elke wachtcategorie weergegeven:

• Cumulatieve wachttijd (ms): Het totale aantal milliseconden dat is verzameld tijdens het huidige vernieuwingsinterval voor deze wachtcategorie.
• Wachttaken: Het aantal taken dat momenteel wacht op bronnen in deze categorie.

De wachttijdwaarde is bijzonder interessant. Als u een vernieuwingsinterval van 10 seconden hebt en een wachttijd van 20,000 ms voor een categorie ziet, duidt dit op meerdere gelijktijdige wachttijden (20,000 ms / 10,000 ms = gemiddelde van 2 gelijktijdige wachttijden gedurende het interval).

3.3.4 Prestatieknelpunten identificeren

Gebruik het deelvenster Resource Waits om te identificeren waar uw server de tijd aan besteedtost wachttijd:

1. Vouw het deelvenster Resourcewachttijden uit.
2. Kijk welke wachtcategorieën de langste wachttijden opleveren.
3. Sorteer op Cumulatieve wachttijd om te zien welke bronnen m zijnost beperkt.

Hoge buffer-latch-wachttijden duiden vaak op conflicten rond gegevenspagina's in het geheugen, wat kan wijzen op I/O-knelpunten of tempdb-conflicten. Hoge lock-wachttijden wijzen op blokkeringsproblemen. Hoge geheugen-wachttijden duiden op onvoldoende geheugentoewijzingen voor querybewerkingen.

3.4 Gegevensbestand I/O-paneel

In het deelvenster Gegevensbestand-I/O wordt de schijfactiviteit voor elk databasebestand op uw server weergegeven. Zo kunt u I/O-knelpunten identificeren en inzicht krijgen in schijfgebruikpatronen.

3.4.1 I/O-metrieken begrijpen

In het deelvenster Gegevensbestand I/O worden verschillende statistieken voor elk databasebestand weergegeven:

• Database: De naam van de databank.
• Bestandstype: Ofwel Gegevens (inclusief tabellen en indexen) of Log (transactielogboek).
• Logische naam: De logische bestandsnaam zoals gedefinieerd in SQL Server.
• MB/sec Lezen: De snelheid waarmee gegevens uit dit bestand worden gelezen.
• MB/sec Geschreven: De snelheid waarmee gegevens naar dit bestand worden geschreven.
• Reactietijd (ms): Gemiddelde responstijd voor I/O-bewerkingen op dit bestand.

Deze statistieken worden vernieuwd met hetzelfde interval als het Overzicht-venster, waardoor u realtime inzicht hebt in de schijfactiviteit.

3.4.2 I/O-knelpunten identificeren

Let op deze patronen die duiden op I/O-prestatieproblemen:

• Hoge responstijd: Responstijden die consistent boven de 15-20 ms liggen, duiden op trage schijfsubsystemen. Responstijden boven de 50 ms duiden op ernstige I/O-knelpunten.
• Onevenwichtige lading: Als één gegevensbestand aanzienlijk hogere I/O-snelheden heeft dan andere gegevensbestanden in dezelfde database, kunt u wellicht extra bestanden toevoegen om de belasting te verdelen.
• Overmatige Tempdb-activiteit: Hoge I/O-snelheden op tempdb-bestanden duiden er vaak op dat query's grote tussenliggende resultaatsets genereren of inefficiënte uitvoeringsplannen gebruiken.

3.4.3 Databasebestandsanalyse

Gebruik het deelvenster Gegevensbestand-I/O om te begrijpen hoe uw databases schijfbronnen gebruiken:

1. Vouw het deelvenster Gegevensbestand I/O uit.
2. Sorteer op MB/sec lezen or MB/sec Geschreven om de m te identificerenost actieve bestanden.
3. Let op bestanden met consistent hoge activiteit of lange responstijden.
4. Vergelijk deze informatie met het deelvenster Recente dure query's om te bepalen welke query's de I/O-belasting veroorzaken.

3.5 Recente dure query's-paneel

Het paneel Recente dure zoekopdrachten is vaak het most Waardevol paneel voor het oplossen van problemen met applicatieprestaties. Het toont query's die aanzienlijke serverbronnen verbruiken, wat u helpt bij het identificeren van optimalisatiemogelijkheden.

3.5.1 Query-statistieken begrijpen

Activity Monitor geeft verschillende statistieken weer voor elke dure query:

• Executies/min: Hoe vaak de query de afgelopen minuut is uitgevoerd.
• CPU (ms/sec): CPU-tijd die per seconde door deze query wordt verbruikt.
• Fysieke lezingen/sec: Aantal fysieke schijfleesbewerkingen per seconde voor deze query.
• Logische schrijfbewerkingen/sec: Aantal logische schrijfbewerkingen (naar buffercache) per seconde.
• Logische lezingen/sec: Aantal logische leesbewerkingen (vanuit buffercache) per seconde.
• Gemiddelde duur (ms): Gemiddelde uitvoeringstijd voor deze query.
• Aantal plannen: Aantal uitvoeringsplannen in de cache voor deze query.

Met deze statistieken kunt u niet alleen begrijpen welke zoekopdrachten duur zijn, maar ook Waarom Hoe duur ze zijn en hoe vaak ze rijden.

3.5.2 Sorteeropties

U kunt het deelvenster Recente dure query's sorteren op verschillende statistieken om verschillende soorten problemen te vinden:

1. Klik op een kolomkop om op die metriek te sorteren.
2. Veelvoorkomende sorteerstrategieën zijn:
   • Sorteren op CPU: Zoek naar zoekopdrachten die de m gebruikenost processortijd.
   • Sorteren op Executies/min: Identificeer zoekopdrachten die extreem vaak worden uitgevoerd.
   • Sorteren op fysieke lezingen: Zoek naar zoekopdrachten die de m veroorzakenost schijf I/O.
   • Sorteren op gemiddelde duur: Zoek naar langlopende zoekopdrachten.

Probeer bij het oplossen van een prestatieprobleem te sorteren op meerdere kolommen om verschillende perspectieven te krijgen. Een query met een matig CPU-gebruik maar extreem hoge uitvoeringsfrequentie per minuut kan het echte probleem zijn.

3.5.3 Querytekst bekijken

Om de werkelijke SQL-instructie achter een dure query te zien:

1. Klik met de rechtermuisknop op de queryrij in het deelvenster Recente dure query's.
2. Kies Querytekst bewerken.
   
3. Er wordt een nieuw queryvenster geopend waarin de volledige SQL-instructie wordt weergegeven.
   

Hiermee kunt u de querylogica onderzoeken en mogelijke optimalisatiemogelijkheden identificeren. Vervolgens kunt u de querytekst kopiëren om gewijzigde versies te testen.

3.5.4 Uitvoeringsplannen analyseren

Uitvoeringsplannen laten zien hoe SQL Server voert een query uit en onthult inefficiënties zoals ontbrekende indexen of ongeschikte join-typen:

1. Klik met de rechtermuisknop op de queryrij in het deelvenster Recente dure query's.
2. Kies Uitvoeringsplan weergeven.
   
3. SQL Server Management Studio geeft een grafische weergave van hoe de query wordt uitgevoerd.
   

Zoek naar bewerkingen die een groot percentage van de query c verbruikenost, waarschuwingen over ontbrekende statistieken of indexen, en onverwachte tabelscanbewerkingen. Deze geven vaak aan waar optimalisatie-inspanningen zich op moeten richten.

3.5.5 Problematische vragen identificeren

Let op deze patronen in het deelvenster Recente dure query's:

• Overmatige executies: Een query die duizenden keren per minuut wordt uitgevoerd, kan duiden op een N+1 queryprobleem waarbij de applicatiecode de database in een lus aanroept.
• Hoge fysieke lezingen: Query's met hoge fysieke leessnelheden raken de schijf vaak, wat kan duiden op ontbrekende indexen of slecht geschreven query's.
• Hoge CPU met korte duur: Veel snelle query's die samen veel CPU verbruiken, kunnen de serverprestaties net zo hard beïnvloeden als een paar langzame query's.
• Meerdere planaantallen: Query's met veel uitvoeringsplannen kunnen last hebben van problemen met het opsporen van parameters of van niet-geparameteriseerde query's die een te grote cache van het plan veroorzaken.

4. Activity Monitor gebruiken voor prestatieproblemen oplossen

Activity Monitor komt pas echt tot zijn recht wanneer u het systematisch gebruikt om prestatieproblemen te diagnosticeren en op te lossen. In dit gedeelte worden veelvoorkomende probleemoplossingsscenario's besproken en hoe u deze kunt aanpakken.

4.1 Overmatige query-uitvoeringen diagnosticeren

Een van henost Veelvoorkomende prestatieproblemen zijn dat query's veel vaker worden uitgevoerd dan nodig is. Dit is vaak te wijten aan problemen met het ontwerp van de toepassing.

4.1.1 Herhaalde zoekopdrachten identificeren

Om query's te herkennen die te vaak worden uitgevoerd:

1. Open Activiteitenmonitor en vouw de Recente dure zoekopdrachten brood.
2. Sorteer op Executies/min (executies per minuut).
3. Zoek naar query's bovenaan met uitvoeringsaantallen die onredelijk hoog lijken.
4. Klik met de rechtermuisknop op de verdachte query en selecteer Querytekst bewerken om de SQL-instructie te onderzoeken.

Als u bijvoorbeeld ziet dat een eenvoudige SELECT-instructie 37,000 keer per minuut wordt uitgevoerd, kunt u zich afvragen of de toepassing deze query echt zo vaak hoeft aan te roepen.ost Zoekopdrachten die meer dan een paar duizend keer per minuut worden uitgevoerd, rechtvaardigen een onderzoek.

4.1.2 Analyse van de hoofdoorzaak

Overmatige query-uitvoeringen worden meestal veroorzaakt door de volgende problemen:

• N+1 Query Probleem: Applicatiecode haalt een lijst met items op en voert vervolgens voor elk item een ​​aparte query uit om gerelateerde gegevens op te halen. Dit genereert N extra query's, waarbij N het aantal items is.
• Ontbrekende cache: De applicatie vraagt ​​de database om gegevens die rarwijzigingen automatisch doorvoeren in plaats van deze in het toepassingsgeheugen op te slaan.
• Polling-lussen: Code raadpleegt herhaaldelijk de database om te controleren op statuswijzigingen in plaats van gebruik te maken van wijzigingsmeldingen of berichtenwachtrijen.
• ORM-inefficiëntie: Entity Framework en vergelijkbare hulpmiddelen genereren soms inefficiënte querypatronen wanneer ontwikkelaars niet begrijpen hoe hun code naar SQL wordt vertaald.

Om de hoofdoorzaak te bepalen, moet u de query terugleiden naar de applicatiecode. Let op de Applicatie en Inloggen kolommen in het deelvenster Processen wanneer de query wordt uitgevoerd. U kunt ook met de rechtermuisknop op het proces klikken en selecteren Traceerproces in SQL Server Profiler om het roeppatroon te zien.

4.1.3 Oplossingen en beste praktijken

Wanneer u overmatig veel query-uitvoeringen hebt geïdentificeerd, kunt u de volgende oplossingen overwegen:

• Batchverwerking: Pas de toepassingscode aan om meerdere items in één query op te halen met behulp van joins of IN-clausules in plaats van afzonderlijke query's in een lus uit te voeren.
• Resultaatcaching: Cache die regelmatig wordt aangeroepen, waarbij gegevens in het toepassingsgeheugen zelden worden gewijzigd, met passende vervaldata.
• Gretig laden: Configureer ORM's om gebruik te maken van eager loading-strategieën waarmee gerelateerde gegevens met minder, maar efficiëntere query's worden opgehaald.
• Queryparameterisatie: Zorg ervoor dat query's parameters gebruiken in plaats van waarden samen te voegen. Dit verbetert het hergebruik van de plancache en vermindert de overheadkosten voor compilatie.

4.2 Onderzoek naar blokkeringsproblemen

Blokkering treedt op wanneer een sessie geblokkeerd is en andere sessies niet verder kunnen. Dit resulteert in trage applicatieresponstijden en gefrustreerde gebruikers.

4.2.1 Blokkeringsketens identificeren

Om blokkering te detecteren en analyseren:

1. Open Activiteitenmonitor en vouw de Processen brood.
2. Zoek naar sessies met waarden in de Geblokkeerd door kolommen: deze wachten op vergrendelingen die door andere sessies worden vastgehouden.
3. Zoek sessies met '1' in de Hoofdblokker kolom - dit zijn de hoofdoorzaken van blokkerende ketens.
4. Merk op Session ID van de hoofdblokkering.
5. Klik met de rechtermuisknop op de sessie van de hoofdblokkering en selecteer Details om te zien welke opdracht wordt uitgevoerd.

Het begrijpen van de blokkeringsketen is cruciaal. De hoofdblocker is de sessie die je moet onderzoeken, niet de geblokkeerde sessies stroomafwaarts.

4.2.2 Slottypen begrijpen

De Wachttype De kolom in het deelvenster Processen geeft aan op welk type geblokkeerde sessies wordt gewacht:

• LCK_M_X: Exclusieve lock-wachttijd, meestal veroorzaakt door UPDATE-, DELETE- of INSERT-bewerkingen.
• LCK_M_S: Gedeelde vergrendelingswachttijd, meestal SELECT-instructies die wachten tot exclusieve vergrendelingen worden vrijgegeven.
• LCK_M_U: Update lock wait, een tussenliggend vergrendelingstype dat wordt gebruikt tijdens updates.
• LCK_M_IX: Intent-exclusieve vergrendelingswachttijd, wat duidt op een vergrendelingsconflict op pagina- of rijniveau.

De Wachtbron In de kolom 'Databaseobject' wordt weergegeven welk databaseobject wordt vergrendeld. Zo krijgt u inzicht in welke tabel of index bij de strijd is betrokken.

4.2.3 Problemen met blokkering oplossen

Zodra u de blokkerende sessie en het effect ervan hebt geïdentificeerd, hebt u verschillende opties:

1. Wacht op voltooiing: Als de head blocker een legitieme query uitvoert die binnenkort voltooid zal worden, is het wellicht het beste om deze vanzelf af te ronden.
2. Sluit de sessie: Als de head blocker vastzit of een query uitvoert die geannuleerd moet worden:
   • Klik met de rechtermuisknop op de sessie in het deelvenster Processen.
   • Kies Kill Process.
   • Bevestig de actie in het dialoogvenster.
3. Optimaliseer zoekopdrachten: Als de blokkering bij dezelfde query's opnieuw optreedt, optimaliseer ze dan om de vergrendelingsduur te verkorten.
4. Pas isolatieniveaus aan: Overweeg het gebruik van READ COMMITTED SNAPSHOT ISOLATION om blokkering in workloads met veel leesbewerkingen te verminderen.
5. Indexafstemming: Voeg indexen toe om query's te versnellen en de duur van vergrendelingen te verkorten.

4.3 Analyse van hoog CPU-gebruik

Wanneer in het overzichtsvenster de processortijd consistent op of nabij 100% wordt weergegeven, moet u bepalen welke query's hiervoor verantwoordelijk zijn en of deze geoptimaliseerd kunnen worden.

4.3.1 CPU-intensieve query's identificeren

Om query's te vinden die veel CPU verbruiken:

1. Open de Recente dure zoekopdrachten brood.
2. Sorteer op CPU (ms/sec) om zoekopdrachten weer te geven met behulp van de most CPU-tijd.
3. Bekijk de belangrijkste zoekopdrachten in de lijst.
4. Klik met de rechtermuisknop op query's met een hoog CPU-gebruik en selecteer Querytekst bewerken om de SQL-instructie te bekijken.
5. Kies Uitvoeringsplan weergeven om te begrijpen hoe de query wordt uitgevoerd.

Let niet alleen op het CPU-gebruik van individuele query's, maar ook op de Executies/min kolom. Een query die een gemiddelde CPU per uitvoering gebruikt, maar duizenden keren per minuut wordt uitgevoerd, kan uw grootste CPU-verbruiker zijn.

4.3.2 Query-optimalisatietechnieken

Veelvoorkomende benaderingen om het CPU-verbruik te verminderen zijn:

• Ontbrekende indexen toevoegen: Indexzoekopdrachten gebruiken veel minder CPU dan tabelscans. Zoek naar aanbevelingen voor ontbrekende indexen in uitvoeringsplannen.
• Herschrijf inefficiënte query's: Vervang cursors door op sets gebaseerde bewerkingen, verwijder onnodige functies in WHERE-clausules en verwijder overbodige joins.
• Statistieken bijwerken: Verouderde statistieken veroorzaken SQL Server om inefficiënte uitvoeringsplannen te kiezen. Voer UPDATE STATISTICS uit op de betrokken tabellen.
• Verminder datavolume: Voeg WHERE-clausules toe om gegevens eerder te filteren, gebruik TOP of OFFSET/FETCH voor paginering en vermijd SELECT *.
• Parameter sniffing oplossen: Gebruik OPTION (RECOMPILE), queryhints of plangidsen wanneer parameter sniffing problemen veroorzaakt.

4.4 Geheugenproblemen onderzoeken

Geheugendruk kan ertoe leiden dat query's naar de schijf lekken, wat de prestaties aanzienlijk verslechtert. Activity Monitor helpt u geheugenintensieve bewerkingen te identificeren.

4.4.1 Geheugenstatistieken begrijpen

De Geheugengebruik De kolom in het deelvenster Processen toont het geheugen dat aan elke sessie is toegewezen in kilobytes. Een hoog geheugengebruik door één sessie duidt vaak op:

• Grote sorteer- of hashbewerkingen die niet in het aanvankelijk toegewezen geheugen pasten
• Query's die enorme resultaatsets ophalen
• Overmatig parallelisme waardoor er veel kopieën van uitvoeringsplanoperatoren ontstaan
• Geheugenlekken in CLR-opgeslagen procedures of functies

In het deelvenster Resourcewachttijden worden mogelijk geheugenwachttijden weergegeven wanneer query's niet voldoende geheugentoewijzingen kunnen verkrijgen en moeten wachten tot er geheugen beschikbaar is.

4.4.2 Identificatie van geheugenintensieve query's

Om zoekopdrachten te vinden die geheugenbelasting veroorzaken:

1. Zoek in de map Processen paneel, sorteren op Geheugengebruik om sessies te zien die de m verbruikenost geheugen.
2. Klik met de rechtermuisknop op sessies met een hoog geheugengebruik en selecteer Details om hun vragen te bekijken.
3. Zoek in de map Recente dure zoekopdrachten paneel, zoek naar zoekopdrachten met hoge Logische lezingen or Logische schrijfbewerkingen, omdat deze vaak verband houden met geheugengebruik.
4. Onderzoek uitvoeringsplannen voor Sort- en Hash Match-operatoren, die gebruikmaken van geheugentoekenningen.

Zoekopdrachten die waarschuwingen over "Memory Grant" in uitvoeringsplannen of spill-waarschuwingen weergeven, duiden op problemen met de geheugendruk.

4.5 Problemen met de applicatieprestaties detecteren

Wanneer gebruikers langzame responstijden van applicaties melden, helpt Activity Monitor u bepalen of de database de bottleneck is.

4.5.1 Activiteitsmonitor correleren met toepassingsproblemen

Om de traagheid van de applicatie te onderzoeken:

1. Noteer het exacte tijdstip waarop gebruikers problemen melden en welke applicaties hierdoor getroffen zijn.
2. Open Activiteitenmonitor en controleer de Overzicht paneel voor pieken in de hoeveelheid bronnen op dat moment.
3. Zoek in de map Processen paneel, filter op Applicatie om alleen de verbindingen van de betreffende toepassing weer te geven.
4. Zoek naar hoog Wacht tijd waarden die vertragingen in de database aangeven.
5. Controleer de Recente dure zoekopdrachten venster voor query's van die applicatie die aanzienlijke bronnen verbruiken.

Als de database geen ongebruikelijke activiteit vertoont, maar gebruikers traagheid ervaren, ligt het probleem waarschijnlijk bij de applicatiecode, netwerklatentie of prestaties aan de clientzijde.

4.5.2 Inefficiënte applicatiepatronen identificeren

Activity Monitor onthult verschillende antipatronen in applicatieontwerp:

• Chatty-toepassingen: Veel kleine zoekopdrachten in plaats van minder, efficiëntere zoekopdrachten. Herkenbaar aan een hoog aantal verbindingen en talrijke eenvoudige zoekopdrachten in Recente Dure Zoekopdrachten.
• N+1-vragen: Eén query gevolgd door N extra query's voor gerelateerde data. Wordt weergegeven als een eenvoudige query met extreem hoge uitvoeringsfrequenties per minuut.
• Grote resultaatsets: Toepassingen die veel meer gegevens ophalen dan nodig is. Zoek naar hoge Logische lezingen gecombineerd met eenvoudige SELECT * query's.
• Ontbrekende time-outs: Toepassingen die geen opdrachttime-outs instellen, kunnen verbindingen onbeperkt open laten staan, wat zichtbaar is als langdurige sessies in het deelvenster Processen.

5. Alternatieve methoden: Activity Monitor-gegevens ophalen via T-SQL

Hoewel Activity Monitor een handige grafische interface biedt, moet u soms equivalente informatie programmatisch ophalen of aangepaste bewakingsoplossingen maken.

5.1 Dynamische beheerweergaven (DMV's) gebruiken

SQL Server geeft informatie over activiteiten weer via dynamische beheerweergaven, die Activity Monitor achter de schermen raadpleegt.

5.1.1 Belangrijkste DMV's voor activiteitsbewaking

De most Belangrijke DMV's voor het repliceren van de Activity Monitor-functionaliteit zijn onder meer:

• sys.dm_exec_verzoeken: Geeft de verzoeken weer die momenteel worden uitgevoerd, met informatie over CPU, I/O en wachten.
• sys.dm_exec_sessies: Bevat informatie op sessieniveau, zoals inlognaam, host naam en programmanaam.
• sys.dm_os_wait_stats: Geeft cumulatieve wachtstatistieken voor het volledige exemplaar.
• sys.dm_exec_query_statistieken: Bevat samengevoegde prestatiestatistieken voor gecachte query's.
• sys.dm_io_virtuele_bestandsstatistieken: Retourneert I/O-statistieken voor gegevens- en logbestanden.
• sys.dm_exec_sql_tekst: Haalt de SQL-tekst op voor een gegeven sql_handle of plan_handle.
• sys.dm_exec_query_plan: Retourneert het uitvoeringsplan voor een gecachte query.

5.1.2 Voorbeeldquery's voor procesinformatie

Om de functionaliteit van het deelvenster Processen te repliceren, kunt u het volgende opvragen:

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 Voorbeeldquery's voor wachtstatistieken

Om wachtstatistieken te bekijken op dezelfde manier als in het deelvenster Resourcewachten:

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 sp_WhoIsActive gebruiken

sp_WhoIsActive is een krachtige, door de community gemaakte opgeslagen procedure die meer gedetailleerde informatie biedt dan Activity Monitor in één resultatenset.

5.2.1 sp_WhoIsActive installeren

Om sp_WhoIsActive te installeren:

1. Download de laatste versie van http://whoisactive.com.
2. De download is een SQL-script met de proceduredefinitie.
3. Open het script in SQL Server Beheer Studio.
4. Maak verbinding met uw SQL Server aanleg.
5. Voer het script uit om de procedure in de masterdatabase te maken.
6. Geef de juiste gebruikers uitvoeringsrechten.

Omdat sp_WhoIsActive in de master is geïnstalleerd, is het toegankelijk vanuit elke databasecontext.

5.2.2 Voorbeelden van basisgebruik

De eenvoudigste manier om sp_WhoIsActive te gebruiken is:

EXEC sp_WhoIsActive;

Hiermee wordt een resultatenset geretourneerd met alle actieve sessies met hun query's, wachttypen, blokkeringsinformatie en resourcegebruik.

Voor een 10 seconden durend voorbeeld waarin de activiteit gedurende die periode wordt getoond:

EXEC sp_WhoIsActive @delta_interval = 10;

Hiermee worden delta's voor statistieken zoals CPU en uitlezingen berekend, zodat u kunt zien wat er in die 10 seconden is gebeurd.

5.2.3 Geavanceerde parameters

sp_WhoIsActive ondersteunt talrijke parameters voor aanpassing:

• @filter: Filter resultaten op specifieke sessies, databases of logins.
• @filter_type: Geef aan waarop het filter van toepassing is (sessie, database, login, enz.).
• @get_plans: Neem uitvoeringsplannen op in de resultaten (ingesteld op 1).
• @get_locks: Gedetailleerde vergrendelingsinformatie weergeven (ingesteld op 1).
• @get_transaction_info: Transactiedetails weergeven (ingesteld op 1).
• @sorteervolgorde: Sorteer resultaten op basis van verschillende meetgegevens (CPU, leesbewerkingen, duur, enz.).
• @bestemmingstabel: Voeg de resultaten in een tabel in voor historische tracking.

Voorbeeld van plannen gesorteerd op CPU:

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

5.3 Systeem opgeslagen procedures gebruiken

SQL Server omvat traditionele opgeslagen procedures voor het monitoren van activiteiten, hoewel ze minder informatie bieden dan DMV's of Activity Monitor.

5.3.1 sp_who en sp_who2

De sp_who-procedure toont basissessie-informatie:

EXEC sp_who;

De sp_who2-procedure biedt iets meer details:

EXEC sp_who2;

Beide procedures tonen sessie-ID's, inlognamen, CPU-tijd en blokkeringsinformatie. Ze missen echter de gedetailleerde informatie die beschikbaar is via DMV's of Activity Monitor. Ze zijn most Handig voor snelle controles wanneer u snel minimale informatie nodig hebt.

5.3.2 Andere nuttige systeemprocedures

Aanvullende systeemprocedures voor monitoring omvatten:

• sp_lock: Geeft vergrendelingsinformatie weer (verouderd; gebruik in plaats daarvan sys.dm_tran_locks).
• sp_monitor: Geeft statistieken weer over SQL Server activiteit.
• sp_help: Geeft objectdefinities en metagegevens weer.
• DBCC SQLPERF: Geeft het transactielogboekruimtegebruik en wachtstatistieken weer.

5.4 Aangepaste monitoringscripts maken

Voor omgevingen die specifieke bewaking vereisen die verder gaat dan wat Activity Monitor biedt, kunt u aangepaste oplossingen bouwen met behulp van DMV's.

5.4.1 Voltooi het Activity Monitor Equivalent Script

Hier is een uitgebreid script dat m repliceertost Functionaliteit van Activiteitenmonitor:

-- 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 Monitoring automatiseren met SQL Agent-taken

U kunt aangepaste bewakingsscripts plannen met behulp van SQL Server Tussenpersoon:

1. Maak een tabel om de monitoringresultaten op te slaan.
2. Pas uw monitoringscript aan om de resultaten in deze tabel in te voegen.
3. In SQL Server Management Studio, uitbreiden SQL Server Agent in Objectverkenner.
4. Klik met de rechtermuisknop Werken bij en selecteer Nieuwe baan.
5. Configureer de taak om uw bewakingsscript met regelmatige tussenpozen uit te voeren.
6. Stel waarschuwingen of rapporten in op basis van de verzamelde gegevens.

Deze aanpak maakt historische tracking en trendanalyse mogelijk, wat Activity Monitor niet biedt.

6. Beperkingen en overwegingen van de Activity Monitor

Activity Monitor is waardevol, maar als u de beperkingen ervan begrijpt, kunt u Activity Monitor beter op de juiste manier gebruiken en indien nodig aanvullen met andere hulpmiddelen.

6.1 De overhead van Activity Monitor begrijpen

Activity Monitor is niet gratis: het verbruikt serverbronnen om informatie te verzamelen en weer te geven. Als u deze overhead begrijpt, kunt u het verantwoord gebruiken.

6.1.1 Impact op serverbronnen

Activity Monitor voert query's uit op systeem-DMV's bij elke vernieuwing. Deze query's verbruiken CPU, genereren logische leesbewerkingen en kunnen systeemtabellen tijdelijk blokkeren. Op drukke servers kan deze overhead de prestaties beïnvloeden.

De deelvensters Processen en Recente dure query's zijn bijzonder duur, omdat ze mogelijk grote DMV's moeten scannen en tabellen moeten cachen. Op servers met duizenden gecachte queryplannen kan het vernieuwen van Recente dure query's enkele seconden duren.

In de documentatie van Microsoft wordt gewaarschuwd dat vernieuwingsintervallen van minder dan 10 seconden een merkbare invloed kunnen hebben op de serverprestaties, vooral op systemen die al zijn geladen.

6.1.2 Aanbevolen procedures voor vernieuwingsintervallen

Kies vernieuwingsintervallen die geschikt zijn voor uw situatie:

• 1-5 seconden: Alleen voor het direct oplossen van kritieke problemen op licht belaste servers. Laat Activity Monitor niet op deze tijdstippen draaien.
• 10 seconden (standaard): Redelijk voor most scenario's voor probleemoplossing en algemene monitoring.
• 30-60 seconden: Betere keuze voor productieservers die zwaar belast worden of bij langdurige monitoring.
• Alleen handmatige vernieuwing: Voor situaties waarin u af en toe de huidige status wilt controleren zonder voortdurend te hoeven pollen.

Sluit Activiteitenweergave altijd af als je klaar bent met onderzoeken. Laat het niet continu draaien, vooral niet als het meerdere keren per dag door verschillende gebruikers wordt uitgevoerd.

6.2 Problemen met wachttypegroepering

De aanpak van Activity Monitor voor het categoriseren van wachttijden kan, hoewel het de weergave vereenvoudigt, belangrijke diagnoses vertroebelen.ostic-informatie.

6.2.1 Hoe Activity Monitor-groepen wachten

SQL Server Houdt honderden verschillende wachttypen bij, die elk een specifieke resource of conditie aangeven. Activity Monitor groepeert deze in brede categorieën zoals 'Buffer Latch', 'Lock' en 'Memory'.

De categorie 'Buffer Latch' omvat bijvoorbeeld PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX en diverse andere specifieke wachttypen. Hoewel ze allemaal gerelateerd zijn aan paginatoegang, hebben ze verschillende oorzaken en oplossingen.

Microsoft geeft niet precies aan welke wachttypen bij welke categorieën horen, waardoor het lastig is te begrijpen wat u precies ziet.

6.2.2 Ontbrekende wachttypen

Activiteitenmonitor toont niet alle wachttypen. Most Met name CXPACKET-wachttijden worden vaak weggelaten, wat wijst op parallelle query-uitvoering. CXPACKET-wachttijden komen vaak voor en zijn meestal niet problematisch, maar als u weet dat ze aanwezig zijn, krijgt u inzicht in de kenmerken van de werklast.

Wanneer Activity Monitor 'Buffer Latch' als uw hoogste wachttijd weergeeft, maar andere tools CXPACKET als dominante parameter weergeven, wordt het verschil veroorzaakt door de filter- en groeperingslogica van Activity Monitor.

6.2.3 Waarom specifieke wachttypes belangrijk zijn

Het kennen van het specifieke wachttype is belangrijk voor het oplossen van problemen:

• PAGELATCH_EX: Geeft vaak een tempdb-conflict aan op toewijzingspagina's. De oplossing bestaat uit het toevoegen van meer tempdb-gegevensbestanden.
• PAGELATCH_SH: Kan wijzen op hot pages in gebruikerstabellen. De oplossing bestaat uit partitionering of indexreorganisatie.
• PAGELATCH_UP: Vaak voorkomend tijdens updates. Kan duiden op een normale werking in plaats van een probleem.

Activity Monitor groepeert al deze gegevens onder 'Buffer Latch', wat de diagnose bemoeilijkt. Tools zoals sp_WhoIsActive en DMV-query's tonen specifieke wachttypen.

6.3 Gegevensnauwkeurigheid en tijdigheid

Activity Monitor biedt een bijna realtime weergave, maar 'bijna' is het sleutelwoord. Inzicht in de methode voor gegevensverzameling helpt u de resultaten correct te interpreteren.

6.3.1 Snapshot versus continue monitoring

Activity Monitor toont momentopnamen die bij elk vernieuwingsinterval zijn gemaakt. Gebeurtenissen die tussen momentopnamen plaatsvinden, worden niet vastgelegd. Als een query 2 seconden duurt en u vernieuwt elke 10 seconden, ziet u deze mogelijk één keer of helemaal niet, afhankelijk van de timing.

Dit betekent dat Activity Monitor uitstekend is in het vinden van hardnekkige problemen (minutenlange blokkades, constant hoge CPU-belasting), maar dat het mogelijk tijdelijke problemen over het hoofd ziet (korte impasses, incidentele querypieken).

6.3.2 Aggregatie en bemonstering

Het deelvenster Recente dure query's toont gegevens die zijn samengevoegd sinds queryplannen in de cache zijn opgenomen. Twee identieke query's met verschillende parameterwaarden worden als één rij weergegeven als ze een plan delen. Deze samenvoeging kan problemen met specifieke parametercombinaties (parametersniffing) maskeren.

Het deelvenster Resourcewachttijden berekent de tarieven door snapshots te vergelijken. Als de wachtstatistieken tussen snapshots worden gereset (rare maar mogelijk), kunnen de berekende tarieven onjuist zijn.

6.4 Wanneer u de Activiteitenmonitor NIET moet gebruiken

Activity Monitor is niet geschikt voor elk monitoringscenario. Herken wanneer alternatieve tools betere keuzes zijn.

6.4.1 Vereisten voor historische analyse

Activity Monitor toont alleen de huidige of recente activiteit. Er worden geen historische gegevens opgeslagen. Als u trends over dagen of weken wilt analyseren, huidige prestaties wilt vergelijken met basislijnen of rapporten over prestatiepatronen wilt genereren, is Activity Monitor niet voldoende.

Gebruik voor historische analyse SQL Server's ingebouwde prestatiedashboard, uitgebreide gebeurtenissen met bestand tarkrijgt, of monitoringoplossingen van derden.

6.4.2 Gedetailleerde wachtstatistieken nodig

Wanneer u nauwkeurige informatie over het wachttype nodig hebt voor geavanceerde afstemming, zijn de groepering en filtering van Activity Monitor niet toereikend. Gebruik in plaats daarvan DMV-query's rechtstreeks of sp_WhoIsActive.

Voor een uitgebreide analyse van wachtstatistieken kunt u sys.dm_os_wait_stats rechtstreeks raadplegen en handmatig onschadelijke wachtstatistieken eruit filteren.

6.4.3 Overwegingen voor productieservers

Op productieservers die zwaar belast worden, kan de overhead van Activity Monitor problematisch zijn. Het is niet raadzaam dat meerdere databasebeheerders Activity Monitor tegelijkertijd op dezelfde server gebruiken.

Voor productiebewaking kunt u lichtgewicht alternatieven overwegen, zoals geplande DMV-snapshots die zijn opgeslagen in een bewakingsdatabase. U kunt ook Read-Only routing gebruiken om secundaire replica's te bewaken in Always On-configuraties.

7. Aanbevolen werkwijzen voor het gebruik van Activity Monitor

Door de best practices te volgen, haalt u het maximale uit Activity Monitor en minimaliseert u de negatieve impact op uw servers.

7.1 Wanneer u Activity Monitor moet gebruiken

Activity Monitor blinkt uit in specifieke situaties. Gebruik hem wanneer de sterke punten aansluiten bij jouw behoeften.

7.1.1 Problemen met realtime prestaties

Activity Monitor is ideaal wanneer gebruikers momenteel problemen ondervinden en u het probleem direct moet diagnosticeren. Dankzij de realtime weergave ziet u wat er op dit moment gebeurt.

Wanneer u een melding krijgt dat "de applicatie traag is", is het openen van Activiteitenweergave een van uw eerste stappen. Zo kunt u snel vaststellen of de database bezet, geblokkeerd of inactief is.

7.1.2 Onderzoek naar vertraging van de toepassing

Wanneer een specifieke applicatie niet meer reageert, helpt Activity Monitor u bepalen of databaseproblemen de oorzaak zijn. Filter het deelvenster Processen op applicatienaam om alleen de databaseactiviteit van die applicatie te bekijken.

Als de applicatie geen databaseactiviteit vertoont terwijl gebruikers problemen melden, ligt het probleem ergens anders in de stack. Als u uitgebreide blokkeringen of dure query's ziet, hebt u de boosdoener gevonden.

7.1.3 Snelle gezondheidscontroles

Activity Monitor biedt een uitstekend dashboard voor snelle gezondheidscontroles tijdens routinematig gebruik. Open het, bekijk de overzichtsgrafieken en controleer of er niets afwijkends is.

Deze snelle controle duurt enkele seconden en kan problemen aan het licht brengen voordat ze kritiek worden. Maak er een vast onderdeel van je dagelijkse routine van.

7.2 Optimale configuratie-instellingen

Door Activity Monitor op de juiste manier te configureren, worden zowel de bruikbaarheid als het gebruik van resources verbeterd.

7.2.1 Aanbevolen vernieuwingsintervallen

Zorg dat uw vernieuwingsinterval aansluit bij uw doel:

• Actieve probleemoplossing: 10 seconden zorgt voor een goede respons met een redelijke overhead.
• Uitgebreide monitoring: 30-60 seconden vermindert de impact op de server tijdens langere observatieperioden.
• Diagnose van kritieke problemen: 5 seconden geeft een hoge mate van nauwkeurigheid wanneer elke seconde telt, maar gebruik het kort.
• Regelmatige gezondheidscontroles: Handmatige vernieuwing (interval van 1 uur) wanneer u niet actief kijkt.

Vergeet niet om Activiteitenweergave af te sluiten als u klaar bent. Als u een lange interval instelt en het vergeet, verspilt dit serverbronnen.

7.2.2 Filterstrategieën

Gebruik filters om u te concentreren op relevante informatie en de cognitieve belasting te verminderen:

• Filter processen op Database om alleen de activiteit in specifieke databases te zien.
• Filteren op Inloggen om de activiteit van een specifieke gebruiker te volgen.
• Filteren op Taakstatus = RUNNING om inactieve sessies te verbergen.
• Filteren op Applicatie om verkeer van specifieke programma's te isoleren.
• Toon alleen niet-lege velden in Geblokkeerd door om alleen blokkerende situaties te zien.

7.2.3 Kolomselectie en sortering

Ontwikkel een systematische aanpak voor het beoordelen van Activity Monitor-gegevens:

1. Start met Overzicht: Controleer de grafieken op duidelijke pieken of afwijkingen.
2. Controleer processen op blokkering: Sorteer op sessie-ID en zoek vervolgens naar waarden voor 'Geblokkeerd door'.
3. Controleer resourcewachttijden: Sorteer op cumulatieve wachttijd om knelpunten in de resource te identificeren.
4. Analyseer dure query's: Sorteer op verschillende statistieken (CPU, uitvoeringen, leesbewerkingen) om verschillende typen problemen te vinden.
5. Verifiëren met I/O-venster: Bevestig of I/O-intensieve query's verband houden met hoge schijfactiviteit.

7.3 Integratie met andere tools

Activity Monitor werkt het beste als onderdeel van een bredere toolkit, en niet als een op zichzelf staande oplossing.

7.3.1 Gebruik met SQL Server Profiler

Activiteitenmonitor en SQL Server Profiler vullen elkaar goed aan. Wanneer u een problematische sessie in Activity Monitor identificeert, klikt u er met de rechtermuisknop op en selecteert u Traceerproces in SQL Server Profiler.

Hiermee start u Profiler met filters die al zijn geconfigureerd om alleen de activiteit van die sessie vast te leggen. U ziet de volledige reeks uitgevoerde statements, timinginformatie en foutmeldingen – details die Activity Monitor niet biedt.

Om meer te leren over SQL Server Profilermogelijkheden en geavanceerde traceringstechnieken, zie onze uitgebreid SQL Server Profiler-gids.

7.3.2 Aanvullen met uitgebreide gebeurtenissen

Extended Events biedt gedetailleerde monitoring met lage overheadkosten die informatie vastlegt die Activity Monitor mist. Maak Extended Event-sessies aan om specifieke gebeurtenissen te volgen, zoals deadlocks, langlopende query's of overmatige hercompilaties.

Gebruik Activity Monitor voor direct onderzoek en Extended Events voor continue monitoring en historische analyse. Beide tools voorzien in verschillende behoeften.

Om meer te leren over SQL Server Uitgebreide evenementenmogelijkheden en geavanceerde monitoringtechnieken, zie onze uitgebreid SQL Server Uitgebreide evenementengids.

7.3.3 Monitoringoplossingen van derden

Commerciële tools zoals SolarWinds Database Performance Analyzer, Redgate SQL Monitor en Quest Spotlight bieden functies die Activity Monitor mist: waarschuwingen, historische trends, capaciteitsplanning en geautomatiseerde diagnose.ostic.

Deze tools zijn waardevolle aanvullingen op Activity Monitor, geen vervangingen. Activity Monitor blijft nuttig voor snelle controles en onderzoeken, zelfs wanneer er geavanceerde monitoringtools beschikbaar zijn.

7.4 veelvoorkomende fouten die u moet vermijden

Als u begrijpt wat de meest voorkomende fouten zijn die u met Activity Monitor kunt maken, kunt u Activity Monitor effectiever gebruiken.

7.4.1 Activity Monitor continu laten draaien

De most Een veelgemaakte fout is het openen van Activiteitenweergave en deze eindeloos laten draaien. Dit verspilt serverbronnen en biedt weinig waarde omdat je niet actief meekijkt.

Sluit Activity Monitor af wanneer u het niet actief gebruikt. Als u continue monitoring nodig hebt, implementeer dan een geschikte monitoringoplossing met geplande gegevensverzameling.

7.4.2 Te veel vertrouwen op alleen de Activiteitenmonitor

Activity Monitor biedt één perspectief op de serverstatus. Vertrouw er niet uitsluitend op. Vul aan met Windows Prestatiemonitor voor statistieken op besturingssysteemniveau, Uitgebreide gebeurtenissen voor gedetailleerde tracking en analyse van het uitvoeringsplan voor query-afstemming.

Met Activity Monitor kunt u problemen identificeren, maar om ze op te lossen hebt u vaak extra hulpmiddelen en een grondigere analyse nodig.

Meer informatie over SQL Server prestatiemonitor in onze complete gids.

7.4.3 Historische trends negeren

Activity Monitor toont de huidige status, maar prestatieproblemen vertonen vaak patronen die pas na verloop van tijd zichtbaar worden. Implementeer historische gegevensverzameling zodat u huidige statistieken kunt vergelijken met basislijnen en trends kunt identificeren.

Zonder historische context ziet u mogelijk niet dat het 'normale' CPU-gebruik van vandaag 30% hoger ligt dan de basislijn van vorige maand, wat wijst op een geleidelijke afname.

8. Problemen met Activity Monitor oplossen

Activity Monitor zelf ondervindt soms problemen. Weten hoe u deze problemen kunt oplossen, voorkomt frustratie.

8.1 Activiteitenmonitor kan niet worden geopend of geeft geen gegevens weer

Als Activiteitenweergave wordt geopend, maar er lege vensters worden weergegeven of de weergave helemaal niet wordt geopend, kunnen meerdere factoren hiervoor verantwoordelijk zijn.

8.1.1 Machtigingsproblemen

De most Een veelvoorkomende oorzaak van problemen met Activity Monitor zijn onvoldoende rechten. Om dit te controleren en op te lossen:

1. Controleer uw machtigingen op serverniveau:

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

2. Als er geen rijen worden geretourneerd, beschikt u niet over de machtiging VIEW SERVER STATE.
3. Vraag een serverbeheerder om toestemming:

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

4. Sluit Activiteitenweergave en open deze opnieuw nadat de machtigingen zijn verleend.

8.1.2 Problemen met versiecompatibiliteit

Met behulp van een oude versie van SQL Server Management Studio om verbinding te maken met een nieuwere SQL Server versie kan ervoor zorgen dat Activity Monitor niet werkt. De tool begrijpt mogelijk geen nieuwe wachttypen of kolommen in de systeemweergave.

Gebruik altijd een SSMS-versie die overeenkomt met of nieuwer is dan uw SQL Server versie. Microsoft biedt de nieuwste SSMS gratis aan als download, los van SQL Server zelf.

8.1.3 Firewall- en netwerkproblemen

Voor Activity Monitor is connectiviteit met de SQL Server Bijvoorbeeld op standaardpoorten (standaard 1433). Als u verbinding kunt maken via Object Explorer, maar Activity Monitor mislukt, blokkeren firewallregels mogelijk specifieke verbindingen.

Controleer of uw klant de SQL Server machine op alle benodigde poorten. Controleer zowel de Windows Firewall als eventuele netwerkfirewalls tussen uw client en de server.

8.2 Activiteitenmonitor permanent gepauzeerd

Een veelvoorkomend probleem, vooral in SQL Server 2019, is Activity Monitor geopend in een gepauzeerde toestand en weigert te hervatten.

8.2.1 De gepauzeerde toestand begrijpen

Wanneer Activiteitenweergave pauzeert, tonen alle deelvensters de status 'Gepauzeerd' met een hervattingsknop die mogelijk niet werkt. Hierdoor ziet u geen serveractiviteit.

De pauzestatus treedt meestal op vanwege machtigingsproblemen, beperkingen van de externe verbinding of fouten in de SSMS-versie, en niet zozeer als gevolg van een opzettelijke pauzeactie.

8.2.2 Veel voorkomende oorzaken

Activity Monitor kan om de volgende redenen permanent in de pauzestand gaan:

• Ontbrekende VIEW SERVER STATE-machtiging op nieuwere panelen die recent zijn toegevoegd SQL Server versies
• Externe verbindingen uitgeschakeld op de SQL Server instantie
• Authenticatiefouten voor specifieke systeemquery's
• Bugs in specifieke SSMS-builds, met name 18.0 tot en met 18.3
• Verbindingsproblemen tussen client en server

8.2.3 Oplossingsstappen

Om problemen met de gepauzeerde status van Activity Monitor op te lossen:

1. SSMS bijwerken: Download en installeer het nieuwste SQL Server Management Studio-versie van de Microsoft-website. Veel bugs met betrekking tot de pauzestatus zijn in latere releases opgelost.
2. Controleer de machtigingen: Zorg ervoor dat u de machtigingen VIEW SERVER STATE en VIEW ANY DEFINITION hebt.
3. Controleer externe verbindingen: Controleer of de SQL Server instantie staat externe verbindingen toe:

   EXEC sp_configure 'remote access';
   

   Als de waarde 0 is, vraag dan een beheerder om deze in te schakelen.

4. Restart SSMS: Soms is het gewoon nodig om alle vensters en res te sluitentarTing SQL Server Management Studio lost het probleem op.
5. Verbinding maken met Windows-verificatie: Als u SQL-verificatie gebruikt, probeer dan Windows-verificatie, omdat dit soms authenticatiegerelateerde pauzeproblemen omzeilt.

8.3 Prestatieproblemen bij het gebruik van Activity Monitor

Als Activity Monitor zelf traag wordt of de serverprestaties verslechtert, is een aanpassing nodig.

8.3.1 Vermindering van de overheadkosten voor monitoring

Om de impact van Activity Monitor te minimaliseren:

1. Verhoog het vernieuwingsinterval naar 30 seconden of 1 minuut.
2. Sluit deelvensters die u niet actief gebruikt door op de knop 'Inklappen' te klikken.
3. Wanneer deelvensters zijn samengevouwen, worden er door Activity Monitor geen gegevens opgevraagd.
4. Zorg ervoor dat u niet meerdere Activity Monitor-exemplaren tegelijkertijd uitvoert.
5. Sluit Activiteitenweergave volledig af wanneer u geen problemen meer onderzoekt.

8.3.2 Alternatieve lichtgewicht monitoringmethoden

Als Activity Monitor te veel bronnen vereist voor uw omgeving, overweeg dan alternatieven:

• Neem rechtstreeks contact op met DMV's: Schrijf specifieke T-SQL-query's die alleen de informatie ophalen die u nodig hebt.
• Gebruik sp_WhoIsActive: Deze opgeslagen procedure is sterk geoptimaliseerd en heeft doorgaans een lagere overhead dan Activity Monitor.
• Bemonstering implementeren: Plan SQL Agent-taken die met regelmatige tussenpozen momentopnamen van DMV-gegevens maken en de resultaten in tabellen opslaan voor latere analyse.
• Secundaire replica's bewaken: Voer Activity Monitor uit op een leesbare secundaire locatie in plaats van op de primaire locatie in Always On-beschikbaarheidsgroepen.

8.4 Onjuiste of ontbrekende informatie

Soms geeft Activity Monitor informatie weer die onjuist of onvolledig lijkt.

8.4.1 Gegevens verifiëren bij DMV's

Wanneer de resultaten van Activity Monitor verdacht lijken, kunt u ze verifiëren door de onderliggende DMV's rechtstreeks te raadplegen. Als het venster Processen bijvoorbeeld geen blokkering aangeeft, maar gebruikers dit melden, voert u de volgende query uit:

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

Als uit deze query blijkt dat Activity Monitor een blokkering heeft gemist, is er sprake van een weergaveprobleem.

8.4.2 Inzicht in de timing van gegevensvernieuwing

Houd er rekening mee dat Activity Monitor momentopnamen weergeeft. Een query die tussen vernieuwingsintervallen is uitgevoerd, wordt niet weergegeven in Recente dure query's, tenzij het uitvoeringsplan in de cache blijft.

Op dezelfde manier weerspiegelen wachtstatistieken in het deelvenster Resourcewachttijden de accumulatie sinds de laatste momentopname. Snel veranderende workloads kunnen bij elke vernieuwing andere patronen vertonen.

9. Geavanceerde activiteitsmonitortechnieken

Ervaren databasebeheerders gebruiken Activity Monitor op geavanceerde manieren om maximale diagnoseresultaten te verkrijgen.ostische waarde.

9.1 Meerdere panelen combineren voor oorzaakanalyse

De ware kracht van Activity Monitor komt naar voren wanneer u informatie uit meerdere deelvensters met elkaar in verband brengt om complexe prestatieproblemen te begrijpen.

9.1.1 Wachttijden correleren met processen

Wanneer in het deelvenster Resourcewachttijden hoge wachttijden in een categorie worden weergegeven, kunt u in het deelvenster Processen bepalen welke sessies met deze wachttijden te maken hebben:

1. Let op de wachtcategorie met een hoge cumulatieve wachttijd (bijv. 'Vergrendelen').
2. Ga naar het deelvenster Processen.
3. Sorteer op Wachttype naar groepssessies op basis van hun huidige wachttijd.
4. Zoek naar sessies met wachttypen in de categorie 'Probleem'.
5. Voor die sessies, bekijk de Wachtbron kolom om te zien welke databaseobjecten erbij betrokken zijn.
6. Klik met de rechtermuisknop en selecteer Details om de querytekst te zien.

Dankzij deze correlatie kunt u van ‘we hebben lock-waitings’ naar ‘deze specifieke query wacht op locks op deze tabel’ gaan.

9.1.2 Dure query's koppelen aan I/O-problemen

Wanneer het venster Gegevensbestand-I/O hoge schijfactiviteit op een specifieke database aangeeft:

1. Let op welke databasebestanden een hoge MB/s lees- of schrijfsnelheid hebben.
2. Schakel over naar recente dure zoekopdrachten.
3. Sorteer op Fysieke lezingen/sec om query's te identificeren die veel van de schijf lezen.
4. Filter of identificeer visueel query's die op de database worden uitgevoerd met een hoge I/O.
5. Controleer de uitvoeringsplannen van deze query's op tabelscans of ontbrekende indexen die overmatige I/O veroorzaken.

Deze analyse met meerdere panelen legt een verband tussen symptomen (hoge schijf-I/O) en oorzaken (specifieke inefficiënte query's).

9.2 Activiteitenmonitor gebruiken voor capaciteitsplanning

Hoewel Activity Monitor geen historische gegevens opslaat, kunt u het strategisch gebruiken voor observaties met betrekking tot capaciteitsplanning.

9.2.1 Identificeren van piekgebruikspatronen

Controleer de serveractiviteit op verschillende tijdstippen van de dag om gebruikspatronen te identificeren:

1. Open Activity Monitor tijdens bekende piekuren.
2. Let op de piekwaarden in de grafiek '% processortijd'.
3. Registreer het maximale aantal wachtende taken.
4. Let op batchverzoeken/sec tijdens piektijden.
5. Documenteer de drukste databases in het deelvenster Processen.
6. Herhaal dit ter vergelijking buiten de spitsuren.

Als de piektijd van de processor constant boven de 80% ligt, nadert u de CPU-capaciteitslimieten. Een toenemend aantal wachttijden wijst eveneens op een toenemende resourceconcurrentie.

9.2.2 Resource Trend Analyse

Hoewel Activity Monitor de huidige status weergeeft, kunt u het gebruiken om steekproeven te doen door belangrijke statistieken in de loop van de tijd vast te leggen:

• Maak elke dag op hetzelfde tijdstip screenshots van het Overzicht-venster
• Noteer piekwaarden uit elke grafiek
• Vergelijk week na week om groeitrends te identificeren
• Let op geleidelijke toenames in de gemiddelde processortijd of I/O-snelheden

Deze handmatige trendregistratie is een aanvulling op geavanceerdere monitoringoplossingen en helpt bij het rechtvaardigen van capaciteitsuitbreiding.

9.3 Prestatiebasislijnen documenteren

Door basisprestatiegegevens vast te stellen, kunt u herkennen wanneer de prestaties verslechteren.

9.3.1 Basisgegevens vastleggen

Leg de Activity Monitor-statistieken vast tijdens periodes met bekende goede prestaties:

1. Open Activity Monitor tijdens normale bedrijfsactiviteiten (niet tijdens piek- of daluren).
2. Waarden in het overzichtsvenster:
   • Typisch % processortijdbereik
   • Gemiddeld aantal wachttaken
   • Normale database I/O-snelheid
   • Typische batchverzoeken/sec
3. Let op de categorieën in het deelvenster Resource Waits die de m weergevenost wacht tijd.
4. Het aantal actieve processen wordt doorgaans in het deelvenster Processen vastgelegd.
5. Registreer representatieve query-uitvoeringsstatistieken van recente dure query's.

Bewaar deze basisdocumentatie voor toekomstig gebruik bij het onderzoeken van prestatieproblemen.

9.3.2 Vergelijking van huidige en basisprestaties

Wanneer er prestatieproblemen optreden, kunt u de huidige Activity Monitor-waarden vergelijken met uw gedocumenteerde basislijn:

• Is de processortijd aanzienlijk hoger dan de basislijn? Focus op CPU-intensieve query's.
• Zijn wachttaken 2-3x zo hoog als de basislijn? Onderzoek de wachttijden van resources.
• Is de I/O substantieel hoger? Controleer het I/O-venster van het gegevensbestand en de dure query's.
• Zijn de batchverzoeken lager dan de basislijn tijdens piekuren? Zoek naar blokkeringen of verbindingsproblemen.

Met deze vergelijking kunt u zien wat er is veranderd en kunt u gerichter aan de slag met het oplossen van problemen.

9.4 Aangepaste monitoringworkflows maken

Ontwikkel systematische workflows voor veelvoorkomende onderzoeksscenario's om grondige, herhaalbare analyses te garanderen.

9.4.1 Stapsgewijs onderzoeksproces

Wanneer gebruikers prestatieproblemen melden, volgt u een consistente workflow:

1. Snelle gezondheidscontrole: Open Activiteitenweergave en scan de grafieken in het Overzicht-venster op duidelijke afwijkingen.
2. Controleer op blokkering: Vouw het deelvenster Processen uit en filter op Niet-lege cellen in de kolom Geblokkeerd door.
3. Identificeer bronconflicten: Het deelvenster Resourcewachttijden bekijken, gesorteerd op wachttijd.
4. Vind dure zoekopdrachten: Bekijk recente dure query's, gesorteerd op CPU, uitvoeringen en leesbewerkingen.
5. Correleer I/O-patronen: Maak kruisverwijzingen tussen dure query's en de activiteit in het venster Gegevensbestand-I/O.
6. Bevindingen documenteren: Maak schermafbeeldingen en noteer relevante sessie-ID's, wachttijden en querygegevens.
7. Diepe duik: Gebruik Profiler-traceringen, uitvoeringsplananalyses en DMV-query's voor een gedetailleerd onderzoek van geïdentificeerde problemen.

9.4.2 Escalatiecriteria

Stel criteria vast voor wanneer problemen moeten worden geëscaleerd en wanneer het onderzoek moet worden voortgezet:

• Direct escaleren: Blokkeringsketens die > 5 minuten duren, processortijd op 100% gedurende > 2 minuten, kritieke systeemprocessen in de status SUSPENDED.
• Escaleren met analyse: Terugkerende, dure query's die >50% van de CPU verbruiken, consistent hoge I/O-responstijden >50 ms, geheugentoekenningen die herhaaldelijk mislukken.
• Onderzoek verder: Temporary wacht op een oplossing binnen enkele minuten, query's met suboptimale plannen maar acceptabele prestaties, kleine blokkeringen met een duur van <30 seconden.

10. Activiteitenmonitor in verschillende SQL Server versies

Activity Monitor is geëvolueerd SQL Server versies, waarbij elke release verbeteringen en soms ook nieuwe problemen met zich meebrengt.

10.1 Activiteitenmonitor in SQL Server 2008 en later

SQL Server In 2008 werd het moderne Activity Monitor-ontwerp geïntroduceerd, dat vandaag de dag grotendeels ongewijzigd is gebleven.

10.1.1 Nieuwe functies geïntroduceerd in SQL Server 2008

De SQL Server Het nieuwe ontwerp van Activity Monitor in 2008 bracht aanzienlijke verbeteringen:

• Grafisch dashboard met realtime grafieken in het Overzicht-venster
• Uitvouwbare/inklapbare paneelinterface ter vervanging van de oude rasterweergave
• Het deelvenster Recente dure query's toont samengevoegde queryprestatiegegevens
• Gegevensbestand I/O-paneel voor bewaking van schijfactiviteit per bestand
• Verbeterd paneel 'Resource Waits' met wachtcategorisering
• Contextmenu's met de rechtermuisknop voor procesacties zoals het beëindigen van sessies en het starten van Profiler
• Configureerbare vernieuwingsintervallen van 1 seconde tot 1 uur

Deze wijzigingen transformeerden Activity Monitor van een eenvoudige proceslijst tot een uitgebreid bewakingsdashboard.

10.1.2 Wijzigingen van SQL Server 2005

SQL Server De Activity Monitor van 2005 was veel beperkter:

• Toegankelijk via de map Management in Object Explorer in plaats van via de werkbalk
• Enkelvoudig raster met proceslijst met basisinformatie
• Geen grafische diagrammen of meerdere deelvensters
• Geen dure query's of I/O-monitoring
• Beperkte informatie over wachtstatistieken

Het nieuwe ontwerp van 2008 was meer een complete herziening dan een incrementele verbetering.

10.2 Activiteitenmonitor in SQL Server 2014/2016

SQL Server In 2014 en 2016 werden stapsgewijze verbeteringen aangebracht in de onderliggende gegevensverzameling van Activity Monitor, maar er waren weinig visuele wijzigingen.

10.2.1 Verbeteringen en uitbreidingen

Belangrijke verbeteringen in deze versies zijn:

• Betere prestaties bij het monitoren van servers met duizenden gecachte plannen
• Verbeterde filtermogelijkheden in het deelvenster Processen
• Verbeterde nauwkeurigheid van de aggregatie van wachtstatistieken
• Betere afhandeling van kolomsortering en -filtering bij grote resultaatsets
• Efficiëntere DMV-query's verminderen de toezichtskosten

De kerninterface bleef consistent met SQL Server 2008, vertrouwdheid voor beheerders behouden.

10.3 Activiteitenmonitor in SQL Server 2019/2022

Recent SQL Server versies zetten de evolutie van Activity Monitor voort met de focus op prestaties en stabiliteit.

10.3.1 Nieuwste functies en mogelijkheden

SQL Server De Activity Monitor voor 2019 en 2022 bevat:

• Ondersteuning voor nieuwe wachttypen die in deze versies zijn geïntroduceerd
• Verbeterde renderingprestaties in SSMS met behulp van WPF-technologie
• Betere afhandeling van grote aantallen actieve sessies
• Verbeterde compatibiliteit met cloud SQL-platforms
• Nauwkeurigere CPU- en I/O-gegevens

10.3.2 Bekende problemen in recente versies

SQL Server In 2019 zijn er verschillende bugs in Activity Monitor geïntroduceerd:

• Permanente gepauzeerde status: Activity Monitor gaat regelmatig in de pauzestand en kan niet meer worden hervat, met name in SSMS 18.0-18.3. Dit probleem is opgelost in latere versies van SSMS.
• Fouten bij externe verbindingen: Sommige configuraties verhinderen dat Activity Monitor op externe instanties wordt geopend. Oplossingen zijn onder andere het inschakelen van specifieke traceervlaggen of het gebruiken van nieuwere SSMS-builds.
• Toestemmingsproblemen: Voor nieuwe systeemweergaven zijn aanvullende machtigingen nodig die niet duidelijk zijn gedocumenteerd. Hierdoor ontstaan ​​lege schermen, zelfs met de optie VIEW SERVER STATE.

Gebruik altijd de nieuwste SSMS-versie wanneer u met SQL Server 2019 en 2022 om deze problemen te voorkomen.

11. Praktische use cases en voorbeelden

Aan de hand van praktijkvoorbeelden wordt gedemonstreerd hoe u Activity Monitor effectief kunt inzetten in veelvoorkomende scenario's voor probleemoplossing.

11.1 Case Study: Een trage webapplicatie diagnosticeren

Een ontwikkelteam meldt dat hun webapplicatie onacceptabel langzaam is geworden. Pagina's laden duurt nu 20-30 seconden in plaats van de normale 2-3 seconden.

11.1.1 Eerste onderzoek met overzichtsvenster

Open Activity Monitor en bekijk het Overzicht-venster:

1. De grafiek '% processortijd' laat een CPU-gebruik van 85-95% zien, aanzienlijk hoger dan de normale basislijn van 30-40%.
2. Het aantal taken in de wachtrij varieert tussen 10 en 20, terwijl het normale aantal taken 0 tot 3 is.
3. Database I/O vertoont een matige activiteit van rond de 50 MB/s.
4. Het aantal batchverzoeken per seconde ligt met 100 per seconde lager dan verwacht, terwijl dit tijdens kantooruren doorgaans 300-400 per seconde is.

Dit patroon duidt op een CPU-bottleneck met resourceconflicten die een verminderde doorvoer veroorzaken. De server werkt hard, maar verwerkt niet veel verzoeken.

11.1.2 De problematische vraag identificeren

Vouw het deelvenster Recente dure query's uit en sorteer op Uitvoeringen/min.:

1. De bovenste query geeft 15,000 uitvoeringen per minuut aan.
2. Klik met de rechtermuisknop en selecteer Querytekst bewerken om de vraag te onderzoeken.
3. De query is een eenvoudige SELECT-instructie die één enkele gebruikersrecord ophaalt: SELECT * FROM Users WHERE UserId = @UserId.
4. Bij normaal toepassingsgebruik mag deze query niet 15,000 keer per minuut worden uitgevoerd.

Klik met de rechtermuisknop op de query en selecteer Uitvoeringsplan weergevenHet plan toont een tabelscan op de tabel Gebruikers met een waarschuwing over een ontbrekende index op de kolom Gebruikers-ID.

Filter het deelvenster Processen op Toepassing om alleen de verbindingen van de webtoepassing weer te geven. Meerdere sessies tonen dat dezelfde query herhaaldelijk wordt uitgevoerd.

11.1.3 Resolutie en verificatie

Het probleem wordt veroorzaakt door twee factoren: overmatig veel query's uitvoeren en een ontbrekende index. Oplossingsstappen:

1. Maak de ontbrekende index:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Neem contact op met het ontwikkelingsteam Over de overmatige uitvoeringen. Onderzoek wijst uit dat er een N+1 queryprobleem is in de applicatiecode, waarbij een lus gebruikersgegevens ophaalt voor elk item in een lijst.
3. De applicatie aanpassen om de zoekopdrachten van de gebruiker in één query te groeperen met behulp van een IN-clausule of tabelwaardeparameter.
4. Controleer de oplossing Door Activity Monitor na de implementatie te monitoren, daalt het CPU-gebruik naar 35-40%, het aantal uitvoeringen per minuut naar 200-300 en de responstijden van de applicatie keren terug naar normaal.

11.2 Casestudy: Een blokkeringsprobleem oplossen

Gebruikers melden dat het orderinvoersysteem af en toe 30-60 seconden vastloopt voordat het weer normaal werkt.

11.2.1 De blokkeringsketen detecteren

Open Activity Monitor tijdens een van deze bevriezingsgebeurtenissen en vouw het deelvenster Processen uit:

1. Sorteer op Session ID om alle georganiseerde sessies te zien.
2. Meerdere sessies tonen waarden in de Geblokkeerd door kolom, die allemaal verwijzen naar sessie-ID 73.
3. Sessie 73 toont '1' in de Hoofdblokker kolom, wat bevestigt dat dit de hoofdoorzaak is.
4. De Wachttype voor geblokkeerde sessies wordt LCK_M_X weergegeven, wat aangeeft dat er wordt gewacht op exclusieve vergrendelingen.
5. De Wachtbron kolom geeft aan dat de blokkering op de tabel Orders betrekking heeft.

11.2.2 De oorzaak analyseren

Klik met de rechtermuisknop op Sessie 73 en selecteer Details om de opdracht te bekijken:

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

Deze update maakt deel uit van een batchverwerkingstaak die elk uur wordt uitgevoerd. Het controleren van de Inloggen kolom bevestigt dat de sessie bij het batchverwerkingsserviceaccount hoort.

De query houdt vergrendelingen op de tabel Orders vast terwijl er duizenden orders worden verwerkt. Wacht tijd voor geblokkeerde sessies neemt gestaag toe, wat bevestigt dat deze langdurige bewerking het probleem is.

11.2.3 De oplossing implementeren

Kortetermijnoplossing:

1. Documenteer sessie 73 met details, inclusief de querytekst en duur.
2. Wacht tot de update op natuurlijke wijze wordt voltooid, aangezien het om legitieme batchverwerking gaat.
3. Controleer na voltooiing of de geblokkeerde sessies zijn gewist en de normale werkzaamheden zijn hervat.

Geïmplementeerde langetermijnoplossingen:

1. De batchtaak opnieuw plannen om buiten de spitsuren te rijden (2-4 uur 's nachts in plaats van tijdens kantooruren).
2. Wijzig de batchverwerking om bestellingen in kleinere batches van 100 records tegelijk bij te werken, waarbij de vergrendelingen tussen batches worden opgeheven.
3. Voeg een index toe in de kolom OrderId om de updatebewerking te versnellen.
4. Overweeg SNAPSHOT-isolatie voor leesbewerkingen om de blokkerende impact te verminderen.

11.3 Case Study: Overmatige query-uitvoeringen identificeren

Uit databasebewaking blijkt dat het CPU-gebruik de afgelopen maand geleidelijk is toegenomen, maar dat er geen duidelijke veranderingen in de applicatiecode zijn opgetreden.

11.3.1 Abnormale uitvoeringsaantallen opsporen

Open Activity Monitor en bekijk het deelvenster Recente dure query's:

1. Sorteer op Executies/min om de m te zienost vaak uitgevoerde zoekopdrachten.
2. De bovenste query laat 37,000 uitvoeringen per minuut zien. Dit is veel hoger dan welke andere query dan ook.
3. Klik met de rechtermuisknop en selecteer Querytekst bewerken.
4. De query haalt productcategorie-informatie op:

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

5. Deze eenvoudige query zou snel en cachebaar moeten zijn, maar wordt tienduizenden keren per minuut uitgevoerd.

11.3.2 Traceren naar applicatiecode

Zoek in het deelvenster Processen naar sessies die deze query uitvoeren:

1. Merk op Applicatie kolom toont “ProductCatalogService”.
2. Klik met de rechtermuisknop op een van deze sessies en selecteer Traceerproces in SQL Server Profiler.
3. SQL Profiler geeft aan dat de query herhaaldelijk en snel achter elkaar wordt uitgevoerd met verschillende CategoryId-waarden.
4. Neem contact op met het ontwikkelteam dat ProductCatalogService beheert voor een codebeoordeling.

Codebeoordeling brengt het probleem aan het licht: een recente wijziging haalt productvermeldingen op met categorieën. Voor elk product in de resultatenset (vaak meer dan 1,000 producten) voert de code een aparte databaseaanroep uit om categorie-informatie op te halen – een klassiek N+1 queryprobleem.

11.3.3 De applicatie optimaliseren

Voer een juiste oplossing uit:

1. De toepassingsquery wijzigen om een ​​JOIN te gebruiken om producten en hun categorieën op te halen in één enkele databaseaanroep:

   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. Implementeer de bijgewerkte code en controleer Activity Monitor.
3. Controleer de oplossing: Het aantal uitvoeringen per minuut voor de categorie query daalt van 37,000 naar minder dan 100 en het algehele CPU-gebruik neemt af met 40%.
4. Documenteer de geleerde les en deel deze met het ontwikkelteam om soortgelijke problemen bij toekomstige codewijzigingen te voorkomen.

12. Mogelijke databasecorruptie detecteren

Hoewel Activity Monitor niet specifiek is ontworpen om corruptie in de database op te sporen, kunnen bepaalde patronen in de weergave ervan wijzen op onderliggende corruptieproblemen die nader onderzoek vereisen.

12.1 Symptomen van mogelijke databasecorruptie

Als er sprake is van corruptie in de database en er toegang toe wordt verkregen, ziet u mogelijk af en toe het volgende:

1. In het deelvenster Processen:

• Sessies blijven hangen in de status GESCHORST met ongebruikelijke wachttypen
• Processen die foutstatussen vertonen
• Query's mislukken herhaaldelijk

2. In het deelvenster Resourcewachttijden:

• Ongebruikelijke I/O-gerelateerde wachttypen die kunnen wijzen op schijfproblemen (hoewel dit waarschijnlijker op hardwareproblemen wijst dan op logische corruptie)

3. In recente dure zoekopdrachten:

• Query's met abnormaal hoge fysieke leesbewerkingen als ze herhaaldelijk proberen beschadigde pagina's te lezen

12.2 Verdere controle met DBCC CHECKDB

Wanneer Activity Monitor symptomen vertoont die wijzen op mogelijke corruptie, moet u onmiddellijk DBCC CHECKDB uitvoeren om de integriteit van de database te controleren. Deze opdracht scant alle databasepagina's, valideert checksums en controleert op fouten in de logische consistentie.

Voor meer informatie over het gebruik van DBCC CHECKDB om databasecorrupties te controleren en te herstellen, zie onze uitgebreide DBCC CHECKDB-gids.

12.3 Repareer met professioneel gereedschap

Als DBCC CHECKDB bevestigt dat de database corrupt is, hebt u verschillende opties om dit te repareren:

• De voorkeursaanpak is het herstellen vanaf een bekende, goede back-up. Zie onze uitgebreide gids over het maken van back-ups en het herstellen SQL Server databanken.
• Bij kleine beschadigingen kunt u mogelijk problemen oplossen met DBCC CHECKDB met REPAIR_REBUILD.
• Voor kritieke databases zonder recente back-ups, professionele SQL-herstelsoftware en services kunnen vaak gegevens herstellen die ingebouwde reparatieopties niet kunnen.

13. Conclusie

SQL Server Activity Monitor is een onmisbaar hulpmiddel voor databasebeheerders. Het biedt direct inzicht in de serverprestaties en helpt bij het snel en effectief diagnosticeren van problemen.

13.1 Samenvatting van de belangrijkste punten

In deze handleiding hebben we besproken hoe Activity Monitor u helpt problemen te begrijpen en op te lossen SQL Server prestatie:

• Activity Monitor biedt realtime inzicht in processen, wachttijden, query's en I/O via een overzichtelijke grafische interface.
• De vijf deelvensters (Overzicht, Processen, Resourcewachttijden, Gegevensbestand-I/O en Recente dure query's) bieden elk een uniek perspectief op serveractiviteit.
• Veelvoorkomende probleemoplossingsscenario's, zoals overmatige query-uitvoeringen, blokkerende ketens en hoog CPU-gebruik, worden beheersbaar met systematisch Activity Monitor-onderzoek.
• Hoewel Activity Monitor krachtig is, kent het beperkingen, waaronder een gebrek aan historische gegevens, wachttypegroepering en bewakingsoverhead die de toepassing beïnvloeden.cabiliteit.
• Door Activity Monitor aan te vullen met DMV-query's, sp_WhoIsActive, Extended Events en eventuele tools van derden, creëert u een uitgebreide monitoringstrategie.
• Door de aanbevolen procedures voor vernieuwingsintervallen te volgen, Activiteitenweergave te sluiten wanneer u deze niet gebruikt en meerdere deelvensters te combineren voor correlatie, kunt u de waarde ervan maximaliseren en de impact ervan minimaliseren.

13.2 Activiteitenmonitor als onderdeel van uw toolkit

Activity Monitor moet uw eerste hulpmiddel zijn voor prestatieonderzoeken, niet uw enige hulpmiddel. De kracht ervan ligt in het bieden van direct inzicht tijdens actieve probleemoplossing, waardoor u snel kunt vaststellen of de database de bottleneck is en welke specifieke aspecten nader onderzoek behoeven.

Beschouw Activity Monitor als een soort dashboard in je auto: het vertelt je direct of er iets mis is en helpt je het algemene probleem te identificeren. Net zoals het dashboard van je auto je niet precies vertelt waarom het motorstoringslampje brandt, wijst Activity Monitor je op problemen zonder altijd de volledige oorzaak te onthullen. Die diepgaandere analyse vereist extra tools en expertise.

Integreer Activity Monitor in een bredere toolkit met onder meer analyse van uitvoeringsplannen, het bijhouden van wachtstatistieken, historische monitoringoplossingen en best practices voor prestaties. Gebruik het in combinatie met de juiste indexeringsstrategieën, query-optimalisatietechnieken en capaciteitsplanning.

13.3 Uw leertraject voortzetten

Het beheersen van Activity Monitor is slechts één stap op weg naar een effectieve databasebeheerder. Blijf je vaardigheden ontwikkelen door:

• Leren om uitvoeringsplannen te interpreteren en inefficiënte operaties te identificeren
• Begrip SQL Server wachtstatistieken en hun implicaties
• Het bestuderen van indexontwerp- en optimalisatietechnieken
• Verkennen SQL Server's architectuur en hoe het query's verwerkt
• Het oefenen van systematische probleemoplossingsmethodologieën
• Ervaring opbouwen met Extended Events voor gedetailleerde tracering
• Inzicht in transactie-isolatieniveaus en hun prestatie-impact

Elk prestatieonderzoek met Activity Monitor leert u iets nieuws over hoe SQL Server werkt en hoe applicaties met databases interacteren. Documenteer je bevindingen, deel kennis met collega's en bouw een bibliotheek.rary van oplossingen voor veelvoorkomende problemen.

13.4 Aanvullende bronnen

Vergroot uw kennis met deze waardevolle bronnen:

• Open Activiteitenmonitor in SQL Server Managementstudio (SSMS) : Officiële SQL Server documentatie over het openen van Activiteitenmonitor in SQL Server Managementstudio (SSMS).
• Activity Monitor : Officieel SQL Server document over het gebruik van Activity Monitor.

14. Veelgestelde vragen (FAQ)

Vraag: Wat is SQL Server Activiteitenmonitor?

A: SQL Server Activity Monitor is een ingebouwde tool binnen SQL Server Management Studio die realtime informatie weergeeft over processen die op een SQL Server en hun impact op serverbronnen. Het biedt een grafisch dashboard met vijf deelvensters die verschillende aspecten van serveractiviteit weergeven, waaronder processorgebruik, wachtende taken, I/O-snelheden, actieve sessies en dure query's.

V: Hoe open ik Activity Monitor in SSMS?

A: U kunt Activity Monitor op vier manieren openen: (1) Klik op het pictogram Activity Monitor in de SSMS-werkbalk, (2) Klik met de rechtermuisknop op uw SQL Server instantienaam in Object Explorer en selecteer Activity Monitor, (3) Druk op Ctrl + anders + A, of (4) Configureer SSMS om het automatisch te starten via Tools -> opties -> Milieu -> Startube.

V: Welke machtigingen heb ik nodig om Activity Monitor te gebruiken?

A: Je hebt de SERVERSTATUS BEKIJKEN toestemming om m te zienost Informatie over de Activiteitenmonitor. Voor het deelvenster Gegevensbestand I/O hebt u ook het volgende nodig: CREËER DATABASE, WIJZIG ELKE DATABASEof BEKIJK ELKE DEFINITIE Machtigingen. Zonder deze machtigingen kan Activity Monitor worden geopend, maar worden er lege vensters weergegeven.

V: Waarom is mijn Activity Monitor gepauzeerd of werkt het niet?

A: Activity Monitor pauzeert meestal vanwege machtigingsproblemen, verouderde SSMS-versies of uitgeschakelde externe verbindingen. Om dit te verhelpen: (1) Werk bij naar de nieuwste SSMS-versie, (2) Controleer of u de machtiging 'SERVERSTATUS WEERGEVEN' hebt, (3) Controleer of externe verbindingen zijn ingeschakeld op de SQL Server bijvoorbeeld (4) Restart SSMS, en (5) Probeer verbinding te maken met Windows-authenticatie in plaats van SQL-authenticatie indien van toepassing.cabze.

V: Wat is het verschil tussen Activity Monitor en sp_WhoIsActive?

A: Activity Monitor is een grafische tool die in SSMS is ingebouwd en overzichtelijke vensters biedt voor verschillende monitoringaspecten. sp_WhoIsActive is een gratis, door de community ontwikkelde opgeslagen procedure die gedetailleerde sessie-informatie retourneert in één resultatenset met specifiekere wachttypen, blokkeringsdetails en aanpassingsopties dan Activity Monitor. Activity Monitor is beter geschikt voor visuele verkenning, terwijl sp_WhoIsActive uitblinkt in scriptmonitoring en meer gedetailleerde informatie biedt.

V: Heeft Activity Monitor invloed op de serverprestaties?

A: Ja, Activity Monitor heeft meetbare overhead omdat het systeem-DMV's raadpleegt bij elk vernieuwingsinterval. De impact neemt toe bij lagere vernieuwingsfrequenties. Microsoft waarschuwt dat intervallen van minder dan 10 seconden de serverprestaties kunnen beïnvloeden. Sluit Activity Monitor altijd af wanneer u het niet actief gebruikt en houd rekening met vernieuwingsintervallen van 30-60 seconden op productieservers die zwaar belast worden.

V: Kan ik Activity Monitor-gegevens verkrijgen met behulp van T-SQL?

A: Ja, Activity Monitor gebruikt dynamische systeembeheerweergaven zoals sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats en sys.dm_exec_query_stats. U kunt deze DMV's rechtstreeks via T-SQL raadplegen om programmatisch equivalente informatie op te halen, wat aangepaste monitoringscripts en geautomatiseerde gegevensverzameling mogelijk maakt.

V: Wat is het standaard vernieuwingsinterval?

A: Het standaard vernieuwingsinterval is 10 seconden. U kunt dit wijzigen door met de rechtermuisknop ergens in het overzichtvenster te klikken en te selecteren. Vernieuw interval, en kies uit vooraf gedefinieerde opties: 1 seconde, 5 seconden, 10 seconden, 30 seconden, 1 minuut of 1 uur. Kortere intervallen bieden meer realtime weergaven, maar verhogen de monitoringkosten.

V: Hoe kan ik Activity Monitor automatisch openen op SSMS-apparaten?tartut?

A: Configureer automatisch starten via SSMS-opties: Navigeer naar Tools -> opties -> Milieu -> Startube, Selecteer dan Open Object Explorer en Activiteitenmonitor aan de hand van de Op startube dropdown. Activity Monitor wordt automatisch geopend telkens wanneer u verbinding maakt met een server in SSMS.

V: Wat zijn de beperkingen van Activity Monitor?

A: Belangrijke beperkingen zijn onder meer: ​​(1) Geen opslag van historische gegevens of mogelijkheden voor trendanalyse, (2) Wachttypen worden gegroepeerd in categorieën in plaats van specifiek weergegeven, (3) Sommige wachttypen zoals CXPACKET worden mogelijk niet weergegeven, (4) Momentopnamen op een bepaald moment kunnen tijdelijke problemen missen, (5) De overhead van de bewaking kan van invloed zijn op drukke servers, (6) Geen waarschuwingsmechanisme voor proactief toezicht, en (7) Gegevens kunnen niet worden samengevoegd over meerdere apparaten. SQL Server instanties. Voor deze behoeften kunt u Activity Monitor aanvullen met Extended Events, dataverzamelingssets of monitoringtools van derden.

---

Over de auteur

Yuan Sheng is een senior databasebeheerder (DBA) met meer dan 10 jaar ervaring in SQL Server omgevingen en enterprise databasebeheer. Hij heeft honderden databaseherstelscenario's succesvol opgelost in financiële dienstverlening, gezondheidszorg en productiebedrijven.

Yuan is gespecialiseerd in SQL Server Databaseherstel, oplossingen voor hoge beschikbaarheid en prestatieoptimalisatie. Zijn uitgebreide praktijkervaring omvat het beheer van multi-terabyte databases, de implementatie van Always-On Availability Groups en de ontwikkeling van geautomatiseerde back-up- en herstelstrategieën voor bedrijfskritische bedrijfssystemen.

Met zijn technische expertise en praktische aanpak richt Yuan zich op het creëren van uitgebreide handleidingen die databasebeheerders en IT-professionals helpen complexe problemen op te lossen. SQL Server uitdagingen efficiënt. Hij blijft op de hoogte van de nieuwste SQL Server releases en de evoluerende databasetechnologieën van Microsoft, waarbij hij regelmatig herstelscenario's test om ervoor te zorgen dat zijn aanbevelingen overeenkomen met de beste praktijken in de praktijk.

Heb vragen over SQL Server herstel of heeft u aanvullende begeleiding nodig bij het oplossen van databaseproblemen? Yuan verwelkomt feedback en suggesties om deze technische middelen te verbeteren.