SAP Business One lento no fechamento do mês é quase sempre gargalo de I/O de disco e buffer pool do banco subdimensionado, não um problema no ERP em si. Jobs como AFAB (depreciações), MMPV (virada de período de materiais) e KSU5 (alocações de centro de custo) geram leituras e escritas massivas em paralelo, exigindo throughput 5 a 10× superior ao das operações diárias. Mover o banco SQL Server para storage NVMe dedicado e dimensionar corretamente a RAM costuma reduzir o tempo de fechamento em 60 a 80%.
Em clouds públicas e hypervisores com storage em pool, múltiplos tenants disputam o mesmo disco. Os jobs de fechamento são intensivos em leitura e escrita sequencial, exatamente o padrão mais prejudicado por latência de storage e esperas de I/O. O resultado: operações que levam segundos em disco dedicado levam minutos em disco compartilhado.
O SQL Server mantém páginas de dados em memória (buffer pool). Durante o fechamento, o working set do banco cresce significativamente. Se a RAM da VM não for suficiente, o buffer pool transborda para disco constantemente, o que transforma minutos em horas. O sintoma clássico: alta taxa de Page Life Expectancy baixo e Page reads/sec elevado nos contadores de performance do SQL Server.
Clouds públicas usam overcommit de CPU: o hypervisor aloca mais vCPUs do que cores físicos existem. Durante picos simultâneos, e muitas empresas fazem fechamento nas mesmas datas, VMs vizinhas competem pelos mesmos cores físicos, gerando CPU wait time elevado. O SAP B1 fica aguardando ciclos de CPU que foram prometidos mas não estão disponíveis.
O SQL Server escreve em arquivos de log de transações (I/O sequencial) e em arquivos de dados MDF (I/O aleatório) simultaneamente. Quando ambos estão no mesmo volume físico, as operações concorrem. Separar dados e logs em volumes distintos é configuração básica de performance para ambientes SAP, e frequentemente ignorada em migrações rápidas para cloud.
Substituir storage em pool compartilhado por NVMe dedicado elimina a disputa de I/O entre tenants. SSDs NVMe entregam latência abaixo de 200 µs e throughput acima de 3 GB/s, suficiente para os jobs de fechamento mais pesados. Na Boreal, cada VM tem storage NVMe exclusivo, sem compartilhamento com vizinhos.
Analise o crescimento do buffer pool durante fechamentos anteriores via DMVs do SQL Server (sys.dm_os_buffer_descriptors). Em geral, ambientes SAP B1 com 50 usuários e base acima de 100 GB se beneficiam de pelo menos 32 GB RAM. Para 100+ usuários, 64 GB ou mais. Adicionar RAM é a mudança de maior impacto com menor custo proporcional.
Migrar para VMs com recursos garantidos, onde vCPUs mapeiam diretamente em cores físicos exclusivos, elimina o CPU wait time durante picos de fechamento. Na Boreal, todas as VMs usam alocação dedicada: os recursos contratados são exclusivamente seus, independentemente da carga dos demais tenants.
Configure o SQL Server com arquivos MDF e NDF (dados) em um volume NVMe e arquivos LDF (logs) em volume separado. Essa separação permite I/O aleatório de leituras de dados e I/O sequencial de escritas de log em paralelo, sem contenção. O resultado é perceptível especialmente durante operações de batch como os jobs de fechamento.
Jobs como AFAB (para faixas distintas de imobilizados) e KSU5 (por centro de custo) podem ser executados como background jobs paralelos no SAP B1. Com storage NVMe dedicado e vCPUs sem overcommit, a paralelização é segura e o ganho é proporcional ao número de jobs simultâneos.
A Boreal oferece VMs com storage NVMe dedicado, sem overcommit de vCPU e com SLA contratual de 99,99% em reais. Se o fechamento do seu SAP Business One está levando mais horas do que deveria e você já descartou problemas de configuração de jobs, um diagnóstico de infraestrutura gratuito da Boreal identifica os gargalos de I/O, memória e CPU, e projeta a configuração correta para o seu ambiente.
Na maioria dos casos, infraestrutura. O código dos jobs de fechamento não muda entre versões; se começaram a demorar mais, é porque o volume de dados cresceu sem que a infra acompanhasse, especialmente RAM (buffer pool do SQL Server) e throughput de I/O de disco. Um diagnóstico com os contadores de performance do SQL Server e as métricas de disco da VM confirma rapidamente onde está o gargalo.
Para ambientes com base acima de 100 GB e até 50 usuários simultâneos, o mínimo recomendado é 8 vCPU, 32 GB RAM e storage NVMe dedicado. Com overcommit ou storage em pool, esse sizing não é suficiente, o recurso nominal e o recurso efetivo divergem sob carga de fechamento.
Sim. Jobs independentes, como AFAB por faixa de imobilizado ou KSU5 por centro de custo, podem ser configurados como background jobs paralelos. A configuração correta depende das dependências entre jobs no seu plano de contas. A Boreal Consulting pode mapear as dependências e configurar o paralelismo seguro para o seu ambiente.
O SAP HANA é in-memory e elimina grande parte do gargalo de I/O de disco para leituras, pois mantém toda a base em RAM. No entanto, se a instância HANA não tiver RAM suficiente para o working set de fechamento, dados 'frios' ainda vão para disco persistente. O dimensionamento correto de RAM continua sendo crítico, e o custo do HANA é substancialmente maior que o do SAP B1 com SQL Server bem dimensionado.
Em geral sim, porque cloud privada com recursos dedicados elimina a contenção com vizinhos, o fator que mais impacta o fechamento. O determinante crítico é o storage: NVMe dedicado elimina a variabilidade de latência inerente ao storage em pool das clouds públicas. Empresas que migraram o SAP B1 de AWS ou Azure para a Boreal relatam redução de 60 a 80% no tempo de fechamento.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.