Partage via

sp_query_store_force_plan (Transact-SQL)

  • Article

S’applique à : SQL Server 2016 (13.x) et versions ultérieures Azure SQL Database Azure SQL Managed Instance

Permet de forcer un plan particulier pour une requête particulière dans le Magasin des requêtes.

Lorsqu’un plan est forcé pour une requête en particulier, SQL Server tente de forcer le plan dans l’optimiseur de requête chaque fois qu’il rencontre la requête en question. Si le forçage de plan échoue, un événement étendu est déclenché. L’optimiseur reçoit alors l’instruction d’effectuer une optimisation normale.

Conventions de la syntaxe Transact-SQL

Syntaxe

sp_query_store_force_plan
    [ @query_id = ] query_id ,
    [ @plan_id = ] plan_id ,
    [ @disable_optimized_plan_forcing = ] disable_optimized_plan_forcing ,
    [ @force_plan_scope = ] 'replica_group_id'
[ ; ]

Arguments

[ @query_id = ] query_id

ID de la requête. @query_id est bigint, sans valeur par défaut.

[ @plan_id = ] plan_id

ID du plan de requête à forcer. @plan_id est bigint, sans valeur par défaut.

[ @disable_optimized_plan_forcing = ] disable_optimized_plan_forcing

Indique si le forçage de plan optimisé doit être désactivé. @disable_optimized_plan_forcing est bit avec une valeur par défaut .0

[ @force_plan_scope = ] 'replica_group_id'

Vous pouvez forcer les plans sur un réplica secondaire lorsque Magasin des requêtes pour les réplicas secondaires est activé. Exécutez sp_query_store_force_plan et sp_query_store_unforce_plan sur le réplica secondaire. L’argument @force_plan_scope facultatif est défini par défaut uniquement sur le réplica local (principal ou secondaire), mais vous pouvez éventuellement spécifier un replica_group_id faisant référence à sys.query_store_replicas.

Valeurs des codes de retour

0 (réussite) or 1 (échec).

Notes

Le plan d’exécution résultant forcé par cette fonctionnalité est identique ou similaire au plan forcé. Étant donné que le plan résultant peut ne pas être identique au plan spécifié par sys.sp_query_store_force_plan, les performances des plans peuvent varier. Dans de rares cas, la différence de performances peut être significative et négative ; dans ce cas, l’administrateur doit supprimer le plan forcé.

Passez en revue les plans forcés sur les réplicas secondaires avec sys.query_store_plan_forcing_locations.

autorisations

Exige l’autorisation ALTER sur la base de données.

Exemples

L’exemple suivant retourne des informations sur les requêtes dans le Magasin des requêtes.

SELECT txt.query_text_id,
    txt.query_sql_text,
    pl.plan_id,
    qry.*
FROM sys.query_store_plan AS pl
INNER JOIN sys.query_store_query AS qry
    ON pl.query_id = qry.query_id
INNER JOIN sys.query_store_query_text AS txt
    ON qry.query_text_id = txt.query_text_id;

Après avoir identifié les query_id et les plan_id que vous souhaitez forcer, utilisez l’exemple suivant pour forcer la requête à utiliser un plan.

EXEC sp_query_store_force_plan
    @query_id = 3,
    @plan_id = 3;

Utilisez sys.query_store_plan_forcing_locations, joint à sys.query_store_replicas, pour récupérer Magasin des requêtes pour les réplicas secondaires.

SELECT query_plan
FROM sys.query_store_plan AS qsp
INNER JOIN sys.query_store_plan_forcing_locations AS pfl
    ON pfl.query_id = qsp.query_id
INNER JOIN sys.query_store_replicas AS qsr
    ON qsr.replica_group_id = qsp.replica_group_id
WHERE qsr.replica_name = 'yourSecondaryReplicaName';

Contenu connexe