Überwachen Sie ganz einfach die SQL Server-Aktivität. Wer ist aktiv? Verwenden des SQL Server-Aktivitätsmonitors Überwachen der Leistung des MS SQL-Servers

Dabei handelt es sich um ein Softwareprodukt von Sybase, das in Verbindung mit SQL Server arbeitet und vielfältige Informationen zur Serverleistung in grafischer Form bereitstellt. Diese Informationen sind äußerst nützlich bei der Analyse der Gründe für den Leistungsabfall.

Version 11.0.1 verfügt über eine Reihe neuer wichtiger Funktionen, die die neue Version deutlich von allen vorherigen unterscheiden. 11.0.1 kann mit jeder Version von SQL Server von 4.9.2 bis System 11 verwendet werden.

Einige der interessantesten Arten von Informationen über die Nutzungsmuster von Datenbankobjekten und die Interaktion des Servers mit dem Netzwerk werden jedoch nur bei der Überwachung von SQL Server System 10 und System 11 bereitgestellt. Daten über die Leistung benannter Cache-Puffer sind natürlich vorhanden Wird nur zur Überwachung der Leistung von SQL Server System 11 bereitgestellt.

Aus Kompatibilitätsgründen mit früheren Versionen unterstützt 11.0.1 auch einen Modus zur Ausgabe statistischer Informationen über die Serverleistung in Dateien, die für spätere Vergleiche und Analysen verwendet werden können. Diese Funktion ist in der Praxis sehr nützlich, ihre Verwendung erschwert jedoch den Installationsprozess.

besteht aus zwei Komponenten: einem Servermodul, das auf demselben Computer wie SQL Server ausgeführt wird, um Zugriff auf den gemeinsam genutzten Speicherbereich des Servers zu ermöglichen, und einem Clientmodul, das auf jedem Computer ausgeführt werden kann. Die Hauptaufgabe des Client-Moduls besteht darin, die vom Server-Modul gesammelten Informationen auszulesen und dem Benutzer in grafischer Form darzustellen.

Beim Start müssen Sie die vom Befehl dbcc memusage durchgeführte Überprüfung des Serverspeichers abbrechen, da dieser Befehl den Server erheblich verlangsamt. Dazu müssen Sie beim Starten von sqlmon (Client-Modul) den Parameter – nomem – angeben.

Die Standardkonfiguration ermöglicht den gleichzeitigen Anschluss von bis zu fünf Clientmodulen an ein Servermodul. Mit anderen Worten: Ein Servermodul kann entweder mit fünf Clientmodulen mit einem Fenster auf jedem Client oder mit einem Client mit fünf geöffneten Fenstern verbunden werden.

Die maximale Anzahl gleichzeitig geöffneter Client-Fenster wird beim Start des Servermoduls festgelegt.

Um also 20 Fenster in der Befehlsdatei zum Starten des Servermoduls zu unterstützen, müssen Sie den Parameter n2 0 angeben. In diesem Fall müssen Sie die Adresse am Anfang des gemeinsam genutzten Speicherbereichs des Servers ändern der Befehl buildmaster und einige andere Aktionen. Diese Aktionen sollten niemals ausgeführt werden, während SQL Server ausgeführt wird. (Einzelheiten zum Prozess der Erweiterung der Anzahl gleichzeitig unterstützter Clients finden Sie im Handbuch „Server Supplement“.)

hat einige Nachteile. Beispielsweise kann ein Balkendiagramm, das die Anzahl der laufenden E/A-Vorgänge und andere Leistungsmerkmale von Servergeräten anzeigt, nur Daten zu einer begrenzten Anzahl von Geräten gleichzeitig melden.

Dies ist unpraktisch, wenn ein großer Server mit einer großen Anzahl von Servergeräten überwacht wird. Darüber hinaus kann der Benutzer keine Geräte auswählen, für die Informationen in das Diagramm aufgenommen werden, oder zwischen verschiedenen Gerätesätzen wechseln.

Die Texttabelle, die gleichzeitig mit dem Diagramm auf dem Bildschirm erscheint, enthält eine Liste aller Servergeräte, enthält jedoch nur die Gesamtzahl der E/A-Vorgänge für jedes dieser Geräte. Dies ist besonders schwierig, wenn Sie mit einem großen Server arbeiten, der über viele Servergeräte verfügt, die Benutzerdatenbanksegmente unterstützen, um seine Leistung zu verbessern. In diesem Fall ist eine Analyse des Betriebs aller vorhandenen Segmente nicht möglich.

Außerdem ist es nicht möglich, die Dynamik von Änderungen der Leistungsindikatoren über einen längeren Zeitraum auf dem Bildschirm anzuzeigen.

Es ist in der Lage, Daten für 60 aufeinanderfolgende Leistungsmessintervalle anzuzeigen. Abhängig von der gewählten Dauer jedes Intervalls können solche Statistiken einen ziemlich großen Zeitraum abdecken. Allerdings ist es mit dieser Technik nicht möglich, aktuelle Daten mit Indikatoren von vor einem Monat oder einem Jahr zu vergleichen.

Natürlich können Bilder von Programmfenstern auf einem Drucker ausgegeben werden, aber dann müssen Sie Dateisätze oder Berge von Ausdrucken speichern, um die zukünftige Leistung des Servers beurteilen zu können. In der Praxis muss ein Serveradministrator häufig Daten, die zu verschiedenen Zeitpunkten im Geschäftszyklus eines Unternehmens gesammelt wurden, erneut untersuchen und Informationen über ähnliche Zeiträume in aufeinanderfolgenden Geschäftszyklen mit Querverweisen versehen, um Einblick in die tatsächliche Serverleistung zu erhalten.

Da der Start zu einer gewissen Verlangsamung des Servers führt, muss vor Beginn der Messungen das Ausmaß dieser Verlangsamung für eine bestimmte Hardware- und Softwareplattform ermittelt werden. Eine gute Möglichkeit zur Messung besteht darin, einen Standardsatz von Testtransaktionen auszuführen.

Es kann sowohl verwendet werden, wenn es auf dem Servercomputer vorhanden ist, als auch nicht. Auch wenn keine Client-Module vorhanden sind, funktioniert das Server-Modul des Programms weiter und muss mit einem separaten Befehl gestoppt werden.

ermöglicht die Anzeige verschiedener Grafikfenster, die jeweils Informationen zu einem bestimmten Aspekt der Serverfunktion enthalten.

Hauptfenster
Diese enthält eine Liste der vom Programm unterstützten Fenster. Wenn beim Starten von sglmon, dem Client-Modul, der Parameter „nomem“ nicht angegeben wurde, wird in diesem Fenster auch ein Kreisdiagramm der Speichernutzung des Servercomputers angezeigt.

Cache-Puffer
In diesem Fenster werden Diagramme angezeigt, die den Betrieb von Prozedur- und Daten-Cache-Puffer charakterisieren. Durch die Steuerung der Anzahl der physischen und logischen E/A-Vorgänge im Daten-Cache-Puffer kann der Benutzer bestimmen, wie viele Datenseitenzugriffe der Server unter Verwendung bereits im Puffer befindlicher Seiten durchführen wird. Diese für den Datenpuffer und den Prozedurpuffer ermittelten Statistiken ermöglichen es uns, die Gesamtspeichermenge zu bestimmen, die von den Cache-Puffer des Servers benötigt wird, sowie das Verhältnis zwischen den Daten- und Prozedur-Cache-Puffer.

Datenpuffer-Cache, nur SQL Server System 11 (Datencache)
Das Fenster meldet die Anzahl der physischen und logischen E/A-Vorgänge für jeden der genannten Cache-Puffer, die auf dem Server konfiguriert sind.

Festplatten-E/A
Hier finden Sie Grafiken und Übersichtstabellen zur aktuellen und Gesamtzahl der Festplattenzugriffe. Sie tragen dazu bei, die I/O-Lastverteilung zwischen vorhandenen Servergeräten zu optimieren. Bei der Analyse der Ausgabeinformationen ist es sinnvoll, das Standardschema zur Auswahl der Namen von Servergeräten basierend auf den Namen der entsprechenden Abschnitte physischer Festplatten zu verwenden, da Sie bei der Überwachung des Wechselkurses mit Servergeräten wissen sollten, welcher Festplattencontroller Jedes dieser Geräte ist mit verbunden.

Arbeiten mit dem Netzwerk, nur für SQL Server System 10 und 11 (Netzwerkaktivität)
Das Fenster meldet statistische Informationen über die Netzwerkeingabe und -ausgabe – Paketgrößen, Verkehrsaufkommen usw.

Blockieren des Zugriffs auf Objekte, nur für SQL Server System 10 und 11 (Objektsperrstatus)
Hier werden Informationen zu Zugriffssperren für Datentabellen angezeigt, einschließlich einer detaillierten Aufschlüsselung der verwendeten Sperrtypen, der Namen der Prozesse, die die Sperren halten usw.

