Início / dba / Perguntas / 212378
Accepted
user9516827
Asked: 2018-07-17 13:23:12 +0800 CST

Plano serial no cache do plano

  • 772

Eu tenho uma consulta que estava executando lentamente anteriormente. Mais tarde descobri que não estava rodando em paralelo e isso está tornando a execução da consulta lenta.

A consulta envolve um grande viewe, em seguida, consulta a exibição com muitos temp tablese sub query.

Eu removi um UDFda view e usei inline functionse também usei um escalar TVFe então ele começou a rodar rápido no parallel execution.

Estava indo bem por alguns dias e um belo dia notei que a consulta rodava lentamente. Então verifiquei o plano de execução e descobri que a consulta está sendo executada no modo serial. Verifiquei o cache do plano para a consulta e vi muitos planos em cache envolvendo essa visualização. Excluí planos que não são paralelos e a consulta é executada rapidamente.

Agora eu faço isso todas as manhãs para forçar a consulta a ser executada em paralelo.

Detalhes adicionais:

  1. SQL Server 2016 Padrão
  2. A consulta é gerada via LINQ-SQL do aplicativo dot net. Portanto, consulta ad hoc.

Como posso forçar a consulta a ser executada em paralelo para sempre?

sql-server performance

3 respostas

  1. Best Answer

    À primeira vista, isso soa como um problema clássico de sniffing de parâmetros .

    O SQL Server cria um plano de execução para o primeiro conjunto de parâmetros que é chamado quando o plano precisa ser compilado e, em seguida, reutiliza esse plano várias vezes ao longo do dia. Você pode ver quais são os parâmetros - quando estiver visualizando o plano serial, clique com o botão direito do mouse na instrução select e vá para propriedades. Na janela de propriedades, procure Parâmetros e, em seguida, Valores Compilados. Isso mostrará quais valores produzem o plano serial.

    Para forçar o plano a sempre ser executado em paralelo, você tem várias opções diferentes (muitas das quais Erland aborda em seu excelente post que vinculei acima), incluindo:

    • Ajuste os índices para que tudo fique em um plano melhor (para obter conselhos sobre isso, poste os detalhes do plano e do servidor conforme descrito em Obtendo ajuda com uma consulta lenta )
    • Temporariamente, use um guia de plano para fixar o plano paralelo no cache (mas saiba que, se a consulta for alterada por uma única letra, o guia de plano falhará silenciosamente, pois não corresponderá mais à consulta)
    • Use uma dica OPTIMIZE FOR no plano para orientá-lo em direção a valores que produzem um plano paralelo
    • Use a nova dica ENABLE_PARALLEL_PLAN_PREFERENCE no SQL Server 2016

    Essa é apenas uma resposta rápida - mas para muito, muito mais, leia a excelente postagem de Erland, Slow in the App, Fast in SSMS, que explica como uma consulta pode obter planos diferentes e como corrigi-la.

    • 9

  2. Pode ser difícil fornecer uma resposta precisa para seu problema, pois não sabemos como são suas consultas, mas você pode forçar um plano específico usando o recurso QueryStore que foi introduzido no SQL 2016. Se você estiver usando uma versão anterior do SQL Server ou não sente que o armazenamento de consultas é uma solução para você - você pode tentar coisas como:

    • forçando a recompilação cada vez que é executado (um dos métodos está adicionando OPTION(RECOMPILE) à instrução que causa o problema)
    • revisar possíveis inibidores de planos paralelos em outras consultas

    Você também deve revisar postagens anteriores no StackExchange sobre este tópico, por exemplo, SQL não envolve paralelismo para consulta extremamente grande

    • 3

  3. Se o custo da consulta exceder o Cost Threshold of Parallelismvalor e cost of the parallel planfor menor que cost of a serial plan, um plano paralelo será criado e usado.

    Em alguns casos, o QO escolhe o plano serial do que o plano paralelo porque parallel plané mais caro do que serial plannesse caso. Por exemplo, se a consulta contém operadores escalares ou relacionais que não podem ser executados em modo paralelo.

    Em alguns casos, o QO toma decisões erradas devido a informações imprecisas, estatísticas desatualizadas, cardinality estimateetc. Devido ao qual o custo do plano serial é ligeiramente superior a parallel plan.

    então QO ainda escolhe o plano serial.

    Para superar esse problema, a consulta pode ser otimizada e as estatísticas também devem ser atualizadas.

    Isso ajuda QO na tomada de decisão correta.

    Eu removi um UDF da visualização e usei funções em linha e também usei um TVF escalar

    Essas são etapas bem-vindas, assim que você melhorar sua consulta, alguns dos planos foram paralelos e o desempenho da consulta melhorou.

    Portanto, pode haver mais escopo para melhorar sua consulta.

    Deve-se prestar mais atenção na otimização do índice de consulta e ajuste do que tentar imediatamenteHint

    O resto das coisas como usar HINT, sniffing de parâmetro, OPTION (RECOMPILE) já são discutidas.

    • 1

relate perguntas