Início / dba / Perguntas / 232449
Accepted
Marc S
Asked: 2019-03-19 08:48:55 +0800 CST

Plano parametrizado liberado

  • 772

Não consigo encontrar documentação em nenhum lugar sobre o que acionaria esse motivo de recompilação. Estamos investigando uma queda repentina no desempenho da consulta e a única coisa em que consigo pensar é que o plano foi recompilado para a consulta parametrizada quando executado em um pequeno conjunto de dados que resultou em mexer nas estimativas de linha. Percebemos que quando esse processo estava em execução (depois de começar a levar horas em vez de segundos), ele estava atingindo o tempdb com bastante força. As estatísticas nas tabelas consumidas não foram alteradas e o único outro motivo que faz sentido na lista de motivos de recompilação é o nº 12 "Plano parametrizado liberado".

O processo em questão estava chamando uma visão e filtrando em uma única coluna INT. Isso foi feito através do Entity Framework. Há apenas 1 Entity Key na classe e é o PK da tabela principal na exibição. Todos os registros são únicos.

Estou curioso para saber se alguém pode me indicar alguma documentação que explique por que um plano pode ser recompilado devido a "plano parametrizado liberado" .

sql-server-2016 plan-cache

1 respostas

  1. Best Answer

    Os Planos de Consulta são liberados do cache por vários motivos, incluindo o envelhecimento, sendo liberados devido à pressão da memória, liberados devido à ação do usuário (DBCC FREEPROCCACHE etc), liberados devido à reinicialização e liberados devido à recompilação explícita (OPTION (RECOMPILE ou sp_recompile) ).

    Se você não puder ver evidências de recompilação forçada ou liberação manual, é provável que o plano tenha expirado ou tenha sido liberado devido à pressão da memória. Dos Documentos: Planejar Cache Internals :

    A remoção de planos do cache é baseada em seu custo. Para planos ad hoc, o custo é considerado zero, mas é aumentado em um toda vez que o plano é reutilizado. Para outros tipos de planos, o custo é uma medida dos recursos necessários para produzir o plano. Quando um desses planos é reutilizado, o custo é redefinido para o custo original. Para consultas não-adhoc, o custo é medido em unidades chamadas ticks, com um máximo de 31. O custo é baseado em três fatores: E/S, trocas de contexto e memória. Cada um tem seu próprio máximo dentro do total de 31 ticks.

    • E/S: cada E/S custa 1 tick, com um máximo de 19.
    • Interruptores de contexto: 1 marca cada com um máximo de 8.
    • Memória: 1 tick por 16 páginas, com um máximo de 4.

    Quando não há pressão de memória, os custos não diminuem até que o tamanho total de todos os planos armazenados em cache atinja 50% do tamanho do buffer pool. Nesse ponto, o próximo acesso ao plano diminuirá o custo em tiques de todos os planos em 1. Quando a pressão de memória for encontrada, o SQL Server iniciará um thread de monitor de recursos dedicado para diminuir o custo de qualquer um dos objetos do plano em um cache específico (por exemplo, pressão local) ou todos os objetos de cache do plano (para pressão global).

    Dê uma olhada nesta resposta do StackExchange , que fornece muitos links excelentes e informações sobre reutilização de planos e armazenamento em cache. Você terá que implementar o monitoramento para detectar a causa exata se isso ocorrer novamente, mas você também deve aproveitar o Query Store, que permitirá forçar um bom plano conhecido para essa consulta e rastrear regressões em seu banco de dados, pois isso pode ser afetando outras consultas também.

    • 4

relate perguntas