Microsoft SQL Server: Verbesserte automatische Plan Correction – warum Abfragen sich heute selbst heilen können

Wenn gute Pläne plötzlich schlecht laufen

Du kennst das:
Eine Abfrage lief gestern noch in 500 ms.
Heute braucht sie 20 Sekunden.
Und niemand hat was geändert – angeblich.

Der Schuldige?
Ein neuer Ausführungsplan.
SQL Server hat optimiert. Nur leider daneben.

Aber: Mit automatischer Plan Correction kann sich die Engine selbst helfen.
Und Du musst nicht mal einschreiten.

Was macht automatische Plan Correction?

SQL Server erkennt, wenn ein Plan „plötzlich schlecht“ ist.
Und ersetzt ihn automatisch durch den vorher besseren.
Nicht auf Verdacht – sondern basierend auf gemessener Performance.

Voraussetzung

• Query Store aktiv
• Kompatibilitätslevel 140 oder höher
• Enterprise Edition oder Azure SQL

Query Store aktivieren

ALTER DATABASE DeineDB 
SET QUERY_STORE = ON;
GO
ALTER DATABASE DeineDB 
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

Danach speichert SQL Server historische Ausführungspläne mit Metriken.

Automatische Korrektur aktivieren

ALTER DATABASE DeineDB 
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON);

SQL Server beobachtet die Query-Performance.
Wenn ein neuer Plan deutlich schlechter ist, wird er ersetzt.
Automatisch. Ohne Deine Eingriffe.

Was heißt „schlechter“?

SQL Server misst:

• Ausführungszeit
• CPU-Verbrauch
• I/O-Kosten

Wenn eine neue Plan-ID z. B. 5× länger braucht → Rollback.

Das Ganze passiert leise im Hintergrund.
Nur über sys.dm_db_tuning_recommendations sichtbar.

Monitoring: Welche Pläne wurden ersetzt?

SELECT 
    reason,
    state,
    details,
    script
FROM sys.dm_db_tuning_recommendations;

Hier siehst Du:

• Warum SQL Server eingegriffen hat
• Welcher Plan gut war
• Welcher Plan verworfen wurde
• Wie Du manuell dasselbe tun könntest

Beispiel: Stored Procedure läuft mal schnell, mal nicht

EXEC dbo.rechnung_generieren @kunde = 123;

SQL Server erzeugt beim ersten Aufruf einen Plan.
Aber der passt nicht für alle Kunden (Parameter Sniffing).

Früher: Du musstest RECOMPILE setzen oder manuell forcen.
Heute: Query Store merkt sich, dass Plan 42 besser lief als Plan 87.
Und setzt automatisch auf 42 zurück.

Manuell Pläne forcen (wenn nötig)

EXEC sp_query_store_force_plan 
    @query_id = 147, 
    @plan_id = 42;

Oder wieder freigeben:

EXEC sp_query_store_unforce_plan 
    @query_id = 147;

Sicht auf alle forcierten Pläne

SELECT 
    q.query_id,
    p.plan_id,
    q.object_id,
    p.is_forced_plan,
    p.is_forced_plan_persisted
FROM sys.query_store_plan p
JOIN sys.query_store_query q ON p.query_id = q.query_id
WHERE p.is_forced_plan = 1;

Damit findest Du alle aktuell fixierten Pläne.

Was bringt’s für KMU?

Mein Fazit

Planregressionen sind tückisch.
Du merkst’s oft erst spät – und findest die Ursache schwer.

Mit automatischer Plan Correction nimmt Dir SQL Server das ab.
Nicht perfekt. Aber in 90 % der Fälle hilfreich.

Wenn Du willst, aktiviere ich Dir Query Store und Tuning mit zwei Befehlen.
Und plötzlich musst Du nicht mehr jede langsame SP manuell jagen.