SQL Server Prestandamonitor: En komplett guide [2026]

SQL Server prestandaövervakare är processen att spåra, analysera och hantera prestandan och hälsan hos din SQL Server databaser. Det innebär att samla in och tolka data om olika aspekter av ditt databassystem för att säkerställa optimal prestanda, förebygga problem och upprätthålla databasens hälsa.

Prestandaövervakning omfattar spårning av frågekörningstider, resursutnyttjande, indexprestanda, blockering och dödlägen samt databasens tillväxtmönster. Denna kontinuerliga övervakning hjälper administratörer att identifiera potentiella problem innan de påverkar användare eller affärsverksamhet.

1.2 Viktiga fördelar med prestationsövervakning

Effektiv SQL Server prestandamätare ger flera viktiga fördelar:

Proaktiv problemdetektering: Identifiera och åtgärda potentiella problem innan de påverkar användare eller affärsverksamhet
Prestandaoptimering: Identifiera flaskhalsar och ineffektivitet för att förbättra databasens övergripande prestanda
Kapacitetsplanering: Prognostisera resursbehov och planera för framtida tillväxt baserat på historiska data
Efterlevnad och säkerhet: Säkerställ att myndighetskrav följs och upptäck misstänkt aktivitet

1.3 Vanliga prestationsutmaningar

Utan korrekt prestandaövervakning av SQL-databasen står organisationer inför flera risker:

Oväntad driftstopp som stör affärsverksamheten
Dålig applikationsprestanda påverkar användarupplevelsen
Dataförlust eller korruption
Ineffektiv resursutnyttjande som leder till onödiga kostnader
Frustrerade användare och potentiell intäktsförlust

Enligt en IDC-studie från 2023 härrör 65 % av databasprestandaproblem från dåliga övervaknings- eller optimeringsmetoder.

2. Förstå Windows Prestandaövervakning (PerfMon)

2.1 Vad är Windows Prestandaövervakare?

Windows Performance Monitor (PerfMon) är ett inbyggt Windows-verktyg som övervakar systemresurser och programprestanda. SQL Server administratörer, PerfMon ger ovärderliga insikter i både operativsystem och SQL Server mätvärden, vilket gör det avgörande för omfattande prestationsanalys.

PerfMon mäter prestandastatistik med jämna mellanrum och sparar denna statistik i filer för senare analys. Databasadministratörer kan välja tidsintervall, filformat och vilken statistik som ska övervakas. Verktyget är inte SQL Server-specifik – systemadministratörer använder den för att övervaka Windows, Exchange, filservrar och alla program som kan uppleva flaskhalsar.

2.2 Starta Prestandamonitor

Du kan starta Prestandamonitorn med flera metoder:

Klicka Start, Typ perfmon I sökrutan klickar du på "Prestandaövervakare" i sökresultatet:
Klicka Windows + R, Typ perfmonoch tryck på ange
Navigera till kontrollpanelen -> System och säkerhet -> Administrativa verktyg -> Performance monitor

3. Essential SQL Server Prestandaräknare

3.1 Minnesprestandaräknare

Minnesräknare är avgörande för övervakning SQL Server prestanda eftersom de indikerar om din databas har tillräckligt med minnesresurser.

Tillgängliga MByte

Denna räknare visar mängden fysiskt minne som är omedelbart tillgängligt för allokering. Det bör förbli relativt konstant och helst inte sjunka under 4096 MB. Låga värden kan tyda på att SQL Servers maximala minnesinställning lämnas på standardinställningen, eller inteSQL Server applikationer förbrukar minne.

Sidans förväntade livslängd

Sidans förväntade livslängd mäter hur länge (i sekunder) en sida stannar kvar i buffertpoolen utan att refereras. Ett normalt värde är 300 sekunder eller mer. Lägre värden indikerar minnesbelastning och överdriven buffertomsättning, vilket minskar cachens effektivitet.

Buffertcacheträffkvot

Denna räknare anger andelen dataförfrågningar som besvaras med hjälp av SQL-buffertcachen (minnet) snarare än att läsas från disken. Den når vanligtvis upp till eller överstiger 99 %. Lägre värden tyder på att SQL Server behöver mer minne eller värms fortfarande upp efter en omstart.

Minnesbidrag väntar

Detta visar antalet processer som väntar på minne inom SQL ServerUnder normala förhållanden bör detta värde konsekvent vara 0. Högre värden indikerar otillräcklig minnesallokering för SQL Server.

Målserverminne kontra totalt serverminne

Målserverminne anger den ideala mängden minne SQL Server vill använda. Totalt serverminne visar vad SQL Server använder för närvarande. Förhållandet mellan dessa värden bör vara ungefär 1. Betydande skillnader kan tyda på minnesbelastning eller otillräckligt tillgängligt minne.

3.2 Processorns prestandaräknare

CPU-räknare hjälper till att identifiera processorflaskhalsar och förstå hur SQL Server använder datorresurser.

% Processortid

Detta mäter andelen förfluten tid som processorn spenderar på att köra trådar som inte är inaktiva. På aktiva servrar kan värdena stiga till 100 %, men ihållande användning över 70–75 % indikerar vanligtvis prestandaproblem för användare. Saknade eller otillräckliga index orsakar ofta hög CPU-användning.

% Privilegierad tid

Processortiden delas upp i användarläge och privilegierat läge (kärneläge). All diskåtkomst och I/O sker i kärnläge. Om denna räknare överstiger 25 % utför systemet troligen för mycket I/O. Normala värden ligger mellan 5 % och 10 %.

Processorkölängd

Denna räknare visar trådar som väntar på CPU-resurser. Värden överstiger konsekvent 1 (förutom under SQL Server säkerhetskopieringskomprimering) indikerar CPU-tryck. Detta betyder ofta att andra program är installerade på SQL Server maskin, vilket bryter mot bästa praxis.

Kontextväxlar/sek

Detta mäter hur ofta processorn växlar mellan trådar. Överdriven kontextväxling kan påverka prestandan och indikerar hög systembelastning.

3.3 Prestandaräknare för disk-I/O

Diskräknare är viktiga för SQL-prestandaövervakning eftersom disk-I/O ofta blir den primära flaskhalsen i databassystem.

% Disktid

Detta registrerar hur många procent av tiden disken var upptagen med läs-/skrivoperationer. Värden som konsekvent överstiger 85 % indikerar en I/O-flaskhals. Eftersom disken är mycket långsammare än minne, förbättras prestandan om man minskar detta mått.

Genomsnittlig disksek/läsning och genomsnittlig disksek/skrivning

Dessa räknare mäter genomsnittlig tid (i sekunder) för läs- och skrivoperationer. Om genomsnittsvärdena överstiger 10–20 ms tar det för lång tid för disken att bearbeta data. Transaktionsloggenheter kräver särskilt snabb skrivprestanda.

Diskkölängd

Detta visar utestående förfrågningar om att läsa/skriva till disk. Värden som är konsekvent högre än 2 (eller 2 per disk för RAID-arrayer) indikerar att disken inte kan hålla jämna steg med I/O-förfrågningar.

Diskbyte/sek

Detta övervakar hastigheten på dataöverföringen till/från disken. Om detta överstiger diskens nominella kapacitet börjar data lagras, vilket indikeras av att diskkölängden ökar.

Disköverföringar/sek

Detta spårar antalet läs-/skrivoperationer som utförs på disken. SQL Server Dataåtkomst är vanligtvis slumpmässig, vilket är långsammare på grund av hårddiskhuvudets rörelser. Se till att detta värde ligger under din hårddisks maximala kapacitet (vanligtvis 100/sek för standardenheter).

3.4 SQL Server Specifika räknare

3.4.1 Räknare i bufferthantering

Bufferthanteringens räknare övervakar SQL Servers minnesbuffertoperationer:

Sidläsningar/sek: Kumulativt antal läsningar av fysiska databasesidor
Sidskrivningar/sek: Kumulativt antal skrivningar till fysiska databaser
Lata skriver/sek: Antal buffertar skrivna av lazy writer för att frigöra minne
Kontrollpunkt sidor/sek: Sidor som rensats av kontrollpunkt eller andra åtgärder som kräver att alla smutsiga sidor rensas

3.4.2 SQL-statistikräknare

Dessa räknare ger insikt i SQL Server frågebehandling:

Batchförfrågningar/sek: Antal SQL-batchförfrågningar som mottagits av servern. Detta fungerar som ett riktmärke för serveraktivitet
SQL-kompileringar/sek: Antal SQL-kompileringar. Bör vara 10 % eller mindre av det totala antalet batchförfrågningar/sek.
SQL-omkompileringar/sek: Antal SQL-omkompileringar. Bör också vara 10 % eller mindre av det totala antalet batchförfrågningar/sek.