Objektseiten-E/A, nur SQL Server System 10 und 11 (Objektseiten-E/A)
Das Fenster enthält Informationen über die Intensität der E/A-Seiten einer der Serverdatentabellen. Achten Sie beim Zusammenstellen einer Liste der am häufigsten verwendeten Servertabellen auf Effizienz. Diese Art von Informationen wird von sp_sysmon nicht zurückgegeben.

Leistungsübersicht
Dies bietet einen Gesamtüberblick über die Leistung von SQL Server – Prozentsatz der genutzten CPU-Zeit, Anzahl der pro Sekunde verarbeiteten Transaktionen, Volumen des Netzwerkverkehrs, Festplatten-E/A und Sperrennutzung.

Leistungstrend
Das Fenster zeichnet kontinuierliche Diagramme der im Fenster „Leistungszusammenfassung“ angezeigten Serverleistungsindikatoren im Vergleich zur Zeit auf.

Serverprozessaktivität (Prozessaktivität)
In diesem Fenster können Sie einen oder mehrere Serverprozesse auswählen und die CPU-Auslastung und das E/A-Volumen für jeden Prozess überwachen.

Prozessdetails
Das Fenster enthält detaillierte Informationen zum ausgewählten Serverprozess.

Prozessliste
Das Fenster enthält eine Liste aller aktuell verfügbaren Serverprozesse mit Angabe ihres Status. Sehr ähnlich der Ausgabe des sp_who-Serverbefehls.

Verwenden der Prozesssperraktivität
Das Fenster informiert über die Verwendung von Sperren durch den von Ihnen ausgewählten Serverprozess.

Verwenden der gespeicherten Prozeduraktivität
Das Fenster enthält Informationen über die Ausführung gespeicherter Prozeduren und die Laufzeit jeder Prozedur.

Transaktionsaktivität
Im Fenster sehen Sie ein Balkendiagramm, das die Anzahl der verarbeiteten Transaktionen, aufgeschlüsselt nach verschiedenen Transaktionstypen, anzeigt. Sie können beispielsweise sehen, welcher Teil der Transaktionen mit dem Update-in-Place-Mechanismus abgeschlossen werden kann.

26.12.2006 Kevin Kline

Was ist die letzte Frage, die einem DBA gestellt werden möchte? Wahrscheinlich eine Nachricht des Benutzers über die Verschlechterung der Anwendung oder eine Frage, was mit der Datenbank passiert ist. Wir müssen alles beiseite legen und in den „Notfallmodus“ wechseln und uns fragen, wie lange das anhalten wird. Da eine der Hauptaufgaben eines Datenbankadministrators darin besteht, die qualitativ hochwertige Funktion industrieller Datenbanken sicherzustellen, bleibt nur noch die schnellstmögliche Behebung des Problems. In der Regel bleibt keine Zeit, die Fehlerursache herauszufinden.

Keine Eilaufträge mehr – nur systematische Beobachtung

Aber ist das das Einzige, was getan werden kann? Es besteht die Möglichkeit, eine proaktive Leistungsüberwachung durchzuführen, ein einfaches Verwaltungsverfahren, das System-Baselines, Benchmarking und kontinuierliche Überwachung nutzt. In diesem Artikel werde ich darüber sprechen, wie man die proaktive Überwachung nutzt und wie man mit Windows System Monitor ein kostenloses Überwachungssystem erstellt.

Proaktive Überwachung

Proaktive Leistungsüberwachung ist ein einfaches System, das Ihnen hilft, Probleme zu lösen, bevor sie kritisch werden. Einige Leute verwenden wahrscheinlich bereits die Ausnahmeüberwachung, bei der sie automatisierte Prozesse erstellen, die nur Anomalien bemerken, aber keine detaillierten Informationen oder die Möglichkeit bieten, Probleme zu verhindern. Die proaktive Leistungsüberwachung hingegen liefert dem Benutzer kurz- und langfristig vielfältige Informationen über die Arbeitsumgebung und Anwendungen. Es werden Datenbankleistungsindikatoren erfasst, Benchmark-Metriken erstellt und eine aktive Überwachung aufrechterhalten.

Wie der Name schon sagt, erfordert eine proaktive Leistungsüberwachung Maßnahmen. Die Installation dauert ein wenig und es dauert etwas, bis man versteht, wie Datenbanken und Anwendungen funktionieren. Damit die proaktive Leistungsüberwachung effektiv ist, müssen Nachrichten überprüft werden, damit die umfangreichen gesammelten Daten genutzt werden können.

Grundparameter, Standard, Monitor

Beginnen wir mit der Definition einiger Begriffe. Grundparameter (Baseline) ist eine Reihe von Parametern, die das Verhalten des Servers und der Anwendung unter normalen Bedingungen widerspiegeln. Die Grundparameter wurden als Durchschnittswerte auf der Grundlage der Ergebnisse mehrerer Messungen ermittelt, die unter den gleichen Bedingungen durchgeführt wurden; Sie sind Vergleichsmaßstäbe.

Benchmark zeigt die Leistung des Systems bei einer bestimmten Serverauslastung an, wodurch Sie die Leistung eines Industrieservers auf dieser Ebene vergleichen und die Leistung des Servers bestimmen können, um wie viel höher oder niedriger sie als normal ist (d. h. wann). der Server arbeitet schlecht). Wie bei Basisparametern werden in einem kontrollierten Umfeld Benchmarkwerte ermittelt und Schlüsselwerte in Bezug auf vordefinierte Indikatoren ermittelt. Wenn Sie sehen möchten, wie sich Server und Anwendung bei mehreren Ebenen oder Lastarten verhalten, erhalten Sie in der Regel mehrere Referenzwerte (in Bezug auf die Grundparameter).

Überwachung- Hierbei handelt es sich um eine geplante Überwachung des Servers in Echtzeit unter vordefinierten Bedingungen (Bedingungssätze, die für weitere Untersuchungen oder Warnungen definiert sind). Wenn Sie beispielsweise wissen möchten, wie lange es dauert, bis eine kritische Geschäftsanwendung erfolgreich ausgeführt wird, wie lange ein Backup dauert oder wann bestimmte Leistungsmeilensteine ​​erreicht werden, werden diese spezifischen Ereignisse überwacht.

Kommen wir nun zur proaktiven Überwachung. Sie können Produkte von Drittanbietern oder eine kostenlose Lösung verwenden, die System Monitor verwendet. Lösungen von Drittanbietern vereinfachen möglicherweise den Prozess der Einrichtung einer proaktiven Überwachung und verfügen möglicherweise über andere Funktionen als eine kostenlose, integrierte Lösung. Aber bevor wir beginnen, zeige ich Ihnen, wie Sie mit System Monitor mit der proaktiven Überwachung beginnen.

Schritt 1: Definieren Sie Leistungsbasislinien.

Im ersten Schritt zur Sicherstellung des proaktiven Überwachungsmodus wird eine Reihe grundlegender Parameter für den Betrieb des Datenbankservers festgelegt. Dieses Aggregat zeigt die Leistung des Servers unter normalen Bedingungen an, hilft bei der Dokumentation und dem Verständnis aller wichtigen Hintergrundprozesse und hilft auch dabei, Situationen zu identifizieren, die keinen Eingriff erfordern, sodass sie in Zukunft ignoriert werden können. Mit anderen Worten: Datenbankadministratoren können Optionen definieren, um Systemmeldungen zu ignorieren, da sonst eine große Anzahl falscher Benachrichtigungen generiert wird.

Um die Qualität des Betriebs klar darzustellen, verwenden die besten Baselines einige Diagramme (idealerweise eines), damit Sie auf einen Blick sehen können, wie die Leistung des Servers ist. Nachdem die Grundparameter ermittelt wurden, müssen Sie Folgendes tun. Wählen Sie zunächst die Option, Leistungsdaten im Systemprotokoll zu speichern oder in Echtzeit anzuzeigen. Es ist ideal, beides zu haben: Mit Protokollen können Sie jederzeit auf die Messwerte zurückblicken, um zu analysieren, wie die Leistung war, als Sie das System nicht direkt überwachten. Die Echtzeitüberwachung beansprucht weder Speicherplatz noch Serverressourcen, sondern erfordert 100 Prozent Ihrer Aufmerksamkeit für das System. Zweitens müssen Sie unter Berücksichtigung der Leistungskosten der Datenerfassung und Daten-E/A-Vorgänge das Intervall bestimmen, in dem die Überwachung durchgeführt wird, und die Kosten für den erforderlichen Speicherplatz abschätzen. Je länger das Intervall ist, desto höher ist die Wahrscheinlichkeit, dass die gewünschten Leistungsdaten nicht erhalten werden. Wählen Sie schließlich die lokale oder Fernüberwachung. Lokale Überwachung, bei der der Überwachungsprozess einen überwachten Server verwendet, erhöht den CPU- und Festplatten-Overhead für den Server. Eine Fernüberwachung, die einen separaten Server nutzt, kann diese Probleme beseitigen, erhöht jedoch die Arbeitslast im Netzwerk erheblich.

