Automatic plan correction is valuable because it can detect a regressed execution plan and force the last known good plan before users spend hours waiting for manual diagnosis. The operational problem is that no production workload is completely uniform. A small number of volatile, long-running, or deliberately forced queries may not fit the same correction logic as the rest of the database. Microsoft's July 2026 guidance on sys.sp_configure_automatic_tuning makes that boundary explicit.

Why it matters in production

The control works through Query Store. A DBA identifies the relevant query_id and can set FORCE_LAST_GOOD_PLAN to OFF for that query while leaving automatic plan correction enabled for the database. The setting is visible through sys.database_automatic_tuning_configurations and is written to the SQL Server error log. That matters because the exception becomes a database configuration that can be reviewed, rather than an informal instruction to ignore the next automatic action.

A query-level exclusion should remain exceptional. It can be justified when a query has a known pattern that automatic plan correction evaluates poorly, when another controlled forcing mechanism owns the plan, or while a regression is being investigated. It is not a substitute for fixing stale statistics, unstable parameter sensitivity, missing indexes, or poor query design. Turning correction off without an owner and an expiry date simply converts automation risk into permanent manual debt.

Laptop displaying a metrics view and a time-based chart
An APC exception needs measurable Query Store evidence and should not be based on a single impression.

Microsoft also documents FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK, an additional time-based regression check for a selected query. Its current documented scope is Azure SQL Database and SQL database in Microsoft Fabric, not the SQL Server engine generally. That distinction is important: teams should not copy syntax from a cloud example into an on-premises runbook without checking product scope, build level, permissions, and the behavior supported by their platform.

The safe operating pattern is small and measurable. Record the query_id, the reason for the exception, the baseline plan and runtime evidence, the owner, and the review date. After applying the setting, verify sys.database_automatic_tuning_configurations, observe Query Store and workload behavior, and keep a tested command that returns the query to normal APC consideration. If the query text or Query Store identity changes after deployment, confirm that the intended exception still points to the intended workload.

Engineer reviewing charts and metrics on a workstation monitor
Query-specific control remains operational work: reason, owner, review date, and return path need to be documented together.

Practical takeaway

The practical takeaway is not to weaken automatic tuning. It is to give it an explicit control boundary. Keep automatic plan correction for the broad set of regressions it can resolve safely, isolate the few queries that need different handling, and make every exception observable and reversible. Automation earns trust when operators can explain where it acts, where it does not, and why.