Início / dba / Perguntas / 307363
Accepted
adam.g
Asked: 2022-02-12 08:22:13 +0800 CST

Comportamento estranho do plano de força no armazenamento de consultas

  • 772

Eu forço o plano no armazenamento de consultas. O plano está conectado ao procedimento em um trabalho que é executado uma vez por dia. Uma das etapas deste trabalho é apenas:

EXEC [schema].[LoadData]

O procedimento [esquema].[LoadData] se parece com

TRUNCATE TABLE [schema].[Data];
     
    INSERT INTO [schema].[Data]
           ([A1],
           [A2],
          .
          .
          .,
          [A49]
    )                
    SELECT *
        ,CURRENT_TIMESTAMP AS [Insert TimeStamp] 
    FROM [schema].[View]

onde view é uma view que contém alguns CTEs e usa sinônimos (conectar a tabelas de diferentes bancos de dados).

Na execução do armazenamento de consultas se parece com: insira a descrição da imagem aqui

Para testar se o plano de forçar está funcionando, sigo as etapas abaixo:

  1. Executar consulta no SSMS ->EXEC [schema].[LoadData]
  2. A execução acima foi tratada como uma consulta diferente, portanto, não viu nada de novo no Query Store para a consulta = 7
  3. O DBA cria um novo trabalho apenas com a etapa que está executando a consulta ->EXEC [schema].[LoadData]
  4. Execução do trabalho recém-criado acima causa ID do plano = 29800

Pergunta por que o plano de execução não foi forçado? Na coluna "contagem de falhas de plano forçado" é 0.

sql-server query-store

1 respostas

  1. Best Answer

    As chances são de que o ID do plano 29800 seja realmente forçado, mas o armazenamento de consultas torna isso difícil de ver.

    O forçamento de plano não garante que novos planos sejam idênticos ao original, conforme documentado em sp_query_store_force_plan(grifo nosso):

    O plano de execução resultante forçado por esse recurso será o mesmo ou semelhante ao plano que está sendo forçado. Como o plano resultante pode não ser idêntico ao plano especificado por sp_query_store_force_plan, o desempenho dos planos pode variar.

    Se o plano gerado não for idêntico , você verá um novo ID de plano. Isso não significa necessariamente que o forçamento do plano falhou. Quando o plano forçado falha, o evento estendido query_store_plan_forcing_failedé acionado.

    Você pode verificar se o plano forçado foi bem-sucedido examinando o xml do plano com o ID 29800 para o atributo UsePlan="1"no QueryPlanelemento. Também aparece como uma propriedade na raiz do plano gráfico. O ID do plano 29800 também aparecerá no relatório 'consultas com planos forçados'.

    Você pode ler a explicação de Erland Sommarskog em seu artigo Slow in the Application, Fast in SSMS?

    Kendra Little também aborda bem essa questão em O que é um "plano de execução moralmente equivalente" e por que é bom?

    Como um aparte, o motivo pelo qual o SSMS gerou um ID de consulta diferente é quase certamente porque você não tem SET QUOTED_IDENTIFIER ONem sua etapa de trabalho ou tem seu SSMS configurado para SET ARITHABORT ON(como é o padrão inútil).

    • 7

relate perguntas