Behandeln von Problemen mit der Anwendungsleistung bei SQL Server

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 224587 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
224587 HOW TO: Troubleshoot Application Performance with SQL Server
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser schrittweise aufgebaute Artikel beschreibt, wie Sie SQL Server-Leistungsprobleme behandeln. Wenn Leistungsprobleme auftreten, muss zur Problembehandlung eine Reihe von Schritten durchgeführt werden, um das Problem einzugrenzen und herauszufinden, weshalb die Anwendung langsamer läuft. Mögliche Ursachen sind:
  • Blockierung.
  • Systemressourcenkonflikt.
  • Probleme mit dem Anwendungsdesign.
  • Eine Konstellation von Abfragen oder gespeicherten Prozeduren mit langen Ausführungszeiten.
Dieser Artikel beschreibt, wie Sie die Ursache eines Leistungsproblems ermitteln. Außerdem verweist er auf weitere Artikel in der Microsoft Knowledge Base, die spezielle Leistungsprobleme detailliert beschreiben, um eine zusätzliche Problembehandlung zu ermöglichen.

SQL Profiler


SQL Profiler ist ein leistungsfähiges Programm zur Behandlung von Leistungsproblemen bei SQL Server 7.0 oder (später) bei Ihrer Anwendung. SQL Profiler ermöglicht Ihnen, alle Ereignisse zu erfassen, die auf dem Server unter einer typischen Auslastung auftreten, und liefert Informationen zu diesen Ereignissen. Durch Verwenden von SQL Profiler zusammen mit dem Microsoft Windows NT-Systemmonitor sowie einiger einfacher Abfragen, um herauszufinden, ob eine Blockierung besteht, erhalten Sie die notwendigen Informationen, um die meisten Leistungsprobleme beheben zu können.

Was überwacht werden sollte

