Escritório contábil que adota o Senior Sistemas normalmente já passou de um certo porte. Não é o software de quem tem cinco estações. É o de quem tem estrutura, várias frentes de trabalho e, muitas vezes, um departamento de folha robusto atendendo dezenas de empresas. Esse porte é o que torna o erro de infraestrutura mais caro. Quando o Senior fica lento ou instável, não é uma pessoa que para — é um andar inteiro.

O Senior não roda sobre um banco de dados “de prateleira” que se instala e esquece — esse é o ponto que pega a maioria dos escritórios de surpresa. Além disso, ele exige um servidor de banco de dados de verdade: Oracle, SQL Server ou PostgreSQL, configurado com critério. Na prática, tratar essa camada com o mesmo descaso de um sistema pequeno é a origem de quase todos os problemas de desempenho. Os gestores costumam atribuir essa lentidão, injustamente, ao software.

Este é o último post do nosso cluster sobre infraestrutura de TI para cada sistema contábil brasileiro. Antes dele vieram os posts sobre Domínio, Alterdata, Questor, Glandata e Fortes. Aqui o foco é o que o gestor de TI ou o sócio precisa garantir por baixo do Senior. É isso que faz o sistema entregar a estabilidade que o porte do escritório exige.

O banco de dados do Senior Sistemas: arquitetura e versões suportadas

O Senior é um sistema construído sobre um banco de dados relacional corporativo. Ele homologa três: Oracle 11 ou superior, Microsoft SQL Server 2012 ou superior e PostgreSQL 9 ou superior. Por isso, essa é a primeira decisão de arquitetura, e ela tem consequências de custo e de gestão. O SQL Server tende a ser o caminho mais comum nos escritórios do ABC e de São Paulo, por já conviver bem com o ambiente Windows. Já o PostgreSQL aparece como opção sem custo de licença de banco.

O detalhe da collation que ninguém avisa

Um detalhe técnico que causa muita dor de cabeça é a collation do banco. A Senior recomenda a configuração SQL_Latin1_General_CP1_CI_AS no SQL Server. Instalar o banco com uma collation diferente da recomendada gera desde ordenação errada de relatórios até erros de integração difíceis de rastrear. É o tipo de ajuste que precisa estar certo na instalação, porque corrigir depois, com a base já em produção, é trabalhoso.

Quem opta por Oracle precisa saber de uma pegadinha clássica. Nesse caso, o client do Oracle deve ser sempre 32 bits nas estações, mesmo em Windows 64 bits. Já a versão 64 bits do Oracle é para o servidor de banco. Se esse servidor também for usado como client, instala-se adicionalmente um client 32 bits nele. Assim, ignorar essa regra é garantia de conexão que não sobe.

Essa dependência de um banco corporativo aproxima o Senior do Questor, que também roda sobre SQL Server. Aliás, os cuidados de dimensionamento e manutenção de banco que descrevemos no post sobre infraestrutura de TI para o Questor valem, em boa parte, para o Senior em SQL Server. A diferença é que o Senior costuma carregar mais módulos e mais volume, o que empurra os requisitos para cima.

Configuração de servidor para o Senior: requisitos mínimos e recomendados

Servidor de banco de dados corporativo pede memória. Para um ambiente de escritório contábil de médio porte rodando Senior sobre SQL Server ou Oracle, 16 GB de RAM é o piso, e 32 GB é o razoável. Além disso, esse patamar maior vale quando há muitos usuários simultâneos e módulos de folha e fiscal trabalhando junto. Na prática, bancos como SQL Server e Oracle usam a memória para manter dados em cache. Quanto mais RAM disponível, menos o banco recorre ao disco — e mais rápido o sistema responde.

Disco: SSD é obrigatório

O disco segue a mesma lógica dos outros sistemas, com peso ainda maior: os arquivos de dados do banco precisam estar em SSD, de preferência NVMe. Em ambientes maiores, vale separar em discos distintos os arquivos de dados, os arquivos de log de transação e o sistema operacional. Ou seja, é uma prática de banco corporativo que reduz contenção de I/O e melhora o desempenho de forma perceptível durante os picos.

A infraestrutura elétrica, que ninguém lembra até faltar, é requisito da própria Senior. Assim, nobreak dimensionado e energia estabilizada são obrigatórios, e em locais com fornecimento instável, gerador também. Afinal, não é preciosismo: uma queda de energia com o banco no meio de uma transação pode corromper a base. E recuperar uma base Senior corrompida é bem mais complexo do que restaurar um sistema pequeno. O ambiente do servidor também deve ser climatizado e com acesso físico controlado.

Rede Gigabit cabeada entre servidor e estações é padrão. Como em qualquer sistema contábil, a estabilidade nos períodos de pico é o que separa o escritório tranquilo do escritório em pânico no dia da entrega. Por isso vale rodar o checklist de TI para o fechamento mensal antes de cada virada.

Backup do Senior: estratégia e automação para dados contábeis críticos

Backup de banco corporativo não é copiar arquivo — é usar as ferramentas nativas do próprio banco para gerar cópias consistentes. No SQL Server, isso significa rotinas de backup automatizadas: full periódico somado a backups do log de transação. Assim, essas rotinas permitem restaurar a base para um ponto no tempo específico. No Oracle, o mesmo se faz com as ferramentas de backup do próprio Oracle. Copiar o arquivo de dados com o banco no ar, sem essas ferramentas, gera cópia inconsistente e inútil.

Automação e teste de restauração

