SQL Server Leistungsmonitor: Ein vollständiger Leitfaden [2026]

SQL Server Performance-Monitor ist der Prozess der Verfolgung, Analyse und Verwaltung der Leistung und Gesundheit Ihrer SQL Server Datenbanken. Dabei werden Daten zu verschiedenen Aspekten Ihres Datenbanksystems gesammelt und interpretiert, um eine optimale Leistung sicherzustellen, Probleme zu vermeiden und die Datenbankintegrität aufrechtzuerhalten.

Die Leistungsüberwachung umfasst die Verfolgung von Abfrageausführungszeiten, Ressourcenauslastung, Indexleistung, Blockierungen und Deadlocks sowie Datenbankwachstumsmustern. Diese kontinuierliche Überwachung hilft Administratoren, potenzielle Probleme zu erkennen, bevor sie sich auf Benutzer oder Geschäftsabläufe auswirken.

1.2 Hauptvorteile der Leistungsüberwachung

Effektiv SQL Server Der Leistungsmonitor bietet mehrere entscheidende Vorteile:

Proaktive Problemerkennung: Identifizieren und beheben Sie potenzielle Probleme, bevor sie sich auf Benutzer oder Geschäftsabläufe auswirken
Leistungsoptimierung: Ermitteln Sie Engpässe und Ineffizienzen, um die allgemeine Datenbankleistung zu verbessern
Kapazitätsplanung: Prognostizieren Sie den Ressourcenbedarf und planen Sie zukünftiges Wachstum auf der Grundlage historischer Daten
Compliance und Sicherheit: Stellen Sie die Einhaltung gesetzlicher Vorschriften sicher und erkennen Sie verdächtige Aktivitäten

1.3 Häufige Leistungsprobleme

Ohne einen geeigneten SQL-Datenbank-Leistungsmonitor sind Unternehmen mehreren Risiken ausgesetzt:

Unerwartete Ausfallzeiten, die den Geschäftsbetrieb stören
Schlechte Anwendungsleistung beeinträchtigt die Benutzererfahrung
Datenverlust oder -beschädigung
Ineffiziente Ressourcennutzung führt zu unnötigen Kosten
Frustrierte Benutzer und potenzielle Umsatzeinbußen

Laut einer IDC-Studie aus dem Jahr 2023 sind 65 % der Datenbankleistungsprobleme auf mangelhafte Überwachungs- oder Optimierungspraktiken zurückzuführen.

2. Den Windows-Leistungsmonitor (PerfMon) verstehen

2.1 Was ist der Windows-Leistungsmonitor?

Der Windows-Leistungsmonitor (PerfMon) ist ein integriertes Windows-Tool zur Überwachung von Systemressourcen und Anwendungsleistung. Für SQL Server Administratoren bietet PerfMon wertvolle Einblicke in das Betriebssystem und SQL Server Metriken, was es für eine umfassende Leistungsanalyse unverzichtbar macht.

PerfMon misst Leistungsstatistiken in regelmäßigen Abständen und speichert diese in Dateien zur späteren Analyse. Datenbankadministratoren können das Zeitintervall, das Dateiformat und die zu überwachenden Statistiken auswählen. Das Tool ist nicht SQL Server-spezifisch – Systemadministratoren verwenden es, um Windows selbst, Exchange, Dateiserver und alle Anwendungen zu überwachen, bei denen Engpässe auftreten können.

2.2 Starten des Leistungsmonitors

Sie können den Leistungsmonitor auf verschiedene Weise starten:

Gehen Sie auf Start, Typ perfmon Klicken Sie im Suchfeld im Suchergebnis auf „Performand Monitor“:
Presse Windows-+ R, Typ perfmon, und drücke Enter
Navigieren Systemsteuerung -> System und Sicherheit -> Verwaltungstools -> Performance Monitor

3. wesentlich SQL Server Leistungsindikatoren

3.1 Speicherleistungsindikatoren

Speicherzähler sind für die Überwachung von entscheidender Bedeutung SQL Server Leistung, da sie anzeigen, ob Ihre Datenbank über ausreichend Speicherressourcen verfügt.

Verfügbare MBytes

Dieser Indikator zeigt die Menge des sofort verfügbaren physischen Speichers an. Er sollte relativ konstant bleiben und idealerweise nicht unter 4096 MB fallen. Niedrige Werte können darauf hinweisen, dass SQL ServerDie maximale Speichereinstellung von ist auf dem Standardwert belassen oder nichtSQL Server Anwendungen verbrauchen Speicher.

Lebenserwartung der Seite

Die Seitenlebenserwartung gibt an, wie lange (in Sekunden) eine Seite im Pufferpool verbleibt, ohne dass auf sie verwiesen wird. Ein normaler Wert liegt bei 300 Sekunden oder mehr. Niedrigere Werte weisen auf Speicherüberlastung und übermäßigen Pufferumsatz hin, was die Cache-Effektivität verringert.

Puffer-Cache-Trefferquote

Dieser Indikator gibt den Prozentsatz der Datenanfragen an, die über den SQL-Puffercache (Speicher) beantwortet wurden, anstatt von der Festplatte zu lesen. Er liegt in der Regel bei 99 % oder mehr. Niedrigere Werte deuten darauf hin, dass SQL Server benötigt mehr Arbeitsspeicher oder ist nach einem Neustart noch nicht wieder aufwärmbereit.

Speicherzuschüsse stehen aus

Dies zeigt die Anzahl der Prozesse, die auf Speicher warten, innerhalb SQL Server. Unter normalen Bedingungen sollte dieser Wert konstant 0 sein. Höhere Werte weisen auf eine unzureichende Speicherzuweisung hin, um SQL Server.

Zielspeicher des Servers vs. Gesamtspeicher des Servers

Die Angabe „Zielserverspeicher“ bezeichnet die ideale Speichermenge. SQL Server verwenden möchte. Der gesamte Serverspeicher zeigt, was SQL Server aktuell verwendet. Das Verhältnis zwischen diesen Werten sollte ungefähr 1 betragen. Erhebliche Unterschiede können auf Speichermangel oder unzureichenden verfügbaren Speicher hinweisen.

3.2 Prozessorleistungsindikatoren

CPU-Zähler helfen, Prozessor-Engpässe zu identifizieren und zu verstehen, wie SQL Server nutzt Rechenressourcen.

% Prozessorzeit

Dies misst den Prozentsatz der verstrichenen Zeit, die der Prozessor mit der Ausführung nicht inaktiver Threads verbringt. Auf aktiven Servern können die Werte bis auf 100 % ansteigen, aber eine anhaltende Auslastung von über 70–75 % deutet in der Regel auf Leistungsprobleme für Benutzer hin. Fehlende oder unzureichende Indizes verursachen häufig eine hohe CPU-Auslastung.

% Privilegierte Zeit

Die Prozessorzeit wird in den Benutzermodus und den privilegierten (Kernel-)Modus aufgeteilt. Alle Festplattenzugriffe und E/A-Vorgänge erfolgen im Kernelmodus. Wenn dieser Indikator 25 % überschreitet, führt das System wahrscheinlich zu viele E/A-Vorgänge durch. Normale Werte liegen zwischen 5 % und 10 %.

Länge der Prozessorwarteschlange

Dieser Zähler zeigt Threads an, die auf CPU-Ressourcen warten. Werte, die konstant über 1 liegen (außer während SQL Server Backup-Komprimierung) zeigen CPU-Auslastung an. Dies bedeutet oft, dass andere Anwendungen auf dem SQL Server Maschine, was gegen bewährte Verfahren verstößt.

Kontextwechsel/Sek.

Hiermit wird gemessen, wie häufig der Prozessor zwischen Threads wechselt. Übermäßige Kontextwechsel können die Leistung beeinträchtigen und auf eine hohe Systemauslastung hinweisen.

3.3 Festplatten-E/A-Leistungsindikatoren

Festplattenzähler sind für die SQL-Leistungsüberwachung unerlässlich, da Festplatten-E/A in Datenbanksystemen häufig zum größten Engpass wird.

% Festplattenzeit

Hiermit wird der Prozentsatz der Zeit erfasst, in der die Festplatte mit Lese-/Schreibvorgängen beschäftigt war. Werte, die konstant über 85 % liegen, weisen auf einen E/A-Engpass hin. Da die Festplatte deutlich langsamer als der Arbeitsspeicher ist, verbessert eine Reduzierung dieses Werts die Leistung.

Durchschnittliche Festplattensekunden/Lesen und Durchschnittliche Festplattensekunden/Schreiben

Diese Indikatoren messen die durchschnittliche Zeit (in Sekunden) für Lese- und Schreibvorgänge. Wenn die Durchschnittswerte 10–20 ms überschreiten, dauert die Datenverarbeitung auf der Festplatte zu lange. Transaktionsprotokolllaufwerke erfordern eine besonders schnelle Schreibleistung.

Länge der Datenträgerwarteschlange

Dies zeigt ausstehende Lese-/Schreibanforderungen für die Festplatte an. Werte, die konstant über 2 (oder 2 pro Festplatte bei RAID-Arrays) liegen, weisen darauf hin, dass die Festplatte mit den E/A-Anforderungen nicht Schritt halten kann.

Datenträgerbytes/s

Hiermit wird die Datenübertragungsrate zur/von der Festplatte überwacht. Übersteigt diese die Nennkapazität der Festplatte, kommt es zu einem Datenstau, der durch eine zunehmende Festplattenwarteschlangenlänge angezeigt wird.

Festplattenübertragungen/Sek.

Dadurch wird die Anzahl der auf der Festplatte ausgeführten Lese-/Schreibvorgänge verfolgt. SQL Server Der Datenzugriff erfolgt in der Regel zufällig und ist aufgrund der Bewegung des Laufwerkskopfes langsamer. Stellen Sie sicher, dass dieser Wert unter der maximalen Leistung Ihres Festplattenlaufwerks bleibt (normalerweise 100/s bei Standardlaufwerken).

3.4 SQL Server Spezifische Zähler

3.4.1 Puffermanager-Zähler

Puffermanager-Zählerüberwachung SQL ServerSpeicherpufferoperationen von:

Seitenaufrufe/Sek.: Kumulative Anzahl der physischen Datenbankseiten-Lesevorgänge
Seitenschreibvorgänge/Sek.: Kumulative Anzahl der physischen Datenbankseitenschreibvorgänge
Faule Schreibvorgänge/Sek.: Anzahl der Puffer, die vom Lazy Writer geschrieben wurden, um Speicher freizugeben
Checkpoint-Seiten/Sek.: Seiten, die durch Prüfpunkte oder andere Vorgänge gelöscht werden, bei denen alle schmutzigen Seiten gelöscht werden müssen

3.4.2 SQL-Statistikzähler

Diese Zähler geben Einblick in SQL Server Abfrageverarbeitung:

