Resumo Executivo: Automatic Plan Correction (APC) é um recurso de Automatic Tuning do SQL Server que identifica regressões de plano de execução e, quando possível, força automaticamente um plano anterior “last good plan”. Baseado no Query Store, o Automatic Plan Correction compara métricas (com foco em tempo de CPU) entre o plano atual e planos históricos para reduzir impacto de mudanças de plano em workloads críticas. No SQL Server 2022 CU4, melhorias estatísticas (incluindo TF 12618 e TF 12656) aumentam a confiabilidade das decisões, tornando o Automatic Plan Correction mais eficaz em ambientes com alta variância e consultas longas. Para líderes e gestores, o valor está em reduzir incidentes de performance, acelerar diagnóstico e manter estabilidade sem depender apenas de intervenção manual — desde que o recurso seja habilitado com governança, monitorado e aplicado com critério.
Pontos-chave
- O que é: Automatic Plan Correction detecta regressão de plano e pode forçar um plano anterior melhor, reduzindo impacto em produção.
- Dependência: O Automatic Plan Correction depende do Query Store para histórico de planos, métricas e comparação de comportamento.
- Métrica central: A comparação tende a usar tempo de CPU como indicador principal para decidir se houve regressão.
- SQL Server 2022 CU4: TF 12618 habilita modelo mais moderno de detecção; TF 12656 adiciona rechecagem com atraso para consultas longas.
- Azure vs On-prem: Em serviços Azure SQL, o modelo moderno já é padrão; no SQL Server 2022 CU4 ele pode exigir habilitação.
- Monitoramento: Use sys.dm_db_tuning_recommendations, Query Store e Extended Events para validar recomendações e evitar “liga e esquece”.
- Cuidados: Nem toda consulta é candidata; temp tables e workloads sensíveis podem sofrer com variações e efeitos colaterais.
Automatic Plan Correction (APC) e Automatic Tuning: por que isso importa
O Automatic Plan Correction, ou APC, faz parte da família de recursos do Automatic Tuning do SQL Server.
Seu objetivo é identificar regressões de plano de execução e, quando possível, forçar automaticamente um plano anterior considerado melhor.
Para organizações que operam sistemas críticos, isso reduz o risco de “quedas silenciosas” de performance após mudanças de plano.
Em termos B2B, Automatic Plan Correction é um mecanismo de estabilidade: menos incidentes, menos urgência e mais previsibilidade.
Esse recurso depende do Query Store, pois é nele que o SQL Server armazena o histórico de execução das consultas, seus planos, métricas de desempenho e informações necessárias para comparar o comportamento de um plano atual com planos anteriores.
Sem Query Store consistente, o Automatic Plan Correction perde contexto e a decisão se torna menos confiável.
Por isso, antes de “ativar automação”, é essencial garantir visibilidade: histórico, métricas e retenção adequadas.
Uma boa governança do Query Store costuma ser o primeiro passo para colher valor do Automatic Plan Correction.
No SQL Server, o APC está disponível a partir do SQL Server 2017 Enterprise Edition.
Isso é relevante para planejamento de plataforma: o ganho de estabilidade pode ser parte do business case de atualização.
Quanto mais volátil é seu workload, mais valor há em reduzir regressões de plano de forma estruturada.
Nesse cenário, Automatic Plan Correction atua como “cinto de segurança” para performance em produção.
Melhorias no SQL Server 2022 CU4 e trace flags associadas
A partir do SQL Server 2022 CU4, foram introduzidas melhorias importantes no modelo estatístico usado para detectar regressões de plano, incluindo novas trace flags relacionadas ao processo de decisão do Automatic Plan Correction.
A documentação do SQL Server 2022 CU4 informa que a TF 12618 adiciona um novo modelo de detecção de regressão de plano.
Além disso, a TF 12656 adiciona uma verificação baseada em tempo, executada cinco minutos após a descoberta de uma alteração de plano.
Na prática, isso tende a tornar o Automatic Plan Correction mais robusto em cenários reais, com variação de carga e consultas longas.
Como o APC detecta regressões
A principal métrica usada pelo APC para comparar planos é o tempo de CPU.
O SQL Server compara o comportamento do plano atual com o plano anterior para decidir se houve regressão de desempenho.
O ponto-chave é que “regressão” não é opinião: é comparação de comportamento sustentado em métricas observáveis.
Automatic Plan Correction, quando bem parametrizado, reduz o tempo entre detectar regressão e aplicar mitigação.
Existem dois modelos principais de detecção, e entender a diferença ajuda a definir expectativas e governança.
Em ambientes com alta variância, o modelo estatístico escolhido pode mudar a rapidez e a confiabilidade da conclusão.
Por isso, a evolução dos modelos no SQL Server 2022 CU4 é um tema importante para ambientes críticos.
Automatic Plan Correction não é “mágica”: é estatística aplicada em dados de execução históricos.
Modelo original: Sigma
O modelo original é baseado em uma análise estatística conhecida como modelo Sigma.
Nesse modelo, o SQL Server calcula a diferença de tempo de CPU entre o plano atual e o plano anterior e verifica se essa diferença ultrapassa um limite estatístico, normalmente baseado em 3 desvios padrão.
Ele funciona e pode capturar regressões claras, mas pode exigir mais evidência para ter confiança na decisão.
Em workloads de alta variância, Automatic Plan Correction com Sigma pode demorar mais para agir.
Apesar de funcional, esse modelo possui algumas limitações importantes.
Cargas de trabalho com alta variância podem mascarar regressões reais e reduzir a sensibilidade do modelo.
Além disso, o modelo assume uma variância mais uniforme entre as amostras, o que nem sempre reflete produção.
Isso gera um risco prático: regressões podem demorar mais para serem detectadas e corrigidas pelo Automatic Plan Correction.
Normalmente são necessárias mais execuções antes que o SQL Server tenha confiança suficiente para tomar uma decisão.
Isso pode ser um problema em OLTP crítico, em que alguns minutos de degradação já impactam atendimento e faturamento.
Em ambientes com consultas instáveis, variação natural de carga ou planos com comportamento muito diferente entre execuções, esse modelo pode ser menos preciso.
Por isso, a evolução para modelos mais adequados tende a melhorar a previsibilidade do Automatic Plan Correction.
Modelo mais recente: teste t de Welch
O modelo mais recente utiliza o teste t de Welch, que é mais adequado para comparar amostras com variâncias diferentes e tamanhos desiguais.
Esse modelo melhora a capacidade do SQL Server de detectar regressões em cenários mais realistas, especialmente quando a carga de trabalho apresenta alta variação de tempo de execução.
Em termos de governança, isso reduz o “tempo de dúvida” e antecipa ações quando há sinais suficientes.
Na prática, o Automatic Plan Correction tende a ser mais confiável quando o workload não é “estável por natureza”.
Entre os principais ganhos estão: maior precisão em workloads com alta variância e início da análise com menos execuções.
Também há capacidade de detectar regressões mais cedo e aumento progressivo da amostragem quando o resultado ainda é incerto.
Outro ponto relevante é a reavaliação contínua mesmo após uma ação de correção ser aplicada.
Isso reforça a ideia de que Automatic Plan Correction é um ciclo: detectar, corrigir, validar e reavaliar.
| Critério | Sigma (modelo original) | Teste t de Welch (modelo recente) |
|---|---|---|
| Adequação à variância | Pode sofrer quando a variância é alta | Mais adequado para variâncias diferentes |
| Velocidade de decisão | Pode exigir mais execuções | Pode iniciar análise com menos execuções |
| Risco de atraso em regressões | Maior em workloads instáveis | Menor, com detecção mais cedo |
| Operação do APC | Pode ser menos preciso em cenários variáveis | Tende a melhorar confiabilidade do Automatic Plan Correction |
Na prática, isso torna o APC mais confiável, principalmente em ambientes onde o comportamento das consultas varia bastante ao longo do tempo.
O modelo baseado no teste t de Welch já é o padrão em serviços como Azure SQL Database, Azure SQL Database in Microsoft Fabric e Azure SQL Managed Instance.
Também é o comportamento padrão no SQL Server 2025, enquanto no SQL Server 2022 Enterprise (CU4+) pode exigir habilitação.
O endereço oficial para referência geral de SQL Server e recursos de performance pode ser consultado aqui: Microsoft Learn (SQL Server).
No SQL Server 2022 Enterprise Edition, a partir do CU4, esse modelo precisa ser habilitado com a trace flag 12618; caso contrário, o SQL Server continua utilizando o modelo original baseado em Sigma.
Isso é um ponto de governança: habilitar TF globalmente é decisão de plataforma e deve ser tratada como mudança controlada.
Se a sua empresa depende de estabilidade e tem alta variância, vale avaliar com cuidado o impacto positivo desse modelo.
Em cenários críticos, Automatic Plan Correction deve evoluir com testes, validação e observabilidade.
Exemplo para habilitar globalmente: DBCC TRACEON (12618, -1);
Ou como parâmetro de inicialização do SQL Server: -T12618
Esses comandos devem ser tratados como parte de um processo de mudança, com janela, rollback e documentação.
Uma mudança de comportamento de detecção influencia diretamente como o Automatic Plan Correction toma decisões em produção.
Atenção com consultas de longa duração
Um ponto importante é que consultas de longa duração podem causar interpretações incorretas pelo APC.
Em alguns casos, o SQL Server pode tomar uma decisão com base apenas nas execuções que terminaram mais rápido, enquanto execuções mais lentas ou que ainda estavam em andamento não entram imediatamente na análise.
Isso pode fazer com que a avaliação da regressão fique enviesada, especialmente quando a carga tem picos e vales ao longo do tempo.
Ou seja: Automatic Plan Correction pode “ver” apenas parte do filme e reagir cedo demais em cenários muito assimétricos.
Para reduzir esse problema, foi introduzida a trace flag 12656, disponível a partir do SQL Server 2022 CU4.
Essa trace flag habilita uma verificação adicional baseada em tempo, chamada de time-based delayed recheck.
Com ela, o SQL Server agenda uma nova avaliação aproximadamente cinco minutos após detectar uma alteração de plano, permitindo que execuções mais longas também sejam consideradas na análise.
Na prática, isso melhora a “justiça” da comparação e tende a elevar a qualidade das decisões do Automatic Plan Correction.
Exemplo: DBCC TRACEON (12656, -1);
Ou como parâmetro de inicialização: -T12656.
De novo, é importante tratar isso como mudança de plataforma, com observabilidade antes e depois.
Para workloads com consultas longas, essa atenção pode ser o divisor de águas para evitar correções precipitadas.
Comportamento no Azure
Nos serviços gerenciados como Azure SQL Database, Azure SQL Database in Microsoft Fabric e Azure SQL Managed Instance, o modelo mais recente de detecção já é usado por padrão.
Porém, a verificação estendida equivalente à TF 12656 não fica necessariamente habilitada automaticamente para todas as consultas.
Para cenários específicos, pode-se utilizar a stored procedure: sys.sp_configure_automatic_tuning.
O ponto aqui é governança: habilitar comportamento “extra” deve ser direcionado por risco e criticidade, não por impulso.
A partir do SQL Server 2022 CU4, essa procedure permite configurar opções mais granulares do Automatic Tuning.
Um dos parâmetros importantes é: FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK.
Esse parâmetro pode ser usado para indicar consultas que devem passar por uma verificação adicional antes ou depois da aplicação da correção automática.
Na prática, isso ajuda principalmente em cenários com consultas mais longas ou com maior variação de execução, onde Automatic Plan Correction pode precisar de mais “evidência” antes de forçar um plano.
Monitoramento das recomendações
Para acompanhar o que o SQL Server está recomendando ou aplicando, podemos consultar a DMV: sys.dm_db_tuning_recommendations.
Essa DMV permite avaliar recomendações de tuning geradas automaticamente, incluindo ações relacionadas ao force last good plan.
Ela pode mostrar informações como consulta afetada, plano anterior, plano atual, motivo da recomendação e estado da recomendação.
Em ambientes críticos, esse monitoramento é a diferença entre governança e “caixa-preta” do Automatic Plan Correction.
Além disso, para uma análise mais aprofundada, também é possível utilizar Extended Events relacionados ao Automatic Tuning e ao Query Store.
Eles ajudam a entender melhor quando uma recomendação foi gerada, quando uma ação foi aplicada e como o mecanismo de correção automática se comportou ao longo do tempo.
Isso é especialmente útil para auditoria interna e para explicar eventos de performance com rastreabilidade.
Se o objetivo é maturidade operacional, Automatic Plan Correction deve estar amarrado a observabilidade e pós-mortem de incidentes.
Cuidados
A Execution Plan Correction é um recurso poderoso do SQL Server para mitigar regressões de plano de execução, mas nem toda consulta é uma boa candidata para esse tipo de automação.
Em workloads OLTP críticos, algumas consultas não podem passar por ciclos repetidos de experimentação até que o SQL Server encontre o melhor plano.
Esse processo pode gerar variações de desempenho, especialmente após atualizações de estatísticas, mudanças de código ou recompilações.
Por isso, Automatic Plan Correction deve ser aplicado com uma visão de criticidade: o que pode variar e o que não pode.
Outro ponto importante são consultas que utilizam tabelas temporárias.
Ao forçar planos nesses cenários, o recurso pode impedir recompilações naturais baseadas nas estatísticas das temporary tables, criando uma espécie de “temp table sniffing”.
O risco aqui é resolver regressões e, ao mesmo tempo, introduzir outro padrão de instabilidade em consultas específicas.
Em resumo: no Automatic Plan Correction, “forçar” é poderoso, mas precisa ser guiado por critérios claros e monitoramento.
Resumo
O Automatic Plan Correction é um recurso poderoso para reduzir impactos causados por regressões de plano de execução.
Ele utiliza dados do Query Store para comparar planos e decidir quando deve forçar um plano anteriormente considerado melhor.
O modelo original, baseado em Sigma, funciona, mas pode ter limitações em ambientes com alta variância.
O modelo mais recente, baseado no teste t de Welch, melhora a precisão e permite decisões mais rápidas e confiáveis, elevando a qualidade do Automatic Plan Correction.
Para SQL Server 2022 Enterprise Edition a partir do CU4, é recomendável avaliar o uso das trace flags 12618 e 12656, principalmente em ambientes críticos.
Já nos serviços Azure SQL e no SQL Server 2025, o modelo mais moderno já está habilitado por padrão.
Mesmo assim, o APC não deve ser tratado como uma solução “liga e esquece”.
Ele deve ser monitorado com a DMV sys.dm_db_tuning_recommendations, Query Store e Extended Events, especialmente em workloads com consultas longas e alta sensibilidade a mudanças de plano.
Perguntas Frequentes
Automatic Plan Correction funciona sem Query Store?
Não. O Automatic Plan Correction depende do Query Store para ter histórico de planos e métricas, que sustentam a comparação entre plano atual e planos anteriores.
Sem esse histórico, o recurso perde contexto e a automação deixa de ser confiável para ambientes críticos.
Qual métrica o APC usa para avaliar regressão?
A métrica central destacada é o tempo de CPU, comparando o comportamento do plano atual com o plano anterior.
Por isso, em governança de performance, é importante entender variação de CPU e de carga antes de interpretar ações do Automatic Plan Correction.
Quando vale habilitar TF 12618 no SQL Server 2022 CU4?
Quando seu ambiente tem alta variância, consultas instáveis e necessidade de detectar regressões mais cedo, o modelo mais recente pode trazer ganhos.
Como é ajuste de plataforma, o recomendável é habilitar com mudança controlada, baseline e monitoramento do Automatic Plan Correction.
Por que TF 12656 é relevante para consultas longas?
Consultas longas podem enviesar a análise se apenas execuções rápidas entrarem no cálculo no momento inicial da detecção.
A TF 12656 adiciona uma rechecagem atrasada para considerar execuções mais longas, elevando a qualidade das decisões do Automatic Plan Correction.
Quais riscos existem ao forçar planos automaticamente?
Workloads OLTP sensíveis podem sofrer variações durante ciclos de experimentação, e consultas com temp tables podem ter efeitos colaterais como “temp table sniffing”.
Por isso, o Automatic Plan Correction deve ser monitorado e aplicado com critério, não como automação irrestrita.
Sua operação não pode parar. Proteja seu negócio hoje.
Se sua empresa sofre com regressões de plano, picos de CPU e instabilidade após atualizações de estatísticas ou mudanças de código, o Automatic Plan Correction pode reduzir o impacto em produção. A Tripletech ajuda a avaliar elegibilidade de consultas, habilitar melhorias do SQL Server, criar rotinas de monitoramento e estruturar um processo seguro de tuning para ambientes críticos. Fale com um especialista e avance com estabilidade e previsibilidade.