A automação é o que torna isso confiável. O backup precisa rodar sozinho, em janela de baixa atividade, com verificação de que a cópia foi concluída sem erro. Além disso, é preciso um alerta para quando o backup falhar. Backup que depende de alguém “lembrar de rodar” é backup que um dia não vai existir justamente no dia em que for preciso. Como sempre, a cópia precisa sair do servidor: mídia separada e nuvem, com pelo menos uma cópia fora do escritório. Idealmente, uma cópia também deve ser imutável, que ransomware não consegue criptografar — seguindo a mesma lógica do protocolo 3-2-1 de backup.

O passo que quase ninguém executa é o teste de restauração. Na prática, restaurar a base num ambiente separado, subir o Senior sobre ela e confirmar que os dados vieram íntegros: esse é o único jeito de saber que o backup funciona. Num escritório com o volume de dados que o Senior costuma ter, descobrir no incidente que o backup estava quebrado é uma catástrofe operacional. E, pior, evitável.

Integrações do Senior com Power BI, Excel e ferramentas externas via ODBC

Aqui o Senior brilha. Por rodar sobre bancos corporativos padronizados (Oracle, SQL Server, PostgreSQL), a conexão com ferramentas de análise é direta e madura. Na prática, um driver ODBC expõe as tabelas do sistema como fonte de dados para dashboards e planilhas. O Power BI também tem conectores nativos para SQL Server, Oracle e PostgreSQL, o que torna a conexão ainda mais direta.

Isso abre um leque de entregas de alto valor para o cliente: painéis de indicadores fiscais e trabalhistas, acompanhamento de obrigações, análise de folha, evolução de honorários. Ou seja, é a informação gerencial que transforma o escritório de “quem entrega obrigação” em “quem entrega inteligência”. É um diferencial competitivo real — e o Senior facilita, porque o banco por trás é um banco que o mercado de BI conhece bem.

O cuidado técnico é o mesmo de qualquer integração séria: usar um usuário de leitura dedicado, nunca o administrativo. Também vale evitar que consultas pesadas de BI rodem sobre a base de produção nos horários de pico. Em escritórios maiores, o correto é ter uma réplica ou uma base de leitura separada só para análise. Assim o dashboard nunca disputa desempenho com a operação de fechamento.

Senior em ambiente de nuvem privada: o que a Altcom recomenda para escritórios no ABC

Colocar o Senior na nuvem é uma decisão que faz muito sentido para o porte de escritório que usa o sistema. Além disso, filiais, home office e continuidade em caso de problema no escritório físico são só alguns dos motivos. A abordagem que a Altcom recomenda para escritórios no ABC Paulista e em São Paulo é a nuvem privada. Na prática, isso significa hospedar o servidor de aplicação e o servidor de banco de dados em um ambiente dedicado, com recursos garantidos, e publicar o sistema aos usuários via sessão remota.

A diferença para uma nuvem pública compartilhada está no controle e na previsibilidade de desempenho. Banco corporativo é sensível a recurso. Nesse caso, numa nuvem privada bem dimensionada, o escritório sabe exatamente quanta memória e quanto processamento o banco tem, sem disputar com vizinhos invisíveis. É a abordagem que dá a estabilidade que o Senior exige. Vale comparar com o caminho de outros sistemas. Aliás, no post sobre Alterdata em nuvem discutimos as diferenças entre as abordagens. Portanto, a lógica de dimensionar bem antes de migrar se aplica igualmente ao Senior.

Os pré-requisitos para migrar

Os dois pré-requisitos são inegociáveis. O primeiro é internet redundante e de qualidade no escritório, porque tudo passa pela sessão remota. O segundo é o dimensionamento correto de RAM e vCPUs para o número de sessões e o volume do banco. Feito com esse critério, o Senior na nuvem privada entrega mobilidade e continuidade sem abrir mão do desempenho. E é isso, no fim, que justifica ter escolhido um sistema desse porte.

Conclusão

O Senior Sistemas entrega o que um escritório de médio e grande porte precisa. Mas cobra em troca uma infraestrutura à altura: banco corporativo bem configurado, servidor com memória e disco adequados, energia protegida, backup automatizado e testado, e uma estratégia de nuvem pensada com critério. Não é o tipo de sistema que se sustenta com TI improvisada. Em resumo, acertar essa fundação é o que faz o Senior ser o ativo que o escritório contratou, e não a fonte de lentidão que ninguém consegue explicar.

Perguntas frequentes

Quais bancos de dados o Senior Sistemas suporta?

O Senior homologa Oracle 11 ou superior, Microsoft SQL Server 2012 ou superior e PostgreSQL 9 ou superior. No SQL Server, a collation recomendada pela Senior é a SQL_Latin1_General_CP1_CI_AS.

Quanta RAM o servidor do Senior precisa?

Para escritório de médio porte, 16 GB é o piso e 32 GB é o recomendado. Isso também vale quando há muitos usuários e módulos de folha e fiscal simultâneos. Bancos como SQL Server e Oracle usam a memória como cache — mais RAM significa menos disco e mais desempenho.

Como fazer backup do banco do Senior?

Usando as ferramentas nativas do banco: backup automatizado do SQL Server ou do Oracle, com cópias saindo do servidor para mídia separada e nuvem. Isso também inclui uma cópia imutável e teste de restauração periódico. Copiar o arquivo de dados manualmente gera cópia inconsistente.

Vale a pena colocar o Senior em nuvem?

Sim, especialmente em nuvem privada, que garante recursos dedicados ao banco e desempenho previsível. Exige internet redundante de qualidade e dimensionamento correto de RAM e vCPUs para as sessões e o volume de dados.