Protheus lento? 4 cases reais de cliente que provam: o caminho mais rápido e barato é o banco de dados
Apresentador
Fabrício Lima · LinkedIn ↗ · YouTube ↗
Sobre o que é
Uma live técnica sobre como resolver lentidão no ERP Protheus atuando diretamente no banco de dados SQL Server. Cobre a arquitetura de índices, análise de queries reais, compressão de dados (com reduções de 60% a 80%) e rotinas essenciais para o DBA manter o ambiente saudável.
💡 Principais Insights
Banco de dados é o caminho mais rápido e barato
Quando o Protheus fica lento, as empresas geralmente tentam comprar mais hardware ou reescrever código AdvPL. Ambos são caros e demorados. A atuação no banco de dados — principalmente criação e otimização de índices — resolve lentidões pontuais de forma rápida, barata e eficiente.
SELECT * é o inimigo número 1
Quando se solicita todas as colunas de uma tabela gigante, o SQL Server é forçado a fazer Key Lookup para cada linha. Com milhares de linhas, o otimizador desiste do índice e faz Table Scan — lendo a tabela toda. A lição: solicite apenas as colunas estritamente necessárias.
Compressão: de 242GB para 50GB
O Protheus preenche colunas vazias com espaços em branco em vez de NULL, desperdiçando espaço massivamente. A compressão nativa do SQL Server elimina esses vazios, reduzindo bancos entre 60% e 80%. O benefício vai além do disco: mais dados cabem na RAM, e leitura em memória é ordens de grandeza mais rápida que em disco.
Índices no JOIN, não só no WHERE
Ao juntar tabelas gigantes do Protheus (como SC5 e SC6), não basta ter índices nos filtros do WHERE. É crucial garantir índices nas colunas de junção (cláusula ON/JOIN), como Filial e Número do Pedido.
Updates/Deletes em massa: sempre em lotes
Nunca execute comandos que afetem milhões de linhas de uma vez. Isso trava a tabela, expande o LDF descontroladamente e, se cancelado, o rollback pode levar horas. A prática correta: fazer em lotes menores (loops).
Power Alerts + Tuning: a dupla que resolve
Sem monitoramento você está no escuro — esperando o usuário reclamar. O Power Alerts identifica queries lentas, locks, sessões sleeping e acompanha rotinas críticas como custo médio, saldo contábil e faturamento. Power Alerts + Tuning de queries é a solução mais rápida e barata para lentidão no Protheus — muito melhor que comprar mais infra.
💬 Frases que Marcaram
📖 Resumo Detalhado
O Problema da Lentidão: 3 Caminhos
Quando o Protheus fica lento, as empresas tentam resolver de três formas diferentes. Cada uma com custo, prazo e efetividade muito distintos:
|
Caminho 1 📊 Hardware Mais CPU, memória, SSD Custo Alto Prazo Semanas a meses ⚠ Problema costuma voltar conforme o banco cresce |
Caminho 2 📝 AdvPL Reescrever código do ERP Custo Médio-alto Prazo Demorado ⚠ Cria dependência de terceiros |
★ FOCO DA LIVE
Caminho 3 💾 Banco de Dados Índices, compressão, queries Custo Baixo Prazo Minutos a horas ✅ Resolve a causa, sem mexer no ERP |
A terceira via é o foco da live: atuar no banco de dados é a forma mais rápida, barata e eficiente de resolver lentidões pontuais — principalmente através da criação e otimização de índices.
A Arquitetura e a Mágica dos Índices
O núcleo da otimização reside no uso adequado de índices, divididos em duas categorias:
Índice Clustered (Físico)
A própria tabela organizada em formato de árvore. No Protheus, é sempre a coluna R_E_C_N_O_. Só pode existir um por tabela — ele define a ordem física dos dados no disco.
Índices Nonclustered (Lógicos)
Estruturas de árvore separadas para facilitar buscas por outras colunas (Nome, Data, Filial). O Protheus possui dezenas desses índices por tabela.
Três conceitos fundamentais de leitura:
⚠ Scan (pior cenário)
SQL lê a tabela inteira para encontrar um dado. Como ler um livro inteiro para achar uma palavra.
✅ Seek (cenário ideal)
SQL vai direto ao ponto usando a árvore do índice. Máxima performance.
⚠ Key Lookup (intermediário)
SQL encontra a linha pelo índice nonclustered, mas precisa “pular” para o clustered para buscar colunas adicionais não presentes no índice.
O Perigo do SELECT *
Quando se solicita todas as colunas de uma tabela gigante, o SQL Server faz Key Lookup para cada linha encontrada. Com milhares de linhas, o otimizador percebe que milhares de lookups é excessivo e decide ignorar o índice — optando por um Table Scan, que lê a tabela toda e degrada severamente a performance. Lição fundamental: solicite apenas as colunas estritamente necessárias.
Índices nos JOINs, Não Só no WHERE
Ao juntar tabelas gigantes do Protheus (como SC5 e SC6), não basta ter índices nos filtros do WHERE. É crucial garantir índices nas colunas de junção (cláusula ON/JOIN), como Filial e Número do Pedido. Sem esses índices, o SQL Server é forçado a fazer Scans em tabelas enormes.
Ordem das Colunas no Índice Composto
A ordem importa muito. A regra geral: a coluna mais seletiva (que filtra mais dados, como Código do Produto) deve vir antes de colunas menos seletivas (como Filial, que tem muitos valores repetidos).
Compressão de Dados: O Segundo Trunfo
O Protheus preenche colunas vazias com espaços em branco em vez de NULL — desperdiçando espaço massivamente. A compressão nativa do SQL Server elimina esses vazios, com reduções reais entre 60% e 80%:
Casos reais de compressão:
● 242 GB → 50 GB (redução de 79%)
● 565 GB → 181 GB (redução de 68%)
O benefício vai além do disco: com o banco menor, muito mais dados cabem na RAM (Buffer Pool). Leitura em memória é ordens de grandeza mais rápida que em disco — a performance geral dá um salto gigantesco.
Rotinas Essenciais para o DBA
Queries Sleeping: Consultas que o sistema “esqueceu” abertas e que ficam segurando Locks (travando tabelas). Devem ser monitoradas e encerradas para evitar travamentos em cadeia.
Updates/Deletes em massa: Nunca execute comandos que afetem milhões de linhas de uma vez. Isso trava a tabela, expande o LDF descontroladamente e, se cancelado, o rollback pode levar horas. Faça sempre em lotes (loops).
Collation: No contexto do Protheus, a collation Latin1_General_BIN é significativamente mais rápida que as opções padrão, pois o SQL não precisa validar acentuação e diferenças entre maiúsculas/minúsculas nas comparações de strings.
Monitoramento: Saia do Escuro com o Power Alerts
Tuning sem monitoramento é tiro no escuro. Antes de otimizar qualquer coisa, você precisa enxergar o que está acontecendo no ambiente. O Power Alerts é fundamental para ambientes Protheus porque entrega exatamente essa visibilidade:
🔍 Queries mais demoradas
Identifica automaticamente as consultas que mais consomem CPU, fazem mais leituras e as que mais se repetem. É assim que você encontra as queries para otimizar.
🔒 Locks e sessões sleeping
Monitora travamentos em tempo real e identifica sessões esquecidas abertas que estão segurando locks desnecessariamente.
⚙ Rotinas críticas do Protheus
Acompanha a performance de rotinas como custo médio, saldo contábil, faturamento e outras — alertando quando algo sai do padrão.
Power Alerts + Tuning de queries é a solução mais rápida e barata para lentidão em ambiente Protheus. Muito melhor que comprar mais infraestrutura — e sem ficar no escuro esperando o usuário reclamar.
📈 Cases Reais: O Poder de um Índice
Pra ilustrar o impacto real dessas técnicas, separei 4 cases de clientes reais demonstrados na live. Em todos, a otimização levou minutos — o impacto, anos de tranquilidade pra equipe de TI.
Case 1 · CT2010 (48 milhões de registros)
O índice sugerido nem sempre é o melhor
Query filtrava por CT2_CREDIT. O SQL Server sugeriu um índice gigante com muitas colunas no INCLUDE — seria caro de manter numa tabela desse tamanho. A solução: um índice menor, apenas pela coluna seletiva CT2_CREDIT (420MB, criado em 5 minutos).
|
❌ Antes 5,7s 91.143 leituras · CPU 10.531ms |
✅ Depois 0,07s 4 leituras · CPU 0ms |
💡 Lição: índice menor e mais seletivo pode ser melhor que o sugerido pelo SQL.
Case 2 · SD2010 (86M de leituras no tempdb)
6 subqueries idênticas + TempDB massivo
Query com 6 subqueries idênticas no CASE e no WHERE, todas buscando na SD2010 sem índice por D2_COD. O operador Spool gerava 86 milhões de leituras no tempdb. A solução: 1 único índice estratégico cobrindo o padrão das subqueries.
|
❌ Antes 4m 05s 86M tempdb · CPU 362s |
✅ Depois 3s 4.504 tempdb · CPU 12,6s |
💡 Lição: um índice bem posicionado resolve múltiplas subqueries de uma vez.
Case 3 · SC5 + SC6 + SC9 (Pedidos)
481 milhões de leituras + Locks travando o banco
Query com múltiplos JOINs entre Pedidos (SC5), Itens (SC6) e Composição (SC9). Realizava 481 milhões de leituras na SC9 e — o pior — causava Locks que travavam outros processos do banco inteiro. Solução “sniper”: 3 índices estratégicos focados nas colunas de filtro e JOIN.
|
❌ Antes 2m 40s 481M leituras · CPU 1.183s |
✅ Depois 4s Locks eliminados |
💡 Lição: índices nos JOINs são tão importantes quanto nos filtros WHERE.
Case 4 · SCT3W0 (15 minutos de execução)
SUBSTRING no WHERE mata o índice
O filtro usava SUBSTRING(CT_DATA, 1, 6) = ‘202101’. Quando você aplica uma função numa coluna do WHERE, o SQL não consegue usar índice — precisa aplicar a função em CADA linha. Resultado: Table Scan completo. Solução: reescrever o filtro sem função (CT_DATA >= ‘20210101’ AND CT_DATA < ‘20210201’) + índice otimizado.
|
❌ Antes 15 min Table Scan completo |
✅ Depois segundos Seek eficiente no índice |
💡 Lição: NUNCA use funções em colunas do WHERE. Reescreva o filtro.
🔗 Quer ver mais? Estes 4 são uma amostra. Veja o post completo com 10 cases reais de melhoria de performance no Protheus →
🎯 Pra quem é essa live?
DBAs que administram ambientes Protheus e precisam melhorar performance. Analistas de infraestrutura que recebem chamados de lentidão do ERP. Desenvolvedores AdvPL que querem entender como o banco processa suas queries. E gestores de TI avaliando se devem investir em hardware ou em otimização.
✅ Takeaways Rápidos
✓ Crie índices nos JOINs, não só nos filtros WHERE
✓ Coluna mais seletiva primeiro no índice composto
✓ Compressão de dados no Protheus é mandatória
✓ Monitore e encerre Queries Sleeping
✓ Deletes/Updates em massa: sempre em lotes (loops)
✓ Use collation Latin1_General_BIN para Protheus
✓ Power Alerts + Tuning = solução mais rápida e barata
✓ Otimize o banco antes de comprar mais hardware
Resumo por Power Tuning · powertuning.com.br
