Unter der Kurve.
Eine CPU-Kurve ist die Summe tausender Entscheidungen des Optimizers. PSG QX zerlegt sie wieder: welche Abfrage, welcher Plan, welche Stelle im Code, seit wann – und worauf sich jede Aussage stützt.
- Ebene 01 · OberflächeWann wurde es anders?Die Kurve, die jedes Monitoring zeigt.
- Ebene 02 · PopulationWer trägt die Last?Viele Abfragen, wenige tragen fast alles.
- Ebene 03 · MechanikWarum hat der Optimizer so entschieden?Ein Plan, an einem Operator verschätzt.
- Ebene 04 · UrsprungWo im Code?Eine Zeile, die den Unterschied macht.
- Ebene 05 · WirkungHat es geholfen?Zurück an der Oberfläche: Die Kurve ist wieder unten. Gestrichelt der Verlauf vor der Änderung.
Die Frage ist einfach: Wurde es teurer oder nur häufiger? Die Antwort ist es nicht.
Monitoring zeigt zuverlässig, wann ein System langsamer wird. Warum, steht nicht in der Kurve, sondern in den Ausführungen darunter: in Plänen, Schätzungen, Statistiken, Parametern und Code. Genau dort setzt PSG QX an.
Dieselbe Kurve, anders gelesen.
Ziehen Sie den Regler von der Monitoring-Sicht zur QX-Sicht. Die Kurve bleibt dieselbe. Sie wird nur in das zerlegt, woraus sie besteht.
Illustration mit synthetischen Daten, kein Kundenfall.
Fünf Ebenen unter der Kurve.
Jede Untersuchung steigt von der Oberfläche in die Tiefe und kehrt mit einer prüfbaren Aussage zurück.
-
Ebene 01 · Oberfläche
Wann wurde es anders?
CPU, Wartezeiten und Ausführungen über die Zeit. Diese Sicht bietet jedes Monitoring. Für uns ist sie der Ausgangspunkt, nicht das Ergebnis.
Was die Kurve nicht zeigt: welche Abfrage die Last trägt.
-
Ebene 02 · Population
Wer trägt die Last, und wurde es teurer oder nur häufiger?
Hinter jedem Intervall stehen Abfragen und ihre Pläne. QX zeigt, welche davon die Last tragen und ob eine Abfrage häufiger lief oder je Ausführung teurer wurde.
Was die Kurve nicht zeigt: dass zwei gleich hohe Ausschläge ganz verschiedene Ursachen haben können.
-
Ebene 03 · Mechanik
Warum hat der Optimizer so entschieden?
Pläne, Schätzungen, Statistiken und Parameter. Hier zeigt sich, ob eine bekannte Abfrage einen neuen Plan bekommen hat, wo Schätzung und Wirklichkeit auseinanderlaufen oder ob Statistiken aus einem früheren Aufruf mitgenommen wurden.
Was die Kurve nicht zeigt: dass der Optimizer mit veralteten Annahmen gerechnet hat.
Wie das aussieht: Eine Abfrage, viele Pläne →
Befund aus einer Demo-Workload: Statistiken einer temporären Tabelle aus früheren Aufrufen. -
Ebene 04 · Ursprung
Wo im Code setzen wir an?
Die Last landet an der Zeile im Quelltext der Prozedur, zusammen mit den Plänen, die dort entstanden sind. So wird aus einem Datenbankbefund eine Aufgabe, die Entwicklung und Betrieb gemeinsam angehen können.
Was die Kurve nicht zeigt: welche Zeile im Code die Last verursacht.
-
Ebene 05 · Wirkung
Hat die Änderung geholfen?
Vorher und nachher unter vergleichbaren Bedingungen. Wo die Bedingungen nicht vergleichbar sind, sagt QX das, statt eine Verbesserung zu behaupten.
Was die Kurve nicht zeigt: ob weniger Last an der Änderung liegt oder nur an einem ruhigeren Tag.
Demo-Workload: Nach der Änderung um 16:36 sinkt die CPU je Aufruf, die Zahl der Aufrufe steigt.
Die Historie als Datensatz, nicht als Dashboard.
Wir lesen die Ausführungshistorie wie Datenanalysten: erst prüfen, was die Daten tragen, dann Schlüsse ziehen. Data Mining nutzen wir dafür seit Jahren, lange vor generativer AI und LLMs.
beobachtung CPU je Aufruf seit Dienstag etwa verdreifacht, Aufrufe unverändert. im plan Neuer Plan für eine bekannte Abfrage; Schätzung an einem Join weit daneben. gemessen Mehr Lesezugriffe je Aufruf; der Plan läuft jetzt parallel, ist aber kaum früher fertig. hypothese Statistik nach der Wartung mit kleiner Stichprobe neu erstellt. offen Ein Teil der Last ist keiner Abfrage sicher zuzuordnen und bleibt ausgewiesen. prüfung Statistik gezielt aktualisieren, dieselben Kennzahlen im selben Zeitfenster vergleichen.
Eigene Normalität statt Faustregel
Eine Phase wird mit früheren Zeiten desselben Musters verglichen, nicht mit einem Grenzwert aus dem Handbuch.
Erst Vergleichbarkeit, dann Vergleich
Jeder Vergleich wird eingestuft: vergleichbar, eingeschränkt oder nicht möglich, jeweils mit Grund.
Belegstufen
Im Plan belegt, gemessen oder Hypothese. Beobachtetes wird nicht als Vorhersage ausgegeben.
Unsicherheit bleibt sichtbar
Was sich nicht zuordnen lässt, bleibt als solches stehen. Fehlende Daten gelten nicht als null.
Modelle müssen sich bewähren
Verfahren werden an derselben Historie gegeneinander geprüft. Ein aufwendigeres Modell muss erst zeigen, dass es besser ist.
Lokal und wiederholbar
Die Analyse läuft lokal und ohne KI-Dienste. Gleiche Eingaben und gleicher Verfahrensstand ergeben dasselbe Ergebnis.
Über zehn Jahre dieselbe Frage.
PSG QX ist die jüngste Generation unserer eigenen Werkzeuge. Die Frage dahinter ist älter: Was tut eine SQL-Server-Workload tatsächlich, und warum?
- 2015Eigene DiagnosewerkzeugeVortrag auf der SQLBits über die Entwicklung eigener Monitoring- und Diagnosewerkzeuge.
- 2017PSG MXMonitoring-Framework für die kontinuierliche Betreuung, die erste Fassung in C#.
- 2020Machine Learning für DBAsVorträge zu Machine Learning für DBA-Aufgaben und Performanceanalyse; ab 2021 vorausschauendes Monitoring.
- 2025PSG QXNeuer Analysekern: die Ausführungshistorie lokal, vom Zeitverlauf bis zum Plan.
- 2026Bis zur CodezeileQuelltext, temporäre Tabellen und strukturierte Befunde mit Belegstufen.
Werkzeuge lassen sich heute schneller bauen als je zuvor. Welche Frage man den Daten stellt und wann ein Vergleich nicht trägt, lernt man nur mit echter Erfahrung. Alles andere ist Imitation.
Parallelismus: Faustregel oder eigene Historie?
„Cost Threshold for Parallelism auf 50, MAXDOP auf 8“ – kaum eine SQL-Server-Einstellung hat so viele Faustregeln. Dabei hängt die richtige Einstellung davon ab, was Ihre Workload tatsächlich tut.
- Parallelität ist ein Werkzeug. Richtig dosiert macht sie große, kritische Abfragen deutlich schneller. Falsch dosiert kostet sie CPU, ohne dass etwas früher fertig wird.
- Das Ziel ist Laufzeit, nicht Wartezeit. Eine gute Einstellung setzt das vorhandene CPU-Budget so ein, dass kritische Abfragen in echter Laufzeit (Wall Clock Time) schneller fertig werden.
- Wartezeit gehört dazu. Parallelismus-Wartezeit entsteht auch dann, wenn sich Parallelität lohnt. Sie isoliert herunterzuschrauben, fühlt sich nach Handeln an, macht aber selten etwas schneller.
Was Parallelität bringt und kostet
Eine parallele Abfrage verteilt ihre Zeilen auf mehrere Threads und sammelt sie am Ende wieder ein. Das spart Zeit für die Abfrage und kostet den Server zusätzliche CPU. Probieren Sie aus, wann sich das lohnt.
Tor und Breite. Cost Threshold for Parallelism ist das Tor: Es entscheidet, ob eine Abfrage überhaupt parallel geplant werden darf. MAXDOP ist die Breite: wie viele Kerne sie dann höchstens bekommt. Microsofts Empfehlung nach NUMA-Knoten leitet diese Breite aus der Hardware ab. Für einen generischen Server ist das ein brauchbarer Ausgangswert, für eine Optimierung oft zu kurz gedacht: Dann muss MAXDOP zur Workload passen, also dazu, wie viele Abfragen gleichzeitig um dieselben Kerne konkurrieren und welche davon kritisch sind. Nicht ohne Grund lässt sich die Breite auch je Datenbank und per Abfragehinweis einstellen. Das Tor gilt dagegen nur für die ganze Instanz.
Microsoft nennt den Standardwert 5 für Cost Threshold for Parallelism a starting point, not a recommendation
und rät, in kleinen Schritten zu ändern und jeweils einen ganzen Geschäftszyklus zu beobachten. Microsoft Learn ↗
Vereinfachtes Modell zur Veranschaulichung, keine Messung.
Was PSG QX daraus macht
Statt jeden Schritt einen Geschäftszyklus lang auszuprobieren, bewertet QX die bereits aufgezeichnete Historie unter einer anderen Schwelle neu. Ausdrücklich als Beobachtung, nicht als Vorhersage.
- Senkrechte Achse: die Kostenschätzung des Optimizers. Nur danach entscheidet die Schwelle.
- Waagerechte Achse: die tatsächlich gemessene CPU-Zeit.
- Rote gestrichelte Linie: die simulierte Schwelle. Rote Punkte darüber dürften parallel planen.
- Schraffiertes Band: Pläne zwischen heutiger und simulierter Schwelle. Sie würden künftig seriell kompiliert.
- Gefüllt oder hohl: lief parallel oder seriell. Die Punktgröße steht für die Zahl der Ausführungen.
- Rechts: die Wirkung in Zahlen, ausdrücklich als Schätzung auf Basis der beobachteten Historie.
Selbst ausprobieren
Dieselbe Demo-Workload, vereinfacht. Verschieben Sie die Schwelle und sehen Sie, welche Pläne heute parallel laufen und künftig seriell kompiliert würden.
Echte Kennzahlen einer Demo-Workload, vereinfacht dargestellt. Beobachtet, nicht vorhergesagt: Ob diese Pläne seriell schneller oder langsamer wären, zeigt erst der Vergleich nach einer Änderung.
Kosten gegen Wirklichkeit
Die Schwelle entscheidet nach der Schätzung des Optimizers, nicht nach der Laufzeit. QX legt beides nebeneinander.
Was eine Änderung kosten würde
Welche wenigen Abfragen profitieren stark von Parallelität und würden bei einer pauschalen Änderung verlieren?
Natürliche Experimente
Dieselbe Abfrage lief einmal seriell und einmal parallel. Was war tatsächlich schneller?
Wenn keine Einstellung hilft
Teure Abfragen, die trotz Eignung seriell laufen, etwa wegen Funktionen, Hinweisen oder Cursorn. Hier hilft eine Änderung im Code, keine Servereinstellung.
Wo QX in unserer Arbeit steckt.
PSG QX ist das Werkzeug unserer Engineers in Troubleshooting, Analyse und laufender Betreuung. Typische Anlässe:
„Seit dem Update ist es langsamer.“
Neue Abfragen, neue und verschlechterte Pläne, häufiger oder teurer: der Vergleich vor und nach dem Update.
Zur Performance-Analyse → Akut & PSG MX„Nachts bricht es ein, morgens ist alles normal.“
Die Ausführungshistorie zeigt die Nacht im Nachhinein. Der QX Recorder hält Belege fest, bevor sie verschwinden.
Mehr zur Performance → Entwicklung & Hersteller„Die Prozedur ist langsam, aber wo?“
Anweisung und Zweig im Quelltext, temporäre Tabellen im Ablauf, die Pläne dazu.
Für Softwarehersteller → Infrastruktur„Mehr Cores, aber nicht schneller.“
Welche Abfragen parallel warten, ohne schneller zu werden, und was eine andere Einstellung in der eigenen Historie bedeutet hätte.
Zu Infrastruktur → Betrieb„Der Hersteller sagt, es liegt an Ihrer Datenbank.“
Ein Befund mit Plan und Codestelle macht aus der Schuldfrage ein sachliches Gespräch.
Für RZ-Betreiber → Große Landschaften„Viele Instanzen, wo lohnt sich die Arbeit?“
Wie sich Last und Wartezeiten über Instanzen und Datenbanken verteilen.
Für RZ-Betreiber →Was PSG QX nicht behauptet.
Keine automatische Ursache
QX grenzt ein und belegt. Ob eine Hypothese stimmt, prüfen wir gemeinsam mit Ihnen.
Keine garantierte Beschleunigung
Eine Neubewertung der Historie zeigt, was beobachtet wurde, nicht was künftig passiert.
Kein Ersatz für Erfahrung
QX ist das Werkzeug unserer Engineers. Den Befund verantworten Menschen.
Die Analyse läuft lokal auf dem Rechner, auf dem QX läuft, ohne Cloud- oder KI-Dienste. Welche Daten wohin gelangen, legen wir für jeden Einsatz fest. Sie nutzen PSG QX bereits? Lizenzen und Zugang →
Schildern Sie uns Ihren Fall.
Welche Anwendung, seit wann, woran merken Sie es? Im ersten Gespräch klären wir, welche Daten Ihre Frage beantworten können. Bitte schicken Sie noch keinen Quelltext mit.