É OPTION (RECOMPILE)
usado na produção?
Esta opção parece ter um monte de má imprensa. É merecido?
Tenho um DBA que, até o momento, não é fã da ideia de OPTION (RECOMPILE)
dentro da carne do Report ETL ssis agent querys. Essas consultas são executadas (até onde eu sei) sequencialmente e em intervalos programados.
Histórico de volta:
- SQL Server 2016
- Consultas ETL que causam varreduras de índice clusterizado quando executadas por meio do agente ssis. Essas consultas levam minutos para serem concluídas e causam grande impacto.
- A mesma consulta e parâmetro executados por meio de procedimentos armazenados locais são executados em menos de um segundo.
Espere você tem certeza que OPÇÃO (RECOMPILAR) é a resposta?
- Desconhecido.
- Mas eu preciso saber se isso é realmente uma má ideia antes de tentar.
Os riscos que conheço:
- Houve pelo menos dois bugs sérios no passado relacionados a OPTION (RECOMPILE). Duas consultas executadas ao mesmo tempo podem trocar conjuntos de resultados. Eca !! https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-or-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241
Então, dado o acima - esta opção é realmente usada no mundo real? É aceitável que eu recomende (e teste) isso como uma opção para um ambiente de produção?
Pediram-me para fornecer mais detalhes. Eu mencionei que eu tenho outros posts todos relacionados a este tópico. Deixe-me dar mais informações sobre isso:
- O problema principal é que as consultas provenientes de um servidor de aplicativos estão demorando mais de 60 segundos. Normalmente, essas consultas levam de 4 a 10 segundos. Com muita dor, determinei que os tempos limite se alinham com as consultas ETL. 4 consultas de 15 para ser específico.
- Um contribuinte para o problema é encontrado nos servidores de aplicativos. Especificamente, o nível de isolamento é definido
serializable
dentro da camada de hibernação; que aprendi não é ideal para ambientes de produção de alto volume.
Deixe-me compartilhar as outras perguntas:
OPTION(RECOMPILE)
é usado em cenários reais de produção de palavras. Eu o empreguei para abordar o sniffing de parâmetros e otimizar as consultas da pia da cozinha. Pode ser a resposta para o seu problema, mas os sintomas sugeremOPTIMIZE FOR UNKNOWN
(o mesmo que as variáveis locais) também podem resolver o problema.Eu certamente não evitaria uma opção apenas porque um bug já existiu e foi corrigido há vários anos. O principal risco
OPTION(RECOMPILE)
é quando é usado de forma inadequada, como consultas de alta frequência.Sim. OPTION RECOMPILE é apropriado para consultas de alto custo/baixa frequência em que o custo da consulta varia significativamente por valores de parâmetro. Como alternativa, considere usar o Query Store , onde você pode forçar um bom plano.
Como os especialistas mencionaram, certamente existem casos de uso válidos para a
OPTION (RECOMPILE)
dica de consulta no código de produção. Geralmente, não é a única ou a melhor solução e pode piorar seus problemas de desempenho quando usado incorretamente, especialmente em consultas de alta frequência.Dito isto, por outro lado, às vezes , há situações em que não há outra correção além de uma dica de consulta
OPTION (RECOMPILE)
e é a solução para um problema de desempenho. Não podemos dizer se sua consulta SSIS é um exemplo disso sem muito mais detalhes, mas apenas um pensamento geral que eu queria lançar para o seu DBA, porque assim como os Siths, é ruim lidar com absolutos. ?Se você tivesse um caso em que a única solução fosse
OPTION (RECOMPILE)
, ficaria curioso sobre qual seria a resposta do seu DBA sobre como resolver o problema. Além disso, você deve perguntar ao seu DBA o que ele pensa para resolver esse problema sem testarOPTION (RECOMPILE)
. Porque geralmente é um teste de baixo risco e pode ser facilmente removido se prejudicar o desempenho mais do que ajudar. Eu até achei útil em um vínculo de desempenho quando não há tempo para resolver o problema raiz, então ele comprou espaço para respirar nesse ínterim.Para encurtar a história, as dicas de consulta têm a notoriedade de serem arriscadas porque há um histórico de pessoas que as usam incorretamente. Mas eles existem por uma razão, quando são a ferramenta certa para o trabalho certo. O risco de uso
OPTION (RECOMPILE)
é baixo quando monitorado de perto e é até a única solução em alguns contextos.Se eu puder recomendar uma solução alternativa com base em um comentário de JD:
Publique a consulta neste site junto com o plano de execução e pergunte se algum de nós vê algum problema óbvio com a consulta. Supondo que sua consulta não contenha dados confidenciais, obviamente. Mesmo que OPTION(RECOMPILE) ajude significativamente a execução da consulta, é possível que haja outros efeitos de executar isso por meio de um procedimento armazenado que você pode não obter por meio da opção Recompilar.
Eu vi o uso de OPTION(RECOMPILE) em produção bastante.
Parece que o mecanismo de cache do plano de consulta não é muito inteligente, mas finge ser inteligente, então gosta de substituir a compreensão do desenvolvedor sobre a reutilização do plano em diferentes contextos.
Uma grande, grande recompilação de consulta pode levar de 20 a 50 ms e um plano ruim do cache pode converter uma consulta de menos de 100 ms em um consumo de CPU de minutos. A este respeito, OPTION(RECOMPILE) parece um bom negócio.