Listet die Systemmonitor-Metriken oder -Zähler auf, die wir zur Bestimmung Ihrer Basislinie empfehlen. Ich kann nicht sagen, was der „richtige“ Wert im Kontext einer bestimmten Anwendung ist, da er von System zu System unterschiedlich ist. Verwenden Sie den Durchschnitt der verschiedenen Basislinien, um die normale Basisleistung festzulegen und anzugeben, dass dies die richtige Option für das verwendete System ist.

Definieren grundlegender Einstellungen mit System Monitor

Rufen wir nun zum Erfassen grundlegender Parameter den Systemmonitor auf. Öffnen wir „Systemsteuerung“, „Verwaltung“ und „Leistung“. Doppelklicken Sie im linken Bereich auf Leistungsprotokolle und Warnungen. Klicken wir mit der rechten Maustaste auf „Zählerprotokolle“ und wählen Sie „Neue Protokolleinstellungen“. Geben Sie einen Namen für das Diagramm ein und klicken Sie dann auf OK. Wählen Sie im Dialogfeld „Zähler auswählen“ den ersten Zähler aus und klicken Sie dann auf „Hinzufügen“. Wiederholen Sie diese Schritte, bis alle Zähler hinzugefügt wurden, und klicken Sie dann auf Schließen.

Probieren Sie zunächst das standardmäßige 15-Sekunden-Intervall aus. Oder wählen Sie ein anderes Intervall aus, indem Sie auf „Eigenschaften“ klicken (oder verwenden Sie die Tastenkombination Strg + Q) und geben Sie dann einen Wert mit der Bezeichnung „Automatisch alle: _ Sekunden abtasten“ ein. Längere Intervalle beanspruchen weniger Platz, liefern aber weniger detaillierte Daten.

Wählen Sie die Tabelle „Protokolldateien“ aus und legen Sie fest, wo die Daten gespeichert werden. Sie können die Daten später mithilfe der Ansicht „Protokolldateidaten anzeigen“ anzeigen. Der Systemmonitor sieht wie in Abbildung 1 dargestellt aus, wenn grundlegende Leistungsdaten erfasst werden. Es ist ersichtlich, dass durch die gleichzeitige Überwachung vieler Zähler viele Daten erfasst werden können. Daher sollten Sie die Zähler für die Hauptleitung sorgfältig auswählen.

Schritt 2: Referenzwerte festlegen

Sobald die Leistungsbasislinie eines Servers festgelegt wurde, können Sie mit dem Festlegen von Benchmarks beginnen, was es einfacher macht, die Serverleistung zu verstehen, wenn sie in mehreren vordefinierten Situationen ausgeführt wird.

Für Standards wird der gleiche Überwachungsmodus verwendet wie für die Ermittlung grundlegender Parameter. Sie können Ihre eigene Lösung oder eines der gängigen Branchentools wie TPC-C oder SAP verwenden. Die besten Ergebnisse zur Berechnung von Benchmark-Werten werden jedoch durch die Entwicklung allgemeiner benutzerdefinierter Skripte erzielt, die für die Verwendung eines bestimmten Datenbankservers und seiner Anwendungen konfiguriert sind .

Sie können Ihr eigenes Skript mit der T-SQL-Skriptsuite, OSQL-Dienstprogrammen oder Query Analyzer, SQL Profiler und System Monitor erstellen. Die Entwicklung von Lasttestskripten in T-SQL dauert normalerweise mehrere Tage. Es kann sogar noch mehr Zeit in Anspruch nehmen, Daten zur Auslastungstestausführung zu sammeln und die resultierenden Daten zu analysieren.

Sobald Sie eine Basislinie für die Serverleistung unter vorgegebenen Arbeitslasten erstellt haben, können Sie wissen, was Sie vom System erwarten können. Nutzen Sie die bei der Ermittlung von Referenzwerten erhobenen Daten als Grundlage für die routinemäßige Überwachung. Es wurde beispielsweise festgestellt, dass der Server bis zu 249 Transaktionen pro Sekunde liefern konnte, bevor er langsamer wurde. In diesem Fall können Sie eine Benachrichtigung mit niedriger Priorität festlegen, wenn der Server etwa 200 TPS erreicht, und eine Benachrichtigung mit hoher Priorität, wenn der Server 235 TPS erreicht. Mit dieser Methode kann der Administrator mögliche Probleme mit dem Server erkennen und die erforderlichen Maßnahmen ergreifen, bevor Benutzer etwas bemerken. Und keine kritischen Situationen. Jetzt ist es möglich.

Schritt 3: Geplante Überwachung

Der vielleicht wichtigste Bestandteil eines proaktiven Überwachungssystems ist die geplante Überwachung. Ohne sie können Sie die Datenbankleistung nicht überwachen oder Leistungsprobleme erkennen.

Mit einer Kombination aus SQL Server Agent und System Monitor können Sie ein kostengünstiges SQL Server-Überwachungstool erstellen. Mit dem SQL Server-Agent können Sie feststellen, welches Ereignis die Anzeige eines Fehlers auf dem Monitor verursacht hat, bestimmen, wer Benachrichtigungen über Ereignisse erhält, und automatisch eine Benachrichtigung senden, wenn ein Fehlerereignis auftritt.

Die Installation des SQL Server-Agenten kann zeitaufwändig und komplex sein. Weitere Informationen finden Sie im Abschnitt „Warnungen in SQL Server“. Online-Bücher (BOL). Der SQL Server-Agent überwacht normalerweise Fehlermeldungen des Datenbankservers und überwacht nicht die Ausführung.

Um die Serverleistung zu überwachen, verwenden Sie System Monitor, um die aktuellen Zähler zu überwachen (stellen Sie die Abfragehäufigkeit auf innerhalb von 15 Minuten ein).

Speicherseiten/Sek

Netzwerkschnittstelle – Bytes insgesamt/Sek

Physische Datenträger-Datenträger-Übertragungen/Sek

Prozessor-% Prozessorzeit

SQLServer:Zugriffsmethoden – Vollständige Scans/Sek

SQLServer:Puffer-Manager-Puffer-Cache-Trefferverhältnis

SQLServer:Datenbanken Anwendungsdatenbank-Transaktionen/Sek

SQLServer:Allgemeine Statistiken – Benutzerverbindungen

SQLServer:Latches – Durchschnittliche Latch-Wartezeit

SQLServer:Sperren – Durchschnittliche Wartezeit

SQLServer:Locks-Lock-Timeouts/Sek

SQLServer:Sperren – Anzahl der Deadlocks/Sek

SQLServer:Memory Manager – Speicherzuteilungen ausstehend

Stellen Sie den Wert für jeden Zähler zwischen den Basiswerten und den durch Tests angezeigten Referenzwerten ein. Sie können beispielsweise eine Benachrichtigung einstellen, wenn der Zähler 75 Prozent des höchsten Lastwerts erreicht, und eine Warnmeldung, wenn er 90 Prozent überschreitet.

Um Warnungen durchzuführen, können Sie kostenlose Tools wie SQL Server Alerts & Notifications, System Monitor verwenden oder Microsoft Operations Manager (MOM) oder andere Tools erwerben. Ich empfehle, Warnungen mindestens für die folgenden Situationen einzurichten:

  • Fehler, die den Betrieb beeinträchtigen, insbesondere Fehler mit einem Schweregrad von 19 bis 25
  • Blockierung
  • CPU-Auslastung
  • Festplattennutzung
  • scan (SQLServer:Zugriffsmethoden)

Alarme können gesendet werden, um Administratoren per E-Mail, Pager oder Netzwerk zu benachrichtigen. Sie können automatische Benachrichtigungen für die folgenden Nachrichtenquellen festlegen:

  • SQL Server-Protokoll
  • SQL-Agent-Protokoll
  • Windows-Anwendungsprotokoll, Sicherheit und System
  • SQL Server-Auftragsausführungsprotokoll

Schließlich müssen Sie sicherstellen, dass Ihre eigenen Anwendungen Fehler korrekt protokollieren und auch auf Fehlermeldungen anderer entwickelter Anwendungen reagieren.

Die proaktive Überwachung der SQL Server-Leistung bedeutet die Festlegung grundlegender Leistungsparameter sowohl für den Server als auch für die Anwendung. Festlegen von Benchmarks, die das Verhalten des Servers gemäß einem vordefinierten Nutzungsszenario simulieren, und Durchführen einer geplanten Überwachung, die im Idealfall Warnungen auslöst, wenn ein Problem erkannt wird. Unabhängig davon, ob Sie kostenlose oder integrierte Tools verwenden oder sich für Lösungen von Drittanbietern entscheiden, stellt die Kontrolle sicher, dass Sie die Informationen erhalten, die Sie benötigen, wenn Sie sie benötigen, und zwar darüber, wie Ihre Anwendungen auf SQL Server ausgeführt werden.

