Automatic Plan Correction ist wertvoll, weil sie einen verschlechterten Ausführungsplan erkennen und den letzten bekannten guten Plan erzwingen kann, bevor Anwender stundenlang auf eine manuelle Diagnose warten. Im Produktionsbetrieb sind Arbeitslasten jedoch nie vollständig gleichförmig. Einige volatile, lang laufende oder bewusst erzwungene Abfragen passen möglicherweise nicht zu derselben Korrekturlogik wie der übrige Datenbankbestand. Microsofts Hinweise vom Juli 2026 zu sys.sp_configure_automatic_tuning machen diese Grenze ausdrücklich steuerbar.

Bedeutung für den Betrieb

Die Steuerung arbeitet mit dem Query Store. Ein DBA ermittelt die betreffende query_id und kann FORCE_LAST_GOOD_PLAN für genau diese Abfrage auf OFF setzen, während Automatic Plan Correction für die Datenbank aktiv bleibt. Die Einstellung ist über sys.database_automatic_tuning_configurations sichtbar und wird im SQL-Server-Fehlerprotokoll festgehalten. Damit wird die Ausnahme zu einer überprüfbaren Datenbankkonfiguration und bleibt keine informelle Anweisung, beim nächsten automatischen Eingriff wegzusehen.

Eine Ausnahme auf Abfrageebene sollte trotzdem selten bleiben. Sie kann sinnvoll sein, wenn Automatic Plan Correction ein bekanntes Abfragemuster unpassend bewertet, ein anderer kontrollierter Mechanismus den Plan erzwingt oder eine Regression gerade untersucht wird. Sie ersetzt weder die Korrektur veralteter Statistiken noch die Arbeit an instabiler Parametersensitivität, fehlenden Indizes oder schlechtem Abfragedesign. Wer die Korrektur ohne Verantwortlichen und Ablaufdatum abschaltet, verwandelt ein Automatisierungsrisiko lediglich in dauerhafte manuelle Schulden.

Laptop mit einer Metrikansicht und zeitlichem Verlauf auf dem Bildschirm
Eine APC-Ausnahme braucht messbare Ausgangsdaten aus dem Query Store und darf nicht allein auf einem einmaligen Eindruck beruhen.

Microsoft dokumentiert außerdem FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK, eine zusätzliche zeitbasierte Regressionsprüfung für eine ausgewählte Abfrage. Der derzeit dokumentierte Geltungsbereich umfasst Azure SQL Database und SQL Database in Microsoft Fabric, nicht allgemein die SQL-Server-Engine. Diese Unterscheidung ist wichtig: Ein Beispiel aus einem Cloud-Dienst gehört nicht ungeprüft in ein lokales Runbook. Produktumfang, Buildstand, Berechtigungen und das tatsächlich unterstützte Verhalten müssen zur eigenen Plattform passen.

Ein sicherer Betriebsablauf bleibt klein und messbar. Dokumentiert werden query_id, Grund der Ausnahme, Ausgangsplan und Laufzeitnachweis, Verantwortlicher und Prüftermin. Nach der Änderung sollten DBAs sys.database_automatic_tuning_configurations, Query Store und das Verhalten der Arbeitslast prüfen und einen getesteten Befehl bereithalten, der die Abfrage wieder der normalen APC-Bewertung zuführt. Ändert sich durch ein Deployment der Abfragetext oder die Query-Store-Identität, muss auch die Zuordnung der Ausnahme erneut geprüft werden.

Techniker bei der Prüfung von Diagrammen und Kennzahlen auf einem Arbeitsplatzmonitor
Abfragespezifische Steuerung bleibt Betriebsarbeit: Grund, Verantwortlicher, Prüftermin und Rückweg müssen zusammen dokumentiert sein.

Praktische Konsequenz

Die praktische Konsequenz besteht nicht darin, Automatic Tuning zu schwächen, sondern ihm eine klare Betriebsgrenze zu geben. Die automatische Plankorrektur bleibt für jene Regressionen aktiv, die sie zuverlässig beheben kann. Die wenigen Sonderfälle erhalten einen anderen, dokumentierten Umgang. Automatisierung verdient Vertrauen, wenn Betreiber erklären können, wo sie eingreift, wo nicht und aus welchem Grund.