Orientações e Configurações de Servidores

De Tek-System Wiki
Ir para navegação Ir para pesquisar

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

SQL Dialect

3

ODS Version

ODS (On-Disk Structure) é um número de formato de arquivo de banco de dados para a versão específica do Firebird 

11.2 FB 2.5
12   FB 3
13   FB 4

Sweep Interval

O intervalo de varredura padrão para um novo banco de dados é 20.000. O intervalo de varredura é a diferença entre a transação instantânea mais antiga ou OST (Oldest snapshot) e a transação interessante mais antiga ou OIT (Oldest Transaction). Isso não significa que a cada 20.000 transações ocorrerá uma varredura. Ocorrerá quando a diferença entre o OST e o OIT for maior que o intervalo de varredura. se houve necessidade de ampliar não passar de 60000, e nunca desative pois será necessário realizar manualmente. A não realização do sweep levando a amplitude da necessidade execução implica na degradação exponencial de performance.

Read Only

Desmarcado, diferente disso é utilizando apenas em sistemas embarcados

Forced Write

O Firebird é instalado com gravações forçadas (gravações síncronas) habilitadas por padrão. Os dados alterados e novos são gravados no disco imediatamente após a postagem. É possível configurar um banco de dados para usar gravações de dados assíncronas, por meio das quais os dados modificados ou novos são mantidos no cache de memória para liberação periódica no disco pelo subsistema de E/S do sistema operacional. O termo comum para esta configuração é cancelamentos forçados (ou desabilitados ). Às vezes, é utilizado para melhorar o desempenho durante grandes operações em lote.

  • AVISO: não desative as gravações forçadas: interrupções de energia, finalização forçada do serviço, se travar, o sistema de E/S ficará fora de alcance implica em perda de dados, e possivelmente em uma corrupção das integridades relacionais
Obrigatório: True

Page Size

Por padrão, os bancos de dados Firebird têm os seguintes tamanhos de página: 

 1.0 - 1024 bytes
 2,5 - 4096 bytes
 3,0 - 8192 bytes
 4.0 - 8192 bytes
 5.0 - 8192 bytes

O tamanho máximo da página é 16K até o FB 3, no FB 4 e 5 é 32K.

Analisando apenas a questão do drive, o ideal é trabalhar com o mesmo tamanho de cluster do disco da base, para ter uma referencia de 1 para 1 (Saber o tamanho do cluster utilize no CMD chkdsk. Acesso o cmd com adminstrador e execute: chkdsk c:)

No entanto o tamanho do page size ideal varia conforme tipo de hardware, sistema operacional, perfil, tipo, volume de dados armazenados, profundidade dos índices, tamanho dos registros.

Por exemplo, para bancos de dados com mais de 100 Gb em 95% dos casos, é melhor ter o maior tamanho de página disponível, para:

- Diminua a profundidade dos índices. Recomenda-se ter índices com profundidade menor ou igual a 3. Índices com profundidade 4 e 5 serão muito mais lentos
- Aumente a utilização da RAM. O cache do Firebird é especificado em páginas, 1000 páginas com tamanho de página de 8K serão 8Mb de memória real e com 16K – 16Mb.
- Diminuir o número de páginas do sistema. Ele irá agilizar o acesso aos registros das tabelas grandes (menos saltos ponteiro-ponteiro-página de dados), e ajuda na preparação das grandes consultas SQL. Para aumentar o tamanho da página do banco de dados, o banco de dados deve ser copiado com a ferramenta gbak e, em seguida, restaurado com o parâmetro –page ( gbak –c –page 16384 ).

Observação: se você tiver um banco de dados com muitos blobs pequenos, aumentar o tamanho da página pode diminuir a fragmentação ou aumentar a fragmentação, e é difícil prever se isso aumentará ou diminuirá o desempenho.

Fonte: https://ib-aid.com/en/articles/23-more-ways-to-speed-up-firebird


Atenção: Qualquer mudança no tamanho das páginas implica diretamente nas configurações de cache do firebird.config, necessitando serem revistas.

Backup

- Use switch para gbak: aumenta a velocidade em até 20% do backup/restaurar, por exemplo: 

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

- Com gbak evit -v, melhora o desempenho

- Backup/restore em um único passo: 

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

- As operações de gravação são executadas sequencialmente durante o processo de backup, o que significa que discos rígidos regulares de baixo custo com a interface SATA (HDD SATA) serão bons para backup uma vez que sequencialmente escreverão muito rápido.