Batch-Anfragen/Sek.: Anzahl der vom Server empfangenen SQL-Batch-Anfragen. Dies dient als Benchmark für die Serveraktivität
SQL-Kompilierungen/Sek.: Anzahl der SQL-Kompilierungen. Sollte 10 % oder weniger der gesamten Batch-Anfragen/Sek. betragen
SQL-Neukompilierungen/Sek.: Anzahl der SQL-Neukompilierungen. Sollte auch 10 % oder weniger der gesamten Batch-Anfragen/Sekunde betragen

3.4.3 Allgemeine Statistikzähler

Benutzerverbindungen: Anzahl der mit dem System verbundenen Benutzer. Wird als Benchmark verwendet, um das Verbindungswachstum im Laufe der Zeit zu verfolgen
Blockierte Prozesse: Aktuelle Anzahl blockierter Prozesse. Idealerweise sollte 0 sein.

3.4.4 Speichermanager-Zähler

Ausstehende Speicherzuweisungen: Gesamtzahl der Prozesse, die auf die Zuweisung von Arbeitsspeicher warten. Sollte idealerweise 0 sein.

4. Einrichten des Leistungsmonitors für SQL Server(Windows Vista / Server 2008 und höher)

Zunächst müssen wir einen Container erstellen, um die Zähler einfacher verwalten zu können:

Für Windows Vista/Server 2008 und spätere Versionen können Sie in diesem Abschnitt Datensammlersätze erstellen.
Für Windows XP / Server 2003 und frühere Versionen können Sie Zählerprotokolle erstellen in der nächste Abschnitt.

4.1 Was sind Datensammler-Sets?

Datensammlungssätze organisieren Leistungsindikatoren, Ereignisablaufverfolgungsdaten und Systemkonfigurationsinformationen in einer einzigen Sammlungseinheit. Sie bieten mehr Flexibilität als einfache Leistungsindikatorprotokolle und ermöglichen die automatisierte, geplante Datenerfassung für eine umfassende Leistungsüberwachung von SQL-Datenbanken.

4.2 Erstellen eines Datensammler-Sets

Erstellen Sie einen benutzerdefinierten Datensammlungssatz zur Überwachung SQL Server Leistungsindikatoren:

Öffnen Sie den Leistungsmonitor
Erweitern Sie die Funktionalität der Datensammler-Sets
Der rechten Maustaste auf Benutzerdefiniert
Wählen Sie New -> Datensammler-Set
Geben Sie einen beschreibenden Namen ein (z. B. „SQL Server Leistungsmetriken“)
Wählen Sie Manuell erstellen (Erweitert)
Gehen Sie auf Weiter
Einblick in das Datenprotokolle erstellen -> Leistungsindikator
Gehen Sie auf Weiter
Gehen Sie auf Speichern zur Auswahl von Zählern
Speichern erwünscht SQL Server und Systemzähler.
Stelle den Probenintervall
- Für die Routineüberwachung verwenden Sie 1 Minute (60 Sekunden)
- Für die aktive Fehlerbehebung verwenden Sie 15-30 Sekunden
- Vermeiden Sie es, über einen längeren Zeitraum hochfrequente Aufnahmen zu machen, da diese die Leistung beeinträchtigen und übermäßige Datenmengen erzeugen können.
Gehen Sie auf Weiter
Wählen Sie den Speicherort für die Protokolle
Gehen Sie auf Farbe, wird ein neuer Datensammlersatz erstellt.
Standardmäßig wird der neue Datensammlersatz NICHT Es wird automatisch gestartet. Sie finden es im linken Bereich unter Leistung -> Datensammler-Sets -> Benutzerdefiniert -> Ihr Datensammler, klicken Sie mit der rechten Maustaste darauf und wählen Sie Start

4.3 Schlüsselzähler zum Hinzufügen

Speicher -> Verfügbare MBytes
Physische Festplatte -> Durchschnittliche Festplattensekunde/Lesevorgang (alle Instanzen außer _Total)
Physische Festplatte -> Durchschnittliche Festplattensekunde/Schreibzugriff (alle Instanzen außer _Total)
Physische Festplatte -> Festplattenlesevorgänge/Sek. (alle Instanzen außer _Total)
Physische Festplatte -> Festplattenschreibvorgänge/Sek. (alle Instanzen außer _Total)
Prozessor -> % Prozessorzeit (alle Instanzen außer _Total)
SQLServer: Allgemeine Statistiken -> Benutzerverbindungen
SQLServer: Speichermanager -> Ausstehende Speicherzuweisungen
SQLServer: SQL-Statistiken -> Batch-Anfragen/Sek.
SQLServer: SQL-Statistiken -> SQL-Kompilierungen/Sek.
SQLServer: SQL-Statistiken -> SQL-Neukompilierungen/Sek.
System -> Prozessorwarteschlangenlänge

4.4 Stoppbedingungen festlegen

Konfigurieren Sie Stoppbedingungen, um ein unbegrenztes Datenwachstum zu verhindern:

Klicken Sie nach dem Erstellen des Datensammlungssatzes mit der rechten Maustaste darauf und wählen Sie Eigenschaften im Vergleich
Klicken Sie auf Stoppbedingung Tab
Ermöglichen Gesamtdauer
Dauer auf 1 Tag (24 Stunden) einstellen
Gehen Sie auf OK , um zu speichern

Dadurch wird sichergestellt, dass das Protokoll nicht zu groß wird und bei Bedarf automatisch neu gestartet wird.

4.5 Planen der Datenerfassung

Automatisieren Sie die Datenerfassung, um eine konsistente Überwachung sicherzustellen:

Klicken Sie mit der rechten Maustaste auf Ihren Datensammlungssatz und wählen Sie Eigenschaften im Vergleich
Klicken Sie auf Programm Tab
Gehen Sie auf Speichern um einen neuen Zeitplan zu erstellen
Startdatum und -zeit konfigurieren
Festlegen eines Wiederholungsmusters (z. B. täglich)
Gehen Sie auf OK um den Zeitplan zu speichern

Für einen automatischen Start konfigurieren Sie das Datensammlerset so, dass es beim Hochfahren des Servers startet, indem Sie einen Startauslöser in der Windows-Aufgabenplanung erstellen.

5. Einrichten des Leistungsmonitors für SQL Server(Windows XP / Server 2003 und früher)

Für Windows XP/Server 2003 und frühere Versionen können Sie Leistungsindikatorenprotokolle erstellen, mit denen Sie eine Reihe von Leistungsindikatoren auswählen und diese regelmäßig in einer Datei protokollieren können.

5.1 Zählerprotokolle erstellen

Führen Sie die folgenden Schritte aus, um ein neues Zählerprotokoll zu erstellen:

Öffnen Sie den Leistungsmonitor
Erweitern Sie die Funktionalität der Performance Logs and Alerts im linken Bereich
Der rechten Maustaste auf Zählerprotokolle
Wählen Sie Neue Protokolleinstellungen
Benennen Sie das Protokoll mit dem Namen Ihres Datenbankservers (z. B. „ProductionSQL01“)
Gehen Sie auf OK um mit der Konfiguration zu beginnen

Durch das Erstellen separater Leistungsindikatorprotokolle für jeden Server können Sie die Leistung einzelner Server testen, ohne gleichzeitig Daten für alle Server erfassen zu müssen.

5.2 Leistungsindikatoren hinzufügen

Nachdem Sie ein Leistungsindikatorenprotokoll erstellt haben, fügen Sie die spezifischen Leistungsindikatoren hinzu, die Sie überwachen möchten:

Klicken Sie auf Zähler hinzufügen im nun erscheinenden Bestätigungsfenster aus,
Ändern Sie den Computernamen, sodass er auf Ihren SQL Server Instanz
Presse Tab um verfügbare Leistungsobjekte zu laden
Wählen Sie ein Leistungsobjekt aus der Dropdown-Liste aus (z. B. Memory)
Wählen Sie bestimmte Zähler aus die Liste
Wählen Sie gegebenenfalls Instanzen aus (z. B. einzelne Prozessoren oder Festplatten).
Gehen Sie auf Speichern den Zähler einschließen
Wiederholen Sie dies für alle gewünschten Zähler
Gehen Sie auf Menu wenn Sie fertig sind

5.3 Konfigurieren der Stichprobenintervalle

Das Stichprobenintervall bestimmt, wie häufig der Systemmonitor Daten sammelt. Konfigurieren Sie die entsprechenden Intervalle entsprechend Ihren Überwachungsanforderungen:

Suchen Sie in den Eigenschaften des Zählerprotokolls Stichprobendaten alle
Legen Sie das Intervall fest (Standard ist 15 Sekunden)
Für die Basisüberwachung verwenden Sie 1-Minuten-Intervalle für die tägliche Erfassung
Zur Fehlerbehebung verwenden Sie 15-30 Sekunden Intervalle für kurze Stöße
Gehen Sie auf OK bewerben

Bedenken Sie, dass kleinere Intervalle mehr Daten generieren, die schwieriger darzustellen und zu analysieren sein können. Bei größeren Intervallen können wichtige Spitzen übersehen werden. Stimmen Sie die Datengranularität mit den Speicher- und Analyseanforderungen ab.

5.4 Konfigurieren von Protokolldateien

Durch die richtige Konfiguration der Protokolldatei wird sichergestellt, dass die Daten effizient gespeichert und zugänglich sind:

Klicken Sie auf Protokolldateien Registerkarte in den Eigenschaften des Zählerprotokolls
Ändern Sie den Protokolldateityp in Textdatei (durch Komma getrennt) für einfachen Excel-Import
Gehen Sie auf Einrichtung
Legen Sie den Dateipfad auf einen dedizierten Speicherort fest (z. B. einen freigegebenen PerformanceLogs-Ordner).
Gehen Sie auf OK bestätigen

Verwenden Sie zur Protokollspeicherung eine über das Netzwerk zugängliche Freigabe, damit Sie remote auf Dateien zugreifen und diese mit anderen Benutzern teilen können.

5.5 Anmeldeinformationen einrichten

Konfigurieren Sie die entsprechenden Anmeldeinformationen, damit der Leistungsmonitor auf Remotezugriff zugreifen kann. SQL Server Instanzen:

Suchen Sie in den Eigenschaften des Zählerprotokolls Rennen wie
Geben Sie Ihren Domänenbenutzernamen im folgenden Format ein: DOMÄNE\Benutzername
Gehen Sie auf Kennwort festlegen
Geben Sie Ihr Passwort ein und bestätigen Sie es
Gehen Sie auf OK , um zu speichern

Dadurch kann der PerfMon-Dienst Statistiken mithilfe Ihrer Domänenberechtigungen und nicht mithilfe seiner eigenen Anmeldeinformationen erfassen.

6. Analysieren von Leistungsüberwachungsdaten

6.1 Anzeigen von Protokolldateien im Leistungsmonitor

