Parks reservation joins suddenly choose a poor plan after statistics shifts, and staff want the prior good plan restored quickly. Which Query Store capability should they use?
Select an answer to reveal the explanation.
Short Explanation
Query Store plan forcing is the ‘restore last good map’ button—parks can pin the join plan that worked instead of hoping the optimizer wanders back.
Full Explanation
When parks reservation joins regress to a poor plan after statistics shifts, Query Store’s plan-forcing capability is the rapid stabilization path: identify the query, compare the prior good plan to the new regressing plan, and force the last known-good plan so reservation joins return to the shape that worked while the team investigates stats or indexing root causes. That surgically restores performance without a broad outage or destructive schema change during peak season demand. Deleting Query Store entirely erases the history needed to find and reapply the good plan; it makes regression analysis harder, not easier. Disabling all nonclustered indexes overnight may change plans unpredictably and can devastate reservation lookup performance. Switching the database to READ ONLY blocks necessary reservation writes and is not a plan-restore technique. Exam caveat: forced plans can fail to apply after schema changes or when the forced plan is invalid for the current shape; monitor force failures in Query Store. Forcing buys stability but is not a substitute for fixing statistics, indexes, or parameter sensitivity that caused the regression. Automatic plan correction (where available) is related but distinct from manual force. Operational check: in Query Store, locate the reservation query by query_id; compare runtime stats across plan_ids; force the prior good plan in a lower environment first; verify compile success and duration/CPU improvement; force in production during a maintenance window if needed; schedule a follow-up to address stats/indexes and eventually unforce once a healthy automatic plan is proven.