Freigeben über

Problembehandlung für die gesamte SQL Server- oder Datenbankanwendung, langsam zu sein scheint

Gilt für: SQL Server

Wenn Sie Abfragen für eine SQL Server-Instanz oder eine bestimmte Anwendung ausführen, sind alle Abfragen langsam. Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

Schritt 1: Behandeln von Anwendungsproblemen

Überprüfen Sie die Anwendungsschicht. Führen Sie eine Abfrage aus der Anwendung aus, führen Sie sie manuell in einer SQL Server-Instanz aus, und sehen Sie, wie sie ausgeführt wird. Testen Sie auf diese Weise mehrere Abfragen. Wenn Abfragen in der SQL Server-Instanz schneller sind, kann sich das Problem auf der Ebene der Anwendungs- oder Anwendungsserver befinden.

Notiz

Beachten Sie die Unterschiede bei der Abfrageleistung zwischen Datenbankanwendung und SSMS.

Wenn die Anwendung auf einem anderen Server ausgeführt wird, überprüfen Sie die Leistung des Anwendungsservers (siehe Schritt 2: Behandeln von Betriebssystemproblemen zur Problembehandlung). Möglicherweise müssen Sie das Anwendungsentwicklungsteam einbeziehen, um nach Problemen mit der Anwendung zu suchen.

Schritt 2: Behandeln von Betriebssystemproblemen

Überprüfen Sie, ob das Betriebssystem, auf dem SQL Server ausgeführt wird, langsam reagiert. Die Maus wird z. B. langsam verschoben, Fenster reagieren nicht länger, der Remotedesktopzugriff auf den Server ist langsam, oder die Verbindung mit einer Freigabe auf dem Server ist langsam.

Dieses Problem kann durch einen anderen Dienst oder eine andere Anwendung verursacht werden. Verwenden Sie Perfmon zur Problembehandlung.

Informationen zu anderen Betriebssystemleistungsproblemen finden Sie in der Dokumentation zur Problembehandlung bei der Windows Server-Leistung.

Häufige Probleme sind beispielweise:

Dieses Problem kann durch andere Anwendungen, das Betriebssystem oder treiber verursacht werden, die auf dem System ausgeführt werden.

Um dieses Problem zu beheben, verwenden Sie den Task-Manager, Leistungsmonitor oder den Ressourcenmonitor, um dieses Problem zu identifizieren. Weitere Informationen finden Sie unter Anleitung zur Problembehandlung bei hoher CPU-Auslastung.

Schritt 3: Behandeln von Netzwerkproblemen

Das Problem könnte sich in der Netzwerkschicht befinden, was zu einer langsamen Kommunikation zwischen der Anwendung und SQL Server führt. Verwenden Sie die folgenden Methoden, um dieses Problem zu beheben:

  • Ein Symptom davon könnte ASYNC_NETWORK_IO auf der SQL Server-Seite warten. Weitere Informationen finden Sie unter Problembehandlung für langsame Abfragen, die aus ASYNC_NETWORK_IO Wartetyp resultieren.

  • Arbeiten Sie mit Ihrem Netzwerkadministrator zusammen, um nach Netzwerkproblemen (Firewall, Routing usw.) zu suchen.

  • Sammeln Sie eine Netzwerkablaufverfolgung , und überprüfen Sie die Netzwerkzurücksetzungs- und Erneutübertragungsereignisse. Informationen zur Problembehandlung finden Sie unter "Intermittierendes oder regelmäßiges Netzwerkproblem".

  • Aktivieren Sie Perfmon-Leistungsindikatoren, um die Netzwerkleistung auf Netzwerkschnittstellenebene (NIC) zu überprüfen. Es sollten keine verworfenen Pakete und Fehlerpakete vorhanden sein. Überprüfen Sie die Netzwerkschnittstellenbandbreite:

    • Netzwerkschnittstelle\Empfangene Pakete verworfen
    • Netzwerkschnittstelle\Empfangene Pakete
    • Netzwerkschnittstelle\Ausgehende Pakete verworfen
    • Netzwerkschnittstelle\Ausgehende Pakete
    • Netzwerkschnittstelle\Bytes Gesamt/Sek.
    • Netzwerkschnittstelle\Aktuelle Bandbreite