3.4.3 Allmänna statistikräknare

Användaranslutningar: Antal användare anslutna till systemet. Används som riktmärke för att spåra anslutningstillväxt över tid.
Blockerade processer: Nuvarande antal blockerade processer. Bör helst vara 0

3.4.4 Räknare i minneshanteraren

Minnesbidrag väntar: Totalt antal processer som väntar på minnestilldelning för arbetsytan. Bör helst vara 0.

4. Konfigurera prestandamonitor för SQL Server(Windows Vista/Server 2008 och senare)

Först och främst behöver vi skapa en container för att enklare hantera räknare:

För Windows Vista/Server 2008 och senare versioner kan du skapa datainsamlingsuppsättningar i det här avsnittet.
För Windows XP/Server 2003 och tidigare versioner kan du skapa räknarloggar i nästa avsnitt.

4.1 Vad är datainsamlingsuppsättningar?

Datainsamlingsuppsättningar organiserar prestandaräknare, händelsespårningsdata och systemkonfigurationsinformation i en enda insamlingsenhet. De ger mer flexibilitet än enkla räknarloggar och möjliggör automatiserad, schemalagd datainsamling för omfattande prestandaövervakning av SQL-databasen.

4.2 Skapa en datainsamlingsuppsättning

Skapa en anpassad datainsamlingsuppsättning för att övervaka SQL Server prestandaräknare:

