Sankhya nota fiscal lenta: causas e como resolver
Sankhya lento na emissão e consulta de notas fiscais tem como causa principal o crescimento das tabelas TGFCAB e TGFITE sem manutenção de índices, com milhões de registros acumulados, queries sem índice adequado fazem full table scan e demoram 10 a 100× mais. O segundo fator é o I/O de disco durante apurações de SPED e EFD, que geram leituras massivas de histórico transacional.
As tabelas de cabeçalho e itens de NF crescem continuamente. Sem índices para os filtros mais usados (data, CNPJ parceiro, status), queries de consulta e listagem fazem full scan, operação que cresce linearmente com o volume de dados.
A geração de arquivos SPED e EFD lê grandes volumes de registros históricos em janelas curtas. Com storage compartilhado e alta latência de I/O, a apuração pode durar horas e competir com usuários ativos no banco.
Alguns ambientes Sankhya guardam os XMLs de NF-e como BLOBs no banco. Com milhares de NFs por mês, isso infla o banco desnecessariamente e piora o I/O de queries que não precisam do XML.
Analise as queries lentas com o Slow Query Log (SQL Server) ou AWR (Oracle). Crie índices compostos para os filtros mais usados em TGFCAB: (DTNEG, CODEMP, TIPMOV). Um único índice correto pode reduzir uma query de 30 segundos para 0,1 segundo.
Programe os jobs de apuração SPED e EFD para horários fora do expediente (00h, 05h). Com storage NVMe dedicado, a leitura de histórico é mais rápida e não prejudica usuários simultâneos.
Configurar o Sankhya para armazenar XMLs no filesystem reduz o tamanho do banco e elimina leituras de BLOB em queries que não precisam do conteúdo do XML. O volume de dados no banco pode diminuir 30 a 50% em empresas com alto volume de NFs.
Com NVMe dedicado, a latência de leitura do histórico transacional cai para abaixo de 500 µs. O impacto é mais perceptível em apurações fiscais e relatórios que leem grandes volumes de NFs históricas.
A Boreal Tecnologias oferece diagnóstico gratuito de lentidão em nota fiscal no Sankhya, análise de índices, wait statistics do banco e métricas de I/O. Cloud privada no Brasil com NVMe dedicado e SLA 99,99% em reais.
As tabelas de NF crescem continuamente e, sem manutenção de índices e estatísticas, os planos de execução das queries ficam progressivamente piores. O crescimento é linear, uma empresa que emite 1.000 NFs por mês terá uma tabela 12× maior em 1 ano, com queries proporcionalmente mais lentas sem manutenção.
Sim, mas é fácil distinguir. Lentidão na transmissão (comunicação com a SEFAZ) afeta apenas o status da autorização, não a emissão ou consulta interna. Lentidão na listagem e consulta de NFs já emitidas é quase sempre problema interno de banco ou infraestrutura.
Para empresas com até 50 mil NFs por mês, a geração do SPED Fiscal deve completar em 30 a 60 minutos com infraestrutura adequada (NVMe, banco bem indexado). Tempos acima de 2 horas indicam problema de I/O, falta de índices ou banco com fragmentação elevada.
O Sankhya tem funcionalidade de arquivamento de NFs antigas para tabelas de histórico, removendo-as das tabelas ativas. Isso reduz o volume de dados que as queries precisam varrer. O prazo legal de guarda de NFs é de 5 anos, mova registros mais antigos para tabelas de histórico particionadas.
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.