Por que seu Protheus esta lento (e como diagnosticar em 30 minutos)

"Trocaram o servidor por um monstro de RAM e CPU. Nao melhorou nada." Frase que ja ouvimos em ~30% dos diagnosticos. Hardware raramente e o gargalo do Protheus em 2026 — quase sempre e configuracao, banco, ou codigo.

Este checklist sai do palpite e entra no metodo. Em 30 minutos voce identifica o culpado especifico.

As 7 causas mais comuns (mindmap)

Etapa 1 — Confirmar onde esta lento

Antes de mexer em nada: onde exatamente esta lento? Use a ferramenta de Schedule do Protheus pra coletar.

Causa 1 — Antivirus em PROTHEUS_DATA (o assassino silencioso)

Como verificar em Windows Server:

# PowerShell - lista exclusoes do Windows Defender
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

# Adicionar PROTHEUS_DATA + binarios
Add-MpPreference -ExclusionPath "C:\TOTVS\Protheus_Data"
Add-MpPreference -ExclusionPath "C:\TOTVS\BIN"
Add-MpPreference -ExclusionProcess "appserver.exe"
Add-MpPreference -ExclusionProcess "dbaccess64.exe"

Pra antivirus de terceiros (Trend, Sophos, McAfee, Crowdstrike), faca o equivalente no console deles.

Causa 2 — Indexacao automatica Windows

O Windows indexa todo arquivo pra busca. Em PROTHEUS_DATA com 200GB de DBF, isso degrada I/O drasticamente.

# Desabilitar indexacao da pasta
$path = "C:\TOTVS\Protheus_Data"
attrib +I $path /S /D
# Confirmar:
Get-ChildItem $path -Recurse | Where-Object { -not $_.Attributes.HasFlag('NotContentIndexed') }

Causa 3 — Statistics estouradas (banco)

Banco SQL Server: o otimizador escolhe plano de execucao baseado em estatisticas. Se elas estao desatualizadas, escolhe plano ruim. Sintoma: query que ontem rodava 2s, hoje roda 40s.

-- SQL Server: tabelas com statistics desatualizadas
SELECT
    OBJECT_NAME(s.object_id) AS table_name,
    s.name AS stat_name,
    sp.last_updated,
    sp.rows,
    sp.rows_sampled,
    DATEDIFF(day, sp.last_updated, GETDATE()) AS days_old
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE OBJECT_NAME(s.object_id) LIKE 'S%'  -- tabelas Protheus
  AND DATEDIFF(day, sp.last_updated, GETDATE()) > 30
ORDER BY days_old DESC;

-- Atualizar tudo (job semanal recomendado):
EXEC sp_updatestats;

Oracle:

-- Tabelas com stats antigas
SELECT table_name, last_analyzed,
       SYSDATE - last_analyzed AS days_old
FROM user_tables
WHERE last_analyzed < SYSDATE - 30
ORDER BY days_old DESC;

-- Atualizar (especifico da tabela):
EXEC DBMS_STATS.GATHER_TABLE_STATS('PROTHEUS', 'SF1010', cascade => TRUE);

Causa 4 — DBAccess + Appserver desalinhados

O DBAccess tem que estar na mesma versao do Appserver. Mismatch causa fallback pra protocolo legado, lento.

# Linux/Windows - confere versao no log
grep "DBAccess version" /opt/totvs/protheus/dbaccess/log/dbaccess.log | tail -5
grep "AppServer version" /opt/totvs/protheus/bin/appserver/console.log | tail -5

Se versoes diferentes, atualize ambos pra release atual (verifique Central de Atendimento TOTVS).

Causa 5 — Queries pesadas

Use Query Store (SQL Server 2016+) pra achar as 5 queries que mais consomem tempo:

-- Top 10 queries por duracao total (Query Store)
SELECT TOP 10
    qt.query_sql_text,
    rs.avg_duration / 1000.0 AS avg_duration_ms,
    rs.count_executions,
    rs.avg_logical_io_reads,
    rs.last_execution_time
FROM sys.query_store_query q
JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan p ON q.query_id = p.query_id
JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id
WHERE qt.query_sql_text LIKE '%S%010%'  -- tabelas Protheus
ORDER BY rs.avg_duration DESC;

Pra cada query lenta, pegue o plano e procure por:

• Table Scan em tabelas grandes → criar indice
• Sort custoso → indice com ordenacao
• Hash Match em JOINs → estatisticas ou indice no campo de join
• Key Lookup + alto numero de rows → indice covering

Causa 6 — Indices fragmentados

-- SQL Server: indices com >30% fragmentacao
SELECT
    OBJECT_NAME(ips.object_id) AS table_name,
    i.name AS index_name,
    ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 30
  AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;

-- Reconstruir indices > 30%, reorganizar entre 5-30%
ALTER INDEX ALL ON SF1010 REBUILD WITH (ONLINE = ON, MAXDOP = 4);

Causa 7 — Codigo: TableScan no AdvPL

Loops que abrem WorkArea sem indice = morte:

// RUIM - le toda SF1 procurando por NFe
DbSelectArea("SF1")
SF1->(DbGoTop())
While !SF1->(Eof())
    If AllTrim(SF1->F1_DOC) == cNumNFe
        // achou
        Exit
    EndIf
    SF1->(DbSkip())
End

// BOM - usa indice
DbSelectArea("SF1")
SF1->(DbSetOrder(1))  // F1_FILIAL+F1_DOC+F1_SERIE
If SF1->(DbSeek(xFilial("SF1") + cNumNFe + cSerie))
    // achou direto
EndIf

Caso real: 8s → 1.2s

Cliente do agro com Protheus 12.1.27. Telas de pedido demorando 8 segundos para abrir. Diagnostico:

Total de 8s para 1.2s. Custo: 1 dia de DBA + 4h de consultor. Sem trocar 1 byte de hardware.

Quando trocar versao vs ajustar config

Update de release Protheus nao e silver bullet. Tem casos de release nova com regressao. Sempre teste em ambiente espelhado.

Lentidao recorrente apesar de tudo isso? Fale conosco — fazemos diagnostico aprofundado em 1 semana.