SQL Server para TOTVS Protheus: infraestrutura, desempenho e alta disponibilidade

Atualizado em 14 de agosto de 2026

O SQL Server é o banco de dados principal do TOTVS Protheus e o componente de infraestrutura com mais impacto direto no desempenho do sistema. RAM insuficiente, storage inadequado ou configuração incorreta do SQL Server são as causas mais frequentes de lentidão em ambientes Protheus — mesmo quando o AppServer está bem dimensionado.

Este artigo cobre os requisitos de infraestrutura do SQL Server para o Protheus, o sizing por perfil de uso, as opções de alta disponibilidade e as considerações sobre virtualização. Licenciamento Microsoft não é abordado com valores absolutos — as regras mudam com frequência e dependem do modelo de contratação.

Por que o SQL Server é o componente mais crítico do Protheus

O AppServer executa as rotinas do Protheus, mas todos os dados — transações, cadastros, lançamentos, documentos fiscais — residem no banco SQL Server. Qualquer operação do Protheus que envolva leitura ou escrita de dados passa pelo SQL Server. Em módulos de alto volume transacional (Fiscal, Manufatura, Folha), o SQL Server recebe centenas ou milhares de operações por minuto.

Diferente do AppServer, que pode ser escalado horizontalmente com múltiplas instâncias, o SQL Server em ambientes Protheus tradicionais é um ponto central — o que significa que seu desempenho afeta todos os usuários simultaneamente. Um gargalo no SQL Server aparece para todos.

RAM: o fator mais determinante no SQL Server

O SQL Server usa a RAM disponível para manter as páginas de dados em um cache chamado buffer pool. Quando uma query acessa dados que já estão no buffer pool (cache hit), a resposta é imediata. Quando os dados não estão em memória (cache miss), o SQL Server precisa ir ao disco — e é aí que o IOPS do storage como gargalo.

A relação é direta: quanto mais RAM o SQL Server tem, mais dados cabem no buffer pool, menos leituras de disco ocorrem e mais rápido o Protheus responde. Para ambientes onde o banco do Protheus cabe inteiro (ou quase) na RAM, as leituras de disco são mínimas mesmo com storage de IOPS modesto.

Regra prática: dimensione a RAM do SQL Server para que o buffer pool possa acomodar pelo menos o conjunto de dados “quentes” — as tabelas e índices acessados com mais frequência durante a operação normal. Para a maioria dos ambientes Protheus, isso representa 30% a 50% do tamanho total do banco.

Storage, IOPS e configuração de arquivos

IOPS: o segundo fator mais determinante

Quando o buffer pool não consegue servir uma query (cache miss), o SQL Server lê do storage. A velocidade dessa leitura depende do IOPS do storage. Storage com baixo IOPS (HDD, SATA de entrada) gera filas de I/O que se traduzem em lentidão percebida pelos usuários. Storage All-Flash com IOPS consistente elimina essa filas.

Separação de arquivos por tipo

O SQL Server tem três tipos de arquivo com padrões de I/O distintos — e a melhor prática é mantê-los em volumes separados:

• Arquivos de dados (.mdf / .ndf): leitura e escrita mista. O maior arquivo do banco.
• Log de transações (.ldf): escrita sequencial intensiva. Muito sensível à latência de escrita.
• tempdb: banco temporário usado internamente. Uso intenso em queries complexas, ordenações e operações de hash. Em All-Flash, pode ficar no mesmo volume sem penalidade.

Em ambientes com storage HDD, separar esses arquivos em spindles diferentes melhora o desempenho. Em All-Flash, a separação ainda é boa prática de organização mas tem menor impacto em performance.

Crescimento automático: configurar corretamente

O crescimento automático configurado com incrementos pequenos (padrão de 1 MB ou 10%) gera eventos de crescimento frequentes que interrompem brevemente as transações. Configure incrementos fixos grandes (ex.: 512 MB ou 1 GB para bancos acima de 100 GB) ou pré-aloque o espaço completo estimado para os próximos 12 meses.

Sizing do SQL Server por perfil Protheus

Alta disponibilidade: Always On e outras opções

Para o Protheus, as principais opções de HA no nível do SQL Server são:

• Always On Availability Groups (AG): replica o banco para um ou mais servidores secundários em modo síncrono ou assíncrono. Failover pode ser automático (síncrono) ou manual (assíncrono). É a opção de maior resiliência e menor RPO/RTO e RPO.
• Log shipping: envia logs de transação para um servidor standby em intervalos regulares. Mais simples e de menor custo que Always On. RPO depende do intervalo de envio de logs.
• Failover Cluster Instance (FCI): instância do SQL Server compartilhada em cluster de Windows Server. Protege contra falha de hardware mas não mantém cópia dos dados — o storage é compartilhado.
• Backup + restore como Guia de Disaster Recovery: não é HA, mas é a linha de base mínima para qualquer ambiente Protheus em produção.

Virtualização do SQL Server com Protheus

O SQL Server do Protheus pode ser virtualizado em VMware, Hyper-V ou em nuvem privada sem impacto de desempenho quando as configurações de virtualização são feitas corretamente. Os pontos críticos são:

• Storage: o storage virtual deve entregar IOPS equivalente ao físico. Em cloud privada com Pure Storage All-Flash, essa premissa é atendida.
• Overprovisioning de vCPU: não aloque mais vCPUs do que cores físicos disponíveis para a VM do SQL Server — overcommit de CPU causa contenção de NUMA e degrada a performance do SQL Server.
• Memória: reserve memória (não use ballooning ou swapping) para a VM do SQL Server. Memória virtual paginada para disco mata o desempenho do buffer pool.
• NUMA topology: alinhe a alocação de vCPUs ao layout NUMA do host físico para melhor performance de memória.

Sobre licenciamento SQL Server

O que podemos afirmar sem risco de erro: o SQL Server utilizado com o TOTVS Protheus precisa ser licenciado adequadamente. A versão homologada para a sua versão do Protheus deve ser consultada na documentação oficial da TOTVS. Em ambientes de nuvem privada gerenciada, verifique com o provedor se a licença está incluída na mensalidade (modelo SPLA) ou se é de responsabilidade do cliente.

Perguntas frequentes

Qual edição do SQL Server usar para o TOTVS Protheus?

A edição adequada depende da versão do Protheus e dos requisitos de disponibilidade. SQL Server Standard atende a maioria dos ambientes. SQL Server Enterprise é necessário quando se deseja Always On Availability Groups com failover automático ou recursos avançados de HA. Consulte a documentação da TOTVS e um parceiro Microsoft para confirmar a homologação para a sua versão.

O SQL Server e o AppServer do Protheus podem estar no mesmo servidor?

Sim, especialmente em ambientes pequenos (até 20 usuários). Em ambientes maiores, a separação em servidores dedicados permite dimensionar cada componente de forma independente e isolar gargalos. Se estiverem no mesmo servidor, some os requisitos de RAM e CPU de ambos e configure o Max Server Memory do SQL Server adequadamente.

O SQL Server precisa de reinicialização para aplicar patches?

Alguns patches do SQL Server exigem reinicialização do serviço — o que causa interrupção breve do Protheus. Em ambientes com Always On AG, é possível aplicar patches no nó secundário primeiro e fazer o failover, evitando interrupção para os usuários. Em ambientes sem HA, a janela de manutenção deve ser planejada.

Como saber se o SQL Server está com gargalo de RAM?

Monitore a métrica “Page Life Expectancy” (PLE) no SQL Server. Uma PLE baixa e decrescente indica que as páginas estão saindo do buffer pool muito rapidamente — sinal de pressão de memória. Em ambientes saudáveis, o PLE tende a crescer ao longo do dia (páginas sendo carregadas e permanecendo em cache). Uma queda brusca indica que houve uma leitura massiva que “varreu” o buffer pool.

Você também pode se interessar:

• Servidores: VPS vs Cloud vs Dedicados — qual escolher?
• Computação em Nuvem: o que é, modelos e como funciona
• 5 características da computação em nuvem que toda empresa deveria conhecer