Tabelle 1. Systemmonitor-Objekte und -Zähler zur Bestimmung grundlegender Parameter
Objekt und Zähler Beschreibung
Speicherseiten/SekDie Anzahl der pro Sekunde gelesenen oder auf die Festplatte geschriebenen Seiten. Dieser Zähler ist ein primärer Indikator für die Arten von Fehlern, die durch Systemverzögerungen oder Leistungsprobleme verursacht werden
Netzwerkschnittstelle – Bytes insgesamt/SekDie Anzahl der Bytes, die pro Sekunde die Netzwerkschnittstelle passieren. Wenn dieser Zähler abnimmt oder in diese Richtung tendiert, weist dies darauf hin, dass möglicherweise Netzwerkprobleme die Anwendung beeinträchtigen
PhysicalDisk-Disk-Übertragungen/SekSchätzung der Lese-/Schreibvorgänge auf der Festplatte. Legen Sie einen Zähler für jede physische Festplatte auf dem Server fest
Prozessor-% ProzessorzeitDer Prozentsatz der Zeit, die der Prozessor mit der Ausführung eines Arbeitsthreads verbringt. Dieser Zähler fungiert als primärer Indikator für die Prozessoraktivität. Wenn alle auf SQL Server ausgeführten Prozessoren eine Auslastung von 100 % aufweisen, werden Endbenutzeranfragen wahrscheinlich ignoriert
SQLServer:Zugriffsmethoden – Vollständige Scans/SekUnbegrenzte Tabellen- oder Index-Scans pro Sekunde. Das Verringern dieses Zählers ist von Vorteil, da Aufrufe oft zu Ressourcenknappheit und Caching-Problemen führen
SQLServer:Puffer-Manager-Puffer-Cache-TrefferverhältnisDer Prozentsatz der Seiten, für die keine Festplattenlesevorgänge erforderlich waren. Je höher ihre Anzahl, desto weniger Festplatten-I/O wird ausgeführt. Bei einem gut abgestimmten System sollte dieser Wert 80 oder höher sein.
SQLServer:Datenbanken – ProtokollwachstumWie stark ist die Transaktionsdatei für eine bestimmte Datenbank gewachsen? Bei einem gut abgestimmten System sollte dieser Zähler niedrig sein, wahrscheinlich weniger als eins alle paar Tage
SQLServer:Datenbankanwendungsdatenbank-Prozentprotokoll verwendetDer Prozentsatz des freien Speicherplatzes in der Protokolldatei. Dieser Zähler variiert wie geplant, sollte jedoch nicht 100 erreichen
SQLServer:Datenbanken Anwendungsdatenbank-Transaktionen/SekDie Anzahl der in der Datenbank bestätigten Transaktionen. Dieser Zähler wird in den Standards zeitweise weggelassen. Beobachten Sie, wann Transaktionen in die Warteschlange geraten. Dies ist ein Hinweis darauf, dass die Festplatten-E/A möglicherweise langsam ist
SQLServer:Latches – Durchschnittliche Latch-WartezeitDie durchschnittliche Zeit, die eine Anfrage verweilt, bevor sie erfüllt wird. Dieser Zählerwert kann hoch sein, wenn auf dem Server Ressourcenkonflikte auftreten, insbesondere um Speicher oder E/A
SQLServer:Sperren – Durchschnittliche Wartezeit, Sperrwartezeiten/Sek., Anzahl der Deadlocks/SekTemporäre Sperren halten SQL Server-Ressourcen fest. Achten Sie auf einen Aufwärtstrend bei diesen sperrbezogenen Zählern, der auf ein mögliches Leistungsproblem hinweist
SQLServer:Allgemeine Statistiken – BenutzerverbindungenDie Anzahl der Benutzerverbindungen zum Datenbankserver. Überprüfen Sie den Wert dieses Zählers auf merkliche Veränderungen. Sie können auf Netzwerkprobleme hinweisen und auf Auslastungen und Verlangsamungen hinweisen
SQLServer:Memory Manager – Speicherzuteilungen ausstehendDie aktuelle Anzahl der Prozesse, die darauf warten, Speicherplatz zugewiesen zu bekommen. Ein hoher oder steigender Wert kann auf eine unzureichende Speicherkapazität hinweisen
SQLServer:User Settable-Query (eine Tracer-Abfrage)Ein spezialisierter Zähler, auch Abfrageindex genannt. Bei diesem Zähler handelt es sich um eine vom Benutzer generierte Abfrage, die die Gesamtgeschwindigkeit oder Effizienz des Systems angibt. Um diesen Wert festzulegen, ruft die Anwendung sp_user_counter1 auf und gibt einen numerischen Wert zurück.


Jeder Datenbankadministrator musste sich wahrscheinlich schon einmal damit auseinandersetzen, dass alles langsam oder gar nicht funktioniert. Als Erstes müssen Sie herausfinden, was derzeit tatsächlich auf SQL Server passiert. Es scheint, dass der Administrator so viele nützliche Dinge in seinem Arsenal hat: einen albernen Aktivitätsmonitor, eine Reihe dynamischer Verwaltungsansichten (DMV), gespeicherte Prozeduren sp_who und sp_who2, übernommen aus den Tagen von SQL Server 7 und SQL Server 2000.
Aber lass es uns herausfinden...

Überwachungstools

Aktivitätsmonitor

Es scheint eine großartige Sache zu sein, es tut genau das, was es tun muss – überwacht die Aktivität. Ich starte einen umfangreichen Buchhaltungsbericht und schaue, was mir der Aktivitätsmonitor anzeigt.
Die Screenshots zeigen einen Aktivitätsmonitor von SQL Server 2005:

und von SQL Server Denali (2012) CTP 3.


Hmmm. Was wäre, wenn ein Dutzend Leute solche Berichte erstellen würden? Und das ist nicht ungewöhnlich... Es wird ziemlich umständlich sein, es herauszufinden, obwohl der Fortschritt natürlich offensichtlich ist. Im Denali Activity Monitor werden viel mehr nützliche Informationen angezeigt (z. B. auf welche bestimmte Ressource gewartet wird). Außerdem können wir beispielsweise einen Profiler für die gewünschte Sitzung direkt vom Monitor aus starten und diese bereits im Profiler verfolgen , aber verdammt, es lädt zusätzlich und ein bereits überlasteter Server. Darüber hinaus gibt es bereits ein Problem mit den Bremsen, und wir werden die Anfragen nicht sehen, deren Ausführung zum Zeitpunkt des Starts des Profilers bereits begonnen hatte.
Und genau das möchte ich sehen – wer gerade was macht.

sp_who und sp_who2

Der Screenshot zeigt das Ergebnis der Ausführung von sp_who (oben) und sp_who2 (unten), die beim Erstellen desselben unglücklichen Berichts ausgeführt wurden:


Ja. Sehr informativ. Wenn wir uns sp_who ansehen, können wir nur sehen, dass etwas läuft. Natürlich wird es ausgeführt – deshalb schauen wir, aber wir sehen, dass eine Art SELECT ausgeführt wird. Oder mehrere SELECTs.
sp_who2 zeigt weitere Informationen. Jetzt können wir sehen, wie viel Prozessorzeit die Sitzung verbraucht hat (und anscheinend die Gesamtzeit in einer Spalte addieren), die Anzahl der E/A-Vorgänge, den Namen der Datenbank, in der all dies ausgeführt wird, und von wem dies geschieht Sitzung ist blockiert (falls sie blockiert ist).
Der Aktivitätsmonitor liefert, wie wir sehen, mehr Informationen.

DMV

Ab SQL Server 2005 verfügen wir über eine neue Möglichkeit, Informationen über den Status des Servers abzurufen – dynamische Verwaltungsansichten. MSDN sagt Folgendes: „Dynamische Verwaltungsansichten und -funktionen geben Daten zum Serverzustand zurück, die zur Überwachung des Zustands einer Serverinstanz, zur Diagnose von Problemen und zur Optimierung der Leistung verwendet werden können.“
Tatsächlich gibt es in SQL Server 2005 eine Reihe von Ansichten, die sich auf die Ausführung von Abfragen im aktuellen Moment beziehen (es gibt jedoch auch Ansichten zum Anzeigen des „Verlaufs“): Hier sind sie und ihre Zahl nimmt von Version zu Version weiter zu!
Sicherlich haben erfahrene Administratoren eine Reihe von Skripten parat, um Informationen über den aktuellen Status des Servers zu erhalten, aber was tun, wenn Sie noch keine Erfahrung mit dem DMV haben, aber bereits Probleme auftreten?

sp_WhoIsActive