Der Leistungsmonitor kann historische Daten aus gespeicherten Protokolldateien anzeigen:

Öffnen Sie den Leistungsmonitor
Klicken Sie im linken Bereich auf Überwachungstools -> Performance Monitor.
Klicken Sie mit der rechten Maustaste auf eine beliebige Stelle im Diagrammbereich
Wählen Sie Eigenschaften im Vergleich
Klicken Sie auf Quelle Tab
Wählen Sie Erhebung von Zugriffsdaten und Logfiles Radio knopf
Gehen Sie auf Speichern
Navigieren Sie zu Ihrer Protokolldatei (.blg oder .csv).
Wählen Sie die Datei aus und klicken Sie auf Öffne
Verwenden Sie die Zeitspanne Schieberegler, um den Zeitraum auszuwählen, den Sie analysieren möchten
Gehen Sie auf OK , um das Dialogfeld „Eigenschaften“ zu schließen
Klicken Sie auf das grüne Plus-Symbol, um Zähler aus der Protokolldatei hinzuzufügen
Wählen Sie die gewünschten Zähler zur Anzeige aus
Gehen Sie auf OK

Das Diagramm zeigt nun historische Daten aus der Protokolldatei an. Verwenden Sie den Schieberegler „Zeitbereich“ in den Eigenschaften, um bestimmte Zeiträume für eine detaillierte Analyse einzugrenzen.

6.2 Daten nach Excel exportieren

Excel bietet leistungsstarke Analysefunktionen für Leistungsindikatordaten:

Öffnen Sie den Leistungsmonitor mit geladener Protokolldatei
Klicken Sie mit der rechten Maustaste auf eine beliebige Stelle im Diagrammbereich
Wählen Sie Daten speichern unter
Wählen Sie einen Speicherort für die Datei
Wählen Sie Textdatei (durch Kommas getrennt) (.csv) aus der Dropdown-Liste
Gehen Sie auf Gespeichert
Öffnen Sie die CSV-Datei in Excel

Formatieren Sie die exportierten Daten für eine bessere Analyse:

Löschen Sie die halbleere Zeile 2 und leeren Sie Zelle A1
Spalte A als Datum/Uhrzeit formatieren
Formatieren Sie numerische Spalten mit Null Dezimalstellen und Tausendertrennzeichen
Suchen und Ersetzen von Servernamen in Headern (z. B. „\\SERVERNAME“ durch ein Leerzeichen ersetzen)
Bereinigen Sie Objektnamen in Headern (z. B. „Speicher“, „PhysicalDisk“, „Prozessor“)
Reduzieren Sie die Schriftgröße der Kopfzeile für eine bessere Sichtbarkeit auf 8 Punkte

6.3 Zählerwerte interpretieren

6.3.1 Speicherzähleranalyse

Achten Sie bei der Analyse von Speicherindikatoren auf die folgenden Indikatoren:

Verfügbare MBytes: Sollte konstant über 4096 MB bleiben
Lebenserwartung der Seite: Werte über 300 Sekunden weisen auf einen gesunden Speicher hin. Niedrigere Werte deuten auf Speicherdruck hin.
Puffer-Cache-Trefferquote: Sollte 99 % erreichen oder überschreiten. Niedrigere Werte weisen auf übermäßige Festplattenzugriffe hin
Ausstehende Speicherzuweisungen: Sollte immer 0 sein. Jeder positive Wert deutet auf Speichermangel hin.

6.3.2 CPU-Zähleranalyse

Zu den CPU-Leistungsindikatoren gehören:

% Prozessorzeit: Eine anhaltende Auslastung von über 75 % weist auf Leistungsprobleme hin. Spitzen auf 100 % sind normal, sollten aber nicht anhalten.
Länge der Prozessorwarteschlange: Werte über 1 zeigen CPU-Auslastung an. Überprüfen Sie den Task-Manager, um festzustellen, welche Prozesse CPU-Belastung verursachen.
% Privilegierte Zeit: Sollte zwischen 5-10% liegen. Werte über 25% deuten auf übermäßige E/A-Operationen hin

6.3.3 Festplattenzähleranalyse

Schwellenwerte für die Festplattenleistung:

Durchschnittliche Festplattensekunden/Lesen und Schreiben: Sollte unter 10-20 ms bleiben. Höhere Werte weisen auf langsame Festplattensubsysteme hin
Länge der Datenträgerwarteschlange: Werte, die konstant über 2 (oder 2 pro Festplatte im RAID) liegen, weisen auf I/O-Engpässe hin.
% Festplattenzeit: Dauerhafte Werte über 85 % weisen auf eine Festplattensättigung hin

6.4 Verwenden von Formeln und Statistiken

Fügen Sie Excel statistische Formeln für eine schnelle Analyse hinzu:

Fügen Sie oben in Ihrer Tabelle 7 leere Zeilen ein
Fügen Sie in Spalte A Beschriftungen hinzu: Durchschnitt, Median, Min, Max, Standardabweichung
Geben Sie in Zelle B2 ein: =AVERAGE(B9:B100) (passen Sie B100 an Ihre letzte Datenzeile an)
Geben Sie in Zelle B3 Folgendes ein: =MEDIAN(B9:B100)
Geben Sie in Zelle B4 Folgendes ein: =MIN(B9:B100)
Geben Sie in Zelle B5 Folgendes ein: =MAX(B9:B100)
Geben Sie in Zelle B6 Folgendes ein: =STDEV(B9:B100)
Formeln über alle Zählerspalten kopieren
Wählen Sie Zelle B9 aus und drücken Sie Alt+W+F+Eingabe, um die Fenster einzufrieren

Diese Statistiken helfen dabei, Trends, Ausreißer und normale Betriebsbereiche für jeden Zähler zu erkennen.

7. Leistungsanalyse für Protokolle (PAL)-Tool

7.1 Einführung in PAL

Performance Analysis for Logs (PAL) ist ein kostenloses Tool von Clint Huffman, das Performance Monitor-Protokolle analysiert und HTML-Berichte mit Schwellenwertanalyse generiert. PAL vergleicht Ihre Leistungsdaten mit bekannten Schwellenwerten und bietet detaillierte Empfehlungen für SQL Server Leistungsoptimierung.

Laden Sie PAL aus dem GitHub-Repository herunter: https://github.com/clinthuffman/PAL

7.2 PAL einrichten

Installieren Sie PAL, indem Sie die folgenden Schritte ausführen:

Laden Sie die PAL-Setup-Datei von GitHub herunter
Führen Sie das Installationsprogramm
Gehen Sie auf Weiter auf dem Begrüßungsbildschirm
Überprüfen und akzeptieren Sie das Installationsverzeichnis
Gehen Sie auf Weiter weiterhin
Gehen Sie auf Installieren um mit der Installation zu beginnen
Warten Sie, bis die Installation abgeschlossen ist
Gehen Sie auf Farbe

7.3 Verarbeitung von Protokolldateien mit PAL

Analysieren Sie Ihre Performance Monitor-Protokolle mit PAL:

Starten Sie PAL über das Startmenü oder das Installationsverzeichnis.
Klicken Sie auf Zählerprotokoll Tab
Gehen Sie auf Jetzt entdecken um Ihre .blg-Datei auszuwählen
Navigieren Sie zu Ihrer Performance Monitor-Protokolldatei
Gehen Sie auf Öffne
Klicken Sie auf Schwellenwertdatei Tab
Wählen Sie eine Schwellenwertdatei aus der Dropdown-Liste aus (z. B. „SQL Server 2016 ”)
Klicken Sie auf Fragen Tab
Beantworten Sie Fragen zu Ihrer Systemkonfiguration
Geben Sie an, ob Ihr SQL Server ist OLTP oder Data Warehouse
Geben Sie den insgesamt verfügbaren RAM ein
Klicken Sie auf Ausgabeoptionen Tab
Wählen Sie ein Ausgabeverzeichnis für den HTML-Bericht
Einblick in das HTML Ausgabeformat
Klicken Sie auf Ausführen Tab
Überprüfen Sie Ihre Auswahl
Einblick in das Die Ausführung wird jetzt gestartet.
Gehen Sie auf Farbe

7.4 PAL-Berichte analysieren

Nachdem PAL die Analyse abgeschlossen hat, generiert es einen HTML-Bericht mit:

Zusammenfassung der Leistungsprobleme
Detaillierte Zähleranalyse mit Diagrammen
Grenzwertverletzungen farblich hervorgehoben
Spezifische Empfehlungen für jedes Problem
Historische Trends und Muster

Der Bericht verwendet Farbcodierung zur Anzeige des Schweregrads: Rot für kritische Probleme, Gelb für Warnungen und Grün für einwandfreie Messwerte. Lesen Sie jeden Abschnitt, um Leistungsengpässe zu erkennen und die Optimierungsempfehlungen von PAL zu befolgen.

8. Alternativen SQL Server Überwachungstools

8.1 Eingebaut SQL Server Zubehör

8.1.1 SQL Server Activity Monitor

SQL Server Activity Monitor zeigt Echtzeitinformationen an über SQL Server Prozesse und Leistung:

Öffne SQL Server Management Studio (SSMS) und stellen Sie eine Verbindung zu Ihrer Serverinstanz her
Klicken Sie mit der rechten Maustaste auf den Servernamen im Objekt-Explorer
Wählen Sie Activity Monitor

Der Aktivitätsmonitor zeigt Prozesse, Ressourcenwartezeiten, Datendatei-E/A und aktuelle, aufwändige Abfragen an. Er bietet schnelle Einblicke in die aktuelle Datenbankaktivität, speichert jedoch keine historischen Daten.

8.1.2 SQL Server Trainings-Dashboard

SQL Server Management Studio enthält integrierte Leistungsberichte:

In SQL Server Management Studio (SSMS), klicken Sie mit der rechten Maustaste auf SQL Server Instanz im Objekt-Explorer
Wählen Sie Reports -> Standardberichte
Wählen Sie aus verfügbaren Berichten wie Trainings-Dashboard

Das Performance Dashboard bietet visuelle Einblicke in SQL Server Instanzleistung, einschließlich System-CPU-Auslastung, aktuell wartende Anfragen und Leistungsmetriken. Der Zugriff erfolgt über das Menü „Standardberichte“.

8.1.3 SQL Server Profiler

SQL Server Profiler erfasst und analysiert SQL Server Ereignisse wie Abfrageausführung, Transaktionsvorgänge und Anmeldeaktivitäten.

So starten SQL Server Profiler:

In SQL Server Management Studio, klicken Sie auf Zubehör -> SQL Server Profiler

Profiler verursacht einen erheblichen Leistungsverlust. Setzen Sie ihn daher mit Bedacht und vorzugsweise außerhalb der Spitzenzeiten ein. In den meisten Fällen bieten erweiterte Ereignisse eine bessere Leistung bei geringerer Belastung.

8.1.4 Erweiterte Ereignisse

