SQL Server: Langsame Applikationen analysieren und beschleunigen

Langsame Applikationen sind nicht nur nervig, sondern können auch massive wirtschaftliche Auswirkungen haben. Doch bevor du wild an der Performance schraubst, solltest du systematisch vorgehen. In diesem Beitrag zeige ich dir drei essenzielle Methoden, um langsame SQL Server-Anfragen zu analysieren und zu optimieren. Daher hier ein kurzer Anriss, wie man beispielsweise mit dem TroubleShooting beginnen könnte.

1. Welche Prozesse laufen auf dem SQL Server?

Ein erster Blick auf die laufenden Prozesse kann dir schnell zeigen, ob bestimmte Abfragen oder Hintergrundprozesse zu viel CPU, Speicher oder I/O-Ressourcen beanspruchen. Hier helfen diese Abfragen bzw System-Views im SQL Server bei der Analyse:

Systemansicht sys.dm_exec_requests

SELECT * FROM sys.dm_exec_requests;

Alternative: sp_who2 für eine schnelle Übersicht

EXEC sp_who2;

Tipp: Falls du eine modernere (GUI-) Lösung suchst, schau dir das SQL Server Activity Monitor im SQL Server Management Studio an, um grafisch zu sehen, welche Sessions hohe Last verursachen.

2. Gibt es Locking oder Blocking?

SQL Server arbeitet mit Locks, um Datenkonsistenz sicherzustellen. Problematisch wird es, wenn eine Abfrage eine Ressource blockiert, die eine andere benötigt. Das kann zu hoher Sperrzeit und Performance-Problemen führen.

Welche Sessions blockieren sich gegenseitig?

SELECT blocking_session_id, wait_type, wait_time, blocking_session_id
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Alternativ: Detailliertere Locks anzeigen mit sys.dm_tran_locks

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

sp_WhoIsActive nutzen: Dieses populäre Skript von Adam Machanic liefert tiefere Einblicke in laufende Abfragen, inklusive Wartezeiten. Das Skript bzw die Stored Procedure könnt ihr auf Github finden, „aktuell“ in der Version 12.00
https://github.com/amachanic/sp_whoisactive/releases

3. Fehlerprotokolle prüfen

Oft liegen die Ursachen für Performance-Probleme direkt im SQL Server Errorlog oder im Windows Event Viewer. Hier findest du Hinweise auf:

• Deadlocks: Wenn zwei Prozesse sich gegenseitig blockieren.
• Speicherprobleme: Wenn der SQL Server auslagert oder nicht genug RAM zur Verfügung steht.
• Fehlgeschlagene Logins: Falls ein Dienstkonto nicht mehr funktioniert.

SQL Server Errorlog auslesen:
Hierzu gibt es natürlich mehrere Weg, je nach persönlicher Vorliebe, über das SQL Server Management Studio, über das Filesystem und das Errorlog mit einem Editor öffnen, aber auch als Query mit einem bevorzugten Abfrage-Tool:

EXEC sp_readerrorlog;

Tipp: Du kannst gezielt nach „Deadlock“ oder „Error“ suchen, um relevante Einträge schneller zu finden. Man kann sich das Errorlog auch in eine Temp-Table laden und dort entsprechend eingrenzen, sortieren oder anreichern.

Fazit: Strukturiert Troubleshooting spart Zeit

Wenn eine Applikation langsam läuft, geh methodisch vor:

Laufende Prozesse analysieren – Welche Abfragen oder Tasks verbrauchen viele Ressourcen?
Blocking und Locking prüfen – Gibt es Abfragen, die andere ausbremsen?
Fehlerprotokolle checken – Gibt es Hinweise auf Deadlocks oder Speichermangel?

Durch diese strukturierte Vorgehensweise findest du Performance-Engpässe schneller und kannst gezielt optimieren. Falls du Fragen hast oder dein SQL Server langsam läuft – schreib mir gerne!

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.