Resposta rápida
O SAP HANA é um banco de dados em memória, então o recurso que domina o dimensionamento é RAM — a regra de partida é ter memória suficiente pra caber toda a base de dados na RAM, com folga pro processamento. Junto vêm CPU de servidor (Xeon/EPYC), storage rápido e persistente (NVMe) com volumes separados de dados e log, e redundância. Por concentrar dados críticos e ser sensível a "vizinho barulhento", o SAP pede hardware dedicado, não recurso compartilhado. No Brasil, o caminho é um servidor dedicado em datacenter Tier III, dimensionado para os requisitos do seu ambiente SAP, com dado em solo nacional (LGPD). O sizing oficial (em SAPS e GB de memória) sai da ferramenta de sizing da SAP ou do seu parceiro SAP — a gente entrega o metal que atende esse número.
Infraestrutura pra SAP não perdoa improviso. É o sistema que roda o financeiro, o fiscal, a produção — se ele fica lento no fechamento do mês, a empresa inteira sente. Este guia é pra quem roda SAP ou implanta SAP pra clientes (integrador, consultoria) e precisa acertar o servidor: o que o HANA realmente exige, por que compartilhar recurso é furada aqui, e onde termina o que a gente entrega e começa o sizing oficial da SAP.
Por que o SAP HANA é diferente de qualquer outro banco
O HANA guarda e processa os dados na memória RAM, não no disco como um banco tradicional. É isso que dá a velocidade que a SAP vende — e é isso que muda todo o dimensionamento. Num banco comum, você pode ter pouca RAM e muito disco. No HANA, a base inteira (mais folga de trabalho) precisa caber na memória. RAM deixa de ser um item da lista e vira O item.
Consequência prática: servidores de SAP HANA têm quantidades de RAM que assustam quem vem de aplicação web — centenas de GB, às vezes terabytes, dependendo do tamanho da base. E como é dado crítico em memória, a RAM ECC (que corrige erros de bit) deixa de ser recomendação e vira requisito de sanidade.
O que o ambiente SAP exige do servidor
| Recurso | Por que importa no SAP |
|---|---|
| RAM (ECC), muita | O HANA vive na memória — a base precisa caber na RAM com folga. É o recurso que dita o tamanho do servidor |
| CPU de servidor (Xeon/EPYC) | Processamento em memória exige núcleos de verdade; o sizing da SAP é medido em SAPS, uma métrica de capacidade |
| NVMe, volumes separados | Mesmo em memória, o HANA persiste dados e logs em disco; a SAP tem KPIs de desempenho de storage, com volumes de dados e log separados |
| Redundância | Fonte, disco em RAID, rede — o sistema que roda a empresa não pode cair por uma peça |
| Datacenter Tier III no Brasil | Energia e refrigeração redundantes, latência baixa pro usuário BR, dado em solo nacional (LGPD) |
Por que SAP pede DEDICADO (e não recurso compartilhado)
Três razões técnicas empurram o SAP pra bare metal exclusivo:
- Sensibilidade a "vizinho barulhento" — num ambiente compartilhado, outro cliente puxando I/O ou CPU no pico degrada o SEU HANA justamente na hora do fechamento. Dedicado elimina a variável;
- Volume de RAM — os requisitos de memória do HANA são altos demais pra caber confortável em oferta compartilhada; faz mais sentido econômico e técnico em máquina exclusiva;
- Previsibilidade de performance — SAP tem KPIs a cumprir; performance que oscila com o vizinho não fecha auditoria. Recurso dedicado entrega desempenho constante.
É o mesmo raciocínio que vale pra qualquer ERP pesado — o panorama completo de rodar ERP brasileiro por vertical (TOTVS, SAP, Sankhya) está no nosso guia de migração de ERP por vertical. Se o seu caso é SAP Business One rodando sobre SQL Server (e não HANA), a lógica de dimensionamento se aproxima do dedicado Windows + SQL Server pra ERP.
SAP HANA, S/4HANA e Business One: onde cada um roda
- SAP S/4HANA — a suíte atual da SAP roda obrigatoriamente sobre o banco HANA (em memória). Aqui a RAM manda no dimensionamento;
- SAP Business One — a versão pra empresas menores roda em duas variantes: sobre SQL Server (dimensionamento tradicional de banco) ou sobre HANA (em memória). Saber qual das duas o cliente usa muda o servidor;
- SAP ECC clássico — bases mais antigas que ainda não migraram pro HANA rodam sobre bancos tradicionais; o dimensionamento segue a lógica clássica de CPU/RAM/disco.
Onde termina a nossa entrega e começa o sizing oficial da SAP
Aqui vale ser transparente, porque é o ponto que mais gera confusão: o sizing oficial de um ambiente SAP — quantos SAPS de CPU e quantos GB de memória — sai da ferramenta de sizing da SAP (o SAP Quick Sizer) ou do parceiro SAP que implanta o sistema, com base no número de usuários, módulos e volume de dados. Esse número é responsabilidade da camada SAP.
O que a gente entrega é o servidor dedicado que atende esse número: o metal com a RAM, a CPU, o storage e a redundância que o sizing pediu, em datacenter Tier III no Brasil, com custo fixo em Real e NF. Você (ou o parceiro SAP) traz o requisito; a gente dimensiona e entrega a infraestrutura que o comporta. É a divisão de trabalho certa — cada um no que domina.
Backup e continuidade: inegociável em SAP
Sistema que roda a empresa precisa de plano de recuperação de verdade. Para SAP isso significa backup consistente do banco (não um snapshot solto no meio de uma transação), destino externo ao servidor e restauração testada — porque backup que ninguém restaurou é só esperança. Como desenhar backup de sistema e banco crítico está no nosso guia de backup de ERP e banco de dados. Para ambientes que não podem cair, entra também redundância de servidor — decisão de projeto, dimensionada pela criticidade.
Perguntas frequentes
Vocês são certificados pra rodar SAP?
Nós entregamos a infraestrutura de servidor dedicado (o hardware, o datacenter, a rede) dimensionada pelos requisitos do seu ambiente SAP. A certificação de sizing e a homologação do software SAP são responsabilidade da SAP e do parceiro SAP que implanta o sistema — nós entregamos o metal que atende ao que esse sizing exigir. Se o seu projeto pede um cenário específico de certificação de hardware, traga o requisito que a gente dimensiona pra ele.
Quanta RAM meu servidor SAP HANA precisa?
A regra de partida é caber a base de dados inteira na memória, com folga de processamento — o que na prática vai de dezenas a centenas de GB (ou mais) conforme o tamanho da base. O número exato sai do sizing oficial da SAP (Quick Sizer) ou do seu parceiro SAP. Com esse número na mão, a gente entrega o dedicado com a RAM certa.
Posso rodar SAP na nuvem em vez de servidor físico?
Pode — o ponto não é físico versus virtual, é recurso dedicado versus compartilhado. SAP roda bem em bare metal exclusivo ou em recurso reservado só pra você; o que não funciona bem é dividir a máquina com cargas de terceiros disputando CPU e I/O no pico.
Meus dados SAP ficam no Brasil?
Sim — servidor dedicado em datacenter Tier III em São Paulo, dado em território nacional. Resolve a discussão de conformidade territorial (LGPD) sem cláusula de transferência internacional, o que costuma pesar em auditoria de empresa que roda SAP.
Tem o sizing do SAP? A gente entrega o metal que atende
Traz o requisito do seu ambiente SAP (RAM, SAPS, storage — ou o número do Quick Sizer / do seu parceiro SAP) que um especialista devolve o dimensionamento do servidor dedicado e a cotação fechada em até 24h úteis. Tier III no Brasil, em Real, com NF, dado em solo nacional.
Dimensionar meu servidor SAP →Implanta SAP pra clientes? Fale sobre parceria de infraestrutura.