Troubleshooting der SQL Server Performance

Erste Schritte zum Troubleshooting der SQL Server Performance

 

Problem

Im Laufe der Zeit können immer wieder Probleme im Zusammenhang mit der Performance eines SQL Servers auftreten. Anwendungen funktionieren nicht, die Website reagiert nicht mehr und Sie erhalten Meldungen wie z.B. „Database Timeout“. Zeit ist hier ein wichtiger Faktor, um mögliche Langzeitfolgen zu verhindern. Um einen größeren Schaden zu vermeiden, zeigen wir Ihnen in diesem Artikel, wie Sie eine Standardanleitung für das Troubleshooting der SQL Server Umgebung erstellen und welche Schritte Sie dafür in Angriff nehmen sollten.

 

Schritt 1 – Überprüfen Sie die Datenbank der Anwendung 

Zuerst sollten Sie den Status der Datenbank der betroffenen Anwendung überprüfen. Gibt es eventuell Sperren oder Blockaden in der Serverumgebung, die das Ausführen der Anwendung / Website verhindern? Trifft dieser Fall zu, sollten Sie sich – bevor Sie die Sitzung beenden – den Code, der die Sitzung ausführt, begutachten und eruieren, woher die Störung kommt. Damit vermeiden Sie, dass beim Neustart der Anwendung der selbe fehlerhafte Code verwendet wird.

Mit der folgenden Abfrage erhalten Sie Informationen zur Blockade:

SELECT *
FROM sys.dm_exec_requests
CROSS APPLY sys.dm_exec_sql_text (sql_handle)

 

Mögliche Problemszenarien:

1. Haben andere, auf demselben Server ausgeführte Anwendungen, ebenfalls Probleme?

Um sicher zu gehen, dass nicht der Server der Ursprung der Probleme ist, sollten Sie untersuchen, ob alle auf dem Server ausgeführten Anwendungen von den Störungen betroffen sind. Ist dies nicht der Fall, liegt die Ursache nicht in der Datenbank, sondern in der Anwendung an sich. Haben wir festgestellt, dass lediglich eine Anwendung betroffen ist, können davon ausgehen, dass unser Server nicht die Problemquelle ist. Also untersuchen wir im nächsten Schritt die betroffene Anwendung.

Gab es eventuell in jüngster Vergangenheit Änderungen in der Anwendungsumgebung, von denen Sie nichts mitbekommen haben? Es könnten beispielsweise nicht gespeicherte Änderungen vorgenommen worden sein, die das Front-End der Anwendung verändert haben, was auch die Leistung des Servers einbüßen könnte. Beispielsweise nutzt die Anwendung für das Empfangen der Daten Frameworks, dessen SQL Code nicht vom Programmierer selbst erstellt wird oder umgekehrt, kann der Webentwickler auch Ad-Hoc Abfragen in den Code einbauen, sodass Sie im SQL-Code keine Änderungen bemerken. Sogar die Konfigurationsdatei könnte nicht bekannte Änderungen beinhalten, die sich negativ auf die Serverleistung auswirken.

 

2. Verfügt die Datenbank über genügend freien Speicherplatz?

Sollte Ihr SQL Server nicht ausreichend freien Speicherplatz haben, könnte die Performance abbauen. Mit folgendem Befehl können Sie sich ein Bild über die verfügbaren freien Speicherplatz machen: xp_fixeddrives. Aber selbst wenn die Festplatte über genügend Speicherplatz verfügt, kann es beispielsweise sein, dass das automatische Wachstum der Datenbank deaktiviert oder auf eine bestimmte maximale Dateigröße eingestellt wurde und somit die Anwendung blockiert.

Als nächsten zentralen Schritt sollten wir uns auf die SQL-Server Instanz konzentrieren und uns einen generellen Überblick verschaffen. Hilfreich ist es, sich die Performance Dashboard Berichte näher anzuschauen um festzustellen, ob die Server Instanz beispielsweise unter CPU Druck steht. Über das SSMS und einem Rechtsklick auf den betroffenen Server, dann weiter auf den Reiter “Berichte” gelangen wir in das Performance Dashboard.

 

Hier können wir nun weitere Hinweise erhalten. Im oben gezeigten Beispielbild, sehen wir, dass zum Zeitpunkt der Berichtsausführung ein Sperrproblem in der Instanz aufgetreten ist. Rufen Sie jetzt den SOS_SCHEDULER_YIELD oder CXPACKET ab, sehen Sie, dass das Problem mit der Parallelität zusammenhängt.

 

Eine weitere Option: → Schauen Sie sich die Fragmentierung der Protokolldateien genauer an.
Sind die Protokolldateien mit einer großen Anzahl von VLF Dateien fragmentiert, werden viele WRITELOG Wartetypen angezeigt, die sich nachteilig auf die Leistung Ihres Servers auswirken können.

 

Ein SQL Server benötigt in der Regel weniger als 30 Millisekunden, um ordnungsgemäß zu funktionieren. Dauert dies länger, könnte auch hier die Problemquelle versteckt sein. Also öffnen wir den SSMS Aktivitätsmonitor, erweitern die I/O-Ansichten der Daten und sortieren diese in absteigender Reihenfolge nach der Antwortzeit.

 

Eine hohe Zugriffszeit kann auf eine Fragmentierung der Tabelle/Index oder auf ein Problem mit dem Festplattensubsystem zurückzuführen sein.

Wir untersuchen als weiteren Schritt die Informationen aus dem SQL Server Fehlerprotokoll. Liegt das Problem eventuell am Festplattensubsystem, sollten wir im SQL Server Fehlerprotokoll nach langen I/O Anforderungen, fehlerhaften Seiten oder Speicherauszügen Ausschau halten. Mit dem Befehl sp_readerrorlog können Sie sich den Inhalt des Fehlerprotokolls anschauen.

Sind wir immer noch nicht erfolgreich bei der Fehlersuche geworden, überprüfen wir im nächsten Schritt, ob die Anwendung über einen Verbindungsserver auf Daten zugreift. Die Ursache ist oft simpel, denn möglicherweise suchen Sie auf dem falschen Server nach den Problemen. Um herauszufinden, ob dies der Fall ist, schauen Sie im Performance Dashboard nach übermäßigen OLEDB Warteaufgaben.

Als letzte Möglichkeit bleibt uns noch zu prüfen, ob auch alle Statistiken aktuell sind.
Wenn die Datenbankstatistik nicht auf dem neusten Stand ist, verfügt das Abfrageoptimierungsprogramm möglicherweise nicht über die Informationen, um den besten Abfrageplan zu erstellen. Das Programm könnte sich beispielsweise für einen parallelen Plan entscheiden, der nicht optimal funktioniert. Erkennen können wir den Vorgang an vielen Warteaufgaben für SOS_SCHEDULER_YIELD oder CXPACKET. Wir sollten nun die Statistiken umfassend aktualisieren und den Prozedurcache leeren, damit vom Abfrageoptimierungsprogramm neue und optimierte Abfragepläne erstellt werden können. Folgender Befehl führt die Leerung des Cache durch:

EXEC sp_updatestats
GO
DBCC FREEPROCCACHE ()
GO

Mit diesem Artikel sollten Sie nun eine Standardanleitung erstellen, die wichtigsten Szenarien prüfen und Maßnahmen zur Fehlerbehebung ergreifen können.


→ Hier findest Du den Artikel zum direkten PDF-Download: madafa.de/download/artikel-downloads/


 

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Secured By miniOrange