Öppna prestandamonitorn
Bygga ut Datainsamlaruppsättningar
Högerklicka Användardefinierad
Välja Nytt -> Datainsamlaruppsättning
Ange ett beskrivande namn (t.ex. "SQL Server Prestandamätningar”)
Välja Skapa manuellt (avancerat)
Klicka Nästa
Kolla upp Skapa dataloggar -> Prestandaräknare
Klicka Nästa
Klicka Lägg till att välja räknare
Lägg till önskas SQL Server och systemräknare.
uppsättning Provintervall
- För rutinmässig övervakning, använd 1 minut (60 sekunder)
- För aktiv felsökning, använd 15–30 sekunder
- Undvik att köra högfrekventa avbildningar under lång tid, eftersom de kan påverka prestandan och generera överdriven data.
Klicka Nästa
Välj platsen för att spara loggarna
Klicka Finish, en ny datainsamlaruppsättning kommer att skapas.
Som standard kommer den nya datainsamlingsuppsättningen att INTE startas automatiskt. Du hittar den i den vänstra panelen, under Prestanda -> Datainsamlaruppsättningar -> Användardefinierad -> Din datainsamlare, högerklicka på den och välj Start

4.3 Nyckelräknare att lägga till

Minne -> Tillgängliga MByte
Fysisk disk -> Genomsnittlig disksek/läsning (alla instanser utom _Total)
Fysisk disk -> Genomsnittlig disksek/skrivning (alla instanser utom _Total)
Fysisk disk -> Diskläsningar/sek (alla instanser utom _Total)
Fysisk disk -> Diskskrivningar/sek (alla instanser utom _Total)
Processor -> % Processortid (alla instanser utom _Total)
SQLServer: Allmän statistik -> Användaranslutningar
SQLServer: Minneshanterare -> Väntar på minnestilldelningar
SQLServer: SQL-statistik -> Batchförfrågningar/sek
SQLServer: SQL-statistik -> SQL-kompileringar/sek
SQLServer: SQL-statistik -> SQL-omkompileringar/sek
System -> Processorns kölängd

4.4 Ställa in stoppvillkor

Konfigurera stoppvillkor för att förhindra obegränsad datatillväxt:

När du har skapat datainsamlingsuppsättningen högerklickar du på den och väljer Våra Bostäder
Klicka på Stoppvillkor fliken
Möjliggöra Total varaktighet
Ställ in varaktigheten till 1 dag (24 timmar)
Klicka OK att spara

Detta säkerställer att loggen inte blir för stor och startar om automatiskt om det är schemalagt.

4.5 Schemaläggning av datainsamling

Automatisera datainsamling för att säkerställa konsekvent övervakning:

Högerklicka på din datainsamlaruppsättning och välj Våra Bostäder
Klicka på tidtabell fliken
Klicka Lägg till att skapa ett nytt schema
Konfigurera startdatum och tid
Ställ in återkommande mönster (t.ex. dagligen)
Klicka OK för att spara schemat

För automatisk start, konfigurera Data Collector Set så att det startar när servern startar genom att skapa en startutlösare i Windows Schemaläggare.

5. Konfigurera prestandamonitor för SQL Server(Windows XP / Server 2003 och tidigare)

För Windows XP/Server 2003 och tidigare versioner kan du skapa räknarloggar, vilket låter dig välja en uppsättning prestandaräknare och logga dem till en fil regelbundet.

5.1 Skapa räknarloggar

Följ dessa steg för att skapa en ny räknarlogg:

Öppna prestandamonitorn
Bygga ut Prestandaloggar och-varningar i den vänstra rutan
Högerklicka Räknare Loggar
Välja Nya logginställningar
Namnge loggen med ditt databasservernamn (t.ex. ”ProductionSQL01”)
Klicka OK för att påbörja konfigurationen

Genom att skapa separata räknarloggar för varje server kan du testa prestandan på enskilda servrar utan att samla in data för alla servrar samtidigt.

5.2 Lägga till prestandaräknare

När du har skapat en räknarlogg lägger du till de specifika prestandaräknare som du vill övervaka:

Klicka på Lägg till räknare Knappen
Ändra datornamnet så att det pekar på din SQL Server exempel
Klicka Fliken för att ladda tillgängliga prestandaobjekt
Välj ett prestationsobjekt från rullgardinsmenyn (t.ex. Minne)
Välj specifika räknare från listan
Välj instanser om tillämpligt (t.ex. enskilda processorer eller diskar)
Klicka Lägg till att inkludera räknaren
Upprepa för alla önskade räknare
Klicka Stäng när det är färdigt

5.3 Konfigurera provintervall

Samplingsintervallet avgör hur ofta Prestandaövervakaren samlar in data. Konfigurera lämpliga intervall baserat på dina övervakningsbehov:

I egenskaperna för räknarloggen, leta upp Exempeldata varje
Ställ in intervallet (standard är 15 sekunder)
För baslinjeövervakning, använd 1 minuts intervall för daglig insamling
För felsökning, använd intervall på 15–30 sekunder för korta intervaller
Klicka OK att ansöka

Kom ihåg att kortare intervall genererar mer data, vilket kan vara svårare att rendera och analysera. Större intervall kan missa viktiga toppar. Balansera datagranularitet med lagrings- och analyskrav.

5.4 Konfigurera loggfiler

Korrekt konfiguration av loggfiler säkerställer att data lagras effektivt och tillgängligt:

Klicka på Loggfiler fliken i räknarloggens egenskaper
Ändra loggfilstyp till Textfil (kommaavgränsad) för enkel Excel-import
Klicka Inställd
Ange sökvägen till en dedikerad plats (t.ex. en delad PerformanceLogs-mapp)
Klicka OK att bekräfta

Använd en nätverksåtkomlig resurs för logglagring så att du kan komma åt filer på distans och dela dem med andra användare.

5.5 Konfigurera inloggningsuppgifter

Konfigurera lämpliga inloggningsuppgifter så att Performance Monitor kan komma åt fjärråtkomst SQL Server instanser:

I egenskaperna för räknarloggen, leta upp Spring som
Ange ditt domännamn i formatet: DOMÄN\användarnamn
Klicka Ange lösenord
Ange och bekräfta ditt lösenord
Klicka OK att spara

Detta gör att PerfMon-tjänsten kan samla in statistik med hjälp av dina domänbehörigheter snarare än sina egna inloggningsuppgifter.

6. Analysera prestandamätardata

6.1 Visa loggfiler i Prestandamonitorn

Prestandaövervakaren kan visa historiska data från sparade loggfiler:

Öppna prestandamonitorn
Klicka på i den vänstra rutan Övervakningsverktyg -> Performance monitor.
Högerklicka var som helst i grafområdet
Välja Våra Bostäder
Klicka på Källa fliken
Välja Loggfiler radioknapp
Klicka Lägg till
Navigera till din loggfil (.blg eller .csv)
Välj filen och klicka på Öppet
Använd Tidsintervall skjutreglaget för att välja den period du vill analysera
Klicka OK för att stänga dialogrutan Egenskaper
Klicka på den gröna plusikonen för att lägga till räknare från loggfilen.
Välj önskade räknare att visa
Klicka OK

Diagrammet visar nu historiska data från loggfilen. Använd skjutreglaget Tidsintervall i Egenskaper för att begränsa specifika tidsperioder för detaljerad analys.

6.2 Exportera data till Excel

Excel erbjuder kraftfulla analysfunktioner för prestandaräknare:

Öppna Prestandamonitorn med din loggfil laddad
Högerklicka var som helst i grafområdet
Välja Spara data som
Välj en plats för filen
Välja Textfil (kommaavgränsad) (.csv) från rullgardinsmenyn
Klicka Spara
Öppna CSV-filen i Excel

Formatera exporterade data för bättre analys:

Ta bort den halvtomma rad 2 och rensa cell A1
Formatera kolumn A som Datum/Tid
Formatera numeriska kolumner med noll decimaler och tusentalsavgränsare
Hitta och ersätt servernamn i rubriker (t.ex. ersätt "\\SERVERNAMN" med tomt)
Rensa objektnamn i rubriker (t.ex. "Minne", "Fysisk disk", "Processor")
Minska rubrikens teckenstorlek till 8 punkter för bättre synlighet

6.3 Tolkning av räknarvärden

6.3.1 Analys av minnesräknare

När du analyserar minnesräknare, leta efter dessa indikatorer:

Tillgängliga MByte: Bör ligga över 4096 MB konsekvent
Förväntad livslängd på sidan: Värden över 300 sekunder indikerar ett friskt minne. Lägre värden tyder på minnesbelastning.
Buffertcacheträffförhållande: Bör uppfylla eller överstiga 99 %. Lägre värden indikerar för många diskläsningar.
Minnesbidrag väntar: Bör alltid vara 0. Alla positiva värden indikerar minnesbrist

6.3.2 Analys av CPU-räknare

CPU-prestandaindikatorer inkluderar:

% Processortid: Långvarig användning över 75 % tyder på prestandaproblem. Toppar till 100 % är normalt men bör inte bestå.
Processorkölängd: Värden över 1 indikerar CPU-belastning. Kontrollera Aktivitetshanteraren för att identifiera vilka processer som förbrukar CPU.
% Privilegierad tid: Bör ligga mellan 5–10 %. Värden över 25 % tyder på överdrivna I/O-operationer.

6.3.3 Analys av diskräknare

Tröskelvärden för diskprestanda:

Genomsnittlig disksekund/läsning och skrivning: Bör ligga under 10–20 ms. Högre värden indikerar långsamma disksystem.
Diskkölängd: Värden som konsekvent ligger över 2 (eller 2 per disk i RAID) indikerar I/O-flaskhalsar
% Disktid: Ihållande värden över 85 % indikerar diskmättnad

6.4 Använda formler och statistik

Lägg till statistiska formler i Excel för snabb analys:

Infoga 7 tomma rader högst upp i ditt kalkylblad
Lägg till etiketter i kolumn A: Genomsnitt, Median, Min, Max, Standardavvikelse
I cell B2, skriv in: =MEDEL(B9:B100) (justera B100 till din sista datarad)
I cell B3, skriv in: =MEDIAN(B9:B100)
I cell B4, skriv in: =MIN(B9:B100)
I cell B5, skriv in: =MAX(B9:B100)
I cell B6, skriv in: =STDEV(B9:B100)
Kopiera formler över alla räknarkolumner
Markera cell B9 och tryck Alt+W+F+Enter för att frysa rutor

Denna statistik hjälper till att identifiera trender, extremvärden och normala driftsintervall för varje räknare.

7. Verktyg för prestandaanalys för loggar (PAL)

7.1 Introduktion till PAL

Performance Analysis for Logs (PAL) är ett gratisverktyg utvecklat av Clint Huffman som analyserar Performance Monitor-loggar och genererar HTML-rapporter med tröskelvärdesanalys. PAL jämför dina prestandadata mot kända tröskelvärden och ger detaljerade rekommendationer för SQL Server prestandaoptimering.

Ladda ner PAL från GitHub-arkivet: https://github.com/clinthuffman/PAL

7.2 Konfigurera PAL

Installera PAL genom att följa dessa steg:

Ladda ner PAL-installationsfilen från GitHub
Kör installationsprogrammet
Klicka Nästa på välkomstskärmen
Granska och godkänn installationskatalogen
Klicka Nästa att fortsätta
Klicka installera för att påbörja installationen
Vänta tills installationen är klar
Klicka Finish

7.3 Bearbeta loggfiler med PAL

Analysera dina prestandaövervakningsloggar med PAL:

Starta PAL från Start-menyn eller installationskatalogen
Klicka på Räknarelogg fliken
Klicka Bläddra för att välja din .blg-fil
Navigera till din loggfil för prestandaövervakning
Klicka Öppet
Klicka på Tröskelfil fliken
Välj en tröskelfil från rullgardinsmenyn (t.ex. "SQL Server 2016” )
Klicka på Frågor fliken
Svara på frågor om din systemkonfiguration
Ange om din SQL Server är OLTP eller datalager
Ange totalt tillgängligt RAM-minne
Klicka på Outputalternativ fliken
Välj en utdatakatalog för HTML-rapporten
Kolla upp html Utmatningsformat
Klicka på Utförande fliken
Granska dina val
Kolla upp Börja körningen nu
Klicka Finish

7.4 Analysera PAL-rapporter

När PAL har slutfört analysen genereras en HTML-rapport som innehåller:

Sammanfattning av prestationsproblem
Detaljerad räknaranalys med diagram
Överträdelser av tröskelvärden markerade i färg
Specifika rekommendationer för varje problem
Historiska trender och mönster

Rapporten använder färgkodning för att ange allvarlighetsgrad: rött för kritiska problem, gult för varningar och grönt för felfria mätvärden. Granska varje avsnitt för att förstå prestandaflaskhalsar och följ PAL:s rekommendationer för optimering.

8. Alternativ SQL Server Övervakningsverktyg

8.1 Inbyggd SQL Server Verktyg

8.1.1 SQL Server Aktivitetskontroll

SQL Server Aktivitetskontroll visar information i realtid om SQL Server processer och prestanda:

Öppet SQL Server Management Studio (SSMS) och anslut till din serverinstans
Högerklicka på servernamnet i Object Explorer
Välja Aktivitetskontroll

Aktivitetsövervakaren visar processer, resursväntningar, datafil-I/O och senaste dyra frågor. Den ger snabba insikter i aktuell databasaktivitet men lagrar inte historisk data.

8.1.2 SQL Server Prestanda Dashboard

SQL Server Management Studio innehåller inbyggda prestationsrapporter:

In SQL Server Management Studio (SSMS), högerklicka på SQL Server instans i Object Explorer
Välja Rapport -> Standardrapporter
Välj bland tillgängliga rapporter som Prestanda Dashboard

Prestandaöversikten ger visuell insikt i SQL Server instansprestanda, inklusive systemets CPU-användning, aktuella vänteförfrågningar och prestandamätvärden. Du kommer åt den via menyn Standardrapporter.

8.1.3 SQL Server Profiler

SQL Server Profiler fångar och analyserar SQL Server händelser som frågekörning, transaktionsåtgärder och inloggningsaktiviteter.

Att börja SQL Server profilerare:

In SQL Server Management Studio, klicka Verktyg -> SQL Server Profiler

Profiler skapar betydande prestandakostnader, så använd den medvetet och helst under lågtrafik. För de flesta scenarier ger Extended Events bättre prestanda med mindre påverkan.

8.1.4 Utökade händelser

Utökade evenemang är ett lättviktigt system för prestationsövervakning inbyggt i SQL Server. Det ersätter SQL Server Profilerare med bättre prestanda och lägre omkostnader.

Viktiga funktioner:

Finkornig övervakning av specifika händelser
Minimal prestandapåverkan
Anpassningsbara evenemangssessioner
Integration med SSMS och andra verktyg
Stöd för komplex filtrering och aggregering

Skapa utökade händelsesessioner via SSMS:

In Objekt Explorer, utöka din server och gå till Hantering -> Utökade händelser -> Sessioner
Högerklicka på sessioner Och välj Ny sessionsguide
Följ instruktionerna för att starta en ny session.

8.1.5 Dynamiska hanteringsvyer (DMV:er)

DMV:er exponerar detaljerad information om serverns tillstånd för att övervaka hälsa, diagnostisera problem och finjustera prestanda. Viktiga DMV:er inkluderar:

sys.dm_exec_query_stats: Statistik över frågeprestanda
sys.dm_os_wait_stats: Väntetyper som påverkar serverns prestanda
sys.dm_os_prestandaräknare: SQL Server prestandaräknardata
sys.dm_exec_requests: För närvarande körs förfrågningar
sys.dm_exec_sessions: Aktiva användarsessioner

Fråga dessa vyer med T-SQL för att få åtkomst till prestandadata och historiska mätvärden i realtid.

Grundläggande användning

-- See all active connections
SELECT * FROM sys.dm_exec_connections;

-- View current sessions
SELECT * FROM sys.dm_exec_sessions;

-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

8.2 Övervakningslösningar från tredje part

Redgate SQL Monitor

Redgate SQL Monitor specialiserar sig på övervakning SQL Server och Azure SQL Database-miljöer. Den erbjuder övervakning av hela fastigheten, anpassningsbara aviseringar och instrumentpaneler, detaljerade rapporteringsfunktioner och integration med andra Redgate-verktyg.

Solarwinds SQL Server Övervakningsverktyg

SolarWinds SQL Server Monitoring Tool, även känt som SQL Sentry, är designat för att diagnostisera, lösa och förhindra allvarliga prestandaproblem med SQL Server.

IDERA SQL Server Verktyg för prestandaövervakning

IDERA SQL Diagnostic Manager är ett kraftfullt SQL Server prestandaövervakningsverktyg utformat för att hjälpa till med proaktiv prestandaövervakning, diagnostik och finjustering.

Application Managers SQL-övervakning

Applications Manager erbjuder en Microsoft SQL Server Övervakningsverktyg som ger användbara IT-lösningar. Den är utformad för att övervaka prestanda för SQL-databaser, samtidigt som den identifierar buggar och löser problem som kan leda till stopp i en organisations verksamhet.

8.3 Övervakningsverktyg med öppen källkod

DBA-dash

DBA Dash är ett gratis övervakningsverktyg med öppen källkod som ger insikter i SQL Server hälsa, prestanda och aktivitet. Det är särskilt användbart för små och medelstora miljöer och inkluderar dagliga DBA-kontroller, prestandaövervakning och konfigurationsspårning.

SQLWATCH

SQLWATCH erbjuder decentraliserad, nära realtidsbaserad SQL Server övervakning med 5-sekunders granularitet för att fånga arbetsbelastningstoppar. Den stöder Grafana för dashboards i realtid och Power BI för djupgående analys. Verktyget erbjuder omfattande konfigurationsalternativ, inga underhållskrav och obegränsad skalbarhet.

Opserver

Opserver, utvecklad av Stack Exchange, övervakar flera system, inklusive SQL Server, Redis och Elasticsearch. Den ger en vy över alla servrar för CPU-, minnes-, nätverks- och hårdvarustatistik över hela din infrastruktur.

sp_VemÄrAktiv

sp_WhoIsActive är en omfattande lagrad procedur för aktivitetsövervakning skapad av Adam Machanic. Den fungerar med alla SQL Server versioner från 2005 till nuvarande utgåvor och används flitigt av SQL Server Databasbaserade databashanteringssystem (DBAs) för aktivitetsövervakning i realtid.

För att använda sp_WhoIsActive, ladda ner det från http://whoisactive.com/, installera det i din databas och kör:

EXEC sp_WhoIsActive

Proceduren visar vilka frågor som för närvarande körs, vänteinformation, blockeringsinformation och resursförbrukning.

9. Bästa metoder för SQL Server Performance monitor

9.1 Fastställande av prestationsbaslinjer

Prestandabaslinjer fastställer normala driftsparametrar för din SQL Server miljö. Utan baslinjer kan man inte avgöra om aktuella mätvärden indikerar problem eller representerar typiskt beteende.

Skapa baslinjer genom att:

Samla in prestandadata under normal drift i minst en vecka
Registrera mätvärden under både rusningstid och lågtrafik
Dokumentera typiska värden för nyckelräknare
Registrera säsongsvariationer om tillämpligt
Lagra baslinjedata för jämförelse med framtida mätvärden

Uppdatera baslinjer kvartalsvis eller efter betydande infrastrukturförändringar, programuppdateringar eller databasmodifieringar.

9.2 Ställa in lämpliga tröskelvärden för varningar

Konfigurera intelligenta tröskelvärden för att få meningsfulla aviseringar utan att överbelasta dig med aviseringar:

Väntande minnestilldelningar > 0 indikerar minnesbelastning
Processorkölängd > 2 per kärna tyder på CPU-flaskhals
Disksek/läsning eller skrivning > 20 ms indikerar långsam I/O
Blockerade processer > 5 signalerar konkurrensproblem
Förväntad sidlivslängd < 300 sekunder indikerar minnesbelastning

Justera tröskelvärden baserat på dina baslinjedata och specifika arbetsbelastningsegenskaper. Använd anpassningsbara tröskelvärden som tar hänsyn till normala variationer i din miljö.

9.3 Regelbunden datagranskning och analys

Schemalägg regelbundna prestationsbedömningar för att identifiera trender och framväxande problem:

Dagligen: Granska övergripande mätvärden och senaste varningar
Veckovis: Genomför djupgående analyser av prestationstrender
Månadsvis: Generera omfattande rapporter och jämför mot baslinjer
Kvartalsvis: Granska kapacitetsplanering och långsiktiga trender

Dokumentera resultat och spåra prestandaförbättringar över tid.

9.4 Balansering av övervakningsomkostnader

Övervakningen i sig förbrukar resurser, så balansera datainsamling med prestandapåverkan:

Använd intervall på 30–60 sekunder för kontinuerlig övervakning
Använd endast 15-sekundersintervall för aktiv felsökning
Begränsa datainsamlingstiden för att undvika överdriven data
Lagra loggar på separata enheter från databasfiler
Arkivera gammal prestandadata för att bibehålla hanterbara filstorlekar

Prestandaövervakaren lägger till minimal overhead när den konfigureras korrekt, vanligtvis under 2 % av systemresurserna.

9.5 Långsiktig datalagring

Spara prestandadata för meningsfull trendanalys och kapacitetsplanering:

Spara minst 1–2 års prestationsdata
Arkivera data till separat lagring efter 3–6 månader
Komprimera äldre loggfiler för att spara utrymme
Dokumentera alla viktiga händelser eller förändringar som påverkar prestandan

Med tanke på den relativt lilla storleken på prestandaräknardata är det ofta möjligt och värdefullt för långsiktig analys att behålla den på obestämd tid.

9.6 Integrering med DevOps-metoder

Integrera övervakning av databasprestanda i CI/CD-pipelines:

Inkludera databasprestandamått i distributionsvalidering
Automatisera prestandatester för nya utgåvor
Kontrollera att kodändringar inte påverkar prestandan negativt
Skapa prestandamått för varje utgåva
Integrera övervakningsaviseringar med incidenthanteringssystem

10. Felsökning av vanliga prestandaproblem

10.1 Identifiera CPU-flaskhalsar

CPU-flaskhalsar visar sig som långsamma svarstider för frågor och hög processorutnyttjande. Använd dessa steg för att diagnostisera CPU-problem:

Kontrollera räknaren för processorkölängd. Värden över 2 per kärna indikerar processortryck.
Granska processortid i %. Värden över 75 % tyder på en flaskhals i CPU:n.
Fjärrskrivbord till SQL Server
Öppna Aktivitetshanteraren (Ctrl+Shift+Esc)
Klicka på Processer fliken
Kolla upp Visa processer från alla användare
Klicka på CPU kolumnrubrik för att sortera efter CPU-användning
Identifiera vilka processer som förbrukar CPU-resurser

Om icke-SQL Server Program förbrukar mycket CPU, ta bort dem från databasservern. Om sqlservr.exe använder mycket CPU, undersök med hjälp av dessa metoder:

Kontrollera SQL-kompileringar/sek och SQL-omkompileringar/sek. Värden över 10 % av batchförfrågningar/sek indikerar överdriven kompilering.
Fråga sys.dm_exec_query_stats för att identifiera CPU-intensiva frågor
Granska körningsplaner för saknade index eller ineffektiva åtgärder
Överväg att lägga till index för att minska antalet tabellskanningar

10.2 Diagnostisera minnesproblem

Minnesproblem påverkar avsevärt SQL Server prestanda. Diagnostisera minnesproblem med hjälp av dessa indikatorer:

Tillgängliga minnesdroppar

Om antalet tillgängliga MB sjunker under 100 MB i ständigt, riskerar operativsystemet minnesbrist. Windows kan komma att sluta fungera. SQL Server minne till disk, vilket orsakar prestandaförsämring.

Låg förväntad livslängd för sidor

En förväntad sidlivslängd på under 300 sekunder indikerar hög buffertcache-omsättning. Detta tyder på antingen otillräcklig minnesallokering eller för hög minnesbelastning från frågor.

Låg träffkvot för buffertcache

Buffertcacheträffkvot under 99 % betyder SQL Server läser ofta data från disk snarare än minne. Detta inträffar när buffertpoolen är för liten eller SQL Server värms fortfarande upp efter omstart.

Minnesbidrag väntar

Alla värden över 0 för Väntande minnestilldelningar indikerar att frågor väntar på minnestilldelningar. Detta representerar en kritisk minnesbrist som kräver omedelbar uppmärksamhet.

För att lösa minnesproblem:

Inställd SQL Server maximal minnesinställning för att lämna tillräckligt med RAM-minne för operativsystemet (vanligtvis 4–8 GB beroende på serverstorlek)
Aktivera behörigheten "Lås sidor i minnet" för SQL Server servicekonto
Lägg till mer fysiskt RAM-minne till servern om minnesbelastningen kvarstår
Identifiera och optimera minnesintensiva frågor

10.3 Lösa problem med disk-I/O

Disk-I/O blir ofta den primära prestandaflaskhalsen i databassystem. Diagnostisera diskproblem med hjälp av dessa metoder:

Hög diskkölängd

Om diskkölängden konsekvent överstiger 2 (eller 2 per disk för RAID) indikerar det att diskundersystemet inte kan hålla jämna steg med I/O-förfrågningar. Detta skapar en eftersläpning av väntande åtgärder.

Överdriven disklatens

Genomsnittliga disksek/läs- och genomsnittliga disksek/skrivvärden över 10–20 ms indikerar långsam diskrespons. Transaktionsloggenheter kräver särskilt snabb prestanda, helst under 5 ms för skrivningar.

Hög % disktid

En ihållande % disktid över 85 % indikerar diskmättnad. Disken spenderar större delen av sin tid med att bearbeta I/O-förfrågningar med liten återstående ledig kapacitet.

Innan du åtgärdar diskproblem, kontrollera att de inte är symptom på minnesproblem. Otillräckliga minnesstyrkor SQL Server för att läsa mer data från disken, vilket artificiellt blåser upp diskmätvärden.

Så här löser du äkta problem med disk-I/O:

Uppgradera till snabbare diskar (SSD-diskar istället för hårddiskar)
Implementera RAID-konfigurationer för bättre prestanda
Separera databasfiler, transaktionsloggar och tempdb på olika fysiska enheter
Lägg till mer minne för att minska diskläsningar
Optimera index för att minska onödiga I/O
Granska och optimera dåligt presterande frågor

10.4 Åtgärda blockeringar och dödlägen

Blockering inträffar när en session har lås som hindrar andra sessioner från att fortsätta. Övervaka dessa räknare för att identifiera blockeringsproblem:

Blockerade processer: Bör helst vara 0
Lås väntar/sek: Antal låsförfrågningar som kräver väntetider
Genomsnittlig väntetid: Genomsnittlig väntetid för lås

För att undersöka blockering:

Öppna Aktivitetsmonitorn i SSMS
Expandera Processer avsnitt
Leta efter processer med värden som inte är noll Blockerad av värden
Identifiera det blockerande sessions-ID:t
Granska de frågor som orsakar blockering

Använd sp_WhoIsActive för en mer detaljerad blockeringsanalys. För många wait_info-poster indikerar ofta tempdb-konflikter eller blockeringsproblem.

För att minska blockering:

Minimera transaktionstiden
Använd lämpliga isoleringsnivåer
Lägg till index för att minska låstiden
Överväg READ_COMMITTED_SNAPSHOT-isolering
Granska och optimera långvariga frågor

10.5 Problem med frågeprestanda

Att identifiera dyra frågor är avgörande för SQL-prestandaövervakning. Använd dessa metoder för att hitta problematiska frågor:

Använda Aktivitetsmonitorn

I SSMS, högerklicka på servernamnet
Välja Aktivitetskontroll
Bygga ut Nyligen dyra sökfrågor
Granskningsfrågor med hög CPU, varaktighet eller logiska läsningar

Använda DMV:er

Fråga sys.dm_exec_query_stats för att identifiera resurskrävande frågor:

SELECT TOP 50
    total_worker_time/execution_count AS avg_cpu_time,
    total_logical_reads/execution_count AS avg_logical_reads,
    execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.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) qt
ORDER BY total_worker_time DESC

Analysera genomförandeplaner

Öppna ett nytt frågefönster i SSMS
Klicka Visa beräknad utförandeplan (Ctrl+L) eller Inkludera faktisk utförandeplan (Ctrl+M)
Kör din fråga
Granska genomförandeplanen för dyra operationer
Leta efter tabellskanningar, indexskanningar eller högkostnadsoperationer

Optimera sökfrågor genom att:

Lägga till lämpliga index
Omskrivning av frågor för att undvika dyra operationer
Uppdatering av statistik
Använda specifika kolumnnamn istället för SELECT *
Undvika onödiga DISTINCT- eller ORDER BY-klausuler

10.6 Upptäck och åtgärda skadad databas

Databasskada kan orsaka prestandaförsämring, dataförlust och systemfel. Att snabbt upptäcka och åtgärda skada är avgörande för att bibehålla databasens hälsa.

Indikatorer för databaskorruption

Var uppmärksam på dessa tecken på potentiell korruption:

Felmeddelanden i SQL Server fellogg (fel 823, 824 eller 825)
Oväntade programfel vid åtkomst till specifika tabeller
Långsam frågeprestanda på tidigare snabba frågor
SQL Server krascher eller oväntade omstarter
Misstänkta sidor visas i tabellen msdb.dbo.suspect_pages

Använda DBCC CHECKDB för detektering

DBCC CHECKDB är det primära verktyget för att upptäcka databaskorruption. Kör det regelbundet för att upptäcka problem tidigt.

Övervakning av misstänkta sidor

SQL Server registrerar automatiskt misstänkta sidor i msdb-databasen:

SELECT 
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)

