Utiliser ABORT_QUERY_EXECUTION pour bloquer l’exécution de requêtes dans SQL Server 2025

Utiliser ABORT_QUERY_EXECUTION dans SQL Server 2025 pour bloquer l’exécution de requêtes identifiées comme problématiques via Query Store Hints.

ABORT_QUERY_EXECUTION est un nouveau “query hint” (SQL Server 2025 / 17.x) conçu comme un frein d’urgence : il permet de bloquer l’exécution future d’une requête identifiée comme problématique (consommation CPU/IO excessive, requête “runaway”, reporting non essentiel qui met en péril un workload critique, etc.).

Si vous l’ajouter en hint de requête, il déclenche un échec immédiat de la requête.

C’est utile en production, combiné avec un Query Store Hint : vous pouvez ainsi bloquer une requête spécifique (identifiée par son query_id dans le Query Store) sans modifier le code applicatif.

Concrètement

La requête échoue immédiatement avec l’erreur 8778 (sévérité 16) : “Query execution has been aborted because the ABORT_QUERY_EXECUTION hint was specified.”
L’objectif principal est l’usage administratif via le Query Store (donc sans modifier le code applicatif).
Il n’arrête pas une requête déjà en cours : il ne s’applique qu’aux exécutions futures. Pour stopper une exécution en cours, il faut utiliser KILL.
Vous ne pouvez pas bloquer une requête “inconnue” : il faut au minimum qu’une exécution de la requête soit enregistrée dans Query Store (même si l’exécution a échoué/timeout/annulée).
ABORT_QUERY_EXECUTION est disponbile sur Azure SQL Database, Azure SQL Managed Instance, et SQL Server 2025 (17.x).

Ce n’est pas un “timeout” paramétrable. C’est une interdiction d’exécuter (par identification Query Store), donc un mécanisme de gouvernance/production.

Activer le hint dans le Query Store

Le Query Store doit être activé.

Il faut identifier le query_id de la requête à bloquer, puis appliquer le hint ABORT_QUERY_EXECUTION via la procédure stockée sys.sp_query_store_set_hints.

Identifier le `query_id` à bloquer

Vous pouvez :

passer par les rapports Query Store dans SSMS,
ou interroger les vues de catalogue.

Les hints sont gérées avec :

sys.sp_query_store_set_hints (création/mise à jour)
sys.sp_query_store_clear_hints (suppression)
La visibilité/diagnostic passe par la vue catalogue sys.query_store_query_hints.

Il faut une permission ALTER sur la base pour définir/retirer ces hints.

Attribuer le Query Hint

EXEC sys.sp_query_store_set_hints
     @query_id    = 39,
     @query_hints = N'OPTION (USE HINT (''ABORT_QUERY_EXECUTION''))';

Toute exécution future de la requête attachée à query_id = 39 échoue avec l’erreur 8778.

Vérifier que la requête est bien “bloquée”

La vue sys.query_store_query_hints expose le texte du hint, l’état et les raisons d’échec éventuelles (si une hint n’a pas pu s’appliquer).

SELECT query_hint_id,
       query_id,
       replica_group_id,
       query_hint_text,
       last_query_hint_failure_reason,
       last_query_hint_failure_reason_desc,
       query_hint_failure_count,
       source,
       source_desc
FROM sys.query_store_query_hints
WHERE query_id = 39;

Débloquer (revenir en arrière)

Vous pouvez supprimer tous les hints pour le query_id :

EXEC sys.sp_query_store_clear_hints @query_id = 39;

Si vous aviez plusieurs hints et souhaitez garder les autres, réappliquez sp_query_store_set_hints en retirant seulement ABORT_QUERY_EXECUTION.

Inventorier tous les blocages

Pour lister toutes les requêtes bloquées via ABORT_QUERY_EXECUTION :

SELECT qh.query_id,
       qh.query_hint_text,
       qh.query_hint_failure_count,
       qh.last_query_hint_failure_reason_desc,
       qt.query_sql_text
FROM sys.query_store_query_hints AS qh
JOIN sys.query_store_query AS q
  ON q.query_id = qh.query_id
JOIN sys.query_store_query_text AS qt
  ON qt.query_text_id = q.query_text_id
WHERE qh.query_hint_text LIKE N'%ABORT_QUERY_EXECUTION%'
ORDER BY qh.query_id DESC;

Si le hint est présent, mais ne s’applique pas

Utilisez sys.query_store_query_hints et regardez :

last_query_hint_failure_reason_desc
query_hint_failure_count

Readable secondaries

SQL Server 2025 introduit/renforce le support de Query Store sur réplicas secondaires lisibles (scénarios AG), et sys.sp_query_store_set_hints expose un paramètre @replica_group_id pour contrôler l’étendue d’application du hint selon le groupe de réplicas.

Vous pouvez vouloir bloquer une requête uniquement sur un secondaire lisible (reporting) sans impacter le primaire, ou l’inverse selon l’architecture.
Cela devient un levier de gouvernance plus précis quand les workloads sont séparés (lecture/reporting vs OLTP).

Références

Query Store hints best practices