Erweiterte Ereignisse ist ein leichtgewichtiges Leistungsüberwachungssystem, das in SQL ServerEs ersetzt SQL Server Profiler mit besserer Leistung und geringerem Overhead.

Die wichtigsten Merkmale sind:

Feingranulare Überwachung bestimmter Ereignisse
Minimale Auswirkungen auf die Leistung
Anpassbare Event-Sitzungen
Integration mit SSMS und anderen Tools
Unterstützung für komplexe Filterung und Aggregation

Erstellen Sie Extended Event-Sitzungen über SSMS:

In Objekt-Explorer, erweitern Sie Ihren Server und gehen Sie zu Verwaltung -> Erweiterte Ereignisse -> Sitzungen
Klicken Sie mit der rechten Maustaste auf Fachsitzungen und wählen Sie Assistent für neue Sitzungen
Folgen Sie den Anweisungen, um eine neue Sitzung zu starten.

8.1.5 Dynamische Verwaltungsansichten (DMVs)

DMVs stellen detaillierte Serverstatusinformationen bereit, um den Zustand zu überwachen, Probleme zu diagnostizieren und die Leistung zu optimieren. Zu den wichtigsten DMVs gehören:

sys.dm_exec_query_stats: Abfrageleistungsstatistiken
sys.dm_os_wait_stats: Wartetypen, die die Serverleistung beeinträchtigen
sys.dm_os_performance_counters: SQL Server Leistungsindikatordaten
sys.dm_exec_requests: Derzeit ausgeführte Anfragen
sys.dm_exec_sessions: Aktive Benutzersitzungen

Fragen Sie diese Ansichten mit T-SQL ab, um auf Leistungsdaten und historische Messwerte in Echtzeit zuzugreifen.

Grundlegende Verwendung

-- 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 Überwachungslösungen von Drittanbietern

Redgate SQL Monitor

Redgate SQL Monitor ist spezialisiert auf die Überwachung SQL Server und Azure SQL-Datenbankumgebungen. Es bietet unternehmensweite Überwachung, anpassbare Warnmeldungen und Dashboards, detaillierte Berichtsfunktionen und die Integration mit anderen Redgate-Tools.

SolarWinds SQL Server Überwachungstool

Die SolarWinds SQL Server Das Überwachungstool, auch bekannt als SQL Sentry, dient zur Diagnose, Lösung und Vorbeugung schwerwiegender Leistungsprobleme SQL Server.

IDERAs SQL Server Leistungsüberwachungstool

IDERA SQL Diagnostic Manager ist ein leistungsstarkes Tool SQL Server Leistungsüberwachungstool zur Unterstützung der proaktiven Leistungsüberwachung, Diagnose und Optimierung.

SQL-Überwachung des Anwendungsmanagers

Applications Manager bietet einen Microsoft SQL Server Überwachungstool, das nützliche IT-Lösungen bietet. Es wurde entwickelt, um die Leistung von SQL-Datenbanken zu überwachen und gleichzeitig Fehler zu identifizieren und Probleme zu lösen, die zu Betriebsunterbrechungen in einer Organisation führen könnten.

8.3 Open Source-Überwachungstools

DBA Dash

DBA Dash ist ein kostenloses Open-Source-Überwachungstool, das Einblicke in SQL Server Integrität, Leistung und Aktivität. Es ist besonders nützlich für kleine bis mittelgroße Umgebungen und umfasst tägliche DBA-Prüfungen, Leistungsüberwachung und Konfigurationsverfolgung.

SQLWATCH

SQLWATCH bietet dezentrale, nahezu Echtzeit SQL Server Überwachung mit 5-Sekunden-Granularität zur Erfassung von Workload-Spitzen. Es unterstützt Grafana für Echtzeit-Dashboards und Power BI für detaillierte Analysen. Das Tool bietet umfangreiche Konfigurationsmöglichkeiten, keinen Wartungsaufwand und unbegrenzte Skalierbarkeit.

Beobachter

Der von Stack Exchange entwickelte Opserver überwacht mehrere Systeme, darunter SQL Server, Redis und Elasticsearch. Es bietet eine Ansicht „alle Server“ für CPU-, Speicher-, Netzwerk- und Hardwarestatistiken in Ihrer gesamten Infrastruktur.

sp_WhoIsActive

sp_WhoIsActive ist eine umfassende gespeicherte Prozedur zur Aktivitätsüberwachung, die von Adam Machanic entwickelt wurde. Sie funktioniert mit allen SQL Server Versionen von 2005 bis zu aktuellen Versionen und wird häufig verwendet von SQL Server DBAs für die Echtzeit-Aktivitätsüberwachung.

Um sp_WhoIsActive zu verwenden, laden Sie es von http://whoisactive.com/ herunter, installieren Sie es in Ihrer Datenbank und führen Sie Folgendes aus:

EXEC sp_WhoIsActive

Das Verfahren zeigt aktuell ausgeführte Abfragen, Warteinformationen, Blockierungsdetails und Ressourcenverbrauch an.

9. Best Practices für SQL Server Performance Monitor

9.1 Festlegen von Leistungsbasislinien

Leistungsbasislinien legen normale Betriebsparameter für Ihr SQL Server Umgebung. Ohne Baselines können Sie nicht feststellen, ob aktuelle Messwerte auf Probleme hinweisen oder ein typisches Verhalten darstellen.

Erstellen Sie Baselines, indem Sie:

Erfassung von Leistungsdaten im Normalbetrieb für mindestens eine Woche
Erfassung von Kennzahlen sowohl während der Spitzenzeiten als auch außerhalb der Spitzenzeiten
Dokumentieren typischer Werte für Schlüsselzähler
Erfassung saisonaler Schwankungen, falls zutreffend
Speichern von Basisdaten zum Vergleich mit zukünftigen Messwerten

Aktualisieren Sie die Baselines vierteljährlich oder nach wesentlichen Infrastrukturänderungen, Anwendungsupdates oder Datenbankänderungen.

9.2 Festlegen geeigneter Warnschwellen

Konfigurieren Sie intelligente Schwellenwerte, um aussagekräftige Warnungen zu erhalten, ohne sich mit Benachrichtigungen zu überhäufen:

Ausstehende Speicherzuweisungen > 0 weisen auf Speicherdruck hin
Eine Prozessorwarteschlangenlänge von > 2 pro Kern deutet auf einen CPU-Engpass hin
Festplattensekunden/Lesen oder Schreiben > 20 ms weisen auf langsame E/A hin
Blockierte Prozesse > 5 signalisieren Konfliktprobleme
Eine Seitenlebenserwartung von < 300 Sekunden weist auf Speicherdruck hin

Passen Sie die Schwellenwerte basierend auf Ihren Basisdaten und spezifischen Workload-Eigenschaften an. Verwenden Sie adaptive Schwellenwerte, die normale Schwankungen in Ihrer Umgebung berücksichtigen.

9.3 Regelmäßige Datenüberprüfung und -analyse

Planen Sie regelmäßige Leistungsbeurteilungen ein, um Trends und neu auftretende Probleme zu erkennen:

Täglich: Überprüfen Sie wichtige Kennzahlen und aktuelle Warnmeldungen
Wöchentlich: Führen Sie eine eingehende Analyse der Leistungstrends durch
Monatlich: Erstellen Sie umfassende Berichte und vergleichen Sie diese mit Basiswerten
Vierteljährlich: Überprüfen Sie die Kapazitätsplanung und die langfristigen Trends

Dokumentieren Sie Ergebnisse und verfolgen Sie Leistungsverbesserungen im Laufe der Zeit.

9.4 Ausgleich des Überwachungsaufwands

Die Überwachung selbst verbraucht Ressourcen. Achten Sie daher auf ein Gleichgewicht zwischen der Datenerfassung und den Auswirkungen auf die Leistung:

Verwenden Sie Intervalle von 30 bis 60 Sekunden für eine kontinuierliche Überwachung
Verwenden Sie 15-Sekunden-Intervalle nur zur aktiven Fehlerbehebung
Begrenzen Sie die Dauer des Datensammler-Sets, um übermäßige Datenmengen zu vermeiden
Speichern Sie Protokolle auf separaten Laufwerken und Datenbankdateien
Archivieren Sie alte Leistungsdaten, um die Dateigröße überschaubar zu halten

Bei richtiger Konfiguration verursacht der Leistungsmonitor nur minimalen Mehraufwand, normalerweise weniger als 2 % der Systemressourcen.

9.5 Langfristige Datenaufbewahrung

Bewahren Sie Leistungsdaten für aussagekräftige Trendanalysen und Kapazitätsplanung auf:

Bewahren Sie Leistungsdaten mindestens 1–2 Jahre lang auf
Archivieren Sie die Daten nach 3–6 Monaten in einem separaten Speicher
Komprimieren Sie ältere Protokolldateien, um Speicherplatz zu sparen
Dokumentieren Sie alle wichtigen Ereignisse oder Änderungen, die sich auf die Leistung auswirken

Angesichts der relativ geringen Größe der Leistungsindikatordaten ist eine unbegrenzte Aufbewahrung oft sinnvoll und für eine langfristige Analyse wertvoll.

9.6 Integration mit DevOps-Praktiken

Integrieren Sie die Datenbankleistungsüberwachung in CI/CD-Pipelines:

Datenbankleistungsmetriken in die Bereitstellungsvalidierung einbeziehen
Automatisieren Sie Leistungstests für neue Versionen
Überprüfen Sie, ob Codeänderungen die Leistung nicht negativ beeinflussen.
Erstellen Sie Leistungsbenchmarks für jede Version
Integrieren Sie Überwachungswarnungen in Vorfallmanagementsysteme

10. Fehlerbehebung bei häufigen Leistungsproblemen

10.1 CPU-Engpässe identifizieren

CPU-Engpässe äußern sich in langsamen Abfrageantwortzeiten und hoher Prozessorauslastung. Gehen Sie wie folgt vor, um CPU-Probleme zu diagnostizieren:

Überprüfen Sie den Zähler für die Prozessorwarteschlangenlänge. Werte über 2 pro Kern weisen auf eine CPU-Auslastung hin.
Überprüfen Sie die Prozessorzeit in %. Dauerhafte Werte über 75 % deuten auf einen CPU-Engpass hin
Remotedesktop zum SQL Server
Öffnen Sie den Task-Manager (Strg+Umschalt+Esc).
Klicken Sie auf Prozesse Tab
Einblick in das Prozesse aller Benutzer anzeigen
Klicken Sie auf CPU Spaltenüberschrift zum Sortieren nach CPU-Auslastung
Identifizieren Sie, welche Prozesse CPU-Ressourcen verbrauchen

Wenn nichtSQL Server Anwendungen verbrauchen viel CPU. Entfernen Sie sie vom Datenbankserver. Wenn sqlservr.exe viel CPU-Leistung verbraucht, untersuchen Sie dies mit den folgenden Methoden:

Überprüfen Sie die SQL-Kompilierungen/s und die SQL-Neukompilierungen/s. Werte über 10 % der Batch-Anfragen/s weisen auf eine übermäßige Kompilierung hin.
Abfrage von sys.dm_exec_query_stats zur Identifizierung CPU-intensiver Abfragen
Überprüfen Sie Ausführungspläne auf fehlende Indizes oder ineffiziente Vorgänge
Erwägen Sie das Hinzufügen von Indizes, um Tabellenscans zu reduzieren

10.2 Diagnose von Speicherproblemen

Gedächtnisprobleme haben erhebliche Auswirkungen SQL Server Leistung. Diagnostizieren Sie Speicherprobleme anhand dieser Indikatoren:

Verfügbare Speicherabfälle

Wenn der verfügbare Speicherplatz dauerhaft unter 100 MB fällt, droht dem Betriebssystem Speichermangel. Windows kann dann möglicherweise Prozesse auslagern. SQL Server Speicher auf die Festplatte, was zu Leistungseinbußen führt.

Geringe Seitenlebenserwartung

Eine Seitenlebenserwartung von unter 300 Sekunden weist auf eine hohe Puffercache-Umschlagshäufigkeit hin. Dies deutet entweder auf eine unzureichende Speicherzuweisung oder eine übermäßige Speicherauslastung durch Abfragen hin.

Niedrige Puffer-Cache-Trefferquote

Eine Puffer-Cache-Trefferquote unter 99 % bedeutet SQL Server liest Daten häufig von der Festplatte statt vom Speicher. Dies tritt auf, wenn der Pufferpool zu klein ist oder SQL Server Der Aufwärmvorgang dauert nach dem Neustart noch an.

Speicherzuschüsse stehen aus

Jeder Wert über 0 für „Ausstehende Speicherzuweisungen“ weist darauf hin, dass Abfragen auf Speicherzuweisungen warten. Dies stellt einen kritischen Speichermangel dar, der sofortiges Eingreifen erfordert.

So beheben Sie Speicherprobleme:

Einrichtung SQL Server Maximale Speichereinstellung, um ausreichend RAM für das Betriebssystem übrig zu lassen (normalerweise 4–8 GB, abhängig von der Servergröße)
Aktivieren Sie die Berechtigung „Seiten im Speicher sperren“ für die SQL Server Dienstkonto
Fügen Sie dem Server mehr physischen RAM hinzu, wenn der Speicherdruck anhält
Speicherintensive Abfragen identifizieren und optimieren

10.3 Beheben von Festplatten-E/A-Problemen

Festplatten-E/A sind in Datenbanksystemen häufig der größte Leistungsengpass. Diagnostizieren Sie Festplattenprobleme mit den folgenden Methoden:

Hohe Warteschlangenlänge

Eine konstant über 2 (oder 2 pro Festplatte bei RAID) liegende Festplattenwarteschlangenlänge weist darauf hin, dass das Festplattensubsystem mit den E/A-Anforderungen nicht Schritt halten kann. Dies führt zu einem Rückstau an ausstehenden Vorgängen.

Übermäßige Festplattenlatenz

Werte über 10–20 ms für die durchschnittliche Lese- und Schreibgeschwindigkeit der Festplatte weisen auf eine langsame Festplattenreaktion hin. Transaktionsprotokolllaufwerke erfordern eine besonders schnelle Leistung, idealerweise unter 5 ms für Schreibvorgänge.

Hohe Festplattenzeit in %

Eine dauerhaft erhöhte Festplattenauslastung von über 85 % deutet auf eine Festplattenüberlastung hin. Die Festplatte verbringt den Großteil ihrer Zeit mit der Verarbeitung von E/A-Anforderungen, sodass kaum noch freie Kapazität verbleibt.

Bevor Sie sich mit Festplattenproblemen befassen, stellen Sie sicher, dass es sich nicht um Symptome von Speicherproblemen handelt. Unzureichender Speicher zwingt SQL Server um mehr Daten von der Festplatte zu lesen, wodurch die Festplattenmetriken künstlich aufgebläht werden.

So beheben Sie echte Festplatten-E/A-Probleme:

Upgrade auf schnellere Festplatten (SSDs statt HDDs)
Implementieren Sie RAID-Konfigurationen für eine bessere Leistung
Separate Datenbankdateien, Transaktionsprotokolle und Tempdb auf verschiedenen physischen Laufwerken
Fügen Sie mehr Speicher hinzu, um die Anzahl der Festplattenlesevorgänge zu reduzieren
Optimieren Sie Indizes, um unnötige E/A-Vorgänge zu reduzieren
Überprüfen und optimieren Sie Abfragen mit schlechter Leistung

10.4 Umgang mit Blockierungen und Deadlocks

Eine Blockierung tritt auf, wenn eine Sitzung Sperren aufweist, die die Fortsetzung anderer Sitzungen verhindern. Überwachen Sie diese Leistungsindikatoren, um Blockierungsprobleme zu identifizieren:

Blockierte Prozesse: Sollte idealerweise 0 sein
Sperrwartezeiten/Sek.: Anzahl der Sperranforderungen, die Wartezeiten erfordern
Durchschnittliche Wartezeit: Durchschnittliche Dauer der Sperrwartezeiten

So untersuchen Sie die Blockierung:

Öffnen Sie den Aktivitätsmonitor in SSMS
Erweitern Sie die Prozesse Abschnitt
Suchen Sie nach Prozessen mit einem Wert ungleich Null Blockiert von Werte
Identifizieren Sie die blockierende Sitzungs-ID
Überprüfen Sie die Abfragen, die die Blockierung verursachen

Verwenden Sie sp_WhoIsActive für eine detailliertere Blockierungsanalyse. Übermäßige wait_info-Einträge weisen häufig auf Tempdb-Konflikte oder Blockierungsprobleme hin.

So reduzieren Sie die Blockierung:

Minimieren Sie die Transaktionsdauer
Verwenden Sie geeignete Isolationsebenen
Hinzufügen von Indizes zur Reduzierung der Sperrdauer
Berücksichtigen Sie die READ_COMMITTED_SNAPSHOT-Isolierung
Überprüfen und optimieren Sie Abfragen mit langer Ausführungszeit

10.5 Probleme mit der Abfrageleistung

Die Identifizierung kostenintensiver Abfragen ist für die SQL-Leistungsüberwachung unerlässlich. Verwenden Sie diese Methoden, um problematische Abfragen zu finden:

Verwenden des Aktivitätsmonitors

Klicken Sie in SSMS mit der rechten Maustaste auf den Servernamen
Wählen Sie Activity Monitor
Erweitern Sie die Funktionalität der Aktuelle teure Anfragen
Überprüfen Sie Abfragen mit hoher CPU-Auslastung, Dauer oder logischen Lesevorgängen

DMVs verwenden

Fragen Sie sys.dm_exec_query_stats ab, um ressourcenintensive Abfragen zu identifizieren:

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

Ausführungspläne analysieren

Öffnen Sie in SSMS ein neues Abfragefenster
Gehen Sie auf Geschätzten Ausführungsplan anzeigen (Strg+L) oder Tatsächlichen Ausführungsplan einschließen (Strg+M)
Ausführen Ihrer Abfrage
Überprüfen Sie den Ausführungsplan auf teure Operationen
Achten Sie auf Tabellenscans, Indexscans oder kostenintensive Operationen.

Optimieren Sie Abfragen durch:

Hinzufügen geeigneter Indizes
Umschreiben von Abfragen, um teure Operationen zu vermeiden
Aktualisieren von Statistiken
Verwenden bestimmter Spaltennamen anstelle von SELECT *
Vermeidung unnötiger DISTINCT- oder ORDER BY-Klauseln

10.6 Beschädigte Datenbank erkennen und reparieren

Datenbankbeschädigungen können zu Leistungseinbußen, Datenverlust und Systemausfällen führen. Um die Integrität der Datenbank zu erhalten, ist es wichtig, Beschädigungen schnell zu erkennen und zu beheben.

Indikatoren für Datenbankbeschädigung

Achten Sie auf diese Anzeichen einer möglichen Korruption:

Fehlermeldungen in SQL Server Fehlerprotokoll (Fehler 823, 824 oder 825)
Unerwartete Anwendungsfehler beim Zugriff auf bestimmte Tabellen
Langsame Abfrageleistung bei zuvor schnellen Abfragen
SQL Server Abstürze oder unerwartete Neustarts
Verdächtige Seiten erscheinen in der Tabelle msdb.dbo.suspect_pages

Verwenden von DBCC CHECKDB zur Erkennung

DBCC-CHECKDB ist das wichtigste Tool zum Erkennen von Datenbankbeschädigungen. Führen Sie es regelmäßig aus, um Probleme frühzeitig zu erkennen.

Überwachung verdächtiger Seiten

SQL Server zeichnet verdächtige Seiten automatisch in der msdb-Datenbank auf:

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)

Alle zurückgegebenen Zeilen weisen auf Beschädigungsprobleme hin, die sofortiger Aufmerksamkeit bedürfen.

Strategien zur Korruptionsprävention

Aktivieren Sie die Seitenüberprüfung mit der Option CHECKSUM
Führen Sie regelmäßige Datenbanksicherungen durch
Verwenden Sie zuverlässige Hardware mit Fehlerkorrektur
Überwachen Sie den Festplattenzustand mit Herstellertools
Planen Sie regelmäßige DBCC CHECKDB-Läufe
Behalten SQL Server mit den neuesten Patches aktualisiert

Wiederherstellungs- und Reparaturoptionen

Wenn Beschädigungen erkannt werden, können Sie das integrierte Tool ausprobieren DBCC-CHECKDB um sie zu beheben. Wenn dies fehlschlägt, verwenden Sie Tools von Drittanbietern wie DataNumen SQL Recovery die mit schweren Beschädigungen umgehen kann.

11. Erweiterte Überwachungstechniken

11.1 Abfragespeicherüberwachung

Query Store, eingeführt in SQL Server 2016 erfasst automatisch Abfrageleistungsdaten. Es bietet wertvolle Einblicke in Abfrageverhalten, Ausführungspläne und Leistungstrends.

Aktivieren des Abfragespeichers

Klicken Sie im SSMS-Objekt-Explorer mit der rechten Maustaste auf eine Datenbank
Wählen Sie Eigenschaften im Vergleich
Klicken Sie auf Abfragespeicher Seite
In Betriebsmodus (angefordert)Wählen Lesen schreiben
Konfigurieren Sie bei Bedarf zusätzliche Einstellungen
Gehen Sie auf OK

Überwachung der Abfrageleistung

Greifen Sie über den Objekt-Explorer auf Abfragespeicherberichte zu:

Erweitern Sie die Datenbank im Objekt-Explorer
Erweitern Sie die Funktionalität der Abfragespeicher
Wählen Sie aus den verfügbaren Berichten:
- Regressierte Abfragen
- Gesamtressourcenverbrauch
- Abfragen mit dem höchsten Ressourcenverbrauch
- Abfragen mit erzwungenen Plänen
- Verfolgte Abfragen

Planen Sie die Regressionserkennung

Der Abfragespeicher erkennt automatisch, wenn sich Abfrageausführungspläne ändern und die Leistung nachlässt. Überprüfen Sie den Bericht „Regressed Queries“, um Abfragen zu identifizieren, die von Planänderungen betroffen sind.

Erzwungenes Planmanagement

Wenn Query Store einen besseren Ausführungsplan identifiziert, erzwingen SQL Server So verwenden Sie es:

Öffnen Sie die Abfrage im Abfragespeicher
Klicken Sie mit der rechten Maustaste auf den gewünschten Plan
Wählen Sie Truppenplan

Dies verbessert die Leistung sofort, ohne dass Codeänderungen erforderlich sind.

11.2 Überwachung der Indexwartung

Die Indexfragmentierung beeinträchtigt mit der Zeit die Abfrageleistung. Überwachen und warten Sie die Indizes regelmäßig, um eine optimale Leistung sicherzustellen.

Fragmentierungsprüfung

Verwenden Sie diese Abfrage, um die Indexfragmentierung zu überprüfen:

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

Führen Sie diese Abfrage außerhalb der Spitzenzeiten aus, da sie ressourcenintensiv sein kann.

Seitendichteanalyse

Die Seitendichte gibt an, wie voll die Indexseiten sind. Eine niedrige Dichte verschwendet Speicherplatz und verringert die Leistung:

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

Entscheidungen zur Reorganisation vs. zum Wiederaufbau

Wählen Sie Indexwartungsvorgänge basierend auf Fragmentierungsstufen aus:

Fragmentierung 10-30 %: Verwenden Sie ALTER INDEX REORGANIZE
Fragmentierung > 30 %: Verwenden Sie ALTER INDEX REBUILD
Fragmentierung < 10 %: Keine Aktion erforderlich

Reorganisationsvorgänge erfordern weniger Ressourcen und können online ausgeführt werden. Wiederherstellungsvorgänge sind gründlicher, verbrauchen jedoch erhebliche Ressourcen.

11.3 Aktualisierungen der Datenbankstatistik

Hilfe zur Datenbankstatistik SQL ServerDer Abfrageoptimierer von erstellt effiziente Ausführungspläne. Veraltete Statistiken führen zu einer schlechten Abfrageleistung.

Automatischer Statistikneuaufbau

Aktivieren Sie automatische Statistikaktualisierungen:

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

Überwachung der Statistikintegrität

Prüfen Sie, wann die Statistiken zuletzt aktualisiert wurden:

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

Aktualisieren Sie die Statistiken bei Bedarf manuell:

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 Erfassen benutzerdefinierter Leistungsdaten

Erstellen Sie benutzerdefinierte Lösungen zur Leistungsüberwachung, indem Sie sys.dm_os_performance_counters direkt abfragen und die Ergebnisse in Tabellen speichern.

Erstellen benutzerdefinierter Sammlungsskripte

Erstellen Sie eine gespeicherte Prozedur zum Erfassen von Leistungsindikatordaten:

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

Verwenden von sys.dm_os_performance_counters

Leistungsindikatoren direkt abfragen:

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

Speichern historischer Daten

Erstellen Sie eine Tabelle zum Speichern von Leistungsmetriken im Zeitverlauf:

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

Pivot-Datenspeichermethoden

Speichern Sie Daten im Pivot-Format mit einer Zeile pro Abtastzeit und einer Spalte pro Zähler. Dies reduziert den Speicherplatz und verbessert die Abfrageleistung im Vergleich zur Speicherung einer Zeile pro Zähler pro Abtastung.

11.5 Multi-Server-Überwachung

Für Umgebungen mit mehreren SQL Server Instanzen, implementieren Sie eine zentrale Überwachung.

Zentralisierter Überwachungsansatz

Erstellen Sie eine dedizierte Überwachungsdatenbank auf einem separaten Server
Sammeln Sie Daten von allen Servern im zentralen Repository
Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, SQL Server Agentenjobs zum Ausführen von Sammlungsskripten
Implementieren einer netzwerkzugänglichen Leistungsindikatorsammlung

Remote-Serverüberwachung

Konfigurieren Sie den Leistungsmonitor so, dass Daten von Remoteservern erfasst werden. Geben Sie beim Hinzufügen von Leistungsindikatoren die Servernamen an. Stellen Sie sicher, dass die Firewall-Regeln den Datenverkehr des Leistungsmonitors zulassen.

Serverübergreifende Berichterstattung

Erstellen Sie Berichte, die die Leistung mehrerer Server vergleichen, um Ausreißer und Kapazitätsungleichgewichte zu identifizieren.

12. Überwachung SQL Server in Cloud-Umgebungen

12.1 Azure SQL-Datenbanküberwachung

Azure SQL-Datenbank bietet integrierte Überwachungsfunktionen, die sich von lokalen unterscheiden SQL Server.

Azure Monitor-Integration

Azure Monitor sammelt automatisch Metriken aus der Azure SQL-Datenbank, darunter:

DTU- oder vCore-Auslastung
Speicherbelegung
Verbindungsstatistiken
Deadlocks und Timeouts

Greifen Sie über das Azure-Portal oder die Azure Monitor-API auf diese Metriken zu.

Integrierte Überwachungsfunktionen

Azure SQL-Datenbank umfasst:

Automatische Optimierungsempfehlungen
Einblicke in die Abfrageleistung
Intelligent Insights zur Anomalieerkennung
Integrierte Warn- und Diagnosefunktionen

Einblicke in die Abfrageleistung

Diese Funktion bietet eine Visualisierung der ressourcenintensivsten Abfragen, eine Analyse der Abfragedauer und historische Leistungstrends. Sie können über das Azure-Portal unter Ihrer SQL-Datenbankressource darauf zugreifen.

12.2 Cloud-native Überwachungstools

Cloud-Plattformen bieten native Überwachungslösungen, die für ihre Umgebungen optimiert sind:

Azure Monitor und Application Insights für Azure SQL-Datenbank
AWS CloudWatch für RDS SQL Server
Google Cloud Monitoring für die Cloud SQL Server

Diese Tools lassen sich nahtlos in die Cloud-Infrastruktur integrieren und bieten eine einheitliche Überwachung aller Cloud-Ressourcen.

Hybride Umgebungsüberwachung

Verwenden Sie für hybride Bereitstellungen vor Ort und in der Cloud Tools, die beide Umgebungen unterstützen, wie Redgate SQL Monitor, SolarWinds DPA oder benutzerdefinierte Lösungen mit zentraler Datenerfassung.

12.3 Leistungsunterschiede in der Cloud

Wolke SQL Server Umgebungen haben einzigartige Eigenschaften:

Ressourcenzuteilungsmodelle

Cloud-Anbieter verwenden unterschiedliche Methoden zur Ressourcenzuweisung (DTUs, virtuelle Kerne, serverlos), die sich auf die Interpretation von Leistungsmetriken auswirken. Machen Sie sich mit den Einschränkungen und Merkmalen Ihrer Serviceebene vertraut.

Überlegungen zur Skalierung

Cloud-Umgebungen bieten dynamische Skalierungsmöglichkeiten. Überwachen Sie die Ressourcenauslastung, um zu bestimmen, wann eine Skalierung erforderlich ist. Viele Cloud-Plattformen bieten eine automatische Skalierung basierend auf Leistungsschwellenwerten.

13. Automatisierung der Leistungsüberwachung

13.1 SQL Server Agentenjobs

Automatisieren Sie die Datenerfassung mit SQL Server Agentenjobs für eine konsistente Überwachung ohne manuelle Eingriffe.

Geplante Datenerfassung

Erweitern Sie in SSMS SQL Server Makler
Der rechten Maustaste auf Jobs gedrückt und wählen Sie Neuer Job
Benennen Sie den Job (z. B. „Leistungskennzahlen erfassen“)
Gehen Sie auf Shritte und fügen Sie einen neuen Schritt hinzu
Setzen Sie den Typ auf Transact-SQL-Skript
Geben Sie Ihr Datenerfassungsskript ein
Gehen Sie auf Zeitpläne und fügen Sie einen Zeitplan hinzu
Konfigurieren Sie die Häufigkeit (z. B. alle 5 Minuten).
Gehen Sie auf OK den Job zu schaffen

Automatisiertes Reporting

Erstellen Sie Jobs, die Leistungsberichte generieren und per E-Mail versenden:

Erstellen einer gespeicherten Prozedur zum Generieren von Berichten
Verwenden Sie Datenbank-E-Mail, um Berichte per E-Mail zu senden
Planen Sie die Ausführung des Jobs täglich oder wöchentlich

13.2 PowerShell-Automatisierung

PowerShell bietet leistungsstarke Automatisierungsfunktionen für SQL Server Leistungsmonitor.

Skripts zur Leistungsindikatorensammlung

$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-Abfragen

Verwenden Sie WMI, um Leistungsdaten von Remoteservern zu sammeln:

$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"

Automatische Alarmierung

Erstellen Sie PowerShell-Skripts, die Metriken überprüfen und Warnungen senden, wenn Schwellenwerte überschritten werden:

$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 Erstellen von Überwachungs-Dashboards

Visualisieren Sie Leistungsdaten mit interaktiven Dashboards für bessere Einblicke.

Power BI-Integration

Verbinden Sie Power BI mit Ihren Leistungsdatentabellen
Erstellen Sie Visualisierungen für wichtige Kennzahlen
Slicer für Zeitbereich und Serverauswahl hinzufügen
Veröffentlichen von Dashboards im Power BI-Dienst
Konfigurieren automatischer Aktualisierungszeitpläne

Dashboard-Erstellung in Echtzeit

Verwenden Sie Tools wie Grafana oder benutzerdefinierte Webanwendungen, um Echtzeit-Dashboards zu erstellen, die DMVs und Leistungsindikatoren direkt abfragen.

Visualisierung historischer Trends

Erstellen Sie Liniendiagramme, die Trends im Zeitverlauf zeigen für:

CPU-Auslastung
Speichernutzung
Datenträger-E / A
Leistung abfragen
Verbindungsanzahl

14. Fallstudien und Praxisbeispiele

14.1 Fallstudie: Behebung von Speicherproblemen

Symptomidentifizierung

Eine Produktion SQL Server Während der Spitzenzeiten kam es zu langsamen Antwortzeiten bei Abfragen. Benutzer beschwerten sich über Anwendungstimeouts und Leistungseinbußen.

Gegenanalyse

Die Daten des Performance Monitors ergaben:

Die Lebenserwartung der Seite wurde auf 50 Sekunden gesenkt (normal: >300)
Die Trefferquote des Puffer-Cache fiel auf 85 % (normal: >99 %)
Memory Grants Pending zeigte häufig Werte von 5-10
Die Anzahl der physischen Festplattenlesevorgänge/s stieg deutlich an

Lösungsschritte

geprüft SQL Server Maximale Speichereinstellung – festgestellt, dass sie auf den Standardwert (unbegrenzt) eingestellt war
Vergleich des gesamten Serverspeichers mit dem Zielserverspeicher – zeigte eine signifikante Diskrepanz.
Maximalen Serverspeicher so konfiguriert, dass 8 GB für das Betriebssystem übrig bleiben
Aktivierte Berechtigung „Seiten im Speicher sperren“ für SQL Server Dienstkonto
Dem Server wurden 32 GB zusätzlicher RAM hinzugefügt
Überwachte Leistung für eine Woche – Die Lebenserwartung der Seite stabilisierte sich bei über 500 Sekunden

Ergebnis: Die Antwortzeiten auf Abfragen verbesserten sich um 60 %, es gab keine Benutzerbeschwerden mehr und die Anwendungsleistung normalisierte sich wieder.

14.2 Fallstudie: CPU-Leistungsoptimierung

Symptomidentifizierung

A SQL Server Während der Geschäftszeiten wurde durchgängig eine CPU-Auslastung von über 90 % festgestellt, was zu einer langsamen Anwendungsleistung und Frustration bei den Benutzern führte.

Gegenanalyse

Die Leistungsüberwachung ergab:

% Prozessorzeit durchschnittlich 92 % mit häufigen Spitzen auf 100 %
Prozessorwarteschlangenlänge konstant über 4 (Server hatte 8 Kerne)
SQL-Kompilierungen/s betrugen 25 % der Batch-Anfragen/s (sollten <10 % sein)
SQL-Neukompilierungen/s betrugen 15 % der Batch-Anfragen/s

Lösungsschritte

Verwendete DMVs zum Identifizieren der CPU-intensivsten Abfragen
Analysierte Ausführungspläne für identifizierte Abfragen
Mehrere Tabellenscans bei großen Tabellen aufgrund fehlender Indizes entdeckt
Erstellen Sie geeignete Indizes basierend auf den Empfehlungen des Ausführungsplans
Dynamisches SQL identifiziert, das übermäßige Kompilierungen verursacht
Modifizierter Anwendungscode zur Verwendung parametrisierter Abfragen
Implementierter Planleitfaden für problematische gespeicherte Prozeduren
Aktualisierte Statistiken zu stark genutzten Tabellen

Ergebnis: Die CPU-Auslastung sank während der Geschäftszeiten auf durchschnittlich 45 %. Die Ausführungszeiten von Abfragen verbesserten sich um 70 %. Die Reaktionsfähigkeit der Anwendung wurde deutlich verbessert.

14.3 Fallstudie: Lösung des Festplatten-E/A-Engpasses

Symptomidentifizierung

Benutzer berichteten von einer extrem langsamen Anwendungsreaktion während Datenladevorgängen und der abendlichen Stapelverarbeitung.

Gegenanalyse

Die Leistungsdaten zeigten:

Durchschnittliche Datenträgersekunde/Schreibvorgang hat auf dem Transaktionsprotokolllaufwerk 45 ms überschritten
Die durchschnittliche Länge der Datenträgerwarteschlange beträgt 12 auf dem Datendateilaufwerk
% Disk Time blieb während Batch-Jobs stundenlang über 95 %
Seitenschreibvorgänge/Sek. waren außergewöhnlich hoch

Lösungsschritte

Überprüfte Speichereinstellungen waren angemessen – keine Speicherprobleme gefunden
Analysierte Festplattenkonfiguration – alle Dateien auf demselben Spindelsatz entdeckt
Getrennte Transaktionsprotokolle auf dedizierten schnellen SSD-Laufwerken
Tempdb auf separate SSD-Laufwerke verschoben
Mehrere Tempdb-Datendateien implementiert (eine pro Kern)
Datendateilaufwerke auf RAID 10 SSD-Konfiguration aktualisiert
Optimierte Batch-Jobs zur Verwendung kleinerer Transaktionsstapel
Indizes hinzugefügt, um unnötige Tabellenscans während Batch-Operationen zu reduzieren

Ergebnis: Durchschnittliche Festplattensekunde/Schreibvorgang auf 3 ms gesunken. Durchschnittliche Festplattenwarteschlangenlänge unter 1. Fertigstellungszeit für Stapeljobs um 75 % reduziert.

15. Zukünftige Trends in SQL Server Überwachung

15.1 Integration von KI und maschinellem Lernen

Künstliche Intelligenz und maschinelles Lernen verändern SQL Server Leistungsmonitor.

Prädiktive Analytik

Modelle des maschinellen Lernens prognostizieren den zukünftigen Ressourcenbedarf auf Grundlage historischer Daten. Diese Systeme können Folgendes prognostizieren:

Wenn die Speicherkapazität erschöpft ist
Erwarteter CPU- und Speicherbedarf während Spitzenzeiten
Leistungseinbußen bei Abfragen, bevor sie sich auf Benutzer auswirken
Optimale Zeitpunkte für Wartungsarbeiten

Anomaly Detection

KI-gesteuerte Tools erkennen automatisch ungewöhnliche Muster in Leistungskennzahlen. Sie identifizieren Anomalien, die menschlichen Administratoren möglicherweise entgehen, und unterscheiden zwischen normalen Abweichungen und echten Problemen.

Automatisierte Behebung

Selbstheilende Systeme beheben häufig auftretende Probleme automatisch, wenn sie erkannt werden:

Starten Sie die beendeten Dienste neu.
Ressourcen bei Spitzenlast neu verteilen
Hotfixes für bekannte Probleme anwenden
Fragmentierte Indizes automatisch neu erstellen

15.2 Entwicklung der Cloud-basierten Überwachung

Die Cloud-Überwachung entwickelt sich ständig weiter und bietet neue Funktionen.

Einheitliche Überwachungsplattformen

Moderne Plattformen bieten eine zentrale Übersicht über:

Auf dem Gelände SQL Server Instanzen
Cloud-basierte Datenbanken
Hybride Umgebungen
Anwendungsleistung
Infrastrukturmetriken

Observability-Trends

Der Wechsel von der Überwachung zur Beobachtbarkeit betont:

Verstehen des Systemverhaltens anhand der Ausgaben
Korrelieren von Metriken, Protokollen und Traces
Tiefe Einblicke in verteilte Systeme
Problemdiagnose in Echtzeit

15.3 Selbstheilende Datenbanksysteme

Future SQL Server Versionen werden mehr autonome Fähigkeiten beinhalten.

Automatische Optimierung

Datenbanken optimieren sich kontinuierlich selbst durch:

Automatisches Erstellen und Löschen von Indizes basierend auf der Arbeitslast
Anpassen der Konfigurationseinstellungen für optimale Leistung
Transparentes Umschreiben ineffizienter Abfragen
Dynamische Verwaltung der Ressourcenzuweisung

Intelligentes Tuning

Fortschrittliche Systeme lernen aus Leistungsmustern und wenden Optimierungsempfehlungen automatisch an, wodurch die Notwendigkeit manueller DBA-Eingriffe reduziert wird.

16. Schlussfolgerung und wichtige Erkenntnisse

16.1 Zusammenfassung der wesentlichen Überwachungspraktiken

Effektiv SQL Server Die Leistungsüberwachung erfordert einen umfassenden Ansatz, der Tools, Techniken und bewährte Methoden kombiniert.

Zusammenfassung der kritischen Zähler

Konzentrieren Sie Ihre Überwachungsbemühungen auf diese wesentlichen Indikatoren:

Speicher: Lebenserwartung der Seite, Trefferquote im Puffercache, ausstehende Speicherzuweisungen
CPU: % Prozessorzeit, Prozessorwarteschlangenlänge
Festplatte: Durchschnittliche Festplattensekunde/Lesen und Schreiben, Festplattenwarteschlangenlänge
SQL Server: Batch-Anfragen/Sek., Kompilierungen/Sek., Benutzerverbindungen

Best Practice-Zusammenfassung

Legen Sie Baselines während des Normalbetriebs fest
Legen Sie intelligente Alarmschwellenwerte basierend auf Basiswerten fest
Überprüfen Sie regelmäßig die Leistungsdaten
Gleichen Sie den Überwachungsaufwand mit der Datengranularität aus
Bewahren Sie Langzeitdaten für Trendanalysen auf
Verwenden Sie für jedes Überwachungsszenario geeignete Tools

16.2 Kontinuierlicher Verbesserungsansatz

SQL Server Die Leistungsüberwachung ist keine einmalige Aktivität, sondern ein fortlaufender Prozess, der kontinuierlicher Verbesserung bedarf.

Regelmäßige Überprüfungszyklen

Täglich: Überprüfen Sie Warnungen und aktuelle Leistung
Wöchentlich: Trends überprüfen und aufkommende Probleme identifizieren
Monatlich: Analysieren Sie langfristige Muster und Kapazitätsbedarf
Vierteljährlich: Basiswerte aktualisieren und Überwachungswirksamkeit überprüfen

Mit Tools auf dem Laufenden bleiben

Halten Sie Überwachungstools und -techniken auf dem neuesten Stand:

Evaluieren Sie neue Überwachungsfunktionen in SQL Server Aktuelles
Testen Sie neue Tools von Drittanbietern
Nehmen Sie an Schulungen und Konferenzen teil
Teilnahme an SQL Server Gemeinschaftsforen
Teilen Sie Wissen mit Teammitgliedern

16.3 nächste Schritte

Implementierung SQL Server Leistungsüberwachung systematisch:

Umsetzungsfahrplan

Woche 1: Richten Sie den Leistungsmonitor mit wichtigen Leistungsindikatoren ein
Woche 2: Erstellen Sie Datensammlungssätze für die automatisierte Erfassung
Woche 3: Legen Sie Baselines während des Normalbetriebs fest
Woche 4: Konfigurieren Sie Warnungen für kritische Schwellenwerte
Monat 2: Implementieren Sie zusätzliche Überwachungstools (DMVs, Extended Events)
Monat 3: Entwickeln Sie benutzerdefinierte Dashboards und Berichte
Laufend: Verfeinern Sie die Überwachung basierend auf Erfahrungen und sich ändernden Anforderungen

Weitere Informationen

Erfahren Sie weiter darüber SQL Server Leistungsüberwachung durch Microsoft-Dokumentation, Community-Blogs und praktische Übungen. Experimentieren Sie mit verschiedenen Tools und Techniken, um herauszufinden, was für Ihre Umgebung am besten geeignet ist.

17. Häufig gestellte Fragen (FAQ)

17.1 Was sind die wichtigsten? SQL Server Zu überwachende Leistungsindikatoren?