Alla returnerade rader indikerar korruptionsproblem som kräver omedelbar uppmärksamhet.

Strategier för korruptionsförebyggande

Aktivera sidverifiering med alternativet CHECKSUM
Säkerhetskopiera regelbundet databasen
Använd pålitlig hårdvara med felkorrigering
Övervaka diskens hälsa med hjälp av tillverkarens verktyg
Schemalägg regelbundna DBCC CHECKDB-körningar
Ha kvar SQL Server uppdaterad med de senaste patcharna

Återställnings- och reparationsalternativ

Om fel upptäcks kan du prova det inbyggda verktyget DBCC CHECKDB för att åtgärda dem. Om det misslyckas, använd tredjepartsverktyg som DataNumen SQL Recovery som kan hantera allvarliga korruptioner.

11. Avancerade övervakningstekniker

11.1 Övervakning av frågearkiv

Query Store, introducerad i SQL Server 2016, samlar in prestandadata för fråger automatiskt. Det ger värdefulla insikter i frågebeteende, exekveringsplaner och prestandatrender.

Aktivera frågelagring

I SSMS Object Explorer högerklickar du på en databas
Välja Våra Bostäder
Klicka på Fråga Butik sida
In Driftläge (begärt), Välj Läsa skriva
Konfigurera ytterligare inställningar efter behov
Klicka OK