Adam Machanic (SQL Server MVP und MCITP) hat die gespeicherte Prozedur sp_WhoIsActive entwickelt und verbessert sie ständig, die auf denselben DMVs basiert und verdammt einfach zu verwenden ist. Sie können die neueste Version von sp_WhoIsActive herunterladen. Adam selbst hat eine Reihe von Artikeln über sp_WhoIsActive geschrieben, die bis zu 30 (dreißig!) Stücke umfasst. Sie können sie lesen, aber ich werde versuchen, Sie für die Lektüre dieses Materials zu interessieren :).
Wir gehen also davon aus, dass Sie dieses Skript heruntergeladen und auf einem der Testserver ausgeführt haben (auf jeder Version, von 2005 bis Denali). Adam empfiehlt, es in der Datenbank des Mastersystems zu speichern, damit es im Kontext jeder Datenbank aufgerufen werden kann. Dies ist jedoch nicht erforderlich. Wenn Sie es nur im Kontext einer anderen Datenbank aufrufen, müssen Sie den Namen vollständig schreiben – DB .schema.sp_whoIsActive.
Also lasst es uns versuchen. Der Screenshot zeigt das Ergebnis seiner Ausführung beim Erstellen desselben Berichts:

Das Ergebnis der exec sp_whoIsActive-Abfrage passt leider nicht auf einen Bildschirm, daher finden Sie hier eine Textbeschreibung der Ausgabe einer gespeicherten Prozedur, die ohne Parameter aufgerufen wird.

  • - Bei einer aktiven Anfrage wird die Ausführungszeit angezeigt, bei einer „schlafenden“ Sitzung die „Schlafzeit“;
  • - eigentlich Spinne;
  • - zeigt den Text der aktuell ausgeführten Anfrage oder den Text der zuletzt abgeschlossenen Anfrage, wenn die Sitzung schläft;
  • - Nun, Sie verstehen;
  • - eine sehr interessante Kolumne. Die Ausgabe erfolgt im Format (Ax: Bms/Cms/Dms)E. A ist die Anzahl der Aufgaben, die auf Ressource E warten. B/C/D ist die Wartezeit in Millisekunden. Wenn nur eine Sitzung auf die Freigabe einer Ressource wartet (wie im Screenshot), wird deren Wartezeit angezeigt. Wenn es zwei Sitzungen gibt, werden deren Wartezeiten im B/C-Format angezeigt. Wenn 3 oder mehr warten, sehen wir die minimale, durchschnittliche und maximale Wartezeit auf DIESER Ressource im B/C/D-Format;
  • - für eine aktive Anfrage – die gesamte CPU-Zeit, die diese Anfrage verbraucht, für eine schlafende Sitzung – die gesamte CPU-Zeit für die „gesamte Lebensdauer“ dieser Sitzung;
  • – Bei einer aktiven Abfrage ist dies die Anzahl der Schreibvorgänge in TempDB während der Abfrageausführung. für eine schlafende Sitzung – die Gesamtzahl der Datensätze in TempDB für die gesamte Lebensdauer der Sitzung;
  • – für eine aktive Anfrage – die Anzahl der Seiten in TempDB, die dieser Anfrage zugewiesen sind; für eine schlafende Sitzung – die Gesamtzahl der Seiten in TempDB, die während der gesamten Sitzungslebensdauer zugewiesen wurden;
  • - Wenn wir plötzlich von jemandem blockiert werden, wird die Spid (Sitzungs-ID) der Person angezeigt, die uns blockiert hat.
  • – für eine aktive Anfrage – die Anzahl der logischen Lesevorgänge, die bei der Ausführung dieser Anfrage durchgeführt wurden; für eine Schlafsitzung – die Anzahl der Seiten, die während der gesamten Dauer dieser Sitzung gelesen wurden;
  • - Alles ist gleich, aber was die Aufnahme angeht;
  • – für eine aktive Anfrage – die Anzahl der physischen Lesevorgänge, die bei der Ausführung dieser Anfrage durchgeführt wurden; für eine Schlafsitzung – traditionell die Gesamtzahl der physischen Messungen über die gesamte Dauer der Sitzung;
  • – für eine aktive Anfrage – die Anzahl der Acht-Kilobyte-Seiten, die bei der Ausführung dieser Anfrage verwendet werden; für eine Schlafsitzung – wie viele Gesamtspeicherseiten ihr während ihrer gesamten Lebensdauer zugewiesen wurden;
  • - Sitzungsstatus – Laufen, Schlafen usw.;
  • - zeigt die Anzahl der von dieser Sitzung eröffneten Transaktionen an;
  • - zeigt, wenn möglich, den Fortschritt des Vorgangs an (z. B. BACKUP, RESTORE), wird nie zeigen, wie viele Prozent von SELECT abgeschlossen sind.

Die restlichen Spalten in Standardausgabe sp_WhoIsActive sind von geringem Interesse und ich werde sie nicht beschreiben – ihr Zweck ist meiner Meinung nach für jeden klar (Hostname, Datenbankname, Programmname, Startzeit, Anmeldezeit, Anforderungs-ID, Sammlungszeit).

Na und? Das ist alles?

Nein, das ist noch nicht alles. Ich werde auch darüber sprechen, mit welchen (aus meiner Sicht interessantesten und nützlichsten) Parametern Sie sp_WhoIsActive aufrufen können und was dabei herauskommt.

  • @help ist eine schrecklich nützliche Option. Wenn wir sp_whoIsActive @help = 1 aufrufen, erhalten wir Informationen über ALLE Parameter und Ausgabespalten auf dem Bildschirm. Wenn also etwas unklar bleibt, können Sie immer auf „Hilfe“ schauen.
  • @filter_type und @filter – ermöglichen das Filtern des Ausführungsergebnisses. @filter_type kann die Werte „session“, „program“, „database“, „login“ und „host“ annehmen. Im @filter-Parameter geben wir an, welches Objekt des ausgewählten Typs uns interessiert. Wir möchten beispielsweise alle Sitzungen sehen, die in der Master-Datenbank laufen. Dazu rufen wir exec sp_whoIsActive @filter_type = „database“, @filter = „master“ auf. Der @filter-Parameter ermöglicht die Verwendung von „%“;
  • @not_filter_type und @not_filter – ermöglichen uns, „umgekehrt“ zu filtern. Das heißt, wir möchten zum Beispiel alles sehen, außer den Sitzungen, die „Master“ im Feld „Datenbank“ haben. Dazu führen wir exec sp_WhoIsActive @not_filter_type = „database“, @not_filter = „master“ aus. Nun ja, oder wir wollen sehen, was alle Benutzer außer Benutzer sa tun ... Es kann viele Anwendungen geben. Der Parameter @not_filter ermöglicht die Verwendung von „%“;
  • @show_system_spids = 1 – zeigt Informationen zu Systemsitzungen an;
  • @get_full_inner_text = 1 – das Feld sql_text enthält nicht nur den Text der aktuellen Anfrage (Anweisung) im Stapel (Batch), sondern den Text des gesamten Stapels;
  • @get_plans – fügt der Ausgabe eine Spalte mit Abfrageausführungsplänen hinzu;
  • @get_transaction_info = 1 – fügt der Ausgabe die Anzahl und das Volumen der Einträge in den Transaktionsprotokollen sowie die Startzeit der letzten Transaktion hinzu;
  • @get_locks = 1 – fügt der Ausgabe Informationen über alle während der Ausführung der Anfrage angewendeten Sperren hinzu;
  • @find_block_leaders = 1 – verfolgt die Blockierungskette und zeigt die Gesamtzahl der Sitzungen an, die darauf warten, dass die aktuelle Sitzung die Blockierung entfernt;
  • @output_column_list = „[%]“ – was ist, wenn Sie keine tempDB-Informationen in der sp_whoIsActive-Ausgabe sehen möchten? Mit dieser Option können Sie steuern, was ausgegeben wird.
  • @destination_table = „table_name“ – versucht, das Ausführungsergebnis in eine Tabelle einzufügen, prüft jedoch nicht, ob diese Tabelle existiert und ob genügend Rechte zum Einfügen vorhanden sind.

Das ist jetzt alles

Damit verfügen wir über ein weiteres äußerst praktisches und flexibles Tool zur Überwachung der aktuellen Aktivität auf SQL Server. Für den normalen Betrieb sind die Berechtigung VIEW SERVER STATE und die Rechte zum Zugriff auf dmv ausreichend.
Dies lohnt sich auch für den Fall, dass der Server nur über verbunden werden kann

Checkliste für Leistungsaudits

Tragen Sie Ihre Ergebnisse in die Tabelle oben ein.

Verwenden von Performance Monutor zur Identifizierung von SQL Server-Hardwareengpässen

Der beste Ort, um mit der Überwachung der SQL Server-Leistung zu beginnen, ist der Leistungsmonitor (Systemmonitor). Durch die Überwachung einiger wichtiger Indikatoren über einen Zeitraum von 24 Stunden erhalten Sie einen ziemlich guten Überblick über alle größeren Hardwareprobleme, die sich auf die Leistung von SQL Server auswirken.

Idealerweise erstellen Sie mit dem Leistungsmonitor ein 24-Stunden-Protokoll der wichtigsten Zählerstände. Sie wählen einen „typischen“ Zeitraum von 24 Stunden für die Erstellung der Protokolldatei.