- Use a unidade rápida para espaço temporário do SGDB: Isso diminuirá o tempo de grandes ordenações, quando o banco de dados estiver sendo restaurado, etc..

- Para backups quentes em meio a trabalhos recomenda-se a utilização do N-Backup

- Atente-se a disponibilidade de espaço sobe o numero de copias permanentes e a projeção de crescimento, e monitore.

- Periodicamente realize testes das copias, sob a possiblidade de voltar a produção, tempo e consistência

- Evite armazenar copias na maquina ou em dispositivos conectados ao servidor, são suscetíveis a danificar com o servidor, roubados ou sequestrados.


Manutenção

- Apague os arquivos temporários antigos do Firebird: O Firebird cria vários arquivos temporários para diversas operações: ordenação, processamento de BLOBs, tracing, etc. Esses arquivos são armazenados nos seguintes locais:

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

Normalmente, esses arquivos são removidos automaticamente, no entanto, algumas vezes isso não acontece (por exemplo, se o servidor for reiniciado brutamente). Verifique esses diretórios periodicamente e apague os arquivos antigos – pode haver vários gigabytes e apagá-los irá liberar espaço no drive do sistema.

- Reinicie o servidor periodicamente.


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 motivos para corrupções

- Queda de energia, desligamento bruto

- Oscilação/intermitência da rede;

- Uso de dll’s (fbclient.dll e gds32.dll) com versões diferentes do Firebird do servidor (dlls na pasta do executável, System32 ou SysWOW64); (fonte: http://www.firebase.com.br/fb/artigo.php?id=2284)

- Falta de espaço na unidade onde está local do BD (deve haver pelo menos um 1GB disponível na unidade onde está a base)

- Falta de espaço na unidade de arquivos temporário do Firebird (por padrão é na mesma unidade da instalação do Firebird a não ser que seja alterado no .conf)

- Propriedades indevidas do BD (force write, entre outras, veja acima com usar as propriedades do BD) e/ou configurações indevidas do Firebird (Fonte: http://www.sinatica.com/blog/en/index.php/2008/08/forced-writes-firebird-database-corruption)

- Hardware com problema, em especial HD (problema em algum setor), mas também controladora, cabeamento da rede, instalações elétricas, etc..

- Problemas na memória RAM;

- Uso indevido de Raid (veja acima informações sobre uso da raid)

- Uso de S.O. pouco seguro (ex: Win 9x, ME e XP).

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


Parceiros do Firebird

Com os parceiros do Firebird poderá obter informações, consultorias e ferramentas:

IBSurgen www.firebirdsql.org/en/ibsurgeon Firebase Brasil www.firebirdsql.org/en/firebase-brazil

Antivírus

- Certifique-se que se o servidor tiver um antivírus instalado, que ele não esteja “rastreando” as bases de dados, os arquivos temporários criados pelo Firebird (c:\ProgramData\Firebird) e o próprio sistema.

- Não recomendamos o uso do Kaspersky Server em conjunto no servidor, consome muito recurso de rede de processador. Faz uso do SGDB (Sistema de gerenciamento de banco de dados) SQL Server consome grande quantidade de recursos, por haver grande volume de acesso a disco mesmo prioridade concorrerá diretamente com o sistema para consumo dos recursos

- Colocar a pasta da Tek-System nas exceções

- Configurar de modo que não faça varredura durante o expediente


Midas

- Versão atual: 24.0.xxx.xxx

- Registrar ou não?: Orientamos não efetuar o registro, é comum efetuar o registro da midas na pasta system por exemplo, ocorre que em uma mudança de versão ela não é atualizada e o sistema a consome ao invés da que está sem sua própria pasta; Outros sistema também podem fazer o uso da midas e efetuar seu registros em outro diretório e o sistema passar a consumi-la.

- Registrar:

Ao abrir o CMD execute como administrador, do contrário mesmo apresentando mensagem de registro realizado com sucesso pode não ter sido realizado;
Deve-se observar se o sistema operacional é 32 ou 64 bits, se for 32 deve utilizar regsvr32 da system32, se for 64 bits deve usar o da SysWOW64:
 Exemplo:
   p/ Windows 32 Bits: C:\Windows\system\regsvr32 C:\Tek-System\Exec \midas.dll
   p/ Windows 64 Bits: C:\Windows\SysWOW64\regsvr32 C:\Tek-System\Exec \midas.dll

- Desregistrar

Mesmo processo anterior, mas adicionar parâmetro “-u” na linha de comando.


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]
Disponível em “https://teksystem.com.br/tekwiki/index.php?title=Orientações_e_Configurações_de_Servidores&oldid=4290”