Schritt 4: Behandeln von Problemen mit hoher CPU-Auslastung in SQL Server

Wenn CPU-intensive Abfragen auf dem System ausgeführt werden, können sie dazu führen, dass andere Abfragen von CPU-Kapazität ausgehungert werden. Häufiger kann jedoch eine hohe CPU-Auslastung, die aus Abfragen stammt, ein Hinweis darauf sein, dass Abfragen optimiert werden müssen. Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Ermitteln Sie zunächst, ob SQL Server eine hohe CPU-Auslastung verursacht (mit Perfmon-Leistungsindikatoren).
  2. Identifizieren Sie Abfragen, die zur CPU-Auslastung beitragen.
  3. Aktualisieren der Statistik
  4. Fehlende Indizes hinzufügen.
  5. Untersuchen und beheben Sie parametersensitive Probleme.
  6. Untersuchen und Beheben von SARGability-Problemen.
  7. Deaktivieren Sie die schwere Ablaufverfolgung.
  8. Fix SOS_CACHESTORE spinlock contention.
  9. Konfigurieren Sie Ihren virtuellen Computer.
  10. Skalieren Sie das System, indem Sie weitere CPUs hinzufügen.

Ausführliche Schritte zur Problembehandlung finden Sie unter "Behandeln von Problemen mit hoher CPU-Auslastung" in SQL Server.

Schritt 5: Behandeln von Problemen mit übermäßiger E/A-Ursache in SQL Server

Ein weiterer häufiger Grund für die wahrgenommene Gesamtverlangsamung von SQL Server-Workloads sind E/A-Probleme. Die E/A-Langsamkeit kann sich auf die meisten oder alle Abfragen im System auswirken. Verwenden Sie die folgenden Methoden, um das Problem zu beheben:

  • Auf Hardwareprobleme überprüfen:

    • SAN-Fehlkonfiguration (Schalter, Kabel, HBA, Speicher).
    • Überschrittene E/A-Kapazität (nicht ausgeglichen im gesamten SAN-Netzwerk, nicht nur Back-End-Speicher, Überprüfen des E/A-Durchsatzes aller Server, die das SAN nutzen).
    • Treiber oder Firmwareprobleme oder Updates.

  • Suchen Sie nach suboptimalen SQL Server-Abfragen, die viele E/A-Vorgänge verursachen und Datenträgervolumes mit E/A-Anforderungen sättigungen.

    • Suchen Sie die Abfragen, die eine hohe Anzahl von logischen Lesevorgängen (oder Schreibvorgängen) verursachen, und optimieren Sie diese Abfragen so, dass Datenträger-E/A mit entsprechenden Indizes minimiert wird, ist der erste Schritt.
    • Halten Sie Statistiken auf dem neuesten Stand, da sie den Abfrageoptimierer mit ausreichenden Informationen bereitstellen, um den besten Plan auszuwählen.
    • Das Neugestalten von Abfragen und manchmal tabellen kann bei verbesserten E/A-Vorgängen hilfreich sein.

  • Filtertreiber: Die SQL Server-E/A-Antwort kann stark beeinträchtigt werden, wenn Dateisystemfiltertreiber schwere E/A-Datenverkehr verarbeiten.

    • Schließen Sie Datenordner von der Virenüberprüfung aus und haben Filtertreiberprobleme, die von Softwareanbietern korrigiert wurden, um eine Auswirkung auf die E/A-Leistung zu verhindern.

  • Andere Anwendungen: Eine andere Anwendung auf demselben Computer mit SQL Server kann den E/A-Pfad mit übermäßigen Lese- oder Schreibanforderungen sättigungen. Diese Situation kann das E/A-Subsystem über Kapazitätsgrenzen hinausschieben und die E/A-Langsamkeit für SQL Server verursachen. Identifizieren Sie die Anwendung, und optimieren Sie sie, oder verschieben Sie sie an eine andere Stelle, um ihre Auswirkung auf den E/A-Stapel zu beseitigen. Dieses Problem kann auch durch Anwendungen verursacht werden, die auf anderen Computern ausgeführt werden, aber das gleiche SAN mit diesem SQL Server-Computer gemeinsam nutzen. Arbeiten Sie mit Ihrem SAN-Administrator zusammen, um E/A-Datenverkehr auszugleichen (siehe Überprüfen auf Hardwareprobleme).

