Query Store als Flugschreiber für SQL-Server-Performance

Viele Performanceprobleme verschwinden, bevor ein Ausführungsplan erfasst wird. Query Store bewahrt Abfrage-, Plan-, Laufzeit- und Wartedaten für die spätere Analyse.

Warum dieses Thema gezielte Aufmerksamkeit verdient

Probleme in diesem Bereich treten selten isoliert auf. Eine Änderung, die eine Abfrage verbessert, kann Schreibkosten, Logvolumen, Blocking, Wiederherstellungszeit oder betriebliche Komplexität an anderer Stelle erhöhen. Behandeln Sie die Arbeit als technische Entscheidung mit messbarem Ziel, bekannten Grenzen und klarer Verantwortung.

Query Store macht aus der ungenauen Aussage, die Datenbank sei langsam gewesen, eine zeitlich eingegrenzte Untersuchung mit Nachweisen.

Was gemessen werden sollte

Vergleichen Sie Dauer, CPU, logische Lesevorgänge, Ausführungen, Wartezeiten und Pläne im genauen Störungszeitraum. Prüfen Sie Deployment, Statistikänderungen und parameterabhängige Pläne.

Diagnoseablauf

• Definieren Sie Symptom, betroffene Last, Beginn, Häufigkeit und sichtbare Auswirkung genau.
• Erfassen Sie Nachweise in normalen und gestörten Zeiträumen für denselben Geschäftsprozess.
• Trennen Sie Korrelation und Ursache durch Prüfung von Plänen, Wartezeiten, Ressourcen, Blocking, Konfiguration und Änderungen.
• Testen Sie repräsentative Datenbanken, Abfragen oder Parametergruppen und nicht nur das einfachste Beispiel.
• Sichern Sie aktuelle Einstellung, Plan, Objektdefinition und relevante Zähler vor jeder Änderung.
• Formulieren Sie das erwartete Ergebnis numerisch, etwa Latenz, CPU, logische Lesevorgänge, Durchsatz, Queue oder Recovery-Zeit.

Die passende Maßnahme auswählen

Bevorzugen Sie die kleinste Änderung, die die nachgewiesene Ursache behandelt. Serverkonfigurationen betreffen viele Lasten, während Änderungen an Abfrage, Index, Statistik oder Zeitplan häufig gezielter wirken. Berücksichtigen Sie Lizenz, SQL-Server-Version, Hochverfügbarkeit, Wartungsfenster und die Fähigkeit des Teams zur Überwachung.

Praktisches Vorgehen

Definieren Sie Größe und Bereinigung. Sichern Sie den schlechten und den früheren Plan. Nutzen Sie Query-Store-Hinweise oder Plan Forcing nur als kontrollierte Stabilisierung mit Überwachung und Ablaufdatum.

Sichere Umsetzungsreihenfolge

• Reproduzieren Sie das Verhalten möglichst mit produktionsnaher Datenmenge in einer sicheren Umgebung.
• Ändern Sie jeweils eine wesentliche Variable und sichern Sie die ursprüngliche Definition für den Rollback.
• Messen Sie Laufzeit, CPU, logische Lese- und Schreibvorgänge, Wartezeiten, Speicher, Logvolumen und Nebenwirkungen.
• Testen Sie normale, maximale und seltene Eingaben sowie gegebenenfalls Neustart und Failover.
• Stellen Sie in einem geeigneten Fenster bereit und verbinden Sie Operator, Anwendungsverantwortlichen und Rollback-Entscheider.
• Bewerten Sie das Ergebnis sofort und erneut während der nächsten repräsentativen Produktionsspitze.

SQL-Server-Beispiel

Das folgende Beispiel ist ein Ausgangspunkt für Untersuchung oder kontrollierte Umsetzung. Passen Sie Datenbanknamen, Grenzwerte, Aufbewahrung und Berechtigungen vor dem Produktionseinsatz an. Bewahren Sie die Ausgabe zusammen mit der Störungszeitleiste auf und bewerten Sie nicht nur eine einzelne Stichprobe.

SELECT TOP (20)
    q.query_id,
    p.plan_id,
    SUM(rs.count_executions) AS executions,
    SUM(rs.avg_duration * rs.count_executions) /
        NULLIF(SUM(rs.count_executions), 0) AS weighted_duration,
    SUM(rs.avg_logical_io_reads * rs.count_executions) AS logical_reads
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
GROUP BY q.query_id, p.plan_id
ORDER BY weighted_duration DESC;

Was vermieden werden sollte

Erzwingen Sie nicht den ersten schnell wirkenden Plan. Ignorieren Sie keinen schreibgeschützten Query Store und lassen Sie Notfallhinweise nicht dauerhaft bestehen.

Überwachung nach der Änderung

Überwachen Sie die Zielmetrik und mindestens zwei mögliche Nebenwirkungen. Vergleichen Sie gleichwertige Zeiträume und Lastmengen. Der Beobachtungszeitraum sollte Wartung, Sicherungen, Berichte, Failover und periodische Aktivitäten enthalten. Dokumentieren Sie, ob die Verbesserung bestehen bleibt und ob die Änderung beibehalten, angepasst oder entfernt wird.

Rollback und Verantwortung

Ein Rollback benennt den exakten früheren Wert oder die Definition, den Entscheider und das Signal zur Rücknahme. Sichern Sie bei Plan- oder Metadatenänderungen den ursprünglichen Plan und das Objektskript. Bestätigen Sie bei Infrastrukturänderungen vorher verfügbare Kapazität und Wartungszeit.

Betriebliches Ergebnis

Query Store macht aus der ungenauen Aussage, die Datenbank sei langsam gewesen, eine zeitlich eingegrenzte Untersuchung mit Nachweisen.

Checkliste für die Produktion

Erfassen Sie eine Ausgangsbasis und definieren Sie die erwartete Verbesserung. Testen Sie mit repräsentativen Daten und realistischer Parallelität. Sichern Sie die ursprüngliche Einstellung oder den Plan, bereiten Sie einen Rollback vor und überwachen Sie die nächste normale Lastspitze.

Fragen vor Abschluss der Arbeit

• Hat sich das ursprüngliche Symptom unter derselben Last verbessert?
• Sind neue Kosten bei Schreiben, Speicher, Blocking, Memory oder Verfügbarkeit entstanden?
• Übersteht das Ergebnis Neustart, Failover, Statistikupdates und Datenwachstum?
• Erkennt das Monitoring eine Regression vor einer Benutzermeldung?
• Sind Entscheidung, Verantwortlicher und Prüfdatum dokumentiert?

Wenn Sie diese Methode auf eine konkrete SQL-Server-Umgebung anwenden möchten, nutzen Sie das Frageformular unten und nennen Sie SQL-Server-Version, Datenbankgröße, Lastprofil und bereits erfasste Nachweise.