DBMS_STATS vs. ANALYZE TABLE: Por que insistir no passado pode arruinar a performance no Oracle 19c e 26ai?

Se você trabalha com Oracle Database há algum tempo, com certeza já digitou o comando ANALYZE TABLE COMPUTE STATISTICS;. No início dos anos 2000, ele era o nosso braço direito. Mas o tempo passou, a arquitetura do banco de dados evoluiu drasticamente, e o otimizador baseado em custos (CBO – Cost-Based Optimizer) tornou-se uma máquina extremamente sofisticada.

Se você ainda utiliza o comando ANALYZE para coletar estatísticas no Oracle 19c ou no novíssimo Oracle 26ai, eu tenho um alerta vital para te dar: você está sabotando o seu próprio banco de dados.

Neste artigo, vamos entender de forma prática e direta por que a package DBMS_STATS é o único caminho aceitável no Oracle moderno e quais são os prejuízos reais de insistir no ANALYZE.

O Otimizador Moderno exige Inteligência (E o ANALYZE é cego)

O papel das estatísticas é fornecer ao CBO um mapa preciso do volume e da distribuição dos dados. Com base nisso, ele decide se vai usar um índice, fazer um Full Table Scan, ou escolher um método de Join específico.

O comando ANALYZE foi projetado na época do otimizador baseado em regras (RBO) e nas primeiras versões do CBO. Ele coleta dados brutos e estruturais básicos. Já a package DBMS_STATS foi introduzida no Oracle 8i e, desde então, foi totalmente integrada ao motor do CBO. Ela não apenas lê dados; ela entende o comportamento dos dados.

O que o DBMS_STATS faz que o ANALYZE ignora:

1. Estatísticas Globais e de Partições Corretas: Em tabelas particionadas, o DBMS_STATS consegue calcular estatísticas em nível de partição, subpartição e globais de forma agregada e inteligente. O ANALYZE falha miseravelmente em gerar estatísticas globais precisas para objetos particionados.
2. Histogramas Avançados: O DBMS_STATS cria histogramas fundamentais (como Top-Frequency e Hybrid) essenciais para lidar com dados assimétricos (data skew).
3. Estatísticas de Extensões e Colunas Virtuais: Essenciais para recursos modernos do Oracle.

Os Grandes Prejuízos de usar ANALYZE TABLE no 19c e 26ai

Usar o ANALYZE para gerar estatísticas do otimizador traz consequências severas:

1. Cegueira em Recursos Avançados do CBO

No Oracle 19c e 26ai, recursos como Adaptive Query Plans, SQL Plan Management (SPM) e Real-Time Statistics (estatísticas coletadas em tempo real durante operações de DML) dependem exclusivamente da infraestrutura da DBMS_STATS. O ANALYZE quebra essa cadeia de inteligência.

2. Falta de Paralelismo

Se você tem uma tabela de 500 Gigabytes, o ANALYZE vai processá-la de forma serial (em uma única thread), gerando um gargalo monstruoso de I/O e tempo de CPU. A DBMS_STATS permite o uso de paralelismo nativo, varrendo tabelas gigantescas em minutos.

3. Falta de Automação

As janelas de manutenção automática do Oracle utilizam por baixo dos panos a DBMS_STATS. Quando você força um ANALYZE, você sobrescreve dados vitais que a automação do banco usa para manter a saúde do ambiente.

Indo para o Código: A Prática

Vamos ver a diferença gritante entre as duas abordagens.

O Jeito Antigo e Problemático (Não faça isso!)

-- Executando a coleta obsoleta
ANALYZE TABLE sales COMPUTE STATISTICS;

-- Ou pior, coletando por amostragem antiga:
ANALYZE TABLE sales ESTIMATE STATISTICS SAMPLE 20 PERCENT;

Por que evitar? Esse comando roda em Single-Thread, gera sobrecarga desnecessária no dicionário de dados e não preenche corretamente colunas vitais nas visões DBA_TAB_STATISTICS e DBA_IND_STATISTICS para o otimizador moderno.

O Jeito Moderno e Eficiente (Padrão Enterprise)

A package DBMS_STATS nos dá superpoderes. Veja como coletar estatísticas de forma otimizada utilizando paralelismo e detecção automática de tamanho de amostra:

BEGIN
  DBMS_STATS.GATHER_TABLE_STATS (
    ownname          => 'SH',
    tabname          => 'SALES',
    estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -- O Oracle decide a melhor amostragem com velocidade incrível
    degree           => 4,                          -- Utiliza 4 threads paralelas para acelerar o processo
    cascade          => TRUE,                       -- Coleta estatísticas dos índices associados automaticamente
    method_opt       => 'FOR ALL COLUMNS SIZE AUTO' -- Deixa o Oracle decidir onde criar histogramas baseado no uso das queries
  );
END;
/

O Recurso Secreto: O que há de novo no Oracle 19c/26ai?

A partir do Oracle 19c, e estendendo-se no 26ai, temos o Real-Time Statistics. Enquanto operações convencionais de DML (Inserts, Updates) acontecem, o Oracle coleta estatísticas em tempo real em background para evitar que o plano de execução fique “cego” entre as janelas de manutenção.

Adivinha quem gerencia isso? Sim, a infraestrutura da DBMS_STATS. O comando ANALYZE ignora completamente essa evolução.

Para que serve o ANALYZE TABLE hoje em dia?

“Mas, o comando ANALYZE foi totalmente banido do banco?” Não! Ele ainda tem utilidade, mas nunca para coletar estatísticas para o otimizador. O ANALYZE hoje serve para tarefas específicas de validação estrutural.

Exemplo: Validando integridade física (Chained Rows e Estrutura de Índices)

Se você precisa verificar se um índice está corrompido ou identificar linhas migradas/encadeadas (chained rows), o ANALYZE é a ferramenta correta:

-- Validar a estrutura física de uma tabela (Procura por corrupções bloco a bloco)
ANALYZE TABLE sales VALIDATE STRUCTURE CASCADE;

-- Listar linhas encadeadas (Exige a criação prévia da tabela CHAINED_ROWS)
ANALYZE TABLE sales LIST CHAINED ROWS INTO chained_rows;

Conclusão: Modernize sua Infraestrutura, Valorize sua Carreira

Manter scripts antigos com ANALYZE TABLE para coletar estatísticas é manter o seu banco de dados Oracle 19c ou 26ai operando com a mentalidade do Oracle 8i.

Para extrair a performance máxima dos servidores modernos, migrar para a DBMS_STATS não é opcional, é obrigatório. Ela traz inteligência, paralelismo, integração com automações e garante que o Otimizador Baseado em Custos sempre tome a melhor decisão para as suas consultas mais críticas.

Deixe o ANALYZE exclusivamente para validações estruturais e leve seus scripts de banco de dados para o próximo nível!

Gostou do artigo?

Deixe seu comentário abaixo dizendo se você ainda encontrou algum script legado com ANALYZE na sua empresa e vamos debater como modernizá-lo!