A decisão foi tomada com as melhores intenções. A equipe de infraestrutura, seguindo as melhores práticas da Microsoft e buscando mais segurança e performance, finalmente atualizou o Nível de Compatibilidade (Compatibility Level) de um banco de dados crítico do SQL Server 2012 (110) para uma versão mais moderna, como SQL Server 2019 (150). Não foi uma instalação de software, não houve downtime, apenas a execução de um único comando: ALTER DATABASE. Nos primeiros momentos, tudo parecia normal. Nenhum alarme soou. Mas, nas horas e dias seguintes, uma praga silenciosa começou a se espalhar.
Queries que rodavam em segundos agora levam minutos. Processos de ETL que nunca falharam começam a estourar o tempo limite. A CPU do servidor, antes estável, agora exibe picos erráticos e inexplicáveis. A equipe de desenvolvimento jura que nenhum código novo foi implantado. A equipe de infraestrutura insiste que nenhum hardware foi alterado. No entanto, o ambiente de produção está se arrastando e ninguém consegue entender o porquê.
O que aconteceu? Sua equipe acaba de se tornar a mais nova vítima de uma das mudanças mais significativas e incompreendidas da história do SQL Server: a troca do Estimador de Cardinalidade (Cardinality Estimator). Esta não é uma atualização de software; é um transplante de cérebro no motor do seu banco de dados, e ele pode estar rejeitando suas queries mais importantes.
O Diagnóstico: Entendendo o Cérebro do SQL Server
Para entender a gravidade do problema, você precisa entender o que é o Estimador de Cardinalidade (CE). Em termos simples, o CE é o cérebro do Otimizador de Consultas do SQL Server. Antes de executar qualquer query, o CE faz uma previsão, uma “estimativa”, de quantas linhas serão retornadas em cada etapa da operação. Com base nessa estimativa, o Otimizador de Consultas toma decisões cruciais sobre como executar a query:
- Deve usar um Nested Loop, um Hash Join ou um Merge Join?
- Deve fazer um Index Seek (preciso e rápido) ou um Table Scan (força bruta)?
- Quanta memória deve alocar para operações de ordenação?
A precisão dessa estimativa é a diferença entre uma query que roda em milissegundos e uma que derruba o servidor.
A Cirurgia de Risco: O “Legacy CE” vs. O “Modern CE”
Até o SQL Server 2012 (nível de compatibilidade 110 e inferior), todas as versões usavam o que hoje é conhecido como “Legacy CE”. Era um cérebro testado e aprovado, com peculiaridades e suposições que os DBAs e desenvolvedores aprenderam a contornar e otimizar por mais de uma década.
A partir do SQL Server 2014 (nível de compatibilidade 120 e superior), a Microsoft introduziu um “Modern CE” completamente reescrito. O objetivo era nobre: usar algoritmos mais sofisticados para lidar melhor com as complexidades dos dados modernos, como correlações entre múltiplas colunas e dados com distribuições distorcidas.
O problema é que este novo cérebro, embora muitas vezes mais inteligente, pensa de forma fundamentalmente diferente. Ele faz suposições diferentes sobre seus dados. Para uma query que foi perfeitamente otimizada para o cérebro antigo, o novo cérebro pode interpretá la de forma completamente errada, fazendo estimativas terrivelmente imprecisas e escolhendo um plano de execução desastroso.
É por isso que o problema é tão misterioso: o seu código T-SQL não mudou. Seus dados não mudaram. Seus índices não mudaram. Mas ao alterar o nível de compatibilidade, você trocou o cérebro que interpreta tudo isso, e o resultado é uma regressão de performance massiva e silenciosa.
A Caça às Bruxas: Tentando Corrigir o Incorrigível Manualmente
Quando uma equipe finalmente diagnostica que o CE é o culpado, uma corrida desesperada por soluções começa. As abordagens manuais são como tentar fazer microcirurgia com ferramentas de jardinagem:
- Forçar o “Legacy CE”: A solução mais comum é ativar a configuração LEGACY_CARDINALITY_ESTIMATION = ON para todo o banco de dados. Isso funciona, mas é uma admissão de derrota. Você desliga o novo cérebro para todos, perdendo todos os benefícios que ele poderia trazer para outras queries.
- Dicas de Consulta (Query Hints): Os desenvolvedores podem começar a injetar dicas de consulta como QUERYTRACEON 9481 ou USE HINT(‘FORCE_LEGACY_CARDINALITY_ESTIMATION’) no final de cada query problemática. Isso rapidamente se torna um pesadelo de manutenção, poluindo o código e tornando o impossível de gerenciar em larga escala.
- Forçar Planos no Query Store: Uma abordagem mais moderna é usar o Query Store para encontrar o “último plano bom” (gerado pelo Legacy CE) e forçá lo para a query. Isso é eficaz, mas altamente reativo. Você precisa que a query problemática rode, cause um incêndio, para então encontrar e forçar o plano antigo. É um trabalho manual constante para cada regressão que aparece.
Essas são todas soluções reativas. Elas não previnem o problema, apenas o remediam após o dano já ter sido causado.
A Cura Definitiva: A Observabilidade Preditiva da dbsnOOp
A única maneira de realizar uma atualização do Estimador de Cardinalidade com segurança é ter uma visibilidade completa do impacto antes, durante e depois da mudança. É preciso uma plataforma que não apenas veja os sintomas, mas que entenda a causa neurológica por trás deles.
O “Eletrocardiograma” das Suas Queries
A dbsnOOp age como uma ferramenta de diagnóstico avançado para o seu banco de dados. Antes mesmo de você pensar em mudar o nível de compatibilidade, a plataforma já estabeleceu uma linha de base (baseline) detalhada da performance de cada uma das suas consultas críticas: seu plano de execução, seu consumo de CPU, sua duração e seu comportamento de I/O.
Detecção de Regressão em Tempo Real
No momento em que a mudança do nível de compatibilidade é ativada, o motor de IA da dbsnOOp começa a comparar o comportamento de cada nova execução de query com sua linha de base histórica. Quando uma query que antes rodava em 100ms de repente leva 10 segundos, a dbsnOOp não dispara um alarme genérico. Ela gera um insight preciso:
Alerta de Regressão de Performance: A query [hash_da_query] sofreu uma regressão de 9.900% após a mudança do Nível de Compatibilidade.
- Causa Provável: Mudança no Estimador de Cardinalidade.
- Diagnóstico: O plano de execução mudou de um Index Seek eficiente para um Index Scan custoso. A estimativa de linhas do CE mudou de 10 para 1.500.000.
- Ação Recomendada: [Comparar Planos de Execução] [Analisar Recomendações de Otimização]
Otimização Inteligente para o “Novo Cérebro”
Em vez de forçá lo a voltar para o cérebro antigo, a dbsnOOp ajuda você a ensinar o novo cérebro a entender suas queries. A plataforma pode analisar o novo plano de execução ruim e sugerir uma otimização — como a criação de estatísticas em múltiplas colunas ou um novo índice — que dê ao Modern CE as informações que ele precisa para tomar a decisão correta. Isso permite que você obtenha o melhor dos dois mundos: a performance estável das suas queries antigas e o poder do novo otimizador para as cargas de trabalho futuras.
Não realize a próxima “atualização invisível” às cegas. O risco de paralisar sua produção é real e devastador.
Arme sua equipe com a visibilidade necessária para modernizar seu ambiente com confiança. Marque uma reunião com nosso especialista ou assista a uma demonstração na prática!
Saiba mais sobre o dbsnOOp!
Visite nosso canal no youtube e aprenda sobre a plataforma e veja tutoriais
Aprenda sobre monitoramento de banco de dados com ferramentas avançadas aqui.
Leitura Recomendada
- IA Tuning Banco de Dados: A mudança no Estimador de Cardinalidade é um problema complexo de otimização. Entenda como a Inteligência Artificial é a abordagem mais eficaz para diagnosticar e resolver essas regressões de performance em escala.
- dbsnOOp: a Plataforma de Monitoramento e Observabilidade com DBA Autônomo: Descubra a visão completa da plataforma, onde a detecção de regressão de performance é apenas um dos muitos recursos projetados para garantir a estabilidade e a eficiência do seu ambiente de dados.
- Ajuste Fino SQL Server: Aprofunde seus conhecimentos em outras técnicas e estratégias de otimização para o SQL Server. Entender o tuning de forma holística é essencial para lidar com desafios complexos como o do Estimador de Cardinalidade.