Dimensionamento de SAP HANA: memória, CPU e disco sem desperdício

📚 Continue aprendendo sobre este tema:

Por que memória é o gargalo de um banco em memória

Em um banco de dados tradicional, os dados moram no disco e o servidor traz para a memória apenas o pedaço de que precisa naquele instante. O disco é o lugar onde a informação vive, e a memória é uma área de passagem. É por isso que, nesse modelo, faltar memória deixa o sistema lento, mas não impede que ele funcione.

O HANA inverte essa lógica. Os dados de trabalho ficam na memória, e é de lá que as consultas são respondidas. O disco continua existindo, com papel de guarda permanente e de recuperação, mas ele não é o lugar de onde o sistema lê no dia a dia. Essa inversão é o que dá a velocidade que justifica o produto, e é também a razão de a memória virar o recurso que manda no projeto inteiro.

A consequência prática é direta: quando falta memória em um banco convencional, você tem um sistema lento. Quando falta memória em um banco em memória, você tem um sistema que passa a fazer exatamente aquilo que ele foi desenhado para evitar, ou que simplesmente para de aceitar novas operações.

O que ocupa memória além do tamanho da base

Aqui está o erro de raciocínio mais comum de quem está orçando pela primeira vez: olhar o tamanho do banco atual e pedir um servidor com essa quantidade de memória. A memória precisa acomodar mais coisas do que os dados:

Os dados propriamente ditos, já comprimidos pelo próprio banco.
A área de trabalho das consultas, ou seja, o espaço temporário que relatórios, fechamentos e integrações consomem enquanto rodam.
Estruturas internas do banco, como índices e áreas de controle.
O sistema operacional e os demais serviços que rodam no mesmo servidor.
Folga para picos, porque o consumo não é constante ao longo do mês.

O item da área de trabalho é o que costuma passar despercebido, e é justamente o que aperta no pior momento. O consumo de memória de um ERP não é uma linha reta. Ele sobe no fechamento contábil, no fechamento fiscal, na virada de mês, quando alguém puxa um relatório de três anos de histórico e quando a integração noturna roda junto com um usuário que ficou até tarde. Dimensionar pela média é dimensionar para quebrar no dia mais importante.

O que acontece quando se subdimensiona

Subdimensionar parece uma economia e é o contrário. Os sintomas aparecem em ordem:

Lentidão intermitente. O sistema fica bom em algumas horas e ruim em outras, o que gera diagnóstico errado e discussão interna sobre se o problema é a rede ou o ERP.
Relatórios que não terminam. Consultas grandes falham por falta de espaço de trabalho, e o usuário aprende a evitar o relatório em vez de reclamar.
Erros de alocação em memória. Operações passam a ser recusadas, geralmente sob carga, ou seja, exatamente quando a empresa mais precisa.
Parada. No limite, o serviço do banco cai, e a recuperação de um banco em memória não é instantânea, porque ele precisa recarregar dados antes de voltar a atender.
Custo escondido. A equipe passa a gastar horas em ajustes paliativos, e o projeto de expansão acontece de forma emergencial, com pressa e sem negociação.

O que torna o subdimensionamento particularmente traiçoeiro é o intervalo entre a compra e a dor. O servidor é comprado, o sistema entra no ar, tudo funciona bem por um tempo, e a base cresce em silêncio. Quando o problema aparece, quase ninguém liga a causa à decisão tomada meses antes.

O que acontece quando se superdimensiona

O excesso também tem preço, e ele não é só o valor da nota fiscal:

Capital parado. Dinheiro imobilizado em recurso que não será usado no horizonte do investimento.
Custo recorrente maior. Em ambiente de nuvem, você paga pelo que provisionou, então o excesso vira despesa mensal permanente.
Efeito cascata. Servidor maior costuma puxar contrato de suporte maior, ambiente de contingência maior e backup maior.
Falsa sensação de segurança. Com folga excessiva, ninguém acompanha o consumo, e o crescimento desordenado da base passa despercebido até a folga acabar.

Em servidor físico, o erro para mais é caro e reversível apenas na próxima compra. Em nuvem, ele é mais fácil de corrigir, o que é um argumento real a favor de rodar o ERP em infraestrutura elástica, tema que detalhamos em SAP Business One na nuvem e desempenho.

CPU e disco: o papel de cada um

Recurso	Para que serve no HANA	Sinal de que está errado
Memória	Guardar os dados de trabalho e a área de processamento das consultas	Erros de alocação, relatórios que falham, consumo próximo do limite em fechamento
CPU	Processar consultas, compressão e cálculos em paralelo	Uso alto e constante mesmo fora de pico, fila de processamento, resposta lenta com memória sobrando
Disco	Persistir os dados, guardar o log de transações e permitir recuperação após reinício	Reinício demorado, gargalo na gravação de log, salvamento de dados atrasando a operação
Rede	Ligar usuários, integrações e cópia para o ambiente de contingência	Lentidão apenas em acessos remotos, replicação atrasada

Disco merece uma observação. Como o dado precisa ser persistido e o banco precisa conseguir recarregar depois de um reinício, a velocidade de gravação e de leitura do armazenamento afeta diretamente quanto tempo o sistema leva para voltar. Ou seja, o disco não influencia tanto o desempenho do dia a dia quanto influencia o tempo de recuperação em uma parada. Quem trata disco como item de sobra costuma descobrir isso justamente no pior momento. Esse é um dos pontos que ligam dimensionamento a continuidade, assunto de alta disponibilidade para SAP Business One e HANA.

Passo a passo para dimensionar sem chute