Wählen Sie beispielsweise einen typischen Wochentag, nicht das Ende der Woche oder einen Feiertag.

Nachdem Sie 24 Stunden Performance Monitor-Daten in einer Protokolldatei aufgezeichnet haben, zeigen Sie die empfohlenen Zähler im Performance Monitor-Grafikmodus an und zeichnen Sie dann die Durchschnitts-, Minimal- und Maximalwerte in der obigen Tabelle auf. Vergleichen Sie anschließend Ihre Ergebnisse mit den Ergebnissen der folgenden Analyse. Dieser Vergleich gibt Ihnen die Möglichkeit, mögliche Hardware-Engpässe zu identifizieren, die Ihren SQL Server beeinträchtigen.

So interpretieren Sie wichtige Leistungsmonitorindikatoren

Im Folgenden besprechen wir einige grundlegende Leistungsindikatoren, ihre empfohlenen Werte und einige Optionen, die bei der Identifizierung und Lösung von Hardwareproblemen helfen sollen. Es ist zu beachten, dass ich die Anzahl der berücksichtigten Leistungsmonitorindikatoren begrenzt habe. Dies geschieht, weil der Zweck dieses Artikels darin besteht, einfache und offensichtliche Probleme des Produktivitätsverlusts zu erkennen. Eine Diskussion über viele andere Leistungsmonitorindikatoren finden Sie an anderer Stelle auf dieser Website.

Speicher: Seiten/Sekunden

Unter der Annahme, dass SQL Server die einzige Hauptanwendung ist, die auf Ihrem Server läuft, sollte dieser Wert idealerweise zwischen null und 20 liegen. Es ist sehr wahrscheinlich, dass Sie Ausreißer deutlich über 20 sehen werden, was völlig normal ist. Der Schlüssel liegt hier darin, den durchschnittlichen Seitenwechselkurs unter 20 zu halten.

Wenn Ihr Server durchschnittlich mehr als 20 Seiten pro Sekunde verarbeitet, ist einer der wahrscheinlichsten Gründe dafür ein Mangel an erforderlichem RAM. Generell gilt: Je mehr RAM verfügbar ist, desto weniger Seitenwechsel sollten durchgeführt werden.

In den meisten Fällen liegt der durchschnittliche Seitenaustausch auf einem für SQL Server dedizierten physischen Server mit ausreichendem RAM bei weniger als 20. Ausreichender RAM für SQL Server kann anhand des folgenden Kriteriums ermittelt werden: Der Server muss über eine Puffer-Cache-Trefferquote (Puffer) verfügen Treffer-Cache-Verhältnis) 99 % oder höher. Dieser Zähler wird später in diesem Artikel beschrieben. Wenn Sie über einen SQL Server verfügen, bei dem dieses Verhältnis über einen Zeitraum von 24 Stunden bei 99 % oder mehr liegt, Sie aber im gleichen Zeitraum eine durchschnittliche Seitenwechselrate von über 20 erhalten, kann dies darauf hinweisen, dass Sie andere Anwendungen darauf ausführen ein anderer physischer Server als SQL Server. In diesem Fall sollten Sie diese Anwendungen idealerweise entfernen, sodass SQL Server die einzige Masteranwendung auf dem physischen Server sein kann.

Wenn auf Ihrem SQL Server keine anderen Anwendungen ausgeführt werden und die Anzahl der Seitenwechsel innerhalb von 24 Stunden durchschnittlich mehr als 20 beträgt, kann dies bedeuten, dass Sie die Speichereinstellungen des SQL Servers geändert haben. SQL Server muss so konfiguriert sein, dass die Option „SQL Server-Speicher dynamisch konfigurieren“ aktiviert ist und die Einstellung „Maximaler Speicher“ auf die höchste Einstellung eingestellt sein muss. Um eine optimale Leistung zu erzielen, sollte SQL Server die Möglichkeit haben, so viel RAM zu beanspruchen, wie er für seine eigenen Anforderungen benötigt, ohne mit anderen Anwendungen um RAM konkurrieren zu müssen.

Speicher: Verfügbarer Speicherplatz

Eine andere Möglichkeit herauszufinden, ob Ihr SQL Server über genügend physischen RAM verfügt, besteht darin, den Zähler „Speicherobjekt: Verfügbare Bytes“ zu überprüfen. Sein Wert muss mehr als 5 MB betragen. Andernfalls benötigt Ihr SQL Server mehr physischen RAM. Auf einem auf SQL Server spezialisierten Server versucht dieser, 4-10 MB freien physischen Speicher zu behalten. Der verbleibende physische RAM wird vom Betriebssystem und SQL Server verwendet. Wenn die Menge des verfügbaren Speichers nahe bei 5 MB oder weniger liegt, liegt höchstwahrscheinlich eine Überlastung des SQL Servers aufgrund von zu wenig Speicher vor. Wenn dies der Fall ist, müssen Sie die Menge des physischen RAM im Server erhöhen, die Belastung des Servers verringern oder Ihre SQL Server-Speentsprechend ändern.

Physische Festplatte: Festplattenverfügbarkeit %

Dieser Zähler zeigt an, wie ausgelastet das physische Festplatten-Array (keine logische Partition oder einzelne Festplatte im Array) ist. Es bietet ein gutes relatives Maß dafür, wie ausgelastet Ihre Festplatten-Arrays sind.

Als Faustregel gilt, dass der Festplattenzeitzähler weniger als 55 % anzeigen sollte.

Wenn die Zählerstände über kontinuierliche Zeiträume (länger als 10 Minuten während Ihrer 24-Stunden-Überwachung) 55 % überschreiten, kann es sein, dass Ihr SQL Server E/A-Probleme hat. Wenn Sie dieses Verhalten während Ihrer 24-Stunden-Überwachung nur gelegentlich bemerken, würde ich mir keine allzu großen Sorgen machen, aber wenn es häufig auftritt (z. B. mehrmals pro Stunde), würde ich nach Möglichkeiten suchen, die E/A-Leistung zu steigern auf dem Server oder reduzieren Sie die Serverlast. Einige Möglichkeiten zur Erhöhung der Festplatten-I/O bestehen darin, neue Festplatten zum Array hinzuzufügen (falls möglich), die Festplatten durch schnellere zu ersetzen, Cache auf der Controller-Platine hinzuzufügen (falls möglich), verschiedene RAID-Versionen zu verwenden oder einen schnelleren Controller zu installieren .

Bevor Sie diesen Zähler unter NT 4.0 verwenden, müssen Sie ihn manuell aktivieren, indem Sie Folgendes in die Eingabeaufforderung eingeben: „diskperf-y“. Danach müssen Sie Ihren Server neu starten. Daher müssen Sie die Festplattenzähler unter Windows NT 4.0 sofort aktivieren. Wenn Sie Windows 2000 verwenden, ist dieser Zähler standardmäßig aktiviert.

Zusätzlich zur Überwachung des Werts des Zählers „Physical Disk: Disk Uptime“ ist es auch ratsam, den Wert des Zählers für die durchschnittliche Länge der Festplattenwarteschlange (Durchschnittliche Länge der Festplattenwarteschlange) zu überwachen. Wenn dieser Wert für jedes Laufwerk im Array kontinuierlich (länger als 10 Minuten während Ihres 24-Stunden-Überwachungszeitraums) 2 überschreitet, stellt das Array möglicherweise einen Engpass bei der Systemleistung dar. Ähnlich wie beim Festplatten-Timer würde ich mir keine allzu großen Sorgen machen, wenn dies während des 24-Stunden-Überwachungszeitraums gelegentlich vorkommt. Wenn es jedoch häufig vorkommt, würde ich wie beschrieben nach Möglichkeiten suchen, die E/A-Leistung des Servers zu erhöhen über.

Sie müssen diese Zahl berechnen, da Performance Monitor nicht weiß, wie viele physische Festplatten sich in Ihrem Array befinden. Wenn Sie beispielsweise über ein Array mit 6 physischen Festplatten verfügen und die durchschnittliche Warteschlangenlänge für dieses Array 10 beträgt, beträgt die tatsächliche durchschnittliche Festplattenwarteschlange pro Festplatte 1,66 (10/6 = 1,66), was deutlich innerhalb der empfohlenen 2 liegt. mal 1 physische Festplatte.

Bevor Sie diesen Zähler unter NT 4.0 verwenden, müssen Sie ihn unbedingt manuell aktivieren, indem Sie an der NT-Eingabeaufforderung „diskperf-y“ eingeben und dann Ihren Server neu starten. Daher ist es notwendig, die Festplattenzähler sofort nach der Installation von Windows NT 4.0 zu aktivieren. Wenn Sie Windows 2000 verwenden, ist dieser Zähler standardmäßig aktiviert.

Verwenden Sie beide oben beschriebenen Zähler, um genau herauszufinden, ob auf Ihrem Server E/A-Probleme auftreten. Wenn Sie beispielsweise viele Zeiträume sehen, in denen die Festplattenverfügbarkeit mehr als 55 % beträgt und die durchschnittliche Länge der Festplattenwarteschlange mehr als 2 pro physischer Festplatte beträgt, können Sie sicher sein, dass auf dem Server ein E/A-Problem vorliegt.

Prozessor: CPU-Zeit %

Der Zähler „Prozessorobjekt: % Prozessorzeit“ ist für jede CPU verfügbar und schätzt die Auslastung jeder einzelnen CPU. Ein ähnlicher Zähler ist auch für den gesamten Satz zentraler Prozessoren (Gesamtzahl) verfügbar. Dies ist ein wichtiger Zähler zur Überwachung der CPU-Auslastung. Wenn die gesamte Prozessorauslastungszeit für diesen Indikator kontinuierlich 80 % überschreitet (mehr als 10 Minuten während eines 24-Stunden-Überwachungszeitraums), können Sie davon ausgehen, dass die CPU der Systemengpass ist. Wenn diese Belastungsphasen ab und zu auftreten und man meint, damit leben zu können, ist alles in Ordnung. Wenn sie jedoch häufig auftreten, sollten Sie Optionen zur Reduzierung der Serverlast in Betracht ziehen, z. B. den Kauf schnellerer CPUs, die Installation weiterer CPUs oder den Kauf von CPUs mit einem größeren integrierten L2-Cache.

System: Länge der CPU-Warteschlange

Neben dem CPU-Zeitzähler sollten Sie auch den Zähler für die Länge der Prozessorwarteschlange überwachen. Wenn diese Rate für kontinuierliche Zeiträume (länger als 10 Minuten während Ihres 24-Stunden-Überwachungszeitraums) 2 pro CPU überschreitet, liegt wahrscheinlich ein Systemengpass vor. Wenn Ihr Server beispielsweise über 4 CPUs verfügt, sollte die Länge der CPU-Warteschlange insgesamt 8 nicht überschreiten.

Wenn die CPU-Warteschlangenlänge regelmäßig das empfohlene Maximum überschreitet, die CPU-Auslastung jedoch nicht so hoch ist (was der typische Fall ist), sollten Sie erwägen, den Wert des SQL Server-Konfigurationsparameters „Max Worker Threads“ zu reduzieren.

Ein möglicher Grund für die hohe Länge der CPU-Warteschlange ist das Vorhandensein einer übermäßigen Anzahl von Arbeitsthreads, die darauf warten, an die Reihe zu kommen. Wenn Sie ihre Anzahl verringern, was Sie mit diesem Parameter tun, sind Sie gezwungen, Thread-Pooling zu verwenden (falls dies nicht bereits der Fall ist) oder seine Rolle zu erhöhen.

SQL Server-Puffer: Puffer-Cache-Trefferrate

Dieser Indikator (SQL Server-Puffer: Puffer-Cache-Trefferquote) zeigt an, wie oft SQL Server auf den Puffer und nicht auf die Festplatte zugreift, um Daten abzurufen. Bei OLTP-Anwendungen sollte dieses Verhältnis über 90 % liegen, idealerweise größer als 99 %. Wenn Ihre Puffer-Cache-Trefferquote unter 90 % liegt, sollten Sie noch heute mehr RAM kaufen. Wenn dieses Verhältnis zwischen 90 % und 99 % liegt, sollten Sie ernsthaft darüber nachdenken, mehr RAM zu kaufen, denn je näher Sie 99 % kommen, desto schneller läuft Ihr SQL Server. In einigen Fällen, wenn Ihre Datenbank sehr groß ist, können Sie nicht annähernd 99 % erreichen, selbst wenn Sie die maximale RAM-Menge auf Ihrem Server bereitstellen. Dann bleibt Ihnen nur noch, so viel Speicher wie möglich hinzuzufügen und den Status Quo zu akzeptieren.

Bei OLAP-Anwendungen kann das Verhältnis aufgrund der Art der OLAP-Anwendung viel niedriger sein. In jedem Fall sollte eine Erhöhung des Arbeitsspeichers SQL Server beschleunigen.

SQL Server: Benutzerverbindungen

Da die Anzahl der Benutzer von SQL Server die Leistung beeinflusst, wird empfohlen, den Benutzerverbindungszähler zu überwachen (SQL Server General Statistics Object: Benutzerverbindungszähler). Es zeigt die Anzahl der Benutzerverbindungen an, nicht die Anzahl der Benutzer, die zu einem bestimmten Zeitpunkt mit SQL Server verbunden sind.

Wenn dieser Zähler größer als 255 ist, sollten Sie den Konfigurationsparameter „Maximale Arbeitsthreads“ erhöhen, der standardmäßig auf 255 eingestellt ist. Wenn die Anzahl der Verbindungen die Anzahl der verfügbaren Arbeitsthreads übersteigt, beginnt SQL Server mit der gemeinsamen Nutzung von Arbeitsthreads, was sich negativ auswirken kann Schlagleistung. Die Einstellung dieses Parameters sollte höher sein als die maximale Anzahl an Verbindungen, die auf Ihrem Server erreicht werden können.

Was kommt als nächstes?

Obwohl es viel mehr Indikatoren als die von uns behandelten gibt, sind letztere von entscheidender Bedeutung für die Überwachung während des Leistungsprüfungsprozesses. Sobald Sie Ihre Performance Monitor-Analyse abgeschlossen haben, nutzen Sie die Empfehlungen in dieser Artikelserie, um die notwendigen Änderungen vorzunehmen, damit Ihr SQL Server so funktioniert, wie er sollte.

Jeder Datenbankadministrator musste sich wahrscheinlich schon einmal damit auseinandersetzen, dass alles langsam oder gar nicht funktioniert. Als Erstes müssen Sie herausfinden, was derzeit tatsächlich auf SQL Server passiert. Es scheint, dass der Administrator so viele nützliche Dinge in seinem Arsenal hat: einen albernen Aktivitätsmonitor, eine Reihe dynamischer Verwaltungsansichten (DMV), gespeicherte Prozeduren sp_who und sp_who2, übernommen aus den Tagen von SQL Server 7 und SQL Server 2000.
Aber lass es uns herausfinden...

Überwachungstools

Aktivitätsmonitor
Es scheint eine großartige Sache zu sein, es tut genau das, was es tun muss – überwacht die Aktivität. Ich starte einen umfangreichen Buchhaltungsbericht und schaue, was mir der Aktivitätsmonitor anzeigt.
Die Screenshots zeigen einen Aktivitätsmonitor von SQL Server 2005:

Und von SQL Server Denali (2012) CTP 3.


Hmmm. Was wäre, wenn ein Dutzend Leute solche Berichte erstellen würden? Und das ist nicht ungewöhnlich... Es wird ziemlich umständlich sein, es herauszufinden, obwohl der Fortschritt natürlich offensichtlich ist. Im Denali Activity Monitor werden viel mehr nützliche Informationen angezeigt (z. B. auf welche bestimmte Ressource gewartet wird). Außerdem können wir beispielsweise einen Profiler für die gewünschte Sitzung direkt vom Monitor aus starten und diese bereits im Profiler verfolgen , aber verdammt, es lädt zusätzlich und ein bereits überlasteter Server. Darüber hinaus gibt es bereits ein Problem mit den Bremsen, und wir werden die Anfragen nicht sehen, deren Ausführung zum Zeitpunkt des Starts des Profilers bereits begonnen hatte.
Und genau das möchte ich sehen – wer gerade was macht.

sp_who und sp_who2
Der Screenshot zeigt das Ergebnis der Ausführung von sp_who (oben) und sp_who2 (unten), die beim Erstellen desselben unglücklichen Berichts ausgeführt wurden:


Ja. Sehr informativ. Wenn wir uns sp_who ansehen, können wir nur sehen, dass etwas läuft. Natürlich wird es ausgeführt – deshalb schauen wir, aber wir sehen, dass eine Art SELECT ausgeführt wird. Oder mehrere SELECTs.
sp_who2 zeigt weitere Informationen. Jetzt können wir sehen, wie viel Prozessorzeit die Sitzung verbraucht hat (und anscheinend die Gesamtzeit in einer Spalte addieren), die Anzahl der E/A-Vorgänge, den Namen der Datenbank, in der all dies ausgeführt wird, und von wem dies geschieht Sitzung ist blockiert (falls sie blockiert ist).
Der Aktivitätsmonitor liefert, wie wir sehen, mehr Informationen.
DMV
Ab SQL Server 2005 verfügen wir über eine neue Möglichkeit, Informationen über den Status des Servers abzurufen – dynamische Verwaltungsansichten. MSDN sagt Folgendes: „Dynamische Verwaltungsansichten und -funktionen geben Daten zum Serverzustand zurück, die zur Überwachung des Zustands einer Serverinstanz, zur Diagnose von Problemen und zur Optimierung der Leistung verwendet werden können.“
Tatsächlich gibt es in SQL Server 2005 eine Reihe von Ansichten, die sich auf die Ausführung von Abfragen im aktuellen Moment beziehen (es gibt jedoch auch Ansichten zum Anzeigen des „Verlaufs“): Hier sind sie und ihre Zahl nimmt von Version zu Version weiter zu!
Sicherlich haben erfahrene Administratoren eine Reihe von Skripten parat, um Informationen über den aktuellen Status des Servers zu erhalten, aber was tun, wenn Sie noch keine Erfahrung mit dem DMV haben, aber bereits Probleme auftreten?

sp_WhoIsActive

Adam Machanic (SQL Server MVP und MCITP) hat die gespeicherte Prozedur sp_WhoIsActive entwickelt und verbessert sie ständig, die auf denselben DMVs basiert und verdammt einfach zu verwenden ist. Sie können die neueste Version von sp_WhoIsActive herunterladen. Adam selbst hat eine Reihe von Artikeln über sp_WhoIsActive geschrieben, die bis zu 30 (dreißig!) Stücke umfasst. Sie können sie lesen, aber ich werde versuchen, Sie für die Lektüre dieses Materials zu interessieren :).
Wir gehen also davon aus, dass Sie dieses Skript heruntergeladen und auf einem der Testserver ausgeführt haben (auf jeder Version, von 2005 bis Denali). Adam empfiehlt, es in der Datenbank des Mastersystems zu speichern, damit es im Kontext jeder Datenbank aufgerufen werden kann. Dies ist jedoch nicht erforderlich. Wenn Sie es nur im Kontext einer anderen Datenbank aufrufen, müssen Sie den Namen vollständig schreiben – DB .schema.sp_whoIsActive.
Also lasst es uns versuchen. Der Screenshot zeigt das Ergebnis seiner Ausführung beim Erstellen desselben Berichts:

Das Ergebnis der exec sp_whoIsActive-Abfrage passt leider nicht auf einen Bildschirm, daher finden Sie hier eine Textbeschreibung der Ausgabe einer gespeicherten Prozedur, die ohne Parameter aufgerufen wird.
  • - Bei einer aktiven Anfrage wird die Ausführungszeit angezeigt, bei einer „schlafenden“ Sitzung die „Schlafzeit“;
  • - eigentlich Spinne;
  • - zeigt den Text der aktuell ausgeführten Anfrage oder den Text der zuletzt abgeschlossenen Anfrage, wenn die Sitzung schläft;
  • - Nun, Sie verstehen;
  • - eine sehr interessante Kolumne. Die Ausgabe erfolgt im Format (Ax: Bms/Cms/Dms)E. A ist die Anzahl der Aufgaben, die auf Ressource E warten. B/C/D ist die Wartezeit in Millisekunden. Wenn nur eine Sitzung auf die Freigabe einer Ressource wartet (wie im Screenshot), wird deren Wartezeit angezeigt. Wenn es zwei Sitzungen gibt, werden deren Wartezeiten im B/C-Format angezeigt. Wenn 3 oder mehr warten, sehen wir die minimale, durchschnittliche und maximale Wartezeit auf DIESER Ressource im B/C/D-Format;
  • - für eine aktive Anfrage – die gesamte CPU-Zeit, die diese Anfrage verbraucht, für eine schlafende Sitzung – die gesamte CPU-Zeit für die „gesamte Lebensdauer“ dieser Sitzung;
  • – Bei einer aktiven Abfrage ist dies die Anzahl der Schreibvorgänge in TempDB während der Abfrageausführung. für eine schlafende Sitzung – die Gesamtzahl der Datensätze in TempDB für die gesamte Lebensdauer der Sitzung;
  • – für eine aktive Anfrage – die Anzahl der Seiten in TempDB, die dieser Anfrage zugewiesen sind; für eine schlafende Sitzung – die Gesamtzahl der Seiten in TempDB, die während der gesamten Sitzungslebensdauer zugewiesen wurden;
  • - Wenn wir plötzlich von jemandem blockiert werden, wird die Spid (Sitzungs-ID) der Person angezeigt, die uns blockiert hat.
  • – für eine aktive Anfrage – die Anzahl der logischen Lesevorgänge, die bei der Ausführung dieser Anfrage durchgeführt wurden; für eine Schlafsitzung – die Anzahl der Seiten, die während der gesamten Dauer dieser Sitzung gelesen wurden;
  • - Alles ist gleich, aber was die Aufnahme angeht;
  • – für eine aktive Anfrage – die Anzahl der physischen Lesevorgänge, die bei der Ausführung dieser Anfrage durchgeführt wurden; für eine Schlafsitzung – traditionell die Gesamtzahl der physischen Messungen über die gesamte Dauer der Sitzung;
  • – für eine aktive Anfrage – die Anzahl der Acht-Kilobyte-Seiten, die bei der Ausführung dieser Anfrage verwendet werden; für eine Schlafsitzung – wie viele Gesamtspeicherseiten ihr während ihrer gesamten Lebensdauer zugewiesen wurden;
  • - Sitzungsstatus – Laufen, Schlafen usw.;
  • - zeigt die Anzahl der von dieser Sitzung eröffneten Transaktionen an;
  • - zeigt, wenn möglich, den Fortschritt des Vorgangs an (z. B. BACKUP, RESTORE), wird nie zeigen, wie viele Prozent von SELECT abgeschlossen sind.
Die restlichen Spalten in Standardausgabe sp_WhoIsActive sind von geringem Interesse und ich werde sie nicht beschreiben – ihr Zweck ist meiner Meinung nach für jeden klar (Hostname, Datenbankname, Programmname, Startzeit, Anmeldezeit, Anforderungs-ID, Sammlungszeit).

Na und? Das ist alles?

Nein, das ist noch nicht alles. Ich werde auch darüber sprechen, mit welchen (aus meiner Sicht interessantesten und nützlichsten) Parametern Sie sp_WhoIsActive aufrufen können und was dabei herauskommt.
  • @help ist eine schrecklich nützliche Option. Wenn wir sp_whoIsActive @help = 1 aufrufen, erhalten wir Informationen über ALLE Parameter und Ausgabespalten auf dem Bildschirm. Wenn also etwas unklar bleibt, können Sie immer auf „Hilfe“ schauen.
  • @filter_type und @filter – ermöglichen das Filtern des Ausführungsergebnisses. @filter_type kann die Werte „session“, „program“, „database“, „login“ und „host“ annehmen. Im Parameter geben wir an, welches Objekt des ausgewählten Typs uns interessiert. Wir möchten beispielsweise alle Sitzungen sehen, die in der Master-Datenbank laufen. Dazu rufen wir exec sp_whoIsActive @filter_type = "database", = "master" auf. Sie können „%“ im Parameter verwenden;
  • @not_filter_type und @not_filter – ermöglichen uns, „umgekehrt“ zu filtern. Das heißt, wir möchten zum Beispiel alles sehen, außer den Sitzungen, die „Master“ im Feld „Datenbank“ haben. Dazu führen wir exec sp_WhoIsActive @not_filter_type = „database“, @not_filter = „master“ aus. Nun ja, oder wir wollen sehen, was alle Benutzer außer Benutzer sa tun ... Es kann viele Anwendungen geben. Der Parameter @not_filter ermöglicht die Verwendung von „%“;
  • @show_system_spids = 1 – zeigt Informationen zu Systemsitzungen an;
  • @get_full_inner_text = 1 – das Feld sql_text enthält nicht nur den Text der aktuellen Anfrage (Anweisung) im Stapel (Batch), sondern den Text des gesamten Stapels;
  • @get_plans – fügt der Ausgabe eine Spalte mit Abfrageausführungsplänen hinzu;
  • @get_transaction_info = 1 – fügt der Ausgabe die Anzahl und das Volumen der Einträge in den Transaktionsprotokollen sowie die Startzeit der letzten Transaktion hinzu;
  • @get_locks = 1 – fügt der Ausgabe Informationen über alle während der Ausführung der Anfrage angewendeten Sperren hinzu;
  • @find_block_leaders = 1 – verfolgt die Blockierungskette und zeigt die Gesamtzahl der Sitzungen an, die darauf warten, dass die aktuelle Sitzung die Blockierung entfernt;
  • @output_column_list = „[%]“ – was ist, wenn Sie keine tempDB-Informationen in der sp_whoIsActive-Ausgabe sehen möchten? Mit dieser Option können Sie steuern, was ausgegeben wird.
  • @destination_table = „table_name“ – versucht, das Ausführungsergebnis in eine Tabelle einzufügen, prüft jedoch nicht, ob diese Tabelle existiert und ob genügend Rechte zum Einfügen vorhanden sind.

Das ist jetzt alles

Damit verfügen wir über ein weiteres äußerst praktisches und flexibles Tool zur Überwachung der aktuellen Aktivität auf SQL Server. Für den normalen Betrieb sind die Berechtigung VIEW SERVER STATE und die Rechte zum Zugriff auf dmv ausreichend.
Dies lohnt sich auch für den Fall, dass der Server nur über verbunden werden kann

VERWANDTE ARTIKEL