Comprar hardware adia. Cloud cobra todo mês. Performance no banco de dados resolve.
Comprar hardware adia. Cloud cobra todo mês. Performance no banco de dados resolve.
Fabrício Lima · Abril 2026
Autor
Fabrício Lima · CEO Power Tuning · LinkedIn ↗ · YouTube ↗
Sobre o que é
Em 20 anos otimizando Protheus, vi muito gestor aprovar centenas de milhares em hardware ou aumentar a fatura mensal de cloud achando que ia resolver lentidão — e ver o problema voltar 6 meses depois. Esse post mostra por que isso acontece, com 4 cases reais do meu arquivo. O ponto não é que mais infra não serve. É que ela é quase sempre a última medida — não a primeira.
💰 Por que mais infra quase nunca é a resposta
A frase que mais ouvi em 20 anos de Protheus é essa — e nos últimos anos, com cloud, ela ganhou uma versão nova:
Mais infra parece a resposta óbvia, e a cloud deixou isso ainda mais fácil — não precisa nem de cotação, é um clique no portal. CPU em 100%? Sobe SKU. Disco lento? Aumenta IOPS. Memória cheia? Mais RAM. A lógica é tão simples que ninguém questiona.
Mas tem um detalhe incômodo: na maioria absoluta dos casos que atendi, mais infra não resolveu nada. Ou resolveu por 6 meses, e a empresa estava de volta com o mesmo problema — agora pagando mais caro pra continuar lenta. Por quê?
Porque infraestrutura não conserta query mal escrita. SSD/Premium Storage não cria índice faltando. Mais vCore não impede um SELECT * lendo tabela de 48 milhões de linhas. Mais infra só faz o problema acontecer mais rápido — e, na cloud, faz você pagar mais por ele todo mês. A causa continua intacta. E cresce com o banco.
As 3 opções que você tem (e o quanto cada uma custa)
Quando o ERP fica lento, você tem três caminhos. Cada um com custo, prazo e risco bem diferentes:
|
Caminho 1 ☁️ Mais Infra Hardware ou vCore/DTU na cloud Custo Alto e recorrente Prazo Imediato (cloud) a meses (on-prem) ⚠ Problema volta — mas você passa a pagar mais |
Caminho 2 📝 AdvPL Reescrever código do ERP Custo Médio-alto Prazo Demorado ⚠ Cria dependência de terceiros |
★ FOCO DESSE POST
Caminho 3 💾 Banco de Dados Índices, compressão, queries Custo Baixo Prazo Minutos a horas ✅ Resolve a causa, sem mexer no ERP |
Esse post inteiro é sobre o caminho 3 — o que economiza dinheiro (capex e opex), tempo e a sua reputação como gestor. E vou provar com 4 cases reais do meu arquivo de cliente.
💡 O que você, gestor, precisa saber sobre seu banco
Você não precisa virar DBA. Mas precisa entender 5 conceitos que separam um ambiente bem cuidado de um prestes a estourar — pra saber quando seu time está fazendo o trabalho certo, e quando está te empurrando hardware.
1. Uma só query pode comer 40% do servidor (ou da sua fatura cloud)
Nos clientes que atendi, era comum encontrar uma única query consumindo 30% a 40% de todo o recurso do banco. Subir o SKU da instância não resolve isso — só faz a query consumir 40% de uma máquina mais cara. Em cloud, isso vira aumento mensal recorrente. Identificar e otimizar essa query, sim, libera o ambiente inteiro — e na cloud derruba a fatura.
2. Sem visibilidade, você vive no escuro
Sem ferramenta de monitoramento, ninguém sabe qual query é cara, qual tabela cresce mais, ou onde estão os locks. Você vive reagindo a chamado de usuário. Esse é o sintoma clássico que faz aprovar mais infra (ou subir o SKU na cloud): quando ninguém enxerga o problema, "trocar tudo" vira a melhor hipótese possível. Não é.
3. SELECT * é o inimigo número 1 da performance
Quando uma query pede "todas as colunas" de uma tabela gigante, o SQL Server desiste de usar índice e lê a tabela inteira. Em tabelas do Protheus com 48 milhões de linhas, isso significa milhões de leituras desnecessárias. Pedir só as colunas necessárias muda tudo.
4. Índices nos JOINs, não só nos filtros
A maioria dos DBAs cuida bem dos índices nos filtros (WHERE). Mas quando uma query junta 3 tabelas grandes do Protheus, e os índices nas colunas de junção não existem, o servidor inteiro trava. Esse é o gargalo mais subestimado que existe — e raramente aparece em diagnóstico de fornecedor.
5. Compressão pode reduzir o banco em 70% (e não é gambiarra)
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% — vi cliente sair de 242GB pra 50GB. Banco menor cabe na RAM, e aí tudo fica mais rápido. Sem mexer no ERP, sem novo servidor.
💬 O que aprendi em 20 anos
📈 4 cases reais que evitaram aumento de infra
Pra ilustrar o impacto real, separei 4 cases de clientes do meu arquivo. Em todos, a empresa estava em vias de aumentar a infra — comprar servidor novo, subir o SKU no Azure, ou aumentar storage premium — e a otimização no banco resolveu o problema em horas. O custo: uma fração do que seria a infra extra (só ou recorrente).
Case 1 · CT2010 (48 milhões de registros)
O índice sugerido nem sempre é o melhor
Query filtrava por uma coluna específica. O próprio SQL Server sugeriu um índice gigante — seria caro de manter numa tabela desse tamanho. Solução: um índice menor, apenas pela coluna seletiva (420MB, criado em 5 minutos):
|
❌ Antes 5,7s 91.143 leituras · CPU 10s |
✅ Depois 0,07s 4 leituras · CPU 0ms |
💡 A lição pro gestor: não aceite cegamente o índice sugerido pelo SQL nem o "precisa de mais máquina" do fornecedor. Diagnóstico bem feito é outra coisa.
Case 2 · SD2010 (TempDB sob pressão)
Quando o disco está lento, o problema raramente é o disco
Cliente com query escrita de forma que o SQL despejava 86 milhões de leituras no TempDB pra cada execução. Sintoma visível: disco lento, servidor "travado". O fornecedor recomendou storage Premium na Azure — o que significaria uns R$ 8 mil/mês a mais na fatura. Solução real: 1 índice estratégico cobrindo o padrão das subqueries:
|
❌ Antes 4m 05s 86M tempdb · CPU 362s |
✅ Depois 3s 4.504 tempdb · CPU 12s |
💡 A lição pro gestor: sintoma de hardware (disco lento) raramente tem causa de hardware. Storage Premium só faria os 86M de leituras serem mais rápidos — sem resolver nada, e com R$ 8 mil/mês a mais na fatura, pra sempre.
Case 3 · SC5 + SC6 + SC9 (Pedidos)
Locks travando o banco inteiro
Query com JOINs em 3 tabelas de Pedidos do Protheus. Realizava 481 milhões de leituras e — o pior — causava locks que travavam outros processos do banco. O cliente já tinha aprovado um upgrade de servidor de R$ 280 mil que se tornou desnecessário. Solução: 3 índices estratégicos focados nas colunas de JOIN:
|
❌ Antes 2m 40s 481M leituras · locks |
✅ Depois 4s Locks eliminados |
💡 A lição pro gestor: R$ 280 mil em hardware não acabariam com os locks — locks são problema lógico, não físico. 3 índices, sim.
Case 4 · Query rodando 15 minutos
Uma função no WHERE matando o índice
Query do ERP demorando 15 minutos pra rodar. Causa: o filtro usava SUBSTRING numa coluna de data — o que força o SQL a aplicar a função linha por linha, lendo a tabela inteira. Solução: reescrever o filtro sem função + criar índice. Resultado:
|
❌ Antes 15 min Table Scan completo |
✅ Depois segundos Seek no índice |
💡 A lição pro gestor: 15 minutos virando segundos não é mágica nem hardware — é reescrita de uma linha de código + 1 índice. Trabalho de horas, não de meses.
🔗 Quer ver mais? Esses 4 são uma amostra. Tenho um post separado com 10 cases reais de melhoria de performance no Protheus →
📝 Reflexão
O que mudou em 20 anos — e o que continua igual
Em 20 anos otimizando Protheus, vi muita coisa mudar. O hardware ficou melhor, o SQL Server ficou mais inteligente, surgiu cloud, surgiu IA. Hoje até o SQL Server 2025 escreve query sozinho com Copilot.
O que não mudou: a pressão pra resolver o problema rápido, e o atalho mais óbvio. Antes era comprar mais máquina — hoje também é subir o SKU na cloud com 2 cliques, ou aumentar a tier de storage. O atalho mudou de embalagem, mas continua sendo o mais caro e o menos eficaz na maioria absoluta dos casos. Pior na cloud: vira fatura recorrente que ninguém olha mais.
Você, gestor, não precisa virar DBA. Precisa cobrar diagnóstico antes de aprovar orçamento. Diagnóstico bom dura horas. Servidor errado dura anos.
🛡 Pra não ficar no escuro
Visibilidade resolve antes de virar incidente
Em quase todos os casos que atendi, a empresa estava prestes a aprovar mais infra (hardware ou aumento de SKU na cloud) porque ninguém enxergava onde estava o gargalo. Foi exatamente esse problema que me fez criar o Power Alerts: 40+ alertas automáticos por e-mail, dashboard Power BI em tempo real, relatórios diários das queries mais caras. Funciona com DBA interno, terceirizado ou em times sem DBA dedicado — e em ambientes on-premise ou cloud.
✅ Pra levar pra sua próxima reunião de orçamento
✓ Uma só query pode comer 40% do servidor (ou da fatura cloud)
✓ Sem visibilidade, "subir o SKU" sempre parece a melhor opção
✓ SELECT * é o inimigo número 1 da performance
✓ Índices nos JOINs são tão importantes quanto nos filtros
✓ Compressão pode reduzir o banco em 70% sem mexer no ERP
✓ Disco lento raramente é problema de disco
✓ Diagnóstico bom dura horas. Infra errada dura anos — e na cloud, fatura todo mês.
📚 Pro DBA do seu time
Esse post foi escrito pra você, gestor. Mas escrevi também a versão técnica detalhada — com a explicação do plano de execução, ordem das colunas no índice composto e mais cases — no blog da Power Tuning. Compartilhe com seu DBA →
Por Fabrício Lima · fabriciolima.net
Nada mais satisfatório do que ver queries lentas sendo aceleradas ao extremo, sem aumentar recurso – e o cliente sorrindo 🙂
POis é… é bom demais…
nos sentimos um super heroi kkkk