Meça a base atual. Levante o tamanho dos dados hoje, separando o que é transacional do que é histórico e do que é anexo. Anexo em base é um vilão silencioso e às vezes pode sair dela.
Levante o histórico de crescimento. Compare o tamanho de hoje com o de meses anteriores. Sem série histórica, comece a medir agora, todo mês, e registre.
Mapeie os picos, não a média. Identifique os momentos de maior carga do mês e do ano, e quantos usuários estão ativos neles.
Liste as integrações. Todo sistema que lê ou escreve no ERP consome recurso, inclusive fora do horário comercial.
Defina o horizonte do investimento. O servidor precisa atender por quantos anos? Essa resposta muda tudo.
Projete o crescimento com aritmética simples. Se a sua base cresce, por hipótese, 2 GB por mês e o horizonte é de três anos, o cálculo é 2 vezes 36, ou seja, 72 GB a mais de dados no fim do período. Use os seus números medidos, não uma média de mercado.
Considere eventos previstos. Abertura de filial, aquisição, novo canal de vendas e aumento no volume de documentos fiscais mudam a curva.
Rode o dimensionamento oficial. Leve os dados medidos ao seu parceiro SAP e use as ferramentas oficiais de dimensionamento do fabricante, além da lista de hardware suportado. Regra de bolso de internet não substitui isso.
Some os ambientes não produtivos. Teste e homologação também precisam de recurso, e esse item costuma ficar fora do orçamento inicial.
Escreva a premissa junto com o número. Registre em qual crescimento e em qual horizonte o dimensionamento se baseou. Quando a realidade divergir da premissa, você vai saber, em vez de descobrir por lentidão.

Um evento de 2026 que entra na conta

A Lei Complementar 214/2025, publicada em 16 de janeiro de 2025, regulamenta a reforma tributária, e 2026 é ano-teste, com alíquotas de IBS em 0,1% e CBS em 0,9%. Do ponto de vista de infraestrutura, o ponto relevante é que o ERP precisa emitir e escriturar os novos tributos em paralelo aos atuais durante a transição. Isso significa mais registros, mais processamento e, muito provavelmente, atualização de versão do sistema, com ambiente de homologação ativo por mais tempo. Se o seu dimensionamento foi feito antes de considerar isso, revise a premissa. Tratamos do assunto em SAP Business One e a reforma tributária.

Ambiente de teste não é luxo

É comum a empresa dimensionar apenas o ambiente de produção e tratar o de teste como algo que se resolve depois. O resultado é previsível: atualizações passam a ser aplicadas direto em produção, porque não existe outro lugar para aplicá-las.

O ambiente de teste serve para validar atualização de versão, mudança de parametrização, integração nova e restauração de backup. Ele não precisa ser idêntico ao de produção, mas precisa ser parecido o bastante para que o resultado do teste signifique alguma coisa. Um ambiente pequeno demais gera falso positivo: o teste passa, e a mesma operação quebra em produção por falta de recurso.

Acompanhar o consumo é parte do dimensionamento

Dimensionamento não é um evento de compra, é uma rotina. O consumo de memória, o crescimento da base e o comportamento em pico precisam ser monitorados de forma contínua, com registro histórico e alerta antes do limite, não depois. É assim que a expansão vira decisão planejada de orçamento, e não compra de emergência com o sistema já sofrendo. Esse acompanhamento é uma das funções do nosso NOC 24x7. Se você ainda está na etapa anterior, escolhendo o servidor, vale começar pelos requisitos de servidor para SAP Business One.

Perguntas frequentes

Posso dimensionar o HANA olhando só o tamanho do meu banco atual?

Não. A memória precisa acomodar os dados comprimidos, a área de trabalho consumida pelas consultas, as estruturas internas do banco, o sistema operacional e uma folga para pico e crescimento. Dimensionar apenas pelo tamanho atual da base é o caminho mais rápido para descobrir o problema durante um fechamento.

Qual a diferença prática entre errar para menos e errar para mais?

Errar para menos custa operação: lentidão, relatórios que falham, risco de parada e expansão emergencial sem poder de negociação. Errar para mais custa dinheiro: capital imobilizado, despesa recorrente maior em nuvem e contratos acessórios inflados. Em servidor físico, o erro para menos é mais grave. Em nuvem, o erro para mais tende a doer mais no caixa mensal, mas é corrigível.

Vale mais rodar o HANA em servidor próprio ou em nuvem?

Depende do seu perfil de crescimento e de quanto a sua empresa quer manter operação de infraestrutura. Servidor próprio faz sentido quando a carga é estável e previsível, e existe equipe e processo para cuidar dele. Nuvem faz sentido quando o crescimento é incerto, quando você quer ajustar recurso sem nova compra e quando prefere converter investimento em despesa mensal. A decisão precisa considerar também disponibilidade, contingência e o desenho do ambiente de teste.

Como a BS IT Solutions conduz o dimensionamento

A BS IT Solutions mede o seu ambiente antes de recomendar qualquer coisa: tamanho e composição da base, curva de crescimento, comportamento em pico, integrações e planos de negócio para os próximos anos. A partir daí, desenhamos a infraestrutura com o parceiro SAP, incluindo os ambientes não produtivos, e deixamos o consumo sob monitoramento contínuo, com alerta antes do limite. Nossa liderança é especializada em SAP B1, HANA e Basis, e atende empresas em São Paulo e região metropolitana de forma presencial, além do atendimento remoto em todo o Brasil.

Fale com um especialista da BS IT Solutions e faça o dimensionamento com base nos seus números, não em regra de bolso.