SQL Server: Langsame Applikationen analysieren und beschleunigen

Eine SQL Server Performance Analyse beginnt oft mit einer einfachen Meldung: Die Anwendung ist langsam. Benutzer melden lange Ladezeiten, einzelne Masken reagieren träge, Reports laufen deutlich länger als gewohnt und manchmal kommen auch noch Timeouts dazu.

Das Problem dabei: Eine langsame Anwendung ist zunächst einmal nur ein Symptom. Ob die Ursache tatsächlich im SQL Server liegt, in der Anwendung selbst, im Netzwerk, im Storage oder vielleicht sogar beim Client, ist zu diesem Zeitpunkt noch völlig offen.

Bevor man also anfängt, wahllos Indexe anzulegen, Speicher zu erhöhen oder SQL Server Parameter anzupassen, sollte man das Problem erst einmal sauber eingrenzen. Genau darum geht es in diesem Beitrag: um einen möglichen Einstieg in eine SQL Server Performance Analyse, wenn eine Anwendung langsam wirkt und noch nicht klar ist, wo die eigentliche Ursache liegt.

Warum „SQL Server ist langsam“ noch keine Diagnose ist

Wenn Benutzer sagen, dass „die Anwendung langsam“ ist, beschreiben sie normalerweise ihre Wahrnehmung. Das ist wichtig, aber es ist noch keine technische Diagnose.

Die eigentliche Frage lautet aus meiner Sicht zuerst:

Wo geht die Zeit tatsächlich verloren?

Zwischen einem Mausklick in der Anwendung und der Antwort auf dem Bildschirm liegen häufig mehrere Komponenten. Der Client spielt eine Rolle, das Netzwerk, die Anwendung, der SQL Server und natürlich auch der darunterliegende Storage.

SQL Server kann die Ursache sein. SQL Server kann aber auch nur der Punkt sein, an dem ein anderes Problem sichtbar wird. Genau deshalb sollte man nicht zu früh mit Optimierung beginnen, sondern erst prüfen, was auf dem Server wirklich passiert.

Schritt 1: Was läuft gerade auf dem SQL Server?

Ein sinnvoller erster Blick geht auf die aktuell laufenden Requests. Damit sieht man nicht sofort die gesamte Ursache, aber man bekommt einen ersten Eindruck davon, ob auf dem SQL Server gerade überhaupt etwas Auffälliges passiert.

Für eine erste Übersicht kann man mit der folgenden Abfrage starten:

SELECT *
FROM sys.dm_exec_requests;

Interessant sind dabei unter anderem Session-ID, Status, Wait Type, CPU-Zeit, Reads, Writes und die bisherige Laufzeit. Wenn eine Anwendung gerade langsam ist, möchte ich zuerst wissen, ob es aktive Requests gibt, die lange laufen, auffällig viel CPU verbrauchen oder auf bestimmte Ressourcen warten.

Für einen schnellen Überblick sieht man in vielen Umgebungen auch noch die alte Prozedur sp_who2:

EXEC sp_who2;

sp_who2 ist sicherlich nicht mehr das modernste Werkzeug, aber für einen ersten Blick kann es immer noch hilfreich sein. Für eine genauere Analyse greife ich aber lieber direkt auf die Dynamic Management Views oder auf sp_WhoIsActive zurück.

Wer lieber grafisch arbeitet, kann zusätzlich den Activity Monitor im SQL Server Management Studio verwenden. Für eine schnelle Orientierung ist das in Ordnung. Für belastbare Analysen sollte man sich aber nicht nur auf die Oberfläche verlassen.

Schritt 2: Gibt es Blocking oder Locking?

Eine der häufigsten Ursachen für eine langsam wirkende Anwendung ist Blocking. SQL Server verwendet Locks, um die Konsistenz von Daten sicherzustellen. Das ist völlig normal und erst einmal kein Problem.

Problematisch wird es dann, wenn Sessions länger aufeinander warten und dadurch Benutzer oder Hintergrundprozesse ausgebremst werden. Genau an dieser Stelle wird aus normalem Locking ein echtes Performance-Problem.

Ein erster Blick auf blockierte Sessions kann zum Beispiel so aussehen:

SELECT
    session_id,
    blocking_session_id,
    wait_type,
    wait_time,
    wait_resource,
    status,
    command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Wenn diese Abfrage Ergebnisse liefert, ist der nächste Schritt nicht nur die blockierte Session anzusehen, sondern vor allem den Blocker zu finden. Häufig ist genau diese verursachende Session der spannendere Teil der Analyse.

Ergänzend kann man sich aktive Locks ansehen:

SELECT
    request_session_id,
    resource_type,
    resource_description,
    request_mode
FROM sys.dm_tran_locks;

In der Praxis nutze ich für solche Situationen sehr gerne sp_WhoIsActive von Adam Machanic. Das Skript zeigt laufende Abfragen, Wartezeiten, Blocking-Informationen und weitere Details sehr übersichtlich an und ist gerade bei akuten Performance-Problemen oft einer der schnellsten Wege zu einem brauchbaren ersten Bild.

Das Skript findet ihr hier:
https://github.com/amachanic/sp_whoisactive/releases

SQL Server Performance Analyse: Worauf wartet SQL Server eigentlich?

An dieser Stelle wird es häufig interessant, weil viele Performance-Diskussionen sehr schnell bei CPU, Arbeitsspeicher oder Storage landen. Diese Werte sind wichtig, aber sie erklären nicht automatisch die Ursache.

Eine bessere Frage lautet oft:

Worauf wartet SQL Server gerade?

Wait Types können helfen, die weitere SQL Server Performance Analyse in die richtige Richtung zu lenken. Sie sind aber keine fertige Diagnose.

• Lock-Waits können auf Blocking hindeuten.
• I/O-Waits können auf Storage, Datenzugriffe oder ungünstige Abfragepläne hinweisen.
• Memory-Waits können ein Hinweis auf Speicherdruck sein.
• ASYNC_NETWORK_IO kann bedeuten, dass SQL Server auf den Client oder die Anwendung wartet.

Gerade ASYNC_NETWORK_IO ist ein gutes Beispiel dafür, warum man Waits vorsichtig interpretieren muss. Der Name klingt schnell nach Netzwerkproblem. In der Praxis kann die Ursache aber auch sein, dass eine Anwendung sehr große Datenmengen abruft und diese nur langsam verarbeitet.

Genau hier liegt häufig ein Denkfehler. SQL Server wirkt langsam, wartet aber eigentlich darauf, dass die Anwendung die gelieferten Daten abnimmt. Mehr CPU, mehr RAM oder schnellerer Storage würden dieses Problem dann nicht sauber lösen.

Schritt 4: Fehlerprotokolle nicht vergessen

Neben den aktuellen Sessions und Waits lohnt sich fast immer auch ein Blick in die Protokolle. Das SQL Server Errorlog ist kein klassisches Performance-Tool, liefert aber oft wichtigen Kontext.

Interessant sind dort zum Beispiel Hinweise auf:

• Deadlocks
• Speicherdruck
• I/O-Fehler oder I/O-Warnungen
• Neustarts des SQL Server Dienstes
• fehlgeschlagene Logins
• ungewöhnliche Fehlermeldungen

Das aktuelle Errorlog lässt sich zum Beispiel so auslesen:

EXEC sp_readerrorlog;

Natürlich kann man das Errorlog auch über das SQL Server Management Studio oder direkt im Dateisystem öffnen. In manchen Situationen ist es auch hilfreich, die Einträge in eine temporäre Tabelle zu laden und dort gezielt nach bestimmten Begriffen zu suchen.

Wichtig ist aus meiner Sicht vor allem, dass man die Protokolle nicht erst dann öffnet, wenn gar nichts mehr geht. Gerade bei Performance-Problemen liefern sie manchmal den Hinweis, der die aktuelle Beobachtung besser einordnet.

Ein häufiger Denkfehler bei langsamen Applikationen

Wenn eine Anwendung langsam reagiert, wird häufig sehr schnell nach einer technischen Lösung gesucht. Mehr RAM, neue Indexe, schnellere Platten oder geänderte SQL Server Einstellungen stehen dann oft früh im Raum.

Das kann alles richtig sein. Es kann aber auch komplett am eigentlichen Problem vorbeigehen.

Ich halte es deshalb für gefährlich, zu früh an einzelnen Stellschrauben zu drehen. Eine SQL Server Performance Analyse sollte zuerst klären, ob SQL Server wirklich der Engpass ist, welche Sessions oder Abfragen beteiligt sind, worauf gewartet wird und ob es Hinweise auf Blocking, Fehler oder ungewöhnliches Verhalten gibt.

Erst wenn diese Richtung klarer ist, lohnt sich die eigentliche Optimierung.

Was man besser nicht sofort tun sollte

Gerade unter Druck ist die Versuchung groß, sofort etwas zu ändern. Das ist verständlich, aber nicht immer hilfreich.

Ich wäre vorsichtig mit Maßnahmen wie:

• blind neue Indexe anlegen
• MAXDOP oder Cost Threshold ohne Analyse ändern
• einfach mehr RAM fordern
• Storage beschuldigen, nur weil I/O-Waits sichtbar sind
• jede langsame Anwendung automatisch als SQL Server Problem behandeln

Manchmal ist eine schnelle Maßnahme notwendig, gerade wenn ein produktives System stark beeinträchtigt ist. Trotzdem sollte man möglichst sauber dokumentieren, was beobachtet wurde und warum eine Änderung vorgenommen wird.

Sonst weiß man hinterher oft nicht mehr, ob die Maßnahme wirklich geholfen hat oder ob das Problem nur zufällig gerade verschwunden ist.

Fazit: Erst eingrenzen, dann optimieren

Langsame Anwendungen lassen sich nur selten durch eine einzelne Kennzahl erklären. Eine hohe CPU-Auslastung, ein auffälliger Wait Type oder ein langsamer Report sind wichtige Hinweise, aber noch keine vollständige Diagnose.

Aus meiner Sicht ist der wichtigste Schritt zunächst herauszufinden, wo die Zeit tatsächlich verloren geht. Eine saubere SQL Server Performance Analyse hilft dabei, aktive Requests, Blocking, Waits und Errorlogs in einen sinnvollen Zusammenhang zu bringen.

Damit ist das Problem natürlich noch nicht vollständig gelöst. In vielen Fällen erhält man dadurch aber genügend Hinweise, um die weitere Untersuchung deutlich zielgerichteter fortzuführen.

Und genau das ist häufig der Unterschied zwischen blindem Aktionismus und systematischem SQL Server Troubleshooting.