Ausführliche Informationen zur Problembehandlung von E/A-bezogenen Problemen mit SQL Server finden Sie unter Problembehandlung bei langsamer SQL Server-Leistung, die durch E/A-Probleme verursacht wird.

Schritt 6: Behandeln von Speicherproblemen

Geringer Arbeitsspeicher auf dem System insgesamt oder innerhalb von SQL Server kann zu einer Langsamkeit führen, wenn Abfragen auf Speichererteilungen (RESOURCE_SEMAPHORE) oder Kompilierungsspeicher (RESOURCE_SEMAPHORE_QUERY_COMPILE) warten. Verwenden Sie die folgenden Methoden, um das Problem zu beheben:

  • Überprüfen Sie mithilfe von Perfmon-Zählern auf externem Arbeitsspeicher auf Betriebssystemebene:

    • Arbeitsspeicher\Verfügbare MBytes
    • Prozess(*)\Arbeitssatz (alle Instanzen)
    • Process(*)\Private Bytes (alle Instanzen)

  • Verwenden Sie für internen Speicherdruck SQL Server-Abfragen, um sys.dm_os_memory_clerks abzufragen oder DBCC MEMORYSTATUS zu verwenden.

  • Überprüfen Sie das SQL Server-Fehlerprotokoll auf 701 Fehler.

Ausführliche Schritte zur Problembehandlung finden Sie unter Problembehandlung bei nicht genügend Arbeitsspeicher oder geringem Arbeitsspeicher in SQL Server.

Schritt 7: Behandeln von Blockierungsproblemen

Die Sperrerfassung wird verwendet, um Ressourcen in einem Datenbanksystem zu schützen. Wenn Sperren lange erworben werden, und andere Sitzungen enden auf diese Sperren, stehen Sie vor einem Blockierungsszenario.

Das kurze Blockieren erfolgt auf Datenbanksystemen wie SQL Server immer. Aber eine längere Blockierung, insbesondere wenn die meisten oder alle Abfragen auf eine Sperre warten, kann dazu führen, dass der gesamte Server als nicht reagiert.

Führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Identifizieren Sie die Kopfblockierungssitzung, indem Sie die Spalte blocking_session_id in sys.dm_exec_requests DMV-Ausgabe oder die Spalte BlkBy in der Ausgabe gespeicherter sp_who2 Prozeduren betrachten.

  2. Suchen Sie die Abfrage(en), die von der Kopfblockierungskette ausgeführt wird (was Sperrungen für einen längeren Zeitraum hält).

    Wenn keine Abfragen aktiv auf der Kopfblockierungssitzung ausgeführt werden, könnte eine verwaiste Transaktion aufgrund von Anwendungsproblemen aufgetreten sein.

  3. Entwerfen Oder optimieren Sie die Kopfblockierungsabfrage so, dass sie schneller ausgeführt wird, oder verringern Sie die Anzahl der Abfragen innerhalb einer Transaktion.

  4. Überprüfen Sie die in der Abfrage verwendete Transaktionsisolation, und passen Sie sie an.

Ausführliche Problembehandlung für Blockierungsszenarien finden Sie unter Grundlegendes und Beheben von SQL Server-Blockierungsproblemen.

Schritt 8: Behandeln von Problemen mit dem Planer (Nichtertragung, Deadlocked Scheduler, nicht erreichter IOCP-Listener, Ressourcenmonitor)

SQL Server verwendet einen kooperativen Planungsmechanismus (Schedulers), um seine Threads für die Planung auf der CPU für das Betriebssystem verfügbar zu machen. Wenn Probleme im Zusammenhang mit SQL-Schedulern auftreten, können SQL Server-Threads die Verarbeitung von Abfragen, Anmeldungen, Abmelden usw. beenden. Daher scheint SQL Server je nachdem, wie viele Planer betroffen sind, möglicherweise nicht mehr reagiert, teilweise oder vollständig. Planerprobleme können sich aus einer Vielzahl von Problemen ergeben, einschließlich Produktfehlern, externen und Filtertreibern und Hardwareproblemen.

