Orientações e Configurações de Servidores

O objetivo deste documento é fornecer informações e diretrizes para auxiliar no entendimento e na tomada de decisões relacionadas a configurações e orientações de servidores. Ele não se destina a oferecer soluções diretas ou "receitas" prontas para problemas específicos.

Cada ambiente e situação de servidor é único, exigindo análise aprofundada, deliberação cuidadosa e monitoramento contínuo para a resolução eficaz de desafios.

Este trabalho e o escopo de resolução de problemas ou implementação de configurações não são de responsabilidade da Tek-System e não fazem parte de nossa carteira de serviços.

Para este tipo de demanda, é fundamental contar com uma empresa especializada e com vasta experiência no mercado. Nesse sentido, para questões ligadas ao Firebird sugerimos a IBSurgeon, reconhecida por sua expertise na área.

Sistema Operacional

Windows

- Gerenciamento de Energia: Versões do Windows frequentemente utilizam o plano de energia "Equilibrado" por padrão. Mudar o gerenciamento de energia de "Equilibrado" para "Alta Performance" pode trazer ganhos significativos, com um ganho médio de 20% nas operações gerais. Neste modo, o sistema prioriza o desempenho máximo, operando a CPU em sua frequência mais alta e minimizando recursos de economia de energia, garantindo respostas mais rápidas às demandas de carga. Tarefas que exigem muito da CPU, em particular, podem se beneficiar ainda mais, como exemplo:

 Equilibrado: TPC-C (operações) 17.029 | Restore (gbak) 4h07
 Alta Performance: TPC-C (operações) 21.226 | Restore (gbak) 2h35

(Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Reinicialização Regular: Recomendamos reiniciar seu servidor mensalmente. Essa prática ajuda a prevenir cenários onde o sistema operacional pode esgotar seu limite para criar novos processos, uma condição às vezes chamada de "esgotamento do desktop heap". Embora não seja extremamente comum, pode levar a erros como:

 "Not enough storage is available to process this command"

Esses erros do sistema operacional, causados por um número excessivo de chamadas de sistema, podem ocorrer em qualquer sistema, não apenas no nosso. Se isso acontecer, você precisará identificar o programa que está fazendo chamadas excessivas e desativá-lo.

- Atualizações do Windows: Mantenha as atualizações automáticas desabilitadas. Em vez disso, realize as atualizações manualmente durante horários de menor pico ou fora do expediente. O processo de atualização consome muitos recursos do sistema, o que pode impactar drasticamente o desempenho. Além disso, há o risco de o servidor reiniciar automaticamente após a instalação (processos envolvidos incluem TrustedInstaller.exe e WuauServ).

- As aplicações da Tek-System são compatíveis exclusivamente com o sistema operacional Microsoft Windows. Sistemas esses condicionados ao suporte ativo do fabricante, que assim recebem atualizações regulares que corrigem vulnerabilidades, oferecem compatibilidade com softwares e asseguram a estabilidade do ambiente. Já sistemas obsoletos, sem suporte, expõem a empresa a problemas com incompatibilidades, instabilidades e riscos de segurança, comprometendo a operação do software e a proteção dos dados. Não menos importante a consideração de instruções de utilização e aplicação, é essencial para garantir que o sistema operacional funcione dentro dos parâmetros de segurança, desempenho e confiabilidade para os quais ele foi projetado. A aplicação correta evita incompatibilidades e assegura que o software seja utilizado conforme suas finalidades técnicas. Ignorar essas diretrizes pode levar a instabilidade do ambiente, perda de desempenho, falhas de segurança e até à invalidação de garantias ou suporte. Fato é a observância da utilização do Windows 10 em alguns servidores. Apesar de ser um software versátil, esse sistema foi projetado para computadores pessoais e não é recomendado para uso como servidor, conforme a orientação da própria Microsoft. Para um ambiente corporativo robusto e seguro, recomendamos fortemente a utilização de sistemas da família Windows Server. Eles são desenvolvidos especificamente para empresas, oferecendo suporte a múltiplas conexões simultâneas, recursos avançados de segurança e controle de acesso, além de estabilidade para operações 24/7. Além disso, o Windows Server possui maior compatibilidade com hardware de servidores e exige menor necessidade de atualizações manuais que podem comprometer o desempenho.

 Alerta Importante: Fim do Suporte ao Windows 10: A Microsoft encerrará oficialmente o suporte ao Windows 10 em outubro de 2025. Após essa data, o sistema se tornará obsoleto e inseguro para uso corporativo, deixando sua empresa exposta a sérios riscos. A migração para uma versão suportada do Windows Server é essencial para manter a segurança e a eficiência do seu ambiente de TI.

Linux

- Distribuições Recomendadas: As distribuições Linux recomendadas para melhor performance são CentOS 7.x e Ubuntu 16 ou 18. O CentOS 6 oferece menor desempenho em comparação com o CentOS 7, assim como o Ubuntu 12 em relação ao Ubuntu 16.

 (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Configuração nobarrier para Ext4 e Firebird: Se estiver usando o sistema de arquivos Ext4 no Linux e a versão 2.5 do Firebird, a falta da opção nobarrier pode causar problemas de compatibilidade.

- Balanceamento entre barrier e Firmware (FW): Manter o "barrier" ligado juntamente com o firmware de disco (FW) ativado pode resultar em uma performance de escrita consideravelmente baixa. Para obter melhor desempenho, é crucial desabilitar um dos dois. Considere desabilitar o "barrier" apenas se o seu armazenamento possuir uma Unidade de Backup de Bateria (BBU) e você puder manter o firmware (FW) ligado.

- Erro "wrong record length" e RAM: Se você estiver utilizando Linux e encontrar frequentemente o erro "wrong record length", é altamente recomendável verificar a memória RAM do servidor.

 (Fonte: http://ib-aid.com/en/articles/how-to-quickly-check-ram-on-linux/)

- Limite de Arquivos Abertos para o Firebird: Verifique os limites para o processo do Firebird (SuperServer ou SuperClassic) usando o comando cat /proc/<firebird_proc_id>/limits. Preste atenção especial à linha que indica o número máximo de arquivos abertos. Se encontrar um valor como "Max open files 4096 4096 files", isso significa que o número de conexões que o Firebird pode servir será limitado a cerca de 1.000 (considerando que o Firebird pode usar até 4 handles por conexão, e se houver múltiplos bancos de dados, todas as conexões são somadas). Considere aumentar este valor para 65535. Após reiniciar o Firebird, verifique novamente se as alterações foram aplicadas. Para o Firebird Classic, é necessário verificar e aumentar os limites para o usuário "firebird".

 (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Uso de irqbalance: Utilize o irqbalance. Geralmente, o uso dessa ferramenta melhora o desempenho do Firebird e o balanceamento do uso da CPU em servidores com múltiplos núcleos.

- Limitação de Conexões em inetd/xinetd: Versões que dependem do inetd ou xinetd possuem uma limitação padrão de poucas conexões. É necessário modificar o arquivo de configuração para aumentar esse limite. Por exemplo, para o firebird2.5-classic que usa /etc/xinet.d/firebird2.5 por padrão, ajuste o arquivo da seguinte forma:

 servicegds_db 
 { 
   flags           = REUSE NODELAY 
   socket_type     = stream
   wait            = no
   user            = firebird
   log_on_success += USERID
   log_on_failure += USERID
   instances       = UNLIMITED
   per_source      = UNLIMITED
   server          = /usr/sbin/fb_inet_server 
 }

Armazenamento (Discos)

A escolha e configuração do subsistema de armazenamento são cruciais para o desempenho e a confiabilidade do seu servidor, especialmente em ambientes com banco de dados.

- Recomendados SSD (Solid State Drive) M.2 NVMe: Oferecem 1000++ IOPS (Operações de Entrada/Saída por Segundo) e proporcionam um desempenho de I/O aleatório e paralelo muito superior aos discos rígidos tradicionais. O I/O aleatório é crítico para ler e gravar dados distribuídos em arquivos de banco de dados grandes. Importante: Utilize SSDs corporativos (enterprise), pois eles são projetados com maior número de ciclos de leitura/gravação. O uso de SSDs de consumo pode levar à perda de dados devido a falhas prematuras. Sempre use SSDs de marcas confiáveis e instale os drivers fornecidos pelo fabricante.

- Não utilizar drives do tipo flash (pendrives, cartões SD) como armazenamento principal, pois sua estrutura dificulta severamente a recuperação de dados em caso de corrupção do banco de dados.

- Não utilizar Drives Externos SAN/NAS para Banco de Dados: A velocidade de um servidor de banco de dados como o Firebird depende criticamente da velocidade de acesso a blocos individuais de 4KB no dispositivo de armazenamento. Enquanto SAN/NAS são excelentes para transferências grandes (centenas de MBs) de um arquivo para outro, um servidor Firebird transfere centenas de milhares de pequenas páginas (blocos de 4KB) entre a memória e o disco rígido físico em diferentes deslocamentos de arquivo. Essa natureza de I/O de blocos pequenos é onde o SAN/NAS pode se tornar um gargalo.

- Segregação de Drives (Unidades Físicas) para Otimização: Recomenda-se a utilização de unidades físicas separadas para os seguintes elementos. Essa segregação evita a concorrência por recursos de I/O, o que poderia comprometer drasticamente o desempenho:

Sistema Operacional (SO): Para arquivos do sistema e programas básicos.

Banco de Dados: Onde os arquivos de dados do Firebird (ou outro DB) residem.

Arquivos Temporários: Unidade dedicada para arquivos temporários do SO, do próprio banco de dados e de aplicações.

Backups: Armazene os backups do banco de dados em uma unidade física dedicada (preferencialmente em RAID). Isso isola as operações de leitura/gravação durante o backup, aumentando sua velocidade e reduzindo a carga sobre a unidade principal. É crucial, especialmente quando os backups são realizados enquanto os usuários estão trabalhando ativamente com o banco de dados.

- Espaço em Disco Suficiente:

Para o Firebird e Pastas Temporárias do SO: O Firebird utiliza alocação temporária de arquivos em disco para diversas operações (ex: ordenação). Pouco espaço pode comprometer diretamente seu desempenho, e a ausência de espaço pode inviabilizar a execução de queries e até causar corrupção da base de dados.

Para a Base de Dados: A unidade que contém a base de dados precisa de um espaço considerável para que o Firebird possa efetuar suas manipulações de forma eficiente.

- Dimensionamento do Drive para o Banco de Dados: O tamanho da unidade que hospeda o banco de dados deve ser de, no mínimo, 400% do tamanho atual do banco de dados, considerando a projeção de crescimento futuro. Outros fatores também devem ser considerados no dimensionamento.

- Vida Útil de SSDs de Consumo: Se estiver utilizando SSDs que não são de nível corporativo (enterprise), considere substituí-los após 2 anos de uso efetivo. SSDs de consumo possuem um limite de ciclos de gravação que pode levar a falhas após esse período.

- Controladoras de Disco com Cache: Utilize controladoras de disco que possuam cache embutido. Isso melhora significativamente o desempenho de I/O.

 (fonte: http://www.firebase.com.br/fb/artigo.php?id=2718)

- Monitoramento do Subsistema de Disco: Verifique regularmente o subsistema de disco em busca de setores defeituosos (bad blocks) e outros problemas de hardware (incluindo superaquecimento). Problemas de hardware podem diminuir drasticamente o desempenho de I/O e levar a corrupções de banco de dados.

- Verificação do Tamanho do Cluster: Para verificar o tamanho do cluster (tamanho da unidade de alocação) de uma unidade, utilize o comando chkdsk no Prompt de Comando. Acesse o CMD como administrador e execute, por exemplo: "chkdsk c:"

- Sinais de Falha Iminente do Disco: Fique atento a sinais de falha do disco, como blocos defeituosos, superaquecimento, ruídos incomuns, lentidão excessiva. Sempre verifique os dados S.M.A.R.T (Self-Monitoring, Analysis and Reporting Technology) do disco para monitorar sua saúde.

RAID

O acesso ao disco é um dos principais fatores limitantes no desempenho de um servidor, especialmente sob alta carga de trabalho, onde escritas intensas podem causar muitos deslocamentos da cabeça de leitura/gravação. A escolha e configuração corretas do RAID (Redundant Array of Independent Disks) são cruciais.

- Sugestões de Configuração de RAID por Tipo de Disco:

Para SSDs: Recomendamos RAID 1. Este nível oferece espelhamento completo dos dados, garantindo alta disponibilidade e boa performance de leitura, aproveitando a velocidade inerente dos SSDs.

Para HDDs (SAS, SATA, nSAS): Para ambientes com alta demanda de I/O, o RAID 10 é a escolha ideal. Ele combina o espelhamento do RAID 1 com o striping do RAID 0, oferecendo excelente desempenho e redundância.

Para Discos de Backup (HDDs): O RAID 1 é suficiente para discos dedicados a backups, fornecendo redundância simples e eficaz.

- Vantagens do RAID 10: Se você optar pelo RAID 10, notará que ele é 15-25% mais rápido que configurações como RAID 1 ou RAID 5, tornando-o superior para cargas de trabalho que exigem alta performance de I/O.

- Problemas Comuns de I/O e Como Evitá-los:

Ausência de Bateria no Controlador RAID (BBU): É vital verificar se o seu controlador RAID possui uma Bateria de Backup (BBU) instalada e operacional. Alguns fabricantes não incluem a BBU por padrão. Sem uma BBU, o controlador desativa o cache de escrita, fazendo com que o RAID opere muito lentamente, por vezes até mais devagar que unidades SATA comuns, devido à perda da eficiência do cache.

Drives Inadequados ou Genéricos: Utilize drives específicos para uso em RAID ou servidores (enterprise-grade). Drives de consumo ou genéricos não são projetados para o rigor e a demanda de um ambiente de servidor e podem causar degradação de desempenho e falhas.

Configuração de Cache Incorreta (Write-back): Com uma BBU instalada e o servidor protegido por um UPS (No-Break), certifique-se de que o cache da sua controladora RAID está configurado para "write-back", e não "write-through". O modo "write-back" permite que o controlador faça o cache das operações de escrita, otimizando o desempenho.

** Cache de Leitura Desativado:** Verifique se o cache de leitura da sua controladora está ativo. Um cache de leitura desativado pode impactar negativamente a performance de leitura dos dados.

Ambientes Virtuais (VMware, Xen, Hyper-V): Em ambientes virtualizados, a banda de I/O pode ser significativamente limitada. Isso, combinado com a complexidade da virtualização, pode aumentar o risco de corrupção em um dos discos de um arranjo RAID (RAID 1/5/10, etc.). Monitore cuidadosamente o I/O em VMs.

Configuração RAID Incorreta: Erros na configuração inicial do RAID podem levar a desempenho subótimo ou perda de dados. Sempre siga as melhores práticas e a documentação do fabricante da controladora.

Memória RAM

A memória RAM é um componente crítico para o desempenho e a estabilidade do servidor, especialmente para aplicações como bancos de dados.

- Cálculo da Quantidade de RAM: A quantidade de RAM deve ser calculada de forma precisa para atender às necessidades do sistema e das aplicações. Reserve pelo menos 40% da RAM para o cache do Windows e 30% para o cache do Linux. Esse espaço é fundamental para o desempenho do sistema operacional.

- Estimativa de RAM para Firebird SuperServer: Embora muitos fatores devam ser considerados, uma estimativa básica para o Firebird SuperServer (versões 3.0 e 4.0) pode ser feita com a seguinte fórmula:

 (Número de páginas no cache * Tamanho da página) + Classificação do tamanho do cache

 Exemplo para um cenário com Firebird SuperServer:
   1 banco de dados, 100 usuários
   Tamanho da página do banco de dados: 8 KB
   Número de páginas no cache de página: 100.000
   Tamanho do cache de classificação: 1024 MB
(100000 * 8 KB) + 1024 = 1805 MB

Portanto, neste exemplo, seria necessário aproximadamente 1805 MB de RAM apenas para essas operações do Firebird.

- RAM com Código de Correção de Erros (ECC RAM): É altamente recomendável utilizar módulos de memória ECC RAM (Error-Correcting Code RAM) em sistemas profissionais. A ECC RAM reduz significativamente o número de erros que podem ocorrer durante o processamento de dados na memória, contribuindo para a integridade dos dados e a estabilidade do sistema.

- Monitoramento do Consumo de Memória no Windows: O Gerenciador de Tarefas do Windows pode exibir a memória usada para cache como "memória livre", o que pode ser enganoso. Para uma visualização mais precisa do consumo real de memória, incluindo o uso de cache, utilize a ferramenta RAMMap*.

 (Fontes: http://ib-aid.com/en/articles/firebird-hardware-guide/ | http://www.firebase.com.br/artigo.php?id=3098)

Interface de rede

A configuração da interface de rede é um fator crucial para o desempenho geral do servidor, especialmente em ambientes virtualizados e com alta demanda de tráfego.

- Evite o "GAS Tecnologia Filter Driver" em Servidores: A GAS Tecnologia fornece o plugin G-Buster, amplamente utilizado por bancos para proteger transações financeiras. No entanto, esse tipo de software atua varrendo o tráfego de rede, o que impõe um custo alto de desempenho. O tráfego de rede pode ficar significativamente mais lento. Além disso, há relatos de versões incompatíveis com algumas atualizações do Windows, resultando em consumo excessivo de CPU. Em casos mais graves, malware pode se infiltrar nesse arquivo, agravando ainda mais o problema. A orientação é não utilizar esse tipo de software em servidores de produção. Eles tendem a causar mais problemas do que benefícios em um ambiente de servidor.

 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2503)

- Em ambientes com alto volume de tráfego de rede, é fundamental que você monitore de perto o uso das interfaces. Redes sobrecarregadas podem se tornar um grande gargalo para o desempenho das suas aplicações, mesmo que o restante do hardware do servidor esteja completamente otimizado.

- Mesclagem Virtual de Interfaces de Rede (NIC Teaming/Bonding): Se o seu servidor dispõe de múltiplas interfaces de rede físicas, você pode configurar uma mesclagem virtual (NIC Teaming no Windows ou Network Bonding no Linux). Essa técnica permite que você combine a largura de banda de várias interfaces físicas em uma única interface lógica. Isso não apenas aumenta o throughput total disponível, mas também pode oferecer redundância em caso de falha de uma das interfaces físicas, coibindo problemas de gargalo e aumentando a disponibilidade da rede.

Máquinas virtuais

Embora as Máquinas Virtuais (VMs) ofereçam benefícios inegáveis como flexibilidade, escalabilidade, consolidação de hardware e otimização de custos, é preciso cautela. Em ambientes com alta demanda de processamento (CPU) ou, principalmente, alta demanda de I/O (entrada e saída de dados), máquinas físicas dedicadas ainda são, em muitos casos, a melhor opção para garantir o desempenho ideal e até mesmo a única viável. Para cargas de trabalho que são extremamente sensíveis à latência, exigem throughput máximo de I/O, ou consomem intensivamente todos os recursos da CPU de forma contínua, a máquina física dedicada ainda é a escolha superior e mais segura em termos de desempenho e previsibilidade. A decisão de usar uma VM ou uma máquina física deve ser baseada em uma análise cuidadosa dos requisitos de workload.

- Cuidado com o Overcommit (superalocação) de recursos é uma prática comum em virtualização que permite configurar máquinas virtuais (VMs) para utilizar mais recursos (memória, CPU, armazenamento, interface de rede) do que o fisicamente disponível no servidor host. Embora útil para otimizar o uso de hardware, ela exige atenção especial, principalmente em ambientes de alta performance. Por exemplo, em momentos de pico de uso de memória, o sistema operacional será forçado a recorrer ao swap (troca de dados entre RAM e disco). A leitura e escrita em disco, em comparação com a RAM, é extremamente lenta, resultando em uma grande degradação de performance.

- Operações de entrada e saída de dados (I/O) são um gargalo frequente e significativo em ambientes virtualizados. A própria camada de virtualização introduz uma sobrecarga que pode levar a latência e throughput (vazão) reduzidos, impactando diretamente o desempenho de aplicações sensíveis ao I/O, como bancos de dados, sistemas transacionais ou soluções de armazenamento massivo. É importante notar que, máquinas virtuais são geralmente criadas com limites muito baixos de CPU e I/O. Por exemplo, não é incomum encontrar configurações que impõem limites de apenas 50 IOPS ou 10% de uso da CPU, especialmente em VMs de uso geral de provedores de nuvem como o Azure.

- Concorrência entre VMs e Contenção de Recursos: Quando várias VMs competem pelos mesmos recursos físicos (CPU, memória, I/O de disco, rede) no mesmo host, pode ocorrer uma "briga" por esses recursos, levando à degradação do desempenho de uma ou mais VMs (fenômeno conhecido como "noisy neighbor"). Ao trabalhar com VMs, a configuração das interfaces de rede exige atenção especial. É muito comum que múltiplas VMs compartilhem a mesma interface de rede física, o que pode rapidamente gerar gargalos de desempenho e dificultar a identificação da origem dos problemas. Para evitar essa situação, a recomendação é clara: sempre que possível, dedique interfaces de rede exclusivas para VMs com alta demanda de tráfego, ou configure suas interfaces virtuais de forma estratégica para distribuir a carga e prevenir sobrecarga. Isso garante que suas VMs críticas tenham a largura de banda necessária para operar sem gargalos.

- É crucial entender que máquinas virtuais (VMs) inerentemente oferecem um desempenho inferior quando comparadas a um servidor físico equivalente. Se o seu objetivo principal é alcançar o melhor desempenho possível, a recomendação é evitar a virtualização e optar por um servidor físico. Caso a virtualização seja uma necessidade para o seu ambiente, é fundamental que a VM não seja executada "sobre" um sistema operacional convencional (como instalar um VMware Workstation no Windows e depois uma VM). Em vez disso, a VM deve ser instalada diretamente no hypervisor (o host da máquina), que é um sistema operacional leve e otimizado para gerenciar a virtualização, como VMware ESXi, Proxmox, Hyper-V Server (versão bare-metal) ou KVM no Linux. Isso minimiza a sobrecarga e maximiza o desempenho disponível para as suas VMs.

Firebird

Importante acompanhar as informações e os recursos disponibilizados pela Firebase, que é parceira brasileira da Firebird Foundation. Seus artigos e publicações são uma fonte valiosa de conhecimento técnico. Com aqui sugerido para esse assunto:

 https://www.firebase.com.br/artigo.php?id=3041

Instalação

- Sistema Operacional: para Instalação preferencialmente Linux, que geralmente oferece uma taxa de I/O superior em comparação com outros sistemas operacionais, o que beneficia diretamente o desempenho do Firebird. Windows Server (ex: Windows Server 2019) Uma opção robusta, mas que exige atenção às configurações de I/O e memória.

- Arquitetura (Firebird 3.0+): SuperServer é a mais indicada para garantir melhor escalabilidade. Evite usar a arquitetura Classic como um serviço no Windows, pois ela pode limitar o número de conexões aceitas (tipicamente entre 250-300) e levar a estouros de memória do heap.

- Firebird 2.5: Se você ainda usa Classic ou SuperClassic, considere a migração para o Firebird 3+ SuperServer. Essa versão agora pode utilizar múltiplos núcleos de CPU e combina essa capacidade com as vantagens do cache compartilhado, resultando em um desempenho superior.

- Não instale a arquitetura Classic em servidores com pouca memória disponível ou em sistemas de 32 bits.

 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2308)

- Não instale SuperClassic em sistemas operacionais de 32 bits.

 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2513)

- Utilize a Versão 64 bits em Servidores 64 bits: Quando seu servidor for de 64 bits, instale a versão 64 bits do Firebird. A versão de 32 bits tem um limite de uso de memória de 3GB e, ao atingir esse limite, passa a recusar novas conexões, comprometendo a disponibilidade do sistema.

- Não use Windows XP ou Windows 7 como servidores Firebird. Esses sistemas têm um limite de 10 conexões de rede simultâneas, o que inviabiliza seu uso em ambientes de produção.

 (Fonte: http://mail.firebase.com.br/pipermail/lista_firebase.com.br/2012-August/078364.html)

- Evite instalar o Firebird em ambientes virtualizados (VMware, Xen, Hyper-V) se o objetivo principal for obter o melhor desempenho possível. VMs podem perder de 20% a 80% da sua velocidade em comparação com um servidor físico, principalmente devido à banda de I/O reduzida.

- Nunca instale o Firebird em um Primary Domain Controller (PDC). PDCs desativam o cache de gravação no disco rígido, o que aumenta drasticamente o risco de perda e corrupção de dados. Além disso, a performance de gravação será significativamente prejudicada.

 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2716)

Configurações

- Autenticação SRP: Não utilize a autenticação SRP no Firebird 3 se ela não for estritamente necessária. Conectar com autenticação SRP é inerentemente mais lento do que uma conexão regular.

- Firebird Classic no Windows: "Permitir que o serviço interaja com a área de trabalho": Se você usa o Firebird Classic no Windows, é crucial habilitar o flag "Permitir que o serviço interaja com a área de trabalho". Sem essa configuração, o desktop heap é limitado pelo Windows, e o Firebird não conseguirá abrir mais do que 250-300 conexões, levando a problemas de conectividade.

- Compressão de Tráfego (WireCompression): Em redes com alta latência, ative a compressão de tráfego configurando o parâmetro WireCompression no arquivo firebird.conf. Isso pode ajudar a reduzir o volume de dados transmitidos e melhorar a resposta.

 (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

Versões de DLL

Manter a compatibilidade das versões das DLLs (Dynamic Link Libraries) do Firebird é crucial para o funcionamento correto, compativiel e eficiente da sua aplicação. Os clientes do SGBD (Sistema Gerenciador de Banco de Dados), deve utilizar as library nGDS32.dll e FBClient.dll na mesma versão.

- A presidência de uso das library são as pastas:

Na pasta dos executáveis da sua aplicação.

Nas pastas do sistema: System32 e, para sistemas 64-bit, também SysWOW64.

- Versão do Servidor Firebird: Para confirmar a versão exata do Firebird instalada no seu servidor, você pode usar as seguintes ferramentas:

TekMonitor: Navegue até a opção "Gerenciador de base de dados" e então para a aba "Informações". Lá você encontrará os detalhes da versão.

IBExpert: No menu, acesse Services > Server Properties/Log. Selecione o servidor desejado e execute. Procure pela propriedade "Server Version" no log.

 Exemplo: Um valor como "Server Version: WI-V2.5.1.26351 Firebird 2.5" indica que o servidor está executando a versão 2.5 do Firebird.

Tuning (Customizações) Firebird.conf e databases.conf

 ** ATENÇÃO **: Não existe uma "receita de bolo" universal para o tuning do Firebird. Cada ambiente e aplicação possui comportamentos distintos. O ajuste fino deve ser feito com base em análises, monitoramento contínuo e uma compreensão clara das necessidades e comportamento do seu sistema. Cuidado! Valores incorretos ou inválidos podem levar a piora de performance, problemas de consistência e até à corrupção da base de dados.

Um excelente ponto de partida para explorar configurações do firebird.conf e databases.conf é a ferramenta de cálculo da IB-Aid: https://cc.ib-aid.com/democalc.html.

As orientações a seguir são para situações específicas e não consideram todas as adversidades dos diversos cenários.

Otimização de Memória e Cache

- TempCacheLimit (Tamanho do Cache Temporário para Ordenação): Este parâmetro controla a quantidade máxima de espaço temporário que pode ser armazenada na memória para operações de ordenação. Os valores padrão são geralmente muito baixos (8MB para Classic e 64MB para SuperServer). Um TempCacheLimit pequeno forçará o Firebird a ordenar dados em disco em vez de na memória, o que degradará o desempenho.

 Sugestão:
   Classic use 64MB a 128MB, para 
   SuperServer e SuperClassic use 364MB a 1GB.

- DefaultDbCachePages (Cache de Buffers de Página): Define o número de páginas que podem ser mantidas em cache na memória para qualquer banco de dados. Um valor de 10.000 páginas, com tamanho de página de 16KB, representa aproximadamente 160MB de cache (16KB x 10.000 ≈ 160MB).

 Sugestão:
   Firebird 2.5 SuperServer: Altere de "2048" para 10.000 páginas.
   Firebird 3.0+ SuperServer: Altere para 50.000 páginas.

- FileSystemCacheThreshold: Se aumentar muito o DefaultDbCachePages, pode ocorrer um "duplo cache", pois o sistema operacional (SO) também realiza cache de arquivos. Para evitar essa redundância e garantir que o cache do SO seja utilizado de forma eficiente, especialmente em 99% dos casos onde é benéfico, siga esta regra:

Regra: Configure DefaultDbCachePages = X e FileSystemCacheThreshold = X + N, onde N > 1.

Se FileSystemCacheThreshold for 0, o cache do sistema de arquivos do SO será desativado. Se for menor que DefaultDbCachePages ou o número de page buffers, o cache do SO não será usado, levando a problemas de desempenho.

(Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- FileSystemCacheSize (Windows): Esta configuração controla a quantidade máxima de memória RAM usada pelo cache do sistema de arquivos do Windows. Se dedicado utiliza 80 % se não 50%.

Gestão de Espaço Temporário

O armazenamento temporário é usado pelo módulo de ordenação e para dados temporários gerados pelo SGBD.

- TempBlockSize: Este parâmetro define o tamanho dos blocos de dados temporários.

 Sugestão:
   Firebird 2.5: Altere de "1048576" para "2048576".
   Firebird 3.0+: Altere de 1MB para 2MB.
 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2680)

====Gerenciamento de Bloqueios==== (Lock Manager) Se você notar quedas de desempenho no meio do dia, possivelmente relacionadas a uma fila de bloqueios muito grande, ajuste os seguintes parâmetros:

- LockMemSize (Memória Alocada para o Gerenciador de Bloqueio): Define a quantidade de memória compartilhada alocada para o gerenciador de bloqueio.

 Sugestão:
   Firebird 2.5: Altere de "1048576" para "10485760" (10MB).
   Firebird 3.0+: Altere de 1MB para 9MB.
 (Fontes: http://www.firebase.com.br/fb/artigo.php?id=222#Lock_Mem_Size | https://www.firebase.com.br/artigo.php?id=3098)

- LockHashSlots: Controla o número de slots na tabela hash do gerenciador de bloqueio.

 Sugestão:
   Firebird 2.5: Altere de "1009" para "10091".
   Firebird 3.0+: Altere de "8191" para "30011" (deve ser um número primo).
 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=222#Lock_Hash_Slots)

Gerenciamento de Lixo (Garbage Collection / Sweep)

Problemas com o Garbage Collection (GC) podem afetar o desempenho. Para identificar e monitorar:

- Identificação de Problemas: Verifique se o valor de "Oldest snapshot" menos "Oldest Transaction" (Oldest snapshot - Oldest Transaction) é maior que o Sweep interval (o padrão é 20000). Se for, há um problema.

- Ferramentas de Monitoramento: Utilize ferramentas como IBMonitoramento ou FBScanner para identificar onde, quando e quem está causando os problemas no GC.

Problemas com Discos Lentos ou Pouco Espaço

Se o disco onde o Firebird está instalado for lento ou tiver pouco espaço, você pode redirecionar o uso da pasta temporária:

- TempDirectories: Defina este parâmetro para uma unidade de disco com maior taxa de gravação/leitura ou mais espaço disponível, por exemplo: TempDirectories = "d:\temp". A pasta temporária é usada para operações cruciais como o cache de ordenação de resultados SQL (ORDER BY).

- Espaço Temporário em Unidades Rápidas: Para operações que exigem uso intensivo de espaço temporário (como grandes ordenações, restaurações de banco de dados, etc.), defina o TempDirectory para uma unidade SSD ou uma RAM rápida (RAMDisk). Isso diminuirá significativamente o tempo de execução dessas operações.

Propriedades da Base de Dados

As propriedades especificas do arquivo de dados do Firebird.

- SQL Dialect: 3, Este é o dialeto SQL recomendado para as versões mais recentes do Firebird e deve ser a escolha padrão para novas bases de dados.

- ODS Version (On-Disk Structure): A ODS representa a versão do formato do arquivo da base de dados, indicando compatibilidade com versões específicas do Firebird.

 ODS 11.2: Firebird 2.5
 ODS 12.0: Firebird 3.x
 ODS 13.0: Firebird 4.x
 ODS 13.1: Firebird 5.x

- Sweep Interval (Intervalo de Varredura): Este valor define um limite para a diferença entre a Transação Snapshot Mais Antiga (OST - Oldest Snapshot Transaction) e a Transação Interessante Mais Antiga (OIT - Oldest Interesting Transaction). Uma operação de sweep (varredura de lixo) será acionada quando a diferença entre OST e OIT exceder o Sweep Interval. Isso não significa que uma varredura ocorrerá a cada 20.000 transações, mas sim quando a "idade" das transações ativas e visíveis atingir esse limite. O padrão para uma nova base de dados é 20.000, se houver necessidade de ajustar esse valor, não o amplie para mais de 60.000. Nunca desative o sweep automático, pois isso exigiria a execução manual e constante, o que é inviável em produção. A não execução regular do sweep ou a sua desativação leva a uma degradação exponencial de performance à medida que a base de dados acumula lixo de transações.

- Read Only (Somente Leitura): Por padrão, esta opção deve estar desmarcada para bases de dados em uso normal. A configuração "Read Only" é utilizada apenas em sistemas embarcados ou cenários específicos onde a base de dados não deve sofrer alterações.

- Forced Write (Gravações Forçadas): O Firebird, por padrão, é instalado com as gravações forçadas (gravações síncronas) habilitadas. Isso significa que dados alterados e novos são gravados no disco imediatamente após a postagem. É possível configurar uma base de dados para usar gravações de dados assíncronas (Forced Writes desabilitado), onde os dados são mantidos em cache na memória para serem liberados periodicamente no disco pelo subsistema de I/O do sistema operacional. Embora isso possa melhorar o desempenho durante grandes operações em lote, há um AVISO CRÍTICO: Não desative as gravações forçadas! Em caso de interrupção de energia, finalização forçada do serviço ou travamento do sistema, a desativação das gravações forçadas pode resultar em perda de dados e, possivelmente, em corrupção da integridade relacional da sua base de dados. Obrigatório: Mantenha esta configuração como True (gravações forçadas habilitadas).

- Page Size: O tamanho da página define o bloco fundamental de dados que o Firebird lê e escreve no disco. Tamanhos Padrão de Página por Versão do Firebird:

 1.0: 1024 bytes
 2.5: 4096 bytes
 3.0/4.0/5.0: 8192 bytes

Tamanho Máximo da Página:

 Firebird 3.x: 16KB
 Firebird 4.x e 5.x: 32KB

Consideração com o Tamanho do Cluster do Disco: Idealmente, o tamanho da página do banco de dados deve ser o mesmo que o tamanho do cluster (unidade de alocação) do disco onde a base está armazenada. Isso cria uma relação de 1:1, otimizando o acesso ao disco. Para verificar o tamanho do cluster no Windows, abra o CMD como administrador e execute: chkdsk c: (substitua c: pela letra da unidade do seu disco).

Fatores Determinantes para o Page Size Ideal: O tamanho ideal da página varia significativamente e depende de múltiplos fatores, como:

 Tipo de hardware.
 Sistema operacional.
 Perfil e volume de dados armazenados.
 Profundidade dos índices.
 Tamanho dos registros.

Benefícios de um Page Size Maior (Ex: 16KB para DBs > 100GB): Para bancos de dados com mais de 100GB, em 95% dos casos, é benéfico usar o maior tamanho de página disponível (ex: 16KB). Isso proporciona:

Diminuição da Profundidade dos Índices: Índices com profundidade menor ou igual a 3 são recomendados. Índices com profundidade 4 ou 5 serão consideravelmente mais lentos.

Aumento da Utilização da RAM: O cache do Firebird é especificado em páginas. Um cache de 1.000 páginas com tamanho de página de 8KB consome 8MB de RAM, enquanto com 16KB consome 16MB, otimizando o uso da memória.

Redução do Número de Páginas do Sistema: Isso agiliza o acesso a registros em tabelas grandes (menos saltos de ponteiro) e auxilia na preparação de consultas SQL complexas.

Como Alterar: Para aumentar o tamanho da página de um banco de dados existente, a base deve ser copiada com a ferramenta gbak e, em seguida, restaurada com o parâmetro --page:

gbak -c -page 16384 <origem.fdb> <destino.fdb>

Observação sobre BLOBs: Se você possui um banco de dados com muitos BLOBs pequenos, aumentar o tamanho da página pode tanto diminuir quanto aumentar a fragmentação, sendo difícil prever o impacto no desempenho.

Atenção Crítica: Qualquer alteração no tamanho das páginas implica diretamente na necessidade de revisão e ajuste das configurações de cache no firebird.conf e databases.conf.

Backup

Realizar backups de forma eficiente e segura é vital para a recuperação de dados e a continuidade dos negócios. Para o Firebird, o uso correto de suas ferramentas e práticas podem otimizar significativamente esse processo.

- Otimizando gbak para Velocidade:

Utilize switches específicos no gbak para aumentar a velocidade do backup/restauração em até 20%. Por exemplo:

 gbak -b -g -se service_mgr c:\db\data.fdb e:\backup\data.fbk

O switch -g suprime a coleta de lixo durante o backup, o que pode acelerar o processo.

Evite o switch -v (verificar) durante o backup, pois ele adiciona sobrecarga e reduz o desempenho. Utilize-o apenas quando a verificação for estritamente necessária após o backup.

- Backup/Restauração em um Único Passo (Pipe): Para maior agilidade e economia de espaço temporário, você pode encadear as operações de backup e restauração usando um pipe:

 gbak -b c:\BD.fdb stdout | gbak -c stdin c:\BD2.fdb

Isso realiza o backup e a restauração simultaneamente, sem a necessidade de um arquivo intermediário no disco.

- Escolha do Disco para Backups:

Como as operações de gravação durante o backup são sequenciais, discos rígidos (HDDs) SATA comuns e de baixo custo podem ser eficientes para armazenar backups, pois se destacam em escritas sequenciais.

Utilize uma unidade rápida (SSD ou RAMDisk) para o espaço temporário do SGBD durante a restauração. Isso reduzirá drasticamente o tempo necessário para grandes ordenações e outras operações que ocorrem quando o banco de dados está sendo restaurado.

- Backups "Quentes" em Produção: Para realizar backups enquanto o sistema está em plena atividade (hot backups), recomenda-se a utilização do N-Backup. Ele permite backups incrementais e diferenciais sem interrupções significativas na operação.

- Gerenciamento e Monitoramento de Espaço:

Mantenha-se atento à disponibilidade de espaço em disco, considerando o número de cópias de backup que você pretende reter permanentemente e a projeção de crescimento da base de dados.

Monitore regularmente o espaço de armazenamento dos backups.

- Testes Periódicos de Recuperação: É crucial e obrigatório realizar testes periódicos das suas cópias de backup. Isso inclui verificar:

A possibilidade de restaurar os dados com sucesso.

O tempo necessário para a restauração completa.

A consistência dos dados após a restauração. Testes falhos indicam que seu plano de recuperação não é eficaz.

- Estratégia de Armazenamento de Cópias:

Evite armazenar cópias de backup na mesma máquina ou em dispositivos diretamente conectados ao servidor de produção (como HDs externos USB). Esses locais são altamente suscetíveis a danos junto com o servidor, roubos ou ataques de ransomware, comprometendo a sua capacidade de recuperação.

Implemente uma estratégia de armazenamento remoto ou em nuvem para suas cópias de backup, seguindo a regra 3-2-1 (3 cópias, em 2 mídias diferentes, 1 cópia fora do local).

Manutenção

- Gerenciamento de Arquivos Temporários do Firebird O Firebird gera diversos arquivos temporários para operações internas como ordenação, processamento de BLOBs, tracing, entre outras. Esses arquivos são armazenados nos seguintes locais padrão:

 No Windows: C:\ProgramData\firebird
 No Linux: /tmp/firebird

Embora esses arquivos sejam normalmente removidos de forma automática, há situações em que isso não ocorre (por exemplo, após um desligamento inesperado do servidor). Por isso, é fundamental verificar esses diretórios periodicamente e apagar os arquivos antigos. Essa prática simples pode liberar vários gigabytes de espaço no disco do sistema, que poderiam estar sendo desperdiçados.

- Reinício Periódico do Servidor: Essa prática ajuda a limpar a memória, encerrar processos "órfãos" e aplicar atualizações pendentes do sistema operacional, contribuindo para a estabilidade e o desempenho geral do ambiente.

Avançado

- Acelere o banco de dados de segurança: Aumente o buffers do security”n”.fdb (o valor empírico máximo é 256); Mova o security”n”.fdb para o drive mais rápido do sistema (a operação é trivial no Firebird 3, mas no Firebird 2.5 exigirá uma reinstalação do Firebird no disco especificado) (Fonte: https://www.firebase.com.br/artigo.php?id=3098)

- Diminuir a profundidade dos índices depth, deve ser <=3. Depth >= 4 terão uma performance muito ruim. Uma forma de realizar é aumentar o tamanho das páginas.

- Diminuir o número de páginas na base: Aumentará a performance de acesso a registros de tabelas enormes (menos “pulos” entre páginas de ponteiros e de dados), e ajuda na preparação de comandos SQLs extensos.

- Aumentar o consumo de RAM: O cache do Firebird é configurado em número de páginas, 1.000 páginas de cache, em uma base com páginas de 8K, significa o uso de 8MB de memória, e 16MB com páginas de 16K.

- LINGER: Permite manter o cache “quente”, mesmo após a desconexão do último usuário. Exemplo para manterá o cache por 60 segundos após o término da última conexão:

 ALTER DATABASE SET LINGER TO 60

gfix -nolinger (fecha imediatamente a base após o último attachment ser encerrado)

-Não use o recurso “no_reserve”. O flag “no_reserve”, quando ativo, faz com que o Firebird deixe de reservar 30% de espaço nas páginas de dados para armazenar versões temporárias de registros, que são criadas após um update ou um delete. Esse flag permite que os dados sejam armazenados de forma mais compacta (diminuindo o tamanho do arquivo da base de dados), mas no caso de um UPDATE/DELETE, todas as mudanças ocorrerão em uma nova página de dados, fazendo com que essas operações se tornem mais lentas. Sendo assim, só ligue esse flag se sua base de dados for ReadOnly (somente leitura). Verifique se o flag está ativo usando o gstat –h base_de_dados e verificando a linha “Attributes”. Desligue o flag com o comando: gfix -use reserve database Depois desse comando, novas páginas de dados serão criadas com espaço reservado. No entanto, para se beneficiar completamente da mudança, é necessário fazer um backup/restore da base de dados com o gbak, para que todas as páginas sejam criadas com reserva de espaço. Obviamente, o tamanho da base de dados irá aumentar após remover o flag no_reserve e fazer o backup/restore.

- Ao commitar, se está com tempo total de teste contém mais de 20% do commit, isso significa que pode haver um problema com o cache de gravação.

SQL lentas em uma base de dados em específico

- Verificar sem todos os INDEX estão ativos. Índice não ativado é um índice que deveria ser habilitado durante o processo de restauração do gbak mas não foi devido alguma falha. Para verificar a existência de índice inativo

 SELECT count(*) FROM RDB$INDICES WHERE RDB$INDEX_INACTIVE<>0;

RDB$INDEX_INACTIVE: 0 - Ativo; 1 - Inativo; 2 - Não Ativo

- Recalcule estatísticas de índices regularmente. Atualizar estatísticas de índices para as tabelas com mudanças frequentes ou maciças com o comando SET STATISTICS, permite que o otimizador Firebird escolha melhores planos SQL. A seletividade dos índices é calculada como 1 dividido pelo número de valores únicos na coluna indexada (ou colunas). Por exemplo, se este for um índice em uma chave primária, e houver 10 mil registros na tabela, então sua seletividade será igual a 1 / 10000 = 0,0001. E se a mesma tabela tiver uma coluna com 10 valores diferentes, então o índice nesta coluna terá uma seletividade de 1/ 10 = 0,1. Para o otimizador, quanto menor a seletividade do índice, melhor. Para atualizar deve executar o comando para cada indice

 SET STATISTICS INDEX xxxxx;

Mas nas bases de dados da Tek-System já conta com o procedure RECALCULA_INDEX que realiza o recalculo de todos, também possível agendar pelo TekAgendador.

- Verificar se há atraso de transações: necessidade de GC e Sweep, (transações antiga e não comitadas, ...), pode haver algum sistema não liberando transações, GC acima de 100000 já começa a ser notório acima de 400000 de difícil trabalho.

- Verificar se a base de dados está corrompido com Validation (Validate Database e Validate Full), necessário uso exclusivo da base.

- Efetuar Backup/Restaure (corrige certos erros, retorna o contador de multformat, reorganiza as páginas no disco etc..).

Principais Causas de Corrupção em Bancos de Dados

A corrupção de um banco de dados é um problema crítico que pode levar à perda de dados e interrupção dos serviços. Compreender as principais causas é o primeiro passo para preveni-las.

- Problemas de Energia: Quedas de energia e desligamentos bruscos do servidor são as causas mais comuns. Sem um No-Break (UPS) e configurações de write-back seguras no RAID (com BBU), qualquer interrupção abrupta pode corromper a base de dados.

- Instabilidade de Rede: Oscilações e intermitências na rede podem causar falhas de comunicação durante transações, levando à inconsistência dos dados.

- Incompatibilidade de DLLs: O uso de DLLs (fbclient.dll e gds32.dll) com versões diferentes das que estão no servidor Firebird é uma fonte comum de corrupção. Verifique essas DLLs nas pastas do executável da aplicação, System32 e SysWOW64 (em sistemas 64-bit).

 (Fonte: http://www.firebase.com.br/fb/artigo.php?id=2284)

- Falta de Espaço em Disco: Espaço insuficiente na unidade onde a base de dados está localizada (deve haver no mínimo 1GB disponível). Ou falta de espaço na unidade de arquivos temporários do Firebird (por padrão, é a mesma unidade da instalação, a menos que seja alterada no firebird.conf). Ambas as situações podem impedir operações críticas e causar corrupção.

- Configurações Incorretas do Firebird/Base de Dados: Propriedades indevidas da base de dados, como desativar o Forced Write (escrita forçada), aumentam drasticamente o risco de corrupção em caso de falha. Configurações incorretas no firebird.conf também podem desestabilizar o sistema. Revise as seções anteriores sobre as propriedades do BD e o tuning do Firebird.

 (Fonte: http://www.sinatica.com/blog/en/index.php/2008/08/forced-writes-firebird-database-corruption)

- Problemas de Hardware: Discos rígidos com setores defeituosos são uma causa primária. Problemas em controladoras de disco, cabeamento de rede defeituoso ou instalações elétricas instáveis também podem levar à corrupção. Problemas na memória RAM (falhas ou erros) podem introduzir dados incorretos no banco de dados.

- Uso Inadequado de RAID: Configurações de RAID inadequadas ou com falhas (como a ausência de BBU em controladoras com cache de escrita) podem comprometer a integridade dos dados. Consulte a seção de RAID para mais detalhes.

- Sistemas Operacionais Inseguros ou Não Recomendados: Utilizar sistemas operacionais antigos ou pouco seguros (ex: Windows 9x, ME e XP) expõe o banco de dados a vulnerabilidades e instabilidades.

 (Fontes Adicionais: http://www.firebase.com.br/fb/artigo.php?id=48 | https://ib-aid.com/articles/firebird-and-interbase-corruptions-reasons/)

Parceiros do Firebird

Para obter informações valiosas, consultoria especializada e ferramentas que otimizem seu trabalho com Firebird, é fundamental conhecer e utilizar os recursos oferecidos pelos principais parceiros da comunidade:

 IBSurgeon: Uma referência global em ferramentas de otimização, recuperação e análise para Firebird.
 www.firebirdsql.org/en/ibsurgeon

 Firebase Brasil: O parceiro oficial da Firebird Foundation no Brasil, oferecendo uma vasta gama de artigos, suporte e soluções para a comunidade brasileira.
 www.firebirdsql.org/en/firebase-brazil

 mqFS de Edson Gregorio
 https://mqfs.com.br/

Antivírus

A presença de um antivírus em um servidor é crucial para a segurança, mas sua configuração inadequada pode comprometer seriamente o desempenho. É vital balancear proteção com otimização.

- Exclua Bases de Dados e Arquivos Temporários da Varredura: Certifique-se de que o antivírus não esteja escaneando ativamente os diretórios que contêm suas bases de dados e os arquivos temporários gerados pelo Firebird (no Windows, tipicamente em C:\ProgramData\Firebird; no Linux, em /tmp/firebird). A varredura constante desses arquivos pode causar gargalos severos de I/O, impactando diretamente a performance do banco de dados.

- Evite o Kaspersky Server em Ambientes Críticos: Não recomendamos o uso do Kaspersky Server em servidores que hospedam bancos de dados ou aplicações de alta performance. Este antivírus é conhecido por seu alto consumo de recursos de rede e processador. Além disso, por utilizar o SQL Server como seu próprio SGBD interno, ele compete diretamente por recursos de disco e processamento com o seu sistema de banco de dados principal, mesmo que a prioridade seja ajustada.

- Adicione Pastas Críticas às Exceções: Sempre adicione a pasta da Tek-System e quaisquer outros diretórios de aplicações críticas às exceções do antivírus. Isso evita que o antivírus interfira no funcionamento normal dos softwares e minimize a sobrecarga.

- Agende Varreduras para Horários de Baixo Tráfego: Configure o antivírus para não realizar varreduras completas durante o horário de expediente ou períodos de pico de uso. Agende essas varreduras intensivas para momentos de baixo tráfego, como de madrugada ou nos fins de semana, a fim de minimizar o impacto no desempenho do servidor.

Midas

A DLL Midas é um componente crucial para certas aplicações. Entender sua versão e como lidar com seu registro é vital para evitar problemas de compatibilidade e garantir o funcionamento correto do sistema.

- Versão Atual: A versão atualmente utilizada pela Tek-System é: 24.0.xxx.xxx.

- Registrar ou Não Registrar a Midas? Nossa orientação é não efetuar o registro global da DLL Midas no sistema (por exemplo, na pasta System32 ou SysWOW64). Há algumas razões importantes para isso:

Problemas de Atualização: Se a Midas for registrada globalmente, uma mudança de versão da sua aplicação pode não atualizar a DLL registrada, fazendo com que o sistema continue consumindo a versão antiga e potencialmente incompatível.

Conflitos com Outros Sistemas: Outros sistemas instalados no mesmo servidor podem ter suas próprias versões da Midas e registrá-las em diferentes diretórios. Isso pode levar a conflitos, onde sua aplicação acaba consumindo uma Midas errada ou incompatível, causando erros inesperados.

A melhor prática é manter a DLL Midas na mesma pasta dos executáveis da sua aplicação, garantindo que ela use sempre a versão correta e que as atualizações sejam feitas de forma controlada junto com a aplicação.

- Como Registrar (Se Estritamente Necessário)? Caso haja uma necessidade específica e justificada para registrar a Midas (e sempre com a ciência dos riscos), siga estes passos:

Abra o Prompt de Comando (CMD) como Administrador. Se você não fizer isso, mesmo que uma mensagem de sucesso apareça, o registro pode não ter sido efetivado. Use o regsvr32 correto para a arquitetura do SO:

Para Windows 32 Bits:

 C:\Windows\system32\regsvr32 C:\Tek-System\Exec\midas.dll

Para Windows 64 Bits:

 C:\Windows\SysWOW64\regsvr32 C:\Tek-System\Exec\midas.dll

Note a diferença nos caminhos (system32 vs. SysWOW64). É crucial usar o regsvr32 da pasta correspondente à arquitetura da DLL que você está registrando, que deve estar na pasta da sua aplicação (ex: C:\Tek-System\Exec).

- Como Desregistrar? Para desregistrar a DLL Midas, utilize o mesmo processo de registro, mas adicione o parâmetro -u na linha de comando:

Para Windows 32 Bits:

 C:\Windows\system32\regsvr32 -u C:\Tek-System\Exec\midas.dll

Para Windows 64 Bits:

 C:\Windows\SysWOW64\regsvr32 -u C:\Tek-System\Exec\midas.dll

Análise e monitoramento

- Para checar problemas de IO:

Windows:

 HDTune: Sistemas\Utilitários\Analise de Servidores\HDTune
 CrystalDiskMark: Sistemas\Utilitários\Analise de Servidores\CrystalDiskMark

Linux:

 HDParm:
 IOMeter:

- Para checar quem está causando GC no BD

 TekMonitor
 IBMonitoramento (Pago)
 FBScaner (Pago) 
 IBExpert (Pago)
 BI (Tek-System) - Indicadores

- Identificar Querys ruins

 TekMonitor
 IBExpert (Pago)
 FBScanner (Pago)
 Sinática: (Pago) [descontinuado]

TekAgendador

Agendamentos de manutenção da base de dados:

- Opção de validade do Firebird, deve-se utilizar opção compatíveis conforme Firebird, interesse utilizar para forçar o Sweep por exemplo

- Recalculo de Index: força o recalculo das estatísticas de índices da base de dados

- Desconectar base de dados: Interessante utilizar para desconectar conexões a mais de X minutos conectados, coloque longo tempo exemplo 480 min (8 hrs x 60 min)

TekMonitor

Configuração de monitoramento:

São 97 elementos divididos em quatro grupos: Servidor, SGDB, BDD e Serviço

Conforme o modo selecionado mudará o tempo de periodicidade e alguns parâmetros de análise

Periodicidade: Tempo em minutos para execução, utilizar Zero para inativar

Satisfação: Forma de análise do elemento

Valores: Mínimo e Máximo, sendo informação, alerta e crítico; Sendo que informação apenas registra nas notificações, diferente de Alerta e Critico que também pode conforme configuração disparar e-mail.

Incidência de notificação: Quando que irá registar e poderá enviar o e-mail:

Nunca

Diária Posteriormente: Registrará, mas enviará o e-mail apeno ao final do dia

Diária na Primeira Incidência: Registrará, e enviará o e-mail apenas na primeira incidência do dia

Sempre: Registrará e enviará o e-mail em toda incidência

Única vez: Registrará e enviará o e-mail apenas uma vez

- Notificações

Elementos informativos, avisos e críticos apurados no monitoramento

- Monitoramento do Servidor

Percentual de uso da memória em uso e Swap

Latencia da rede

Percentual de uso do processador

Carga da bateria (depende da disponibilidade de drive e hardware com repasse essa informação)

- Monitoramento da base de dados

Atividade de I/O: Estes gráficos e lista mostram informações breves sobre as principais declarações que executam muitas leituras. Isso significa que elas consomem IO significativas e podem afetar o desempenho de outras consultas. As instruções SQL com valores de pico devem ser cuidadosamente verificadas para o desempenho ideal.

Atividade de transações: AOT, AIT, OST, Next

Leitura de registros: "Leituras sequenciais / leituras indexadas" nos mostra a relação total entre leituras seqüenciais (não indexadas) e leituras indexadas no aplicativo.

Operações em registros: Visão geral das operações de escrita: relação entre INSERTs / UPDATEs / DELETEs entre todas as conexões do banco de dados. Na tabela dos melhores escritores, você pode ver as conexões com o maior número de operações de gravação. É útil identificar aplicativos ou módulos de software que executem um número excessivo de atualizações ou exclusões (que são as operações mais perigosas em termos de coleções de lixo).

Transações pendentes: Este gráfico mostra a quantidade de pendentes ao longo da linha de tempo. Existem dois tipos de transações pendentes, aquelas que estão aguardando o garbage collector e as que estão aguardando o sweep.

Memória em uso: O gráfico de "uso da memória" mostra a memória total usada por todas as conexões ativas e o pico da memória alocada para eles no passado. A lista dos principais anexos por uso de memória nos mostra os maiores consumidores de memória entre seus anexos. É útil encontrar aplicações ou módulos de software com uso excessivo de memória.

Espaço em disco: Disponível apenas se o SGDB estiver na mesma máquina do TekMonitor

Objetos: Este gráfico mostra o total de objetos na base de dados ao longo da linha de tempo: Conexões, Transações e Comandos

Arquivo: Tamanho da base de dados

Mutex Wait: Porcentagem de tentativas de adquirir a tabela de bloqueio bloqueada. [I.e. ((Adquirir blocos) / (adquire)) * 100]