1. Richten Sie SQL Profiler für die Aufzeichnung einer Ablaufverfolgung ein. Gehen Sie hierzu folgendermaßen vor:
  1. Öffnen Sie SQL Profiler.
  2. Klicken Sie im Menü Extras auf Optionen.
  3. Stellen Sie sicher, dass die Optionen Alle Ereignisklassen und Alle Datenspalten gewählt wurden.
  4. Klicken Sie auf OK.
  5. Erstellen Sie eine neue Ablaufverfolgung.
  6. Zeigen Sie im Menü Datei auf Neu, und klicken Sie auf Ablaufverfolgung.
  7. Geben Sie auf der Registerkarte Allgemein einen Namen für die Ablaufverfolgung und eine Datei an, in der die Daten aufgezeichnet werden sollen.
  8. Fügen Sie auf der Registerkarte Ereignisse folgende Ereignistypen zu Ihrer Ablaufverfolgung hinzu:

    Tabelle minimierenTabelle vergrößern
    ÜberschriftHinzuzufügendes EreignisBeschreibung
    CursorsCursorPrepareDieses Ereignis zeigt an, dass ein Cursor für eine SQL-Anweisung unter Verwendung von ODBC, OLEDB oder der DB-Library vorbereitet wurde.
    Fehler und WarnungMissing Column StatisticsDieses Ereignis zeigt an, dass Spaltenstatistiken, die eventuell für den Optimierer nützlich gewesen wären, nicht verfügbar waren. Die Spalte Text zeigt die Liste der Spalten mit fehlenden Statistiken. Dieses Ereignis zeigt zusammen mit einem Ereignis Misc: Auto-UpdateStats an, dass die Option Statistiken automatisch erstellen ausgelöst wurde.
    Versch.AttentionDieses Ereignis zeigt an, dass ein Warnungssignal von einem Client gesendet wurde.
    Versch.Auto-UpdateStatsDieses Ereignis zeigt an, dass die Option Statistiken automatisch aktualisieren ausgelöst wurde.
    Versch.Exec Prepared SQLDieses Ereignis zeigt an, dass ODBC, OLE DB oder die DB-Library eine oder mehrere zuvor vorbereitete Transact-SQL-Anweisungen ausgeführt hat.
    Versch.Execution PlanDieses Ereignis zeigt die Planungsstruktur der ausgeführten Transact-SQL-Anweisung an.
    Versch.Prepare SQLDieses Ereignis zeigt an, dass eine ODBC-, OLE DB- oder DB-Library-Anwendung eine oder mehrere Transact-SQL-Anweisungen für die Verwendung vorbereitet hat.
    Versch.Unprepare SQLDieses Ereignis zeigt an, dass eine ODBC-, OLE DB- oder DB-Library-Anwendung die Vorbereitung einer oder mehrerer Transact-SQL-Anweisungen für die Verwendung aufgehoben hat.
    SitzungenConnectDieses Ereignis zeigt an, dass eine neue Verbindung hergestellt wurde.
    SitzungenDisconnectDieses Ereignis zeigt an, dass ein Client getrennt wurde.
    SitzungenExisting ConnectionDieses Ereignis zeigt an, dass eine Verbindung bestand, als die SQL-Profilerablaufverfolgung gestartet wurde.
    Gespeicherte ProzedurenSP: CompletedDieses Ereignis zeigt an, wann die Ausführung einer gespeicherten Prozedur abgeschlossen wurde.
    Gespeicherte ProzedurenSP: RecompileDieses Ereignis zeigt an, dass eine gespeicherte Prozedur während der Ausführung neu kompiliert wurde.
    Gespeicherte ProzedurenSP: StartingDieses Ereignis zeigt an, wann die Ausführung einer gespeicherten Prozedur gestartet wurde.
    Gespeicherte ProzedurenSP: StmtCompletedDieses Ereignis zeigt an, wann die Ausführung einer Anweisung in einer gespeicherten Prozedur abgeschlossen wurde.
    TSQL:SQL:BatchCompletedDieses Ereignis zeigt an, dass ein Transact-SQL-Batch abgeschlossen wurde. Die Spalte Text zeigt die ausgeführte Anweisung.
    TSQL:SQL:StmtCompletedDieses Ereignis zeigt an, dass eine Transact-SQL-Anweisung abgeschlossen wurde. Die Spalte Text zeigt die ausgeführte Anweisung.
    TSQL:RPC:CompletedDieses Ereignis zeigt an, dass ein Remoteprozeduraufruf (RPC) abgeschlossen wurde.
  9. Wenn Ihre Anwendung nicht mehr reagiert (hängt), oder Timeoutfehler oder andere Ereignisse auftreten, die dazu führen, dass die problematischen Anweisungen nie abgeschlossen werden, fügen Sie auch die folgenden Ereignisse hinzu:

    Tabelle minimierenTabelle vergrößern
    TSQL:SQL:BatchStartingDieses Ereignis zeigt an, dass ein Transact-SQL-Batch gestartet wurde. Die Spalte Text zeigt die ausgeführte Anweisung.
    TSQL:SQL:StmtStartingDieses Ereignis zeigt an, dass eine Transact-SQL-Anweisung gestartet wurde. Die Spalte Text zeigt die ausgeführte Anweisung.
    TSQL:RPC:StartingDieses Ereignis zeigt an, dass ein Remoteprozeduraufruf (RPC) gestartet wurde.
    Gespeicherte ProzedurenSP: StmtStartingDieses Ereignis zeigt an, wann die Ausführung einer Anweisung in einer gespeicherten Prozedur gestartet wird.


    Auf diese Weise kann sichergestellt werden, dass Sie die Anweisung sehen, die beim Auftreten des Timeouts ausgeführt wurde.
  10. Stellen Sie sicher, dass auf der Registerkarte Datenspalten die folgenden Spalten beinhaltet sind:

    Für SQL Server 2000

    Start Time

    End Time

    LoginSid

    SPID

    Event Class

    TextData

    IntegerData

    BinaryData

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    DBUserName


    Für SQL Server 7.0

    Start Time

    End Time

    Connection ID

    SPID

    Event Class

    Text

    Integer Data

    Binary Data

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    SQL User Name

Informationen zur Verwendung von SQL Profiler finden Sie in der Onlinedokumentation zu SQL Server 7.0 und SQL Server 2000.


2. Verwenden Sie den Systemmonitor, um Windows NT- und SQL Server-Leistungsindikatoren aufzuzeichnen. Gehen Sie hierzu folgendermaßen vor:
  1. Starten Sie den Windows NT-Systemmonitor.
  2. Klicken Sie im Menü Ansicht auf Protokoll.
  3. Klicken Sie im Menü Optionen auf Protokoll.
  4. Geben Sie einen Dateinamen und einen Speicherort für die Protokollierung der Leistungsindikatoren an. Sie können das Aktualisierungsintervall entsprechend anpassen.
  5. Klicken Sie im Menü Bearbeiten auf Protokoll erweitern.
  6. Fügen Sie alle Objekte hinzu, sowohl die Windows NT- als auch die SQL Server-Objekte.
  7. Klicken Sie zum Starten der Protokollierung im Menü Optionen auf Protokoll und anschließend auf die Schaltfläche Protokollierung starten.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
