Wer ein Performance-Problem auf dem SQL Server hat, greift oft zuerst zum Query Store. Verständlich – das Tool ist gut, visuell aufgeräumt, zeigt Ressourcenverbrauch auf der Zeitachse. Aber genau hier fängt das Problem an. Der Query Store zeigt, welche Abfrage gerade die meiste CPU oder das meiste Memory zieht. Was er nicht zeigt: ob diese Abfrage wirklich schuld ist.
Thorsten Strauß bringt das an einem Beispiel auf den Punkt, das jeder DBA kennt, aber nicht jeder richtig deutet: Locking und Blocking. Eine Abfrage verändert einen Datensatz und hält dabei einen exklusiven Lock. Eine zweite Abfrage will denselben Datensatz lesen – und wartet. Im Query Store sieht das so aus, als wäre die wartende Abfrage das Problem, weil ihre Execution-Time durch die Wartezeit in die Höhe schießt. Die eigentliche Ursache, nämlich die schreibende Abfrage, läuft unauffällig durch. Wer jetzt die lesende Query tuned, hat Zeit verschwendet.
Bevor man also überhaupt in den Query Store schaut, empfiehlt Strauß den Blick auf die DMVs. Dynamic Management Views sammeln seit dem letzten SQL-Server-Neustart Metadaten und Wartestatistiken – und die zeigen einem erfahrenen DBA schnell, ob ein dominanter Wartetyp vom Typ LCK auf Locking-Probleme hindeutet, ob eine offene Transaktion im Hintergrund sitzt, oder ob die TempDB bei Optimistic Concurrency Control gerade zum Flaschenhals wird. Erst wenn die DMVs eine Richtung vorgeben, macht es Sinn, gezielter mit Extended Events zu tracken.
Extended Events sind dabei nicht einfach ein Ersatz für den alten SQL Server Profiler – sie sind eine andere Kategorie. Der Profiler erzeugt selbst CPU-Last auf dem System, das er analysieren soll. Auf einem Server, der ohnehin schon knirscht, ist das kontraproduktiv. Extended Events sind deutlich leichter, gehen tiefer und lassen sich präzise auf bestimmte Event-Typen eingrenzen. Trotzdem: Strauß sieht noch immer Umgebungen, in denen der Profiler im Einsatz ist – obwohl Microsoft ihn seit Jahren als Deprecated markiert hat.
Ein weiteres Muster, das Strauß beschäftigt, ist der reflexartige Griff zu den Automatisierungsfeatures im SQL Server. Plan Regression als Beispiel: Der Query Store zeigt, dass eine Abfrage jetzt einen schlechteren Plan verwendet als früher. Microsoft empfiehlt, den besseren Plan zu forcieren. Klingt sinnvoll – ist aber eine Falle, wenn die Abfrage je nach übergebenem Parameter unterschiedliche Pläne braucht. Wer jetzt einen Plan fest einfriert, verbaut sich die Möglichkeit, das eigentliche Problem zu lösen, zum Beispiel durch einen passenden Index. Der forcierte Plan läuft dann auch dann suboptimal weiter, wenn der Index längst vorhanden wäre.
Das zieht sich durch: Features sind dann großartig, wenn man versteht, was sie tun. Und was sie nicht tun. Gerade bei unpredictable Workload Spikes – dem Black-Friday-Problem, das sich nicht wegtunen lässt – hilft kein Feature der Welt, wenn die Grundlage fehlt. Was hilft: eine Testinstanz mit simulierter Zufallsworkload, auf der man Blockaden und Ressourcenkonflikte sichtbar macht, bevor sie im Produktivbetrieb zuschlagen. Nicht eine einzelne Abfrage schnell machen. Die Gesamtauslastung der Workload senken.
Das ist, kurz gefasst, Thorstens Credo: Nicht die Query tunen. Die Workload tunen.
Thorsten Strauß spricht auf der DWX 2026 in Mannheim. DWX 2026, 29. Juni bis 2. Juli 2026, Mannheim. https://www.developer-world.de/dwx