Führen Sie die folgenden Schritte aus, um diese Probleme zu beheben:

  1. Überprüfen Sie das SQL Server-Fehlerprotokoll auf Fehler wie die folgenden zum Zeitpunkt der gemeldeten fehlenden Antwort von SQL Server:

    • ***********************************************
*
* BEGIN STACK DUMP:
* 03/10/22 21:16:35 spid 22548
*
* Non-yielding Scheduler
*
***********************************************

    • **********************************************
*
* BEGIN STACK DUMP:
* 03/25/22 08:50:29 spid 355
*
* Deadlocked Schedulers
*
* ********************************************


    • * *******************************************************************************                                
*                                                                                                                
* BEGIN STACK DUMP:                                                                                              
* 09/07/22 23:01:04 spid 0                                                                                     
*                                                                                                                
* Non-yielding IOCP Listener                                                                                     
*                                                                                                                
* *******************************************************************************   

    • * ********************************************
*
* BEGIN STACK DUMP:
* 07/25/22 11:44:21 spid 2013
*
* Non-yielding Resource Monitor
*
* ********************************************

  2. Wenn Sie einen dieser Fehler finden, ermitteln Sie, welche Version kumulatives Update (CU) von SQL Server Sie verwenden. Überprüfen Sie, ob nach Ihrem aktuellen CU behobene Probleme in CUs enthalten sind. Informationen zu den SQL Server-Fixes finden Sie unter "Neueste Updates", die für derzeit unterstützte Versionen von SQL Server verfügbar sind. Für eine detaillierte Fixliste können Sie diese Excel-Datei herunterladen.

  3. Verwenden Sie die Problembehandlung bei der SQL Server-Planung und - Rendite für weitere Ideen.

  4. Suchen Sie nach schweren Blockierungsszenarien oder massiven Parallelitätsabfragen, die zu Deadlock-Schedulern führen können. Ausführliche Informationen finden Sie im Tao eines Deadlocked Scheduler.

  5. Überprüfen Sie bei einem nicht ertragenden IOCP-Listener, ob ihr System nicht genügend Arbeitsspeicher hat und SQL Server ausgelagert wird. Ein weiterer Grund könnte sein, dass Antivirensoftware oder Eindringschutzsoftware I/O-API-Aufrufe abfangen und die Threadaktivität verlangsamt. Weitere Informationen finden Sie unter "Überwacht der IOCP-Listener tatsächlich? und Leistungs- und Konsistenzprobleme, wenn bestimmte Module oder Filtertreiber geladen werden.

  6. Bei Problemen mit der Ressourcenüberwachung sind Sie möglicherweise nicht unbedingt mit diesem Problem in einigen Fällen befasst. Weitere Informationen finden Sie unter "Ressourcenüberwachung" eine Bedingung ohne Ertrag auf einem Server, auf dem SQL Server ausgeführt wird.

  7. Wenn diese Ressourcen nicht helfen, suchen Sie das im Unterverzeichnis \LOG erstellte Speicherabbild, und öffnen Sie ein Supportticket mit Microsoft CSS, indem Sie das Speicherabbild für die Analyse hochladen.

Schritt 9: Suchen nach ressourcenintensiven Profiler- oder XEvent-Ablaufverfolgungen

Suchen Sie nach aktiven erweiterten Ereignissen oder SQL Server Profiler-Ablaufverfolgungen, insbesondere nach Filtern nach Textspalten (Datenbankname, Anmeldename, Abfragetext usw.). Deaktivieren Sie nach Möglichkeit die Ablaufverfolgungen, und überprüfen Sie, ob die Abfrageleistung verbessert wird. Je nach ausgewähltem Ereignis verbraucht jeder Thread möglicherweise zusätzliche CPU, was zu einer gesamten Langsamkeit führt. Informationen zum Identifizieren der aktiven Ablaufverfolgungen für erweiterte Ereignisse finden Sie unter sys.dm_xe_sessions und für Profiler-Ablaufverfolgungen unter sys.traces.

SELECT * FROM sys.dm_xe_sessions
GO
SELECT * FROM sys.traces