150934 Erstellen eines Systemmonitorprotokolls für die NT-Problembehandlung

3. Überprüfen Sie, ob eine Blockierung besteht.

Führen Sie die gespeicherte Systemprozedur sp_who aus, um festzustellen, ob eine Blockierung besteht.
exec sp_who
Diese Ausgabe enthält eine Spalte blk. Untersuchen Sie die Ausgabe auf Einträge ungleich Null, die anzeigen, dass eine Blockierung besteht. Führen Sie diese Prozedur regelmäßig im gesamten Zeitrahmen durch, in dem der Leistungsverlust auftritt.

Hinweis: Die Ausführung der gespeicherten Systemprozedur sp_who dient zur Überprüfung, ob eine Blockierung besteht. Normalerweise liefert sie nicht genügend Informationen für eine vollständige Behandlung eines Blockierungsproblems. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
251004 INF: Überwachen von SQL Server 7.0-Blockierungen

Ausführen der Anwendung unter typischer Auslastung

Idealerweise sollte die Ausgabe von SQL Profiler, Systemmonitor und Blockierungsprüfung während desselben Zeitrahmens aufgezeichnet werden. Dieser Zeitrahmen muss einen Zeitpunkt einschließen, bei dem die Anwendungsleistung sich verschlechtert. Mithilfe der Kombination dieser Informationen erhalten Sie ein klareres Bild davon, wo der Leistungsabfall eintritt.