Die kritischste SQL Server Zu den Leistungsindikatoren gehören:

Speicher: Seitenlebenserwartung (sollte >300 Sekunden sein) und Puffer-Cache-Trefferquote (sollte >99 %) sein
CPU: % Prozessorzeit (dauerhafte Werte <75 %) und Prozessorwarteschlangenlänge (sollte <2 pro Kern sein)
Festplatte: Durchschnittliche Festplattensekunde/Lesen und Schreiben (sollte <10–20 ms sein) und Festplattenwarteschlangenlänge (sollte <2 pro Festplatte sein)
SQL Server: Batch-Anfragen/Sek., SQL-Kompilierungen/Sek. und ausstehende Speicherzuweisungen (sollte 0 sein)

Diese Zähler bieten umfassende Einblicke in den Systemzustand und helfen dabei, Engpässe schnell zu erkennen.

17.2 Wie oft sollte ich Leistungsdaten erfassen?

Die Erfassungshäufigkeit hängt von Ihren Überwachungszielen ab:

Basislinienüberwachung: Alle 1 Minute (60 Sekunden)
Aktive Fehlerbehebung: Alle 15–30 Sekunden für kurze Zeit
Langzeittrends: Alle 5 Minuten

Vermeiden Sie die kontinuierliche Ausführung hochfrequenter Datenerfassungen, da dies die Leistung beeinträchtigen und zu viele Daten generieren kann. Verwenden Sie längere Intervalle für die Routineüberwachung und kürzere Intervalle nur bei der Untersuchung spezifischer Probleme.

17.3 Was ist der Unterschied zwischen Performance Monitor und SQL Server Profiler?

Performance Monitor und SQL Server Profiler dienen verschiedenen Zwecken:

Performance Monitor:

Überwacht das System und SQL Server Leistungsindikatoren
Verfolgt die Ressourcenauslastung (CPU, Speicher, Festplatte)
Geringer Overhead, geeignet für kontinuierliche Überwachung
Bietet aggregierte Metriken im Zeitverlauf

SQL Server Profiler:

Spuren individuell SQL Server Ereignisse und Abfragen
Erfasst detaillierte Informationen zur Abfrageausführung
Höherer Overhead, nicht für den Dauereinsatz empfohlen
Am besten geeignet für die Behebung spezifischer Abfrageprobleme
Veraltet zugunsten von Extended Events

Verwenden Sie den Leistungsmonitor für die allgemeine Systemüberwachung und Extended Events (nicht Profiler) für eine detaillierte Analyse auf Abfrageebene.

17.4 Kann der Performance Monitor Auswirkungen haben? SQL Server Performance?

Bei richtiger Konfiguration hat der Performance Monitor nur minimale Auswirkungen auf SQL Server Leistung, typischerweise weniger als 2 % Overhead. Übermäßige Überwachung kann jedoch Probleme verursachen:

Zu viele Zähler erhöhen den Overhead
Sehr kurze Abtastintervalle (unter 15 Sekunden) belasten die Ressourcen
Kontinuierliche Hochfrequenzerfassung erzeugt große Protokolldateien

So minimieren Sie die Auswirkungen:

Überwachen Sie nur die erforderlichen Zähler
Verwenden Sie geeignete Probenahmeintervalle (60 Sekunden für die Routineüberwachung).
Speichern Sie Protokolle auf Laufwerken getrennt von Datenbankdateien
Planen Sie ressourcenintensive Überwachungen außerhalb der Spitzenzeiten

17.5 Wie lange sollte ich Leistungsüberwachungsdaten aufbewahren?

Die Aufbewahrung hängt von Ihren Analyseanforderungen und der Speicherkapazität ab:

Minimum: 3 Monate für die Behebung aktueller Probleme
Empfohlen: 1–2 Jahre für Kapazitätsplanung und Trendanalyse
Am besten: Unbegrenzt, sofern die Speicherkapazität es zulässt, da historische Daten mit der Zeit wertvoller werden

Leistungsindikatordaten lassen sich gut komprimieren und benötigen relativ wenig Speicherplatz. Erwägen Sie, ältere Daten auf einem separaten Speicher zu archivieren, anstatt sie zu löschen. Viele Unternehmen sind der Meinung, dass jahrelange historische Daten für die Kapazitätsplanung und die Erkennung langfristiger Trends von unschätzbarem Wert sind.

17.6 Was sind gute Schwellenwerte für wichtige Leistungsindikatoren?

Empfohlene Schwellenwerte für die Alarmierung:

Ausstehende Speicherzuweisungen: Alarm, wenn > 0
Lebenserwartung der Seite: Alarm bei < 300 Sekunden
% Prozessorzeit: Alarm, wenn > 80 % für 5 Minuten
Länge der Prozessorwarteschlange: Warnung, wenn > 2 pro Kern
Durchschnittliche Festplattensekunde/Lesen oder Schreiben: Alarm bei > 20 ms
Länge der Datenträgerwarteschlange: Warnmeldung, wenn > 2 pro Datenträger
Blockierte Prozesse: Alarm, wenn > 5

Passen Sie diese Schwellenwerte basierend auf Ihren Basisdaten und spezifischen Workload-Eigenschaften an. Was in einer Umgebung normal ist, kann in einer anderen auf Probleme hinweisen.

17.7 Wie überwache ich SQL Server Leistung aus der Ferne?

Monitor-Fernbedienung SQL Server Instanzen mit diesen Methoden:

Performance Monitor: Geben Sie beim Hinzufügen von Zählern den Namen des Remotecomputers an
Power Shell: Verwenden des Parameters „-ComputerName“ mit „Get-Counter“
DMVs: Stellen Sie über SSMS eine Verbindung zu Remoteservern her und fragen Sie DMVs ab
Tools von Drittanbietern: Die meisten Überwachungstools unterstützen die Fernüberwachung von Servern.

Stellen Sie sicher, dass die Firewall-Regeln den Datenverkehr des Performance Monitors zulassen und dass Sie über die entsprechenden Berechtigungen auf dem Remote-Server verfügen. Bei mehreren Servern empfiehlt sich die Implementierung einer zentralen Überwachung mit einem dedizierten Überwachungsserver und einer Datenbank.

17.8 Was ist das beste kostenlose Tool für SQL Server Leistungsmonitor?

Für die Überwachung stehen mehrere hervorragende kostenlose Tools zur Verfügung SQL Server Performance:

Windows-Leistungsmonitor: Integriert, umfassend und zuverlässig
SSMS-Aktivitätsmonitor: Echtzeitüberwachung ohne zusätzliche Installation
Erweiterte Ereignisse: Leichte Ereignisüberwachung integriert in SQL Server
sp_WhoIsActive: Beliebte kostenlose gespeicherte Prozedur zur detaillierten Aktivitätsüberwachung
DBA Dash: Open-Source-Monitoring-Tool mit umfassenden Funktionen
SQLWATCH: Open Source mit Überwachungsfunktionen nahezu in Echtzeit

Für die meisten Organisationen bietet Performance Monitor in Kombination mit SSMS-Tools und sp_WhoIsActive hervorragende Überwachungsmöglichkeiten ohne zusätzliche Kosten.

17.9 Wie exportiere ich PerfMon-Daten zur Analyse?

Exportieren Sie Performance Monitor-Daten mit diesen Methoden:

Exportieren in CSV:

Öffnen Sie den Leistungsmonitor mit geladener Protokolldatei
Klicken Sie mit der rechten Maustaste auf das Diagramm und wählen Sie Daten speichern unter
Wählen Textdatei (durch Kommas getrennt) (.csv)
Standort auswählen und speichern
Zur Analyse in Excel öffnen

Verwenden Sie den Relog-Befehl:

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

Dieses Befehlszeilenprogramm konvertiert binäre Protokolldateien (.blg) in das CSV-Format, um die Analyse in Tabellenkalkulationsanwendungen zu erleichtern.

17.10 Wann sollte ich Überwachungstools von Drittanbietern anstelle integrierter Optionen verwenden?

Ziehen Sie Tools von Drittanbietern in Betracht, wenn:

Verwaltung einer großen Anzahl von SQL Server Instanzen (10+)
Erfordert eine zentrale Überwachung über mehrere Rechenzentren hinweg
Benötigen Sie erweiterte Funktionen wie prädiktive Analysen oder Anomalieerkennung?
Wunsch nach integrierter Alarmierung mit Incident-Management-Systemen
Compliance-Berichte und historische Analysen erforderlich
Fehlende DBA-Ressourcen zum Erstellen und Warten benutzerdefinierter Lösungen
Überwachung heterogener Datenbankumgebungen (SQL Server(Oracle, MySQL usw.)

Integrierte Tools eignen sich gut für kleinere Umgebungen oder wenn Sie über erfahrene Datenbankadministratoren verfügen, die benutzerdefinierte Überwachungslösungen entwickeln können. Tools von Drittanbietern bieten Mehrwert durch Zeitersparnis, erweiterte Funktionen und professionellen Support.

18. Zusätzliche Ressourcen

18.1 Offizielle Dokumentation

Microsoft bietet umfangreiche Dokumentation für SQL Server Leistungsmonitor:

SQL Server Dokumentation zum Performance Monitor: https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
Dynamische Verwaltungsansichten: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
Erweiterte Ereignisse: https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
Abfragespeicher: https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
Leistungsoptimierung und -überwachung: https://learn.microsoft.com/en-us/sql/relational-databases/performance/

18.2 Empfohlene Tools und Downloads

Wichtige Tools für SQL Server Leistungsmonitor:

PAL-Tool: https://github.com/clinthuffman/PAL
sp_WhoIsActive: http://whoisactive.com/
DBA Dash: https://dbadash.com/
SQLWATCH: https://github.com/marcingminski/sqlwatch
Ersthelfer-Kit (Brent Ozar): https://www.brentozar.com/first-aid/
SQL Server Managementstudio: https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 Community-Ressourcen

Lernen Sie aus dem SQL Server Gemeinschaft:

SQL Server Central: https://www.sqlservercentral.com/
Brent Ozar Blog: https://www.brentozar.com/blog/
SQL Shack: https://www.sqlshack.com/
MSSQL-Tipps: https://www.mssqltips.com/
Reddit r/SQLServer: https://www.reddit.com/r/SQLServer/
Stapelüberlauf SQL Server tag: https://stackoverflow.com/questions/tagged/sql-server

Diese Ressourcen bieten Tutorials, Tipps zur Fehlerbehebung und Best Practices von erfahrenen SQL Server Fachleute. Durch die Teilnahme an Community-Foren können Sie von den Erfahrungen anderer lernen und Ihr eigenes Wissen teilen.

Über den Autor

Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.

Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung Hochverfügbarkeitslösungenund Leistungsoptimierung. Seine umfassende praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung Always On-Verfügbarkeitsgruppenund die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Systeme.

Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.

Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.