Övervakning av frågeprestanda

Få åtkomst till Query Store-rapporter via Object Explorer:

Expandera databasen i Object Explorer
Bygga ut Fråga Butik
Välj bland tillgängliga rapporter:
- Regresserade frågor
- Total resursförbrukning
- Mest resurskrävande frågor
- Frågor med påtvingade planer
- Spårade frågor

Planregressionsdetektering

Query Store upptäcker automatiskt när frågekörningsplaner ändras och prestandan försämras. Granska rapporten om regresserade frågor för att identifiera frågor som påverkas av planändringar.

Tvingad planhantering

När Query Store identifierar en bättre exekveringsplan, tvinga SQL Server att använda det:

Öppna frågan i Query Store
Högerklicka på önskad plan
Välja Styrkeplan

Detta förbättrar prestandan omedelbart utan att kräva kodändringar.

11.2 Övervakning av indexunderhåll

Indexfragmentering försämrar frågeprestanda över tid. Övervaka och underhåll index regelbundet för att säkerställa optimal prestanda.

Fragmenteringskontroll

Använd den här frågan för att kontrollera indexfragmentering:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
    AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC

Kör den här frågan under lågtrafik eftersom den kan vara resurskrävande.

Analys av siddensitet

Siddensiteten anger hur fulla indexsidorna är. Låg densitet slösar utrymme och minskar prestandan:

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75

Omorganisera kontra återuppbygga beslut

Välj indexunderhållsåtgärder baserat på fragmenteringsnivåer:

Fragmentering 10–30 %: Använd ALTER INDEX REORGANIZE
Fragmentering > 30 %: Använd ALTER INDEX REBUILD
Fragmentering < 10 %: Ingen åtgärd krävs

Omorganisering av verksamheter kräver färre resurser och kan köras online. Återuppbyggnadsåtgärder är mer grundliga men förbrukar betydande resurser.

11.3 Uppdateringar av databasstatistik

Hjälp med databasstatistik SQL Servers frågeoptimerare skapar effektiva exekveringsplaner. Föråldrad statistik leder till dålig frågeprestanda.

Automatisk ombyggnad av statistik

Aktivera automatiska statistikuppdateringar:

ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON

Övervakning av statistik Hälsa

Kontrollera när statistiken senast uppdaterades:

SELECT 
    OBJECT_NAME(s.object_id) AS TableName,
    s.name AS StatisticsName,
    STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
    sp.rows,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated

Uppdatera statistik manuellt vid behov:

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 Insamling av anpassade prestandadata

Skapa anpassade prestandaövervakningslösningar genom att fråga sys.dm_os_performance_counters direkt och lagra resultaten i tabeller.

Skapa anpassade samlingsskript

Bygg en lagrad procedur för att samla in prestandaräknardata:

CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
    INSERT INTO dbo.PerformanceHistory (
        SampleTime,
        CounterName,
        CounterValue
    )
    SELECT 
        GETDATE(),
        counter_name,
        cntr_value
    FROM sys.dm_os_performance_counters
    WHERE counter_name IN (
        'Page life expectancy',
        'Batch Requests/sec',
        'Buffer cache hit ratio'
    )
END

Använda sys.dm_os_performance_counters

Fråga prestandaräknare direkt:

SELECT 
    object_name,
    counter_name,
    instance_name,
    cntr_value,
    cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name

Lagring av historiska data

Skapa en tabell för att lagra prestandamått över tid:

CREATE TABLE dbo.PerformanceHistory (
    ID INT IDENTITY PRIMARY KEY,
    SampleTime DATETIME2 NOT NULL,
    PageLifeExpectancy BIGINT,
    BatchRequestsPerSec DECIMAL(18,4),
    BufferCacheHitRatio DECIMAL(5,2)
)

CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory 
ON dbo.PerformanceHistory

Pivoterade datalagringsmetoder

Lagra data i pivoterat format med en rad per samplingstid och en kolumn per räknare. Detta minskar lagringsutrymmet och förbättrar frågeprestanda jämfört med att lagra en rad per räknare per sampling.

11.5 Övervakning av flera servrar

För miljöer med flera SQL Server instanser, implementera centraliserad övervakning.

Centraliserad övervakningsmetod

Skapa en dedikerad övervakningsdatabas på en separat server
Samla in data från alla servrar till det centrala arkivet
Använda SQL Server Agentjobb för att köra inkassoskript
Implementera nätverksåtkomlig prestandaräknarinsamling

Fjärrserverövervakning

Konfigurera Prestandamonitorn för att samla in data från fjärrservrar genom att ange servernamn när du lägger till räknare. Se till att brandväggsregler tillåter trafik från Prestandamonitorn.

Rapportering mellan servrar

Skapa rapporter som jämför prestanda över flera servrar för att identifiera avvikelser och kapacitetsobalanser.

12. Övervakning SQL Server i molnmiljöer

12.1 Azure SQL-databasövervakning

Azure SQL Database erbjuder inbyggda övervakningsfunktioner som skiljer sig från lokala övervakningsfunktioner. SQL Server.

Azure Monitor-integrering

Azure Monitor samlar automatiskt in mätvärden från Azure SQL Database, inklusive:

DTU- eller vCore-användning
Användning Lagring
Anslutningsstatistik
Dödlägen och timeouts

Få åtkomst till dessa mätvärden via Azure Portal eller Azure Monitor API.

Inbyggda övervakningsfunktioner

Azure SQL-databasen inkluderar:

Rekommendationer för automatisk inställning
Insikt i frågeprestanda
Intelligenta insikter för avvikelsedetektering
Inbyggda varningar och diagnostik

Insikt i frågeprestanda

Den här funktionen ger visualisering av de mest resurskrävande frågorna, analys av frågelängd och historiska prestandatrender. Du kan komma åt den via Azure Portal under din SQL Database-resurs.

12.2 Molnbaserade övervakningsverktyg

Molnplattformar erbjuder inbyggda övervakningslösningar som är optimerade för sina miljöer:

Azure Monitor och Application Insights för Azure SQL Database
AWS CloudWatch för RDS SQL Server
Google Cloud-övervakning för molnet SQL Server

Dessa verktyg integreras sömlöst med molninfrastruktur och ger enhetlig övervakning över alla molnresurser.

Hybrid miljöövervakning

För hybriddistributioner som omfattar lokala och molnbaserade lösningar, använd verktyg som stöder båda miljöerna, som Redgate SQL Monitor, SolarWinds DPA eller anpassade lösningar med centraliserad datainsamling.

12.3 Prestandaskillnader i molnet

cloud SQL Server miljöer har unika egenskaper:

Resursallokeringsmodeller

Molnleverantörer använder olika resursallokeringsmetoder (DTU:er, virtuella kärnor, serverlösa) som påverkar hur du tolkar prestandamått. Förstå din tjänstnivås begränsningar och egenskaper.

Skalningsöverväganden

Molnmiljöer erbjuder dynamiska skalningsmöjligheter. Övervaka resursutnyttjandet för att avgöra när det är dags att skala upp eller ner. Många molnplattformar erbjuder automatisk skalning baserat på prestandatrösklar.

13. Automatisera prestandaövervakning

13.1 SQL Server Agentjobb

Automatisera datainsamling med hjälp av SQL Server Agentjobb för konsekvent övervakning utan manuell inblandning.

Schemalagd datainsamling

I SSMS, expandera SQL Server Recensioner
Högerklicka Lediga jobb och välj Nya jobb
Namnge jobbet (t.ex. ”Samla in prestationsstatistik”)
Klicka Steg och lägg till ett nytt steg
Ställ in typ till Transact-SQL-skript
Ange ditt datainsamlingsskript
Klicka Scheman och lägg till ett schema
Konfigurera frekvens (t.ex. var 5:e minut)
Klicka OK att skapa jobbet

Automatiserad rapportering

Skapa jobb som genererar och skickar prestationsrapporter via e-post:

Skapa en lagrad procedur som genererar rapporter
Använd Database Mail för att skicka rapporter via e-post
Schemalägg jobbet att köras dagligen eller veckovis

13.2 PowerShell-automatisering

PowerShell tillhandahåller kraftfulla automatiseringsfunktioner för SQL Server prestandamonitor.

Skript för insamling av prestandaräknare

$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)

$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append

WMI-frågor

Använd WMI för att samla in prestandadata från fjärrservrar:

$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01'
$memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01'

Write-Host "CPU Usage: $($cpu.LoadPercentage)%"
Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"

Automatiserade aviseringar

Skapa PowerShell-skript som kontrollerar mätvärden och skickar aviseringar när tröskelvärden överskrids:

$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

if ($cpu -gt $cpuThreshold) {
    Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
        -Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}

13.3 Skapa övervakningsdashboards

Visualisera prestationsdata med interaktiva dashboards för bättre insikter.

Power BI-integration

Anslut Power BI till dina prestandadatatabeller
Skapa visualiseringar för viktiga mätvärden
Lägg till utsnitt för tidsintervall och serverval
Publicera instrumentpaneler till Power BI-tjänsten
Konfigurera automatiska uppdateringsscheman

Skapande av instrumentpaneler i realtid

Använd verktyg som Grafana eller anpassade webbapplikationer för att skapa dashboards i realtid som frågar DMV:er och prestandamätare direkt.

Visualisering av historiska trender

Skapa linjediagram som visar trender över tid för:

CPU-utnyttjande
Minnesanvändning
Disk I / O
Frågeprestanda
Antal anslutningar

14. Fallstudier och praktiska exempel

14.1 Fallstudie: Att lösa minnesbelastning

Symptomidentifiering

En produktion SQL Server upplevde långsamma svarstider för frågor under rusningstid. Användare klagade på tidsgränser för applikationer och försämrad prestanda.

Räknaranalys

Data från Prestandaövervakningen avslöjade:

Sidans förväntade livslängd sänktes till 50 sekunder (normalt: >300)
Buffer Cache Hit Ratio sjönk till 85 % (normalt: >99 %)
Väntande minnestillstånd visade ofta värden på 5–10
Antalet läsningar/sekund på fysiska diskar ökade markant

Upplösningssteg

Kontrollerade SQL Server maximal minnesinställning – upptäckte att den var inställd på standard (obegränsat)
Granskat totalt serverminne kontra målserverminne – visade betydande skillnad
Konfigurerade maximalt serverminne för att lämna 8 GB för operativsystemet
Aktiverade behörigheten "Lås sidor i minnet" för SQL Server servicekonto
Lade till 32 GB extra RAM till servern
Övervakad prestanda i en vecka – Sidlivslängden stabiliserades över 500 sekunder

Resultat: Svarstiderna för frågor förbättrades med 60 %, användarklagomålen upphörde och applikationens prestanda återgick till det normala.

14.2 Fallstudie: CPU-prestandaoptimering

Symptomidentifiering

A SQL Server visade konsekvent en CPU-utnyttjandegrad på över 90 % under kontorstid, vilket orsakade långsam applikationsprestanda och frustration hos användarna.

Räknaranalys

Prestandaövervakning avslöjade:

Processortiden i genomsnitt 92 % med frekventa toppar till 100 %
Processorkölängden var konsekvent över 4 (servern hade 8 kärnor)
SQL-kompileringar/sek var 25 % av batchförfrågningar/sek (borde vara <10 %)
SQL-omkompileringar/sek var 15 % av batchförfrågningar/sek

Upplösningssteg

Använde DMV:er för att identifiera de mest CPU-krävande frågorna
Analyserade exekveringsplaner för identifierade frågor
Upptäckte flera tabellskanningar på stora tabeller på grund av saknade index
Skapade lämpliga index baserat på rekommendationer för genomförandeplaner
Identifierade dynamisk SQL som orsakar överdrivna kompileringar
Modifierad applikationskod för att använda parametriserade frågor
Implementerad planguide för problematiska lagrade procedurer
Uppdaterad statistik över flitigt använda tabeller

Resultat: CPU-utnyttjandet sjönk till 45 % i genomsnitt under kontorstid. Frågekörningstiderna förbättrades med 70 %. Applikationens svarstider förbättrades avsevärt.

14.3 Fallstudie: Flaskhalslösning för disk-I/O

Symptomidentifiering

Användare rapporterade extremt långsam applikationsrespons under datainläsning och batchbearbetning på kvällen.

Räknaranalys

Prestandadata visade:

Genomsnittlig disksek/skrivningstid översteg 45 ms på transaktionsloggenheten
Diskkölängden var i genomsnitt 12 på datafilenheten
% disktid låg över 95 % i timmar under batchjobb
Sidskrivningar/sek var exceptionellt höga

Upplösningssteg

Verifierade att minnesinställningarna var korrekta – inga minnesproblem hittades
Analyserade diskkonfigurationen – upptäckte alla filer på samma spindeluppsättning
Separerade transaktionsloggar till dedikerade snabba SSD-diskar
Flyttade tempdb till separata SSD-diskar
Implementerade flera tempdb-datafiler (en per kärna)
Uppgraderade datafilenheter till RAID 10 SSD-konfiguration
Optimerade batchjobb för att använda mindre transaktionsbatchar
Lade till index för att minska onödiga tabellskanningar under batchoperationer

Resultat: Genomsnittlig disksek/skrivningstid sjönk till 3 ms. Diskkölängden var i genomsnitt under 1. Slutförandetiden för batchjobb minskade med 75 %.

15. Framtida trender inom SQL Server Övervakning

15.1 AI och maskininlärning

Artificiell intelligens och maskininlärning förändras SQL Server prestandamonitor.

Predictive Analytics

Maskininlärningsmodeller förutspår framtida resursbehov baserat på historisk data. Dessa system kan prognostisera:

När lagringskapaciteten kommer att vara slut
Förväntade CPU- och minneskrav under toppperioder
Försämrad prestanda för frågor innan det påverkar användarna
Optimala tider för underhållsarbeten

Anomali upptäckt

AI-drivna verktyg upptäcker automatiskt ovanliga mönster i prestandamått. De identifierar avvikelser som mänskliga administratörer kan missa och skiljer mellan normala variationer och verkliga problem.

Automatiserad sanering

Självläkande system löser automatiskt vanliga problem när de upptäcks:

Starta om tjänster som har stoppats
Omfördela resurser under högbelastning
Tillämpa snabbkorrigeringar för kända problem
Återuppbygg fragmenterade index automatiskt

15.2 Utvecklingen av molnbaserad övervakning

Molnövervakning fortsätter att utvecklas med nya funktioner.

Enhetliga övervakningsplattformar

Moderna plattformar ger sikt i en enda glasruta över:

Lokalt SQL Server instanser
Molnbaserade databaser
Hybridmiljöer
Applikationsprestanda
Infrastrukturmått

Observerbarhetstrender

Skiftet från övervakning till observerbarhet betonar:

Förstå systembeteende från utgångar
Korrelera mätvärden, loggar och spår
Djupgående insikter i distribuerade system
Problemdiagnos i realtid

15.3 Självläkande databassystem

Framtida SQL Server versionerna kommer att innehålla fler autonoma funktioner.

Automatisk optimering

Databaser kommer kontinuerligt att optimera sig själva genom att:

Skapa och ta bort index automatiskt baserat på arbetsbelastning
Justera konfigurationsinställningar för optimal prestanda
Omskrivning av ineffektiva frågor transparent
Hantera resursallokering dynamiskt

Intelligent inställning

Avancerade system lär sig av prestandamönster och tillämpar finjusteringsrekommendationer automatiskt, vilket minskar behovet av manuell DBA-intervention.

16. Slutsats och viktiga tips

16.1 Sammanfattning av viktiga övervakningsmetoder

Effektiv SQL Server Prestandaövervakning kräver en omfattande strategi som kombinerar verktyg, tekniker och bästa praxis.

Sammanfattning av kritiska räknare

Fokusera övervakningsinsatserna på dessa viktiga räknare:

Minne: Sidlivslängd, träffförhållande för buffertcache, väntande minnestilldelningar
CPU: % processortid, processorkölängd
Disk: Genomsnittlig disksek/läsning och skrivning, diskkölängd
SQL ServerBatchförfrågningar/sek, Kompileringar/sek, Användaranslutningar

Sammanfattning av bästa praxis

Etablera baslinjer under normal drift
Ställ in intelligenta tröskelvärden för varningar baserat på baslinjer
Granska prestationsdata regelbundet
Overhead för balansövervakning med datagranularitet
Spara långsiktiga data för trendanalys
Använd lämpliga verktyg för varje övervakningsscenario

16.2 Metod för kontinuerlig förbättring

SQL Server Prestandaövervakning är inte en engångsaktivitet utan en pågående process som kräver kontinuerlig förfining.

Regelbundna granskningscykler

Dagligen: Kontrollera varningar och aktuell prestanda
Veckovis: Granska trender och identifiera nya problem
Månadsvis: Analysera långsiktiga mönster och kapacitetsbehov
Kvartalsvis: Uppdatera baslinjer och granska övervakningens effektivitet

Hålla sig uppdaterad med verktyg

Håll övervakningsverktyg och tekniker uppdaterade:

Utvärdera nya övervakningsfunktioner i SQL Server uppdateringar
Testa nya tredjepartsverktyg
Delta i utbildningar och konferenser
Delta i SQL Server community forum
Dela kunskap med teammedlemmar

16.3 Nästa steg

Implementera SQL Server prestandaövervakning systematiskt:

Färdplan för genomförande

Vecka 1: Konfigurera prestandamonitor med viktiga räknare
Vecka 2: Skapa datainsamlingsuppsättningar för automatiserad insamling
Vecka 3: Etablera baslinjer under normal drift
Vecka 4: Konfigurera aviseringar för kritiska tröskelvärden
Månad 2: Implementera ytterligare övervakningsverktyg (DMV:er, utökade händelser)
Månad 3: Utveckla anpassade dashboards och rapporter
Pågående: Förfina övervakningen baserat på erfarenheter och förändrade krav

Ytterligare resurser

Fortsätt lära dig om SQL Server prestandaövervakare genom Microsoft-dokumentation, communitybloggar och praktisk övning. Experimentera med olika verktyg och tekniker för att hitta vad som fungerar bäst för din miljö.

17. Vanliga frågor (FAQ)

17.1 Vilka är de viktigaste SQL Server prestandamätare att övervaka?

Det mest kritiska SQL Server prestandaräknare inkluderar:

Minne: Sidlivslängd (bör vara >300 sekunder) och buffertcacheträffkvot (bör vara >99 %)
CPU: % processortid (ihållna värden <75 %) och processorkölängd (bör vara <2 per kärna)
Disk: Genomsnittlig disksek/läsning och skrivning (bör vara <10–20 ms) och diskkölängd (bör vara <2 per disk)
SQL ServerBatchförfrågningar/sek, SQL-kompileringar/sek och väntande minnestilldelningar (ska vara 0)

Dessa räknare ger omfattande insikter i systemets hälsa och hjälper till att snabbt identifiera flaskhalsar.

17.2 Hur ofta bör jag samla in prestationsdata?

Insamlingsfrekvensen beror på dina övervakningsmål:

Baslinjeövervakning: Var 1 minut (60 sekunder)
Aktiv felsökning: Var 15–30:e sekund under korta perioder
Långsiktig trend: Var 5:e minut

Undvik att köra högfrekvent insamling kontinuerligt eftersom det kan påverka prestandan och generera överdriven data. Använd längre intervall för rutinmässig övervakning och kortare intervall endast vid undersökning av specifika problem.

17.3 Vad är skillnaden mellan Prestandamonitor och SQL Server Profilerare?

Prestandaövervakning och SQL Server Profiler tjänar olika syften:

Performance Monitor:

Övervakar systemet och SQL Server prestandaräknare
Spårar resursanvändning (CPU, minne, disk)
Låg omkostnad, lämplig för kontinuerlig övervakning
Tillhandahåller aggregerade mätvärden över tid

SQL Server profilerare:

Spårar individ SQL Server händelser och frågor
Samlar in detaljerad information om frågekörning
Högre omkostnader, rekommenderas inte för kontinuerlig användning
Bäst för felsökning av specifika frågeproblem
Avskrivet till förmån för utökade evenemang

Använd Prestandaövervakaren för övergripande systemövervakning och Utökade händelser (inte Profiler) för detaljerad analys på frågenivå.

17.4 Kan prestandamätaren påverka SQL Server prestanda?

När den är korrekt konfigurerad har Prestandaövervakaren minimal inverkan på SQL Server prestanda, vanligtvis mindre än 2 % omkostnader. Överdriven övervakning kan dock orsaka problem:

För många räknare ökar omkostnaderna
Mycket korta provintervall (under 15 sekunder) belastar resurser
Kontinuerlig högfrekvent insamling genererar stora loggfiler

För att minimera påverkan:

Övervaka endast nödvändiga räknare
Använd lämpliga provtagningsintervall (60 sekunder för rutinmässig övervakning)
Lagra loggar på hårddiskar separat från databasfiler
Schemalägg resurskrävande övervakning under lågtrafik

17.5 Hur länge ska jag behålla prestandaövervakningsdata?

Lagring beror på dina analysbehov och lagringskapacitet:

Minimum: 3 månader för felsökning av aktuella problem
Rekommenderas: 1–2 år för kapacitetsplanering och trendanalys
Bäst: På obestämd tid om lagring tillåter, eftersom historisk data blir mer värdefull med tiden

Prestandaräknardata komprimeras väl och förbrukar relativt lite utrymme. Överväg att arkivera äldre data till separat lagring snarare än att radera den. Många organisationer finner att åratal av historisk data visar sig vara ovärderliga för kapacitetsplanering och identifiering av långsiktiga trender.

17.6 Vilka är bra tröskelvärden för nyckelprestandaräknare?

Rekommenderade tröskelvärden för varning:

Minnesbeviljande väntar: Avisering när > 0
Sidans förväntade livslängd: Avisering när < 300 sekunder
% Processortid: Avisering när > 80 % i 5 minuter
Processorkölängd: Avisering när > 2 per kärna
Genomsnittlig disksek/läsning eller skrivning: Avisering när > 20 ms
Diskkölängd: Avisering när > 2 per disk
Blockerade processer: Avisering när > 5

Justera dessa tröskelvärden baserat på dina baslinjedata och specifika arbetsbelastningsegenskaper. Det som är normalt för en miljö kan tyda på problem i en annan.

17.7 Hur övervakar jag SQL Server prestanda på distans?

Fjärrkontroll för monitorn SQL Server exempel med hjälp av dessa metoder:

Performance Monitor: Ange fjärrdatorns namn när du lägger till räknare
PowerShell: Använd parametern -ComputerName med Get-Counter
DMV:er: Anslut till fjärrservrar via SSMS och fråga DMV:er
Tredjepartsverktyg: De flesta övervakningsverktyg stöder fjärrövervakning av servrar

Se till att brandväggsregler tillåter trafik från Prestandaövervakning och att du har rätt behörighet på fjärrservern. För flera servrar, överväg att implementera centraliserad övervakning med en dedikerad övervakningsserver och databas.

17.8 Vilket är det bästa gratisverktyget för SQL Server prestandamätare?

Flera utmärkta gratisverktyg finns tillgängliga för övervakning SQL Server prestanda:

Windows Prestandaövervakare: Inbyggd, omfattande och pålitlig
SSMS Aktivitetsmonitor: Realtidsövervakning utan ytterligare installation
Utökade händelser: Lättviktig händelseövervakning inbyggd i SQL Server
sp_VemÄrAktiv: Populär gratis lagrad procedur för detaljerad aktivitetsövervakning
DBA-dash: Öppen källkodsövervakningsverktyg med omfattande funktioner
SQLWATCH: Öppen källkod med övervakningsfunktioner i nära realtid

För de flesta organisationer erbjuder Performance Monitor i kombination med SSMS-verktyg och sp_WhoIsActive utmärkta övervakningsfunktioner utan extra kostnad.

17.9 Hur exporterar jag PerfMon-data för analys?

Exportera prestandaövervakningsdata med dessa metoder:

Exportera till CSV:

Öppna Prestandamonitorn med din loggfil laddad
Högerklicka på grafen och välj Spara data som
Välja Textfil (kommaavgränsad) (.csv)
Välj plats och spara
Öppna i Excel för analys

Använd Relog-kommandot:

relog input.blg -f csv -o output.csv

Det här kommandoradsverktyget konverterar binära loggfiler (.blg) till CSV-format för enklare analys i kalkylprogram.

17.10 När ska jag använda övervakningsverktyg från tredje part istället för inbyggda alternativ?

Överväg tredjepartsverktyg när:

Hantera ett stort antal SQL Server instanser (10+)
Kräver centraliserad övervakning över flera datacenter
Behöver avancerade funktioner som prediktiv analys eller avvikelsedetektering
Vill ha integrerad varning med incidenthanteringssystem
Krav på efterlevnadsrapportering och historisk analys
Saknar DBA-resurser för att bygga och underhålla anpassade lösningar
Övervakning av heterogena databasmiljöer (SQL Server, Oracle, MySQL, etc.)

Inbyggda verktyg fungerar bra för mindre miljöer eller när du har skickliga databasadministratörer som kan utveckla anpassade övervakningslösningar. Tredjepartsverktyg ger värde genom tidsbesparingar, avancerade funktioner och professionell support.

18. Ytterligare resurser

18.1 Officiell dokumentation

Microsoft tillhandahåller omfattande dokumentation för SQL Server prestandamonitor:

SQL Server Dokumentation för prestandaövervakning: https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
Dynamiska hanteringsvyer: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
Utökade händelser: https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
Frågebutik: https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
Prestandajustering och övervakning: https://learn.microsoft.com/en-us/sql/relational-databases/performance/

18.2 Rekommenderade verktyg och nedladdningar

Viktiga verktyg för SQL Server prestandamonitor:

PAL-verktyg: https://github.com/clinthuffman/PAL
sp_VemÄrAktiv: http://whoisactive.com/
DBA-dash: https://dbadash.com/
SQLWATCH: https://github.com/marcingminski/sqlwatch
Första hjälp-kit (Brent Ozar): https://www.brentozar.com/first-aid/
SQL Server Management Studio: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 Gemenskapens resurser

Lär dig av SQL Server gemenskap:

SQL Server Central: https://www.sqlservercentral.com/
Brent Ozars blogg: https://www.brentozar.com/blog/
SQL-hack: https://www.sqlshack.com/
MSSQLTips: https://www.mssqltips.com/
Reddit r/SQLServer: https://www.reddit.com/r/SQLServer/
stack Overflow SQL Server märka: https://stackoverflow.com/questions/tagged/sql-server

Dessa resurser innehåller handledningar, felsökningsråd och bästa praxis från erfarna SQL Server yrkesverksamma. Att delta i communityforum hjälper dig att lära av andras erfarenheter och dela med dig av din egen kunskap.

Om författaren

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

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

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

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