Interpretieren der Ergebnisse

  1. Überprüfen Sie, ob eine Blockierung besteht.

    Wenn die Spalte blk in der Ausgabe sp_who ungleich Null ist, zeigt dies an, dass auf Ihrem System eine Blockierung besteht. Wenn Prozesse sich gegenseitig blockieren, können die blockierten Prozesse längere Ausführungszeiten haben. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    224453 INF: Verstehen und Lösen von Blockierproblemen in SQL Server 7.0 und SQL Server 2000
  2. Untersuchen Sie die SQL Profiler-Ausgabe.

    Bei der Lösung von Leistungsproblemen ist die effiziente Auswertung der SQL Profiler-Daten von entscheidender Bedeutung. Dabei ist vor allem wichtig, dass Sie nicht alle erfassten Daten analysieren müssen; treffen Sie eine Auswahl. SQL Profiler liefert Ihnen Möglichkeiten, die erfassten Daten effektiv zu analysieren. Auf der Registerkarte Eigenschaften (klicken Sie im Menü Datei auf Eigenschaften) können Sie die angezeigten Daten durch Ein-/Ausblenden von Datenspalten oder Ereignissen, durch Gruppierung (Sortierung) der Daten und durch Anwendung von Filtern eingrenzen. Sie können die gesamte Ablaufverfolgung oder nur eine spezielle Spalte nach speziellen Werten durchsuchen (klicken Sie im Menü Bearbeiten auf Suchen). Sie können die SQL Profiler-Daten auch in einer SQL Server-Tabelle speichern (zeigen Sie im Menü Datei auf Speichern unter, und klicken Sie auf Ablaufverfolgungstabelle) und dann SQL-Abfragen in der Tabelle ausführen.

    Achten Sie darauf, die Filter nur auf eine bereits gespeicherte Ablaufverfolgungsdatei anzuwenden. Wenn Sie diese Schritte auf eine aktive Ablaufverfolgung anwenden, riskieren Sie den Verlust von Daten, die seit Beginn der Ablaufverfolgung aufgezeichnet wurden. Speichern Sie eine aktive Ablaufverfolgung zuerst als Datei oder Tabelle (klicken Sie im Menü Datei auf Speichern unter), und öffnen Sie sie anschließend wieder (klicken Sie im Menü Datei auf Öffnen), bevor Sie fortfahren. Wenn Sie an einer gespeicherten Ablaufverfolgungsdatei arbeiten, werden die ausgefilterten Daten durch den Filtervorgang nicht permanent entfernt, sondern einfach nur ausgeblendet. Sie können Ereignisse und Datenspalten je nach Bedarf hinzufügen und entfernen, um Ihre Suche besser einzugrenzen.

    Der erste Schritt bei der Untersuchung von SQL Profiler-Ablaufverfolgungsdateien besteht darin zu ermitteln, wo die verschiedenen Ereignistypen auf dem Server auftreten.

    Gruppieren der Ablaufverfolgung nach Ereignisklasse:

    a. Klicken Sie im Menü Datei auf Eigenschaften.

    b. Verwenden Sie auf der Registerkarte Datenspalten die Aufwärts-Schaltfläche, um Ereignisklasse unter die Überschrift Gruppen zu verschieben, und die Abwärts-Schaltfläche, um alle anderen Spalten unter der Überschrift Gruppen zu entfernen.

    c. Klicken Sie auf OK.

    Die Gruppierung nach der Spalte Ereignisklasse zeigt, welche Ereignistypen wie häufig auf SQL Server auftreten. Durchsuchen Sie diese Spalte nach den folgenden Ereignissen:

    SP:RECOMPILE

    Dieses Ereignis zeigt an, dass eine gespeicherte Prozedur während der Ausführung neu kompiliert wurde. Mehrere Neukompilierungs-Ereignisse zeigen an, dass SQL Server Ressourcen für die Abfragekompilierung statt für die Abfrageausführung aufwendet.

    Weitere Informationen zur Problembehandlung bei der Neukompilierung von gespeicherten Prozeduren finden Sie in folgendem Artikel der Microsoft Knowledge Base:
    243586 Beheben eines Kompilierung der gespeicherten Prozedur


    Attention

    Ein Warnungssignal zeigt an, dass eine Abfrage durch einen Client abgebrochen wurde. Dies hat in der Regel eine von zwei Ursachen:

    Der Benutzer hat die Abfrage bewusst abgebrochen oder die Anwendung beendet.

    -oder-

    Ein Abfragetimeout wurde überschritten.

    Die Anzeige von Warnungssignalen kann bedeuten, dass bestimmte Abfragen langsam ausgeführt werden.

    Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    243589 SO WIRD'S GEMACHT: Fehlerbehandlung bei langsamen Abfragen auf SQL Server 7.0 oder höher
    Zum Identifizieren der Abfrage, für die das Warnungssignal angezeigt wurde, ändern Sie die Ablaufverfolgung, sodass sie nicht nach einer Datenspalte gruppiert ist, und filtern Sie nach der Systemprozess-ID (SPID), die das Signal empfangen hat (setzen Sie auf der Registerkarte Filter SPID auf x). Das Ereignis SQL:StmtStarting, SQLBatchStarting oder SP:StmtStarting, das dem Warnungssignal unmittelbar vorausgeht, ist die Abfrage, bei der der Timeout oder Abbruch stattgefunden hat. Sie können die Spalte Event Class nach dem Attention-Ereignis durchsuchen, um es schnell zu finden (klicken Sie im Menü Bearbeiten auf Suchen).

    PREPARE SQL und EXEC PREPARED SQL

    Das Ereignis Prepare SQL zeigt an, dass eine ODBC-, OLE DB- oder DB-Library-Anwendung eine oder mehrere Transact-SQL-Anweisungen für die Verwendung vorbereitet hat. Das Ereignis Exec Prepared SQL zeigt an, dass die Anwendung eine vorbereitete Anweisung verwendet hat, um einen Befehl auszuführen.

    Vergleichen Sie die Häufigkeit des Auftretens der beiden Ereignisse. Idealerweise muss eine Anwendung eine SQL-Anweisung einmal vorbereiten und mehrere Male ausführen. Dies erspart dem Optimierer den Aufwand, jedesmal einen neuen Plan zu kompilieren, wenn die Anweisung ausgeführt wird. Daher sollte die Anzahl der Exec Prepared SQL-Ereignisse viel größer als die Anzahl der Prepare SQL-Ereignisse sein. Wenn die Anzahl der Prepare SQL-Ereignisse ungefähr so groß ist wie die Anzahl der Exec Prepared SQL-Ereignisse, kann dies bedeuten, dass die Anwendung das Modell Prepare/Execute schlecht nutzt. Am besten sollte keine Anweisung vorbereitet werden, die nur einmal ausgeführt werden wird. Weitere Informationen zum Vorbereiten von SQL-Anweisungen finden Sie in der SQL Server 7.0-Onlinedokumentation unter dem Thema "Preparing SQL Statements" (Vorbereiten von SQL-Anweisungen).

    Wenn die Anzahl der Exec Prepared SQL-Ereignisse nicht drei- bis fünfmal größer ist als die Anzahl der Prepare SQL-Ereignisse, kann dies bedeuten, dass die Anwendung das Modell Prepare/Execute nicht effizient nutzt. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
    243588 Kann die Leistung von Ad-Hoc-Abfragen in SQL Server wie beheben

    In SQL Server 2000 werden die übermäßigen Roundtrips pro Prepare/Execute eliminiert, sodass der Faktor 3-5 nicht ganz so streng anzuwenden ist. Es kann aber dennoch eine gute Richtlinie sein, zu versuchen, den vorbereiteten Plan mehr als einmal zu verwenden.

    Missing Column Statistics

    Dieses Ereignis zeigt an, dass statistische Informationen, die der Optimierer zum Generieren eines besseren Abfrageplans hätte verwenden können, nicht verfügbar waren. Dies weist darauf hin, dass die Abfrage keine brauchbaren Indizes für mindestens eine beteiligte Tabelle hat. Es fehlt nicht nur ein brauchbarer Index, sondern SQL Server fehlen auch statistische Daten zu den beteiligten Spalten, sodass keine fundierte Entscheidung über einen Abfrageplan getroffen werden kann. Dies führt dazu, dass der generierte Abfrageplan möglicherweise nicht optimal ist. Wenn Sie diese Ereignisse sehen, untersuchen Sie die Abfrage und den generierten Ausführungsplan, und richten Sie sich zum Verbessern der Leistung dieser Abfrage nach den Schritten im folgenden Artikel der Microsoft Knowledge Base:
    243589 SO WIRD'S GEMACHT: Fehlerbehandlung bei langsamen Abfragen auf SQL Server 7.0 oder höher

    Wenn Sie Missing Column Statistics-Ereignisse sehen, konzentrieren Sie sich zunächst auf die Ereignisse, die mit langsamen Abfragen verbunden sind. Einige Ereignisse werden möglicherweise von SQL Server mit AutoStats generiert und automatisch gelöst, sodass kein Eingreifen des Benutzers erforderlich ist. Daher ist es die beste Strategie, sich zunächst auf langsame Abfragen zu konzentrieren, wie weiter unten in diesem Artikel gezeigt wird, und darauf zu achten, ob Missing Column Statistics-Ereignisse damit verbunden sind.

    Wenn Sie keine Instanzen dieser Ereignisklassen sehen, sollten Sie im nächsten Schritt ermitteln, wo die übermäßige Zeit aufgewendet wird.

    Gruppieren der Ablaufverfolgungs-Ausgabe nach Dauer:

    a. Klicken Sie im Menü Datei auf Eigenschaften.

    Verwenden Sie auf der Registerkarte Datenspalten die Aufwärts-Schaltfläche, um Dauer unter die Überschrift Gruppen zu verschieben, und die Abwärts-Schaltfläche, um alle anderen Spalten unter der Überschrift Gruppen zu entfernen.

    c. Entfernen Sie auf der Registerkarte Ereignisse alle Gruppen außer TSQL und Gespeicherte Prozeduren.

    d. Klicken Sie auf OK.

    Durch Gruppieren nach Dauer können Sie einfach sehen, welche SQL-Anweisungen, -Batches oder -Prozeduren am langsamsten ausgeführt werden. Es ist sehr wichtig, nicht nur auf den Zeitpunkt zu achten, an dem das Problem auftritt, sondern auch eine Basislinie mit guter Leistung zu finden, anhand der ein Vergleich durchgeführt werden kann. Sie können nach Startzeit filtern, um die Ablaufverfolgung in Abschnitte mit guter Leistung und einen separaten Abschnitt mit schlechter Leistung aufzuschlüsseln. Suchen Sie nach Abfragen mit der längsten Dauer bei guter Leistung. Diese sind wahrscheinlich die Ursache des Problems. Wenn die gesamte Systemleistung herabgesetzt ist, können selbst gute Abfragen langsam sein, da sie auf Systemressourcen warten müssen.

    Wenn Sie eine geringe Anzahl von langsamen Abfragen sehen, lesen Sie den folgenden Artikel in der Microsoft Knowledge Base:
    243589 SO WIRD'S GEMACHT: Fehlerbehandlung bei langsamen Abfragen auf SQL Server 7.0 oder höher
    Wenn Sie feststellen, dass die Dauer einzelner Abfragen niedrig ist, es aber mehrere davon gibt, und der Leistungsindikator SQL-Kompilierungen/Sekunde in der Systemmonitor-Ausgabe (siehe Beschreibung weiter unten) hoch ist, lesen Sie den folgenden Artikel in der Microsoft Knowledge Base:
    243588 Kann die Leistung von Ad-Hoc-Abfragen in SQL Server wie beheben
    Untersuchen der verbleibenden Datenspalten:

    Weitere Hinweise auf die Ursachen eines Leistungsproblems können Sie durch Anzeigen der anderen Datenspalten in den Ablaufverfolgungsdaten erhalten. Dabei sind einige Dinge zu beachten:

    Wenn die CPU-Auslastung hoch ist, gruppieren Sie nach CPU, um zu sehen, welche Abfragen die meiste CPU-Zeit beanspruchen. Suchen Sie in der Spalte Text nach "hash" oder "merge", um herauszufinden, welcher Abfrageausführungsplan diese Verknüpfungstypen verwendet. Sie sind CPU- und Speicher-intensiver als eine Nested Loop-Verknüpfung, die normalerweise E/A-intensiv ist.

    Wenn Datenträger-E/A der Engpass ist, gruppieren Sie nach Lese- und Schreibvorgängen (Reads und Writes). Zeigen Sie die Felder Application Name, NT User Name und SQL User Name an, um die Ursache einer langsamen Abfrage zu isolieren.

    Die Spalte "Integer Data" des Exception-Ereignisses zeigt alle Fehler an, die an den Client zurückgegeben wurden. Sie können den Text der Fehlermeldung finden, indem Sie in der SQL Server 7.0-Onlinedokumentation nach der Nummer suchen.

    Anhand des Felds Connection ID können Sie sicherstellen, dass Sie dieselben Sitzungen für einen bestimmten Client untersuchen. Eine SPID kann dies nicht garantieren, da möglicherweise ein Benutzer die Verbindung getrennt hat und ein neuer Benutzer eine Verbindung hergestellt und dieselbe SPID erhalten hat.

    Der Nutzen dieser Felder kann je nach Szenario unterschiedlich sein. Dennoch sollten diese Felder untersucht werden, wenn die aussagekräftigeren Felder weiter oben in diesem Artikel keine Antwort bieten.
  3. Untersuchen Sie die Systemmonitor-Ausgabe.

    Der Systemmonitor zeigt einen Überblick über die Systemengpässe. Es kann sein, dass SQL Server und die Anwendung die erwartete Leistung zeigen, die Computerleistung jedoch niedrig ist, weil Arbeitsspeicher oder andere Ressourcen fehlen. Bestimmte Leistungsindikatoren können auch auf Probleme mit der SQL Server- oder Anwendungsleistung hinweisen. Überprüfen Sie zumindest die folgenden Leistungsindikatoren:

  • Objekt: Prozess

    Leistungsindikator: Prozessor

    Instanz: SQL Server

  • Objekt: Prozessor

    Leistungsindikator: % Prozessorzeit

    Instanz: Überprüfen Sie jede Prozessorinstanz

  • Objekt: Physikalischer Datenträger

    Leistungsindikator: Durchschnittl. Warteschlangenlänge des Datenträgers

    Instanz: Überprüfen Sie jede physikalische Datenträger-Instanz

  • Objekt: SQL Server:SQL-Statistik

    Leistungsindikator: SQL-Kompilierungen/Sekunde
Suchen Sie in dem Zeitrahmen, in dem die Leistung sich verschlechtert hat, nach einem Trend: was hat sich zuerst erhöht? Ist der Computer CPU-gebunden oder Datenträger-E/A-gebunden? Diese Informationen zusammen mit der Profiler-Ausgabe weiter oben in diesem Artikel sollten Ihnen helfen, die Problembereiche einzugrenzen. Probleme mit hoher CPU-Auslastung können auf eine große Anzahl von Neukompilierungen gespeicherter Abfragen oder Kompilierungen von Ad-hoc-Abfragen oder auf eine intensive Verwendung von Hash- und Zusammenführungsverknüpfungen hinweisen. Richten Sie sich nach den Anleitungen in den weiter oben in diesem Artikel genannten Artikeln, um die richtige Vorgehensweise zu bestimmen. Hohe Datenträger-Warteschlangenlängen können darauf hinweisen, dass mehr Systemspeicher oder ein verbessertes Datenträgerteilsystem benötigt wird.

Eigenschaften

Artikel-ID: 224587 - Geändert am: Freitag, 26. Oktober 2007 - Version: 4.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 7.0 Standard Edition
Keywords: 
kbhowto kbhowtomaster kbinfo kbproductlink KB224587
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com