SQL Server Wait Stats interpretieren
Wartetypen lesen, Engpässe benennen, gezielt handeln
Wait Stats interpretieren — der DBA-Kompass
Wartetypen sind die Sprache, in der der SQL Server seine Engpässe erklärt. Wer sie liest, rät nicht mehr — er weiß, wo er gräbt.
Stell dir zwei DBAs vor, die denselben langsamen Server vor sich haben. Der eine öffnet den Task-Manager, sieht 40 Prozent CPU, zuckt mit den Schultern und beginnt zu raten: vielleicht die Indizes neu aufbauen, vielleicht mehr RAM beantragen, vielleicht den Server mal neu starten. Der andere führt eine einzige Abfrage aus, liest fünf Zeilen Ergebnis und sagt: „Der Server verbringt 70 Prozent seiner Wartezeit mit PAGEIOLATCH — das ist ein I/O- oder Speicher-Thema, und genau dort schaue ich jetzt nach.“ Derselbe Server, dieselben Symptome — aber der zweite hat einen Kompass, und der erste hat nur ein Gefühl.
Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) macht dich zum zweiten DBA. Wait Stats sind kein exotisches Spezialwissen, sondern das Fundament jeder seriösen Diagnose — sie sind die Sprache, in der der SQL Server dir selbst sagt, woran es hakt. Anders als die akuten Symptom-Beiträge der ROT- und GELB-Stufe geht es hier nicht um einen einzelnen Notfall, sondern um die Grundfertigkeit, die unter allen Notfällen liegt: Wartetypen lesen und in Handlungsrichtungen übersetzen. Ruhig, systematisch, ein für alle Mal.
Was sind Wait Stats — und warum sind sie so ehrlich?
Der SQL Server arbeitet seine Aufgaben in winzigen Arbeitseinheiten ab, die ständig auf etwas warten müssen: auf eine Datenseite, die erst von der Platte kommen muss; auf eine Sperre, die ein anderer hält; auf Arbeitsspeicher für eine Sortierung; auf einen freien Platz auf einem Prozessor. Jedes Mal, wenn eine Arbeitseinheit nicht weiterarbeiten kann, notiert der Server den Grund als Wartetyp und addiert die Wartezeit zu einer laufenden Statistik. Das passiert tausendfach pro Sekunde, völlig automatisch, ohne dass du etwas einschalten müsstest.
Genau diese Mechanik macht Wait Stats so wertvoll: Sie sind nicht interpretiert. Der Task-Manager zeigt dir, dass die CPU bei 40 Prozent liegt — aber nicht, ob die restlichen 60 Prozent ungenutzt sind oder ob hunderte Sessions auf Sperren warten, während die wenigen laufenden die CPU beschäftigen. Die Wait Stats zeigen dir, worauf tatsächlich gewartet wird. Sie sind der Unterschied zwischen „der Server ist langsam“ (ein Gefühl) und „der Server verwartet 70 Prozent seiner Zeit auf Plattenzugriffe“ (ein Befund). Aus einem Befund wird eine Richtung, aus einer Richtung ein Plan. Das ist kein akademischer Unterschied: Der ratende DBA aus dem Eingangsbeispiel hätte mit seinem Index-Rebuild Stunden verbrannt, ohne das Problem auch nur zu berühren — der messende wusste in fünf Minuten, dass er beim Storage und beim Speicher graben muss. Dieselbe Stunde Arbeit, völlig verschiedene Ergebnisse, und der ganze Unterschied liegt in der einen Abfrage, die der zweite zuerst ausgeführt hat.
Drei Dinge muss man über die Mechanik wissen. Erstens: Die Zahlen sind kumulativ seit dem letzten Dienststart — auf einem Server mit 200 Tagen Uptime ist das ein 200-Tage-Durchschnitt, in dem sich das Problem von heute leicht versteckt. Zweitens: Es zählt der Anteil, nicht die absolute Zahl. „Acht Stunden CXPACKET“ klingt dramatisch, ist aber bei 200 Tagen Laufzeit ein Nichts. Drittens: Eine große Gruppe von Wartetypen ist reiner Leerlauf — Hintergrundprozesse, die planmäßig schlafen. Wer die nicht herausfiltert, diagnostiziert den Schlaf des Lazywriters. Damit sind wir bei der Kategorisierung, die aus der langen Liste einen brauchbaren Kompass macht.
|
Der Kompass-Gedanke Ein Wartetyp ist eine Himmelsrichtung, kein Ziel. LCK_M_X sagt: „Such bei den Sperren“ — nicht: „Hier ist dein Problem“. |
|---|
Die Wartetypen nach Kategorien
Statt eine alphabetische Liste auswendig zu lernen, ordnest du Wartetypen in eine Handvoll Kategorien ein — jede zeigt in eine Diagnose-Richtung. Die folgende Übersicht ist der Kompass, den du dir an die Wand hängst:
Die Skripte: messen und einordnen
Modus 1 — Was prägt diesen Server grundsätzlich?
Die kumulative Sicht beantwortet die Frage nach dem Charakter des Servers. Das folgende Skript filtert die harmlosen Leerlauf-Typen und zeigt den prozentualen Anteil — wichtiger als jede absolute Zahl:
|
— Top-Wartetypen seit Neustart, mit Anteil (Harmloses gefiltert) SELECT TOP (15) wait_type, wait_time_ms / 1000 AS WaitSec, signal_wait_time_ms / 1000 AS SignalSec, — davon CPU-Wartezeit waiting_tasks_count AS Anzahl, CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER() AS decimal(5,2)) AS Prozent FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ( N'SLEEP_TASK', N'LAZYWRITER_SLEEP', N'BROKER_TASK_STOP', N'BROKER_TO_FLUSH', N'SQLTRACE_BUFFER_FLUSH', N'WAITFOR', N'XE_TIMER_EVENT', N'XE_DISPATCHER_WAIT', N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH', N'LOGMGR_QUEUE', N'DIRTY_PAGE_POLL', N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'SP_SERVER_DIAGNOSTICS_SLEEP', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION', N'ONDEMAND_TASK_QUEUE' ) AND wait_time_ms > 0 ORDER BY wait_time_ms DESC; |
|---|
Ein nützlicher Nebenbefund steckt in der Spalte SignalSec: Sie ist der Teil der Wartezeit, der nach dem Bereitwerden noch verging, bis ein Prozessor frei war — ein hoher Signal-Anteil an der Gesamtwartezeit ist ein eigenständiges Indiz für CPU-Druck, unabhängig vom Wartetyp selbst.
Modus 2 — Was tut gerade weh?
Für die Akut-Diagnose brauchst du die Gegenwart, nicht die Geschichte. Diese Delta-Messung blendet die 200-Tage-Vergangenheit aus:
|
— Snapshot 1 SELECT wait_type, wait_time_ms INTO #w1 FROM sys.dm_os_wait_stats;
WAITFOR DELAY '00:05:00'; — typische Last abwarten
— Delta: Was ist in den letzten 5 Minuten an Wartezeit dazugekommen? SELECT TOP (15) w2.wait_type, (w2.wait_time_ms – w1.wait_time_ms) / 1000 AS DeltaSec FROM sys.dm_os_wait_stats AS w2 JOIN #w1 AS w1 ON w1.wait_type = w2.wait_type WHERE w2.wait_time_ms – w1.wait_time_ms > 0 ORDER BY w2.wait_time_ms – w1.wait_time_ms DESC; |
|---|
Ein dritter Blick lohnt für das Jetzt: sys.dm_os_waiting_tasks zeigt nicht die Historie, sondern die Sessions, die in diesem Moment warten — ideal, um einen aktuellen Engpass auf konkrete Sessions herunterzubrechen. Kumulativ für den Charakter, Delta für den Trend, waiting_tasks für die Momentaufnahme: drei Blickwinkel auf dieselbe Sprache.
Die wichtigsten Wartetypen im Klartext
Die CPU-Familie: SOS_SCHEDULER_YIELD, CXPACKET, CXCONSUMER
SOS_SCHEDULER_YIELD heißt: Sessions standen Schlange für einen Prozessor — ein direktes Zeichen für CPU-Druck. CXPACKET und das modernere CXCONSUMER entstehen bei Parallelverarbeitung und sind meist Folge teurer Abfragen, nicht die Ursache. Die häufigste Fehlreaktion — Parallelität per MAXDOP 1 abwürgen — kuriert das Symptom und schafft neue Probleme. Richtig ist: die teuren Abfragen finden und MAXDOP sowie Cost Threshold for Parallelism sinnvoll setzen. Die ganze Diagnose-Pyramide dazu steht im CPU-Beitrag des Notarztwagens.
Die I/O-Familie: PAGEIOLATCH, WRITELOG
PAGEIOLATCH_SH und _EX bedeuten Warten auf Datenseiten von der Platte; WRITELOG bedeutet, dass Commits auf das Schreiben ins Transaktionslog warten — der gnadenlose Typ, weil er jede einzelne Buchung bremst. Beide werfen dieselbe Folgefrage auf: Ist das Storage zu langsam, oder fordert der Server zu viel an (Scans, kalter Cache)? Die Verzweigung führt zu den Beiträgen über I/O-Latenz und Memory Pressure — und genau hier zeigt sich der Wert des Kompasses, der dich nicht zur falschen Hardware-Bestellung verleitet.
Die Sperren-Familie: LCK_M_*, PAGELATCH
Die LCK_M_*-Typen (X für exklusiv, S für shared, U für Update und so weiter) bedeuten Warten auf Sperren — der Server ist nicht überlastet, sondern blockiert. Dominieren sie, geht es zum Blocking- oder Deadlock-Beitrag. Aufpassen bei PAGELATCH (ohne IO!): Das ist Warten auf eine Seite im Speicher, klassisch die tempdb-Allokations-Contention auf den Adressen 2:1:1 und Verwandten — ein völlig anderes Thema als das ähnlich aussehende PAGEIOLATCH. Ein Buchstabe Unterschied, zwei verschiedene Beiträge.
Die Speicher-Familie und der Sonderfall ASYNC_NETWORK_IO
RESOURCE_SEMAPHORE heißt: Abfragen warten auf ihre Speicherzuteilung (Memory Grant), bevor sie überhaupt starten dürfen — direkter Weg zum Memory-Pressure-Beitrag. Und dann der Wartetyp, der die meisten Fehldiagnosen produziert: ASYNC_NETWORK_IO heißt fast nie „Netzwerk kaputt“, sondern „die Anwendung holt die fertigen Ergebnisse zu langsam ab“ — zu große Ergebnismengen, zeilenweise Client-Verarbeitung, fehlendes Paging. Steht der ganz oben, liegt das Problem nicht im Server, sondern in der Anwendung. Die Wait Stats liefern dir hier die Munition fürs Gespräch mit dem Entwicklerteam — nachweisbar, nicht behauptet. Genau das ist oft die wertvollste Rolle der Wait Stats: Sie verhindern, dass der DBA monatelang an einem Server schraubt, dessen Problem in Wahrheit ein paar Stockwerke weiter in der Anwendungsschicht sitzt.
Was du auf keinen Fall tun solltest
|
Die drei häufigsten Anfängerfehler 1. Den Wartetyp mit der Ursache verwechseln. CXPACKET ist nicht „Parallelität kaputt“, sondern „teure Abfragen laufen parallel“ — der Kompass zeigt die Richtung, nicht das Ziel. |
|---|
Die Wait-Stats-Baseline: dein wichtigstes Wartungsprojekt
Wait Stats entfalten ihren vollen Wert erst mit einer Baseline — und die aufzubauen ist das lohnendste Wochenend-Projekt eines DBAs. Das Prinzip ist simpel: Ein Agent-Job schreibt alle 15 oder 30 Minuten die aktuellen Wait Stats als Delta zur vorigen Messung in eine eigene Tabelle. Nach zwei Wochen hast du, was im Ernstfall den Unterschied macht: Vergleichswerte. „CXPACKET bei 30 Prozent“ ist eine Zahl; „CXPACKET seit dem letzten Release von 12 auf 30 Prozent gestiegen“ ist ein Befund mit Verdächtigem. Mit der Baseline erkennst du Trends, bevor sie zu den Notfällen der ROT- und GELB-Stufe werden — und genau das ist der Geist der GRÜN-Stufe: messen, bevor es brennt.
Wie die Wait-Stats-Baseline in das größere Bild der proaktiven Wartung passt — zusammen mit Konfigurations-Check, Backup-Prüfung und Performance-Baseline —, zeigt der Health-Check-Beitrag. Wait Stats sind dort der Anker, an dem fast alle anderen Prüfungen hängen.
Vertiefung in der Buchreihe
Die vollständige Wartetypen-Landkarte mit allen Kategorien und Therapiewegen füllt in der Buchreihe „SQL Server in der Praxis“ ein eigenes Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.
|
Empfohlener Band Band 1: Performance & Troubleshooting — das Heimatbuch dieses Beitrags: Wait Stats in der ganzen Breite, die komplette Kategorien-Landkarte, Signal-Waits und CPU-Druck, die Delta-Methodik und der Aufbau einer belastbaren Baseline — das Fundament, auf dem jede der vier Diagnose-Pyramiden-Stufen steht. |
|---|
Wohin der Kompass zeigt — die Anschluss-Beiträge
Wait Stats sind der Ausgangspunkt; je nach dominantem Wartetyp geht es hier weiter:
Drei Wege, deinen Kompass lesen zu lernen
Selbst-Diagnose-Kit
Wait Stats sind die Grundfertigkeit, die du selbst beherrschen solltest — und genau dafür ist dieser Beitrag der Einstieg. Das Diagnose-Kit bündelt die Skripte von hier — kumulative Analyse mit Filter und Prozent-Anteil, die Delta-Messung, die waiting_tasks-Momentaufnahme — plus den Kategorien-Kompass zum Ausdrucken und eine Vorlage für den Baseline-Job, der alle 30 Minuten misst. Damit baust du dir in einer Stunde das Fundament, auf dem jede künftige Diagnose steht.
Festpreis-Analyse
Du willst lieber einmal mit Erfahrung über die Wait Stats schauen lassen, bevor du selbst eine Baseline aufsetzt? Die Festpreis-Analyse liefert genau das: Ich werte den Wartetyp-Charakter deiner Instanz aus, ordne die Befunde gegen typische Vergleichswerte ein, verfolge die dominanten Richtungen bis zur Ursache und liefere einen Bericht mit priorisierten Maßnahmen — und gleich die fertige Baseline-Konfiguration dazu. Zum vereinbarten Festpreis, ohne Stundenzähler.
Akut-Hotline
Wenn ein konkreter Engpass gerade jetzt drückt und du den Kompass im Ernstfall gemeinsam lesen willst: anrufen. Halte einen Zugang mit VIEW-SERVER-STATE-Rechten bereit — mit der Delta-Messung aus diesem Beitrag ist die Richtung in Minuten klar, und von dort führt der Weg gezielt zum passenden Symptom statt ins Raten.
|
Ein letzter Tipp Richte diese Woche den Baseline-Job ein — eine Tabelle, ein Agent-Job alle 30 Minuten, fertig. Es ist die Investition mit dem besten Verhältnis von Aufwand zu Wirkung im ganzen DBA-Alltag: zwanzig Minuten Arbeit heute, und beim nächsten „der Server ist langsam“ hast du nicht ein Gefühl, sondern eine Kurve. Der Unterschied zwischen Raten und Wissen ist genau diese eine Tabelle. |
|---|
Häufige Fragen (FAQ)
Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.
Was sind Wait Stats?
Wait Stats sind die Warte-Statistiken des SQL Servers: Immer wenn eine Arbeitseinheit nicht weiterarbeiten kann — weil sie auf eine Sperre, einen Plattenzugriff, Arbeitsspeicher oder einen freien Prozessor wartet —, protokolliert der Server den Grund als Wartetyp und summiert die Wartezeiten. Diese Statistik ist die ehrlichste Auskunft, die du über einen SQL Server bekommst: Sie sagt dir nicht, was du vermutest, sondern worauf der Server tatsächlich seine Zeit verwartet. Deshalb sind Wait Stats der Ausgangspunkt jeder seriösen Performance-Diagnose — die Sprache, in der der Server seine Engpässe selbst benennt.
Wie nutze ich sys.dm_os_wait_stats?
Die DMV liefert pro Wartetyp die Gesamtwartezeit (wait_time_ms), die Anzahl der Wartevorgänge und die Signal-Wartezeit seit dem letzten Dienststart oder dem letzten manuellen Zurücksetzen. Für eine erste Einordnung filterst du die harmlosen Leerlauf-Typen heraus und sortierst nach Wartezeit absteigend — das fertige Skript steht in diesem Beitrag. Für die Akut-Diagnose ist allerdings die Delta-Messung wichtiger: zweimal im Abstand von ein paar Minuten messen und die Differenz betrachten, sonst versteckt sich das aktuelle Problem im Durchschnitt der gesamten Laufzeit. Mit DBCC SQLPERF lassen sich die Werte bei Bedarf zurücksetzen.
Was bedeutet der Wartetyp CXPACKET?
CXPACKET entsteht bei der Parallelverarbeitung: Eine Abfrage wurde auf mehrere Prozessor-Threads aufgeteilt, und dieser Wartetyp zählt die Zeit, die beim Koordinieren und Zusammenführen dieser Threads anfällt. Wichtig: CXPACKET ist kein Problem an sich, sondern meist ein Symptom — er taucht auf, wenn teure Abfragen parallel laufen. Auf neueren Versionen wurde der „echte“ Wartebestandteil in CXCONSUMER ausgelagert, sodass hohe CXPACKET-Werte heute seltener Alarm bedeuten. Die Therapie ist fast nie „Parallelität abschalten“, sondern die teuren Abfragen zähmen sowie MAXDOP und Cost Threshold sinnvoll setzen — Details im CPU-Beitrag.
Was bedeutet PAGEIOLATCH_SH?
PAGEIOLATCH_SH heißt: Eine Session will eine Datenseite lesen, die nicht im Buffer Pool liegt, und wartet darauf, dass sie von der Platte geladen wird — das SH steht für den Shared-Latch des Lesevorgangs. Vereinzelt ist das normal; dominiert der Typ die Wait Stats, liest der Server zu viel von der Platte. Die Folgefrage entscheidet über die Therapie: Liegt es am Storage (zu langsam) oder am SQL Server selbst (Scans wegen fehlender Indizes, ein zu kleiner Buffer Pool durch Memory Pressure)? Diese Verzweigung führt zu den Beiträgen über I/O-Latenz und Memory Pressure.
Was bedeutet ASYNC_NETWORK_IO?
ASYNC_NETWORK_IO ist der am häufigsten missverstandene Wartetyp. Er heißt fast nie „das Netzwerk ist kaputt“, sondern: Der SQL Server hat seine Ergebnisse fertig, aber die Anwendung holt sie zu langsam ab — etwa weil sie Millionen Zeilen anfordert und clientseitig zeilenweise verarbeitet (das klassische RBAR-Anti-Pattern). Dominiert dieser Typ, liegt das Problem also meist nicht am Server, sondern in der Anwendung: zu große Ergebnismengen, ineffiziente Client-Verarbeitung, fehlendes Paging. Die Wait Stats zeigen hier auf einen Bereich, den der DBA oft gar nicht selbst beheben kann — aber mit Zahlen belegen.
Welche Wartetypen sollte ich ignorieren?
Eine ganze Reihe von Wartetypen protokolliert nur planmäßigen Leerlauf oder interne Verwaltung und sagt nichts über Engpässe — Hintergrundprozesse, die schlafen, Timer, Warteschleifen. Klassische Vertreter sind SLEEP_TASK, LAZYWRITER_SLEEP, BROKER_TASK_STOP, XE_TIMER_EVENT, WAITFOR, CHECKPOINT_QUEUE, DIRTY_PAGE_POLL und REQUEST_FOR_DEADLOCK_SEARCH (das ist nur der Deadlock-Monitor bei seinem Fünf-Sekunden-Rundgang). Würdest du diese nicht herausfiltern, stünden sie mangels echter Arbeit oft ganz oben und würden die Diagnose verfälschen. Das Skript in diesem Beitrag filtert die gängigen Harmlosen bereits — die Community-Liste von Paul Randal ist die umfassende Referenz dafür.
Wie erstelle ich eine Wait-Stats-Baseline?
Eine Baseline ist eine regelmäßige Momentaufnahme der Wait Stats, die du über die Zeit wegschreibst — typischerweise per Agent-Job alle 15 oder 30 Minuten in eine eigene Tabelle, idealerweise als Delta zur vorherigen Messung. Der Wert liegt im Vergleich: „CXPACKET bei 30 Prozent“ ist ohne Kontext nur eine Zahl, aber „CXPACKET seit Dienstag von 12 auf 30 Prozent gestiegen“ ist ein Befund. Mit einer Baseline erkennst du Trends, bevor sie zu Notfällen werden, und kannst im Ernstfall gegen Normalwerte statt gegen Bauchgefühl diagnostizieren. Sie ist das Fundament, auf dem der ganze Health Check aufbaut.