Fonte: www.activedelphi.com.br
Defina índices para todas as colunas que vão ser usadas para join’s ou ordenações. Os índices são estruturas de dados de árvores balanceadas que fornecem um grande aumento na velocidade da procura dos valores nas colunas em que os índices são definidos. Isto é especialmente útil quando ordenamos por uma coluna em particular ou juntamos duastabelas por uma coluna que as duas têm em comum.Lembre que um índice Firebird é específico para uma direção de ordenação, ascendente ou descendente (ASCENDING x DESCENDING), e a direção de um índice deve ser igual à direção escolhida quando se faz a ordenação. Se você for usar as duas direções, ascendente ou descendente, crie dois índices para as chaves de ordenação. As inclusões e alterações usam índices para serem gravadas, o que pode prejudicar a performance durante um INSERT ou UPDATE, mas alguns custos impostos durante a entrada de dados podem resultar em um grande ganho de performance mais tarde na pesquisa destes dados. Para minimizar a perda de performance durante um INSERT, considere em desabilitar os índices durante um grande volume de INSERTs. Isto irá ‘desligar’ os índices, tornando-os indisponíveis para ajudar a acelerar as pesquisas, mas também não vão ser atualizados durante os INSERTs.Então, reabilite-os depois de terminados os INSERTs, e os índices serão atualizados e balanceados uma vez para todos os dados incluídos.Periodicamente reconstrua os índices, desativando e ativando novamente (ALTER INDEX nome INACTIVE; seguido de ALTER INDEX nome ACTIVE;). Recalcule o índice seletivamente (SET STATISTICS INDEX nome;) se uma mudança na tabela afeta a distribuição regular dos valores e dados. Os índices também são reconstruídos do mesmo modo durante o restore.
Otimize as pesquisas
O Firebird irá analisar uma pesquisa (query) e o otimizador fará a melhor estimativa de quais índices deverão ser empregados para acelerar a pesquisa. Mas nenhum otimizador automático é infalível. Para queries complexas que serão usadas freqüentemente, ou que serão aplicadas a um número elevado de dados, construa a pesquisa cuidadosamente. Usea opção SET PLAN da ferramenta ISQL para testar queries, ver sua performance e ver qual PLAN o otimizador escolheu. No Interbase v4.0, v4.1 e v4.2 existem alguns problemas conhecidos em tais queries usando a sintaxe JOIN na linguagem ANSI SQL-92, que não são analisados e otimizados corretamente. Evite esta sintaxe ou, se tiver que usá-la, especifique seu próprio PLAN.
Ajuste o cache do Firebird
O Firebird mantém seu próprio cache de páginas do banco de dados correntemente em uso na RAM do servidor. O tamanho padrão do cache na versão superserver (Windows) é 2048 páginas de banco de dados (isto é compartilhado por todos os clientes conectados a um dado banco de dados). Para um banco de dados com 1Kb de páginas, isto ainda ésomente 2048Kb. A maioria dos servidores tem muita memória, então ponha em uso! Experimente ajustar o cache de 256 até 10.000 páginas. Em algum ponto verá diminuir os retornos, mas alguma experimentação irá revelar este ponto.
Faça Backup / Restore
Existem vários benefícios em fazer periodicamente um backup/restorede um banco de dados Firebird usando o utilitário GBAK:-reconstruir índices;-eliminar versões obsoletas de registros (‘garbage’);-defragmentar páginas de dados;-regravar tabelas de dados contiguamente; e
-fazer uma cópia dos dados!
Use processamento Cliente-servidor
Usando funções externas (UDFs), Triggers, Stored Procedures e Select Procedures fazem com que o banco de dados faça muito processamento no servidor, que provavelmente é um computador muito mais potente que a estação de trabalho. Esta técnica evita também tráfego de rede desnecessário.
Use o cache de disco do Sistema Operacional
A maioria dos sistemas operacionais oferece sistema de cache de disco para leitura/gravação. Com isto os programas podem fazer suas gravações na RAM do servidor, e o sistema operacional irá salvar este conteúdo fisicamente no disco periodicamente. Fazendo sempre pequenas gravações ou fazer de uma só vez numa operação maior podeaumentar bastante a performance de leitura/gravação de dados. Usar este sistema de cache de disco é algumas vezes chamado de leitura/gravação assíncrona (asynchronous I/O) ou gravação em cache (cached writes). Forçando a gravação direta dos dados no disco,sobrepondo o sistema de cache, é chamado de leitura/gravação síncrona (synchronous I/O) ou gravação forçada (forced writes). O sistema de leitura/gravação assíncrona tem o benefício de aumentar a performance, mas como a RAM é um sistema volátil de armazenamento, pode perder dados se houver uma queda de energia ou uma falha no servidor ou ainda uma reinicialização do servidor quando o cache ainda não tiver sidodescarregado no disco. A leitura/gravação síncrona garante que nada será perdido por estar no cache, mas ler ou gravar diretamente no disco é bem mais lento que fazê-lo na RAM.O Firebird permite fazer a leitura/gravação assíncrona ou síncrona. O comando GFIX –WRITE SYNC.GDB faz o banco de dados usar a gravação forçada (forced writes), e o comando GFIX –WRITE ASYNC .GDB faz o banco usar a gravação em cache (cached writes).A gravação em cache pode ganhar muito em performance no Firebird, mas devem ser tomadas medidas de proteção contra perda de dados. Por exemplo, usando espelhamento de disco para manter uma duplicação dos dados. Usando também no-break e estabilizadores para garantir uma energia estável e ininterrupta para o servidor. Com medidas como estas,a leitura/gravação assíncrona pode trazer benefícios sem sacrificar a segurança.
Administre o protocolo de rede
O protocolo TCP/IP é muito mais rápido que o SPX ou NetBEUI. Conectar sua rede usando TCP/IP resultará em uma melhor performance. O serviço NetBEUI tem um prioridade baixa em servidores NT, mas existe um meio no sistema operacional para aumentar a prioridade deste serviço. Alguns usuários dizem ter aumentado a performance depois de ter feito isto. Veja na documentação do Windows NT as instruções paraajustar a prioridade dos serviços NetBEUI. NOTA: A partir do Windows NT 4.0, a performance da implementação do Microsoft NetBEUI foi aumentada. É agora pelo menos tão boa quanto a implementação do Microsoft TCP/IP, entretanto, em uma rede ocupada, o NetBEUI é ainda limitado por ser um protocolo independente de conecção. Isto significa que cada host na rede deve checar cada pacote para ver seu conteúdo. Com mais hosts transmitindo na rede, cada host deve manipular uma crescente leitura de "números errados".
Escolha o sistema operacional
Sistemas operacionais basados no UNIX/Linux são sempre mais rápidos em multiprocessamento que sistemas Windows em um mesmo equipamento. Se velocidade é algo importante para você considere o uso desta plataforma. Pense sempre em utilizar o Firebird como servidor dedicado, que não funcione como servidor de arquivos, pois ele poderá ficar sentado no "banco de trás" nas questões de prioridade de processamento.No Windows NT o servidor é configurado para dar prioridade ao compartilhamento de arquivos. Você pode modificar esta configuração no servidor: Painel de Controle -> Rede -> Software de Rede. Modifique para "balancear" ou "servidor de banco de dados". Esta modificação irá resultar em uma melhora dramática na performance do Firebird.O uso de sistemas operacionais não específicos para uso de Servidores como os Windows 9x, Me ou XP Home podem prejudicar sua performance, além das fragilidades conhecidas.
Considere a limpeza do lixo (garbage collection)
O Firebird tem por padrão a função de automaticamente limpar as antigas versões dos registros quando estas se tornam muito numerosas. O problema deste método é que se um processo cliente que for sem sorte suficiente para iniciar uma transação que coincida com o início da limpeza automática, vai ter que esperar o trabalho de limpeza. O processo clienteatrasa enquanto o processo de limpeza é feito. Desabilite a limpeza automática (automatic garbage collection), usando GFIX –h 0, em favor da limpeza programada (scheduled database sweep), usando GFIX –s. Isto irá eliminar a perda na performance do cliente.Fazer um backup e restore efetivamente faz a mesma coisa do que uma limpeza completa no banco de dados. O backup somente copia a versão mais recente de cada registro, nunca copia versões anteriores, assim, quando os dados são restaurados, existe somente uma versão de cada registro. Existem também outros benefícios de fazer backup/restore,descritos na seção própria deste artigo. Falando em limpeza do lixo, muitos programadores não se dão conta da necessidade de iniciar e terminar (START e COMMIT) suas transaçõescom o banco de dados. Abrir transações impede que a varredura periódica complete a limpeza do lixo, e a performance irá sofrer progressivamente com o tempo.
Normalize seu banco de dados
Projete seu banco de dados com uma normalização adequada dos dados. Registros que têm muitos grupos de campos repetidos são maiores que deveriam ser, podem aumentar o custo de ordenação e ainda podem causar a ocupação de mais páginas do que o necessário,resultando em uma maior fragmentação de páginas e um banco de dados enorme sem necessidade.
Pense nas transações
Projete sua aplicação para que resolva o mais rápido possível as transações depois de abertas. Freqüentemente os programadores de aplicação abrem uma transação e apresentam uma tela de entrada de dados para o usuário. Ao invés disso, pegue os dados com o usuárioantes, abra uma transação para dar o INSERT e então dê o COMMIT na transação imediatamente. O propósito disto é diminuir o tempo de duração das transações, que diminui a probabilidade de duas aplicações concorrentes conflitarem em um bloqueio de registro. Isto também ajuda a evitar muitos ROLLBACKs e tráfego de rede, já que a sua aplicação decide quando submeter os dados ao banco ou descartá-los.
Programe com a API do Firebird
Um programa escrito em C com SQL embutido responde melhor que uma aplicação cliente Firebird escrita em Paradox, Delphi ou outra ferramenta visual. A idéia é programar diretamente na API do Firebird ao invés de adicionar camadas intermediárias com mais um protocolo de rede sobre ele.
Otimize as pesquisas
O Firebird irá analisar uma pesquisa (query) e o otimizador fará a melhor estimativa de quais índices deverão ser empregados para acelerar a pesquisa. Mas nenhum otimizador automático é infalível. Para queries complexas que serão usadas freqüentemente, ou que serão aplicadas a um número elevado de dados, construa a pesquisa cuidadosamente. Usea opção SET PLAN da ferramenta ISQL para testar queries, ver sua performance e ver qual PLAN o otimizador escolheu. No Interbase v4.0, v4.1 e v4.2 existem alguns problemas conhecidos em tais queries usando a sintaxe JOIN na linguagem ANSI SQL-92, que não são analisados e otimizados corretamente. Evite esta sintaxe ou, se tiver que usá-la, especifique seu próprio PLAN.
Ajuste o cache do Firebird
O Firebird mantém seu próprio cache de páginas do banco de dados correntemente em uso na RAM do servidor. O tamanho padrão do cache na versão superserver (Windows) é 2048 páginas de banco de dados (isto é compartilhado por todos os clientes conectados a um dado banco de dados). Para um banco de dados com 1Kb de páginas, isto ainda ésomente 2048Kb. A maioria dos servidores tem muita memória, então ponha em uso! Experimente ajustar o cache de 256 até 10.000 páginas. Em algum ponto verá diminuir os retornos, mas alguma experimentação irá revelar este ponto.
Faça Backup / Restore
Existem vários benefícios em fazer periodicamente um backup/restorede um banco de dados Firebird usando o utilitário GBAK:-reconstruir índices;-eliminar versões obsoletas de registros (‘garbage’);-defragmentar páginas de dados;-regravar tabelas de dados contiguamente; e
-fazer uma cópia dos dados!
Use processamento Cliente-servidor
Usando funções externas (UDFs), Triggers, Stored Procedures e Select Procedures fazem com que o banco de dados faça muito processamento no servidor, que provavelmente é um computador muito mais potente que a estação de trabalho. Esta técnica evita também tráfego de rede desnecessário.
Use o cache de disco do Sistema Operacional
A maioria dos sistemas operacionais oferece sistema de cache de disco para leitura/gravação. Com isto os programas podem fazer suas gravações na RAM do servidor, e o sistema operacional irá salvar este conteúdo fisicamente no disco periodicamente. Fazendo sempre pequenas gravações ou fazer de uma só vez numa operação maior podeaumentar bastante a performance de leitura/gravação de dados. Usar este sistema de cache de disco é algumas vezes chamado de leitura/gravação assíncrona (asynchronous I/O) ou gravação em cache (cached writes). Forçando a gravação direta dos dados no disco,sobrepondo o sistema de cache, é chamado de leitura/gravação síncrona (synchronous I/O) ou gravação forçada (forced writes). O sistema de leitura/gravação assíncrona tem o benefício de aumentar a performance, mas como a RAM é um sistema volátil de armazenamento, pode perder dados se houver uma queda de energia ou uma falha no servidor ou ainda uma reinicialização do servidor quando o cache ainda não tiver sidodescarregado no disco. A leitura/gravação síncrona garante que nada será perdido por estar no cache, mas ler ou gravar diretamente no disco é bem mais lento que fazê-lo na RAM.O Firebird permite fazer a leitura/gravação assíncrona ou síncrona. O comando GFIX –WRITE SYNC
Administre o protocolo de rede
O protocolo TCP/IP é muito mais rápido que o SPX ou NetBEUI. Conectar sua rede usando TCP/IP resultará em uma melhor performance. O serviço NetBEUI tem um prioridade baixa em servidores NT, mas existe um meio no sistema operacional para aumentar a prioridade deste serviço. Alguns usuários dizem ter aumentado a performance depois de ter feito isto. Veja na documentação do Windows NT as instruções paraajustar a prioridade dos serviços NetBEUI. NOTA: A partir do Windows NT 4.0, a performance da implementação do Microsoft NetBEUI foi aumentada. É agora pelo menos tão boa quanto a implementação do Microsoft TCP/IP, entretanto, em uma rede ocupada, o NetBEUI é ainda limitado por ser um protocolo independente de conecção. Isto significa que cada host na rede deve checar cada pacote para ver seu conteúdo. Com mais hosts transmitindo na rede, cada host deve manipular uma crescente leitura de "números errados".
Escolha o sistema operacional
Sistemas operacionais basados no UNIX/Linux são sempre mais rápidos em multiprocessamento que sistemas Windows em um mesmo equipamento. Se velocidade é algo importante para você considere o uso desta plataforma. Pense sempre em utilizar o Firebird como servidor dedicado, que não funcione como servidor de arquivos, pois ele poderá ficar sentado no "banco de trás" nas questões de prioridade de processamento.No Windows NT o servidor é configurado para dar prioridade ao compartilhamento de arquivos. Você pode modificar esta configuração no servidor: Painel de Controle -> Rede -> Software de Rede. Modifique para "balancear" ou "servidor de banco de dados". Esta modificação irá resultar em uma melhora dramática na performance do Firebird.O uso de sistemas operacionais não específicos para uso de Servidores como os Windows 9x, Me ou XP Home podem prejudicar sua performance, além das fragilidades conhecidas.
Considere a limpeza do lixo (garbage collection)
O Firebird tem por padrão a função de automaticamente limpar as antigas versões dos registros quando estas se tornam muito numerosas. O problema deste método é que se um processo cliente que for sem sorte suficiente para iniciar uma transação que coincida com o início da limpeza automática, vai ter que esperar o trabalho de limpeza. O processo clienteatrasa enquanto o processo de limpeza é feito. Desabilite a limpeza automática (automatic garbage collection), usando GFIX –h 0, em favor da limpeza programada (scheduled database sweep), usando GFIX –s. Isto irá eliminar a perda na performance do cliente.Fazer um backup e restore efetivamente faz a mesma coisa do que uma limpeza completa no banco de dados. O backup somente copia a versão mais recente de cada registro, nunca copia versões anteriores, assim, quando os dados são restaurados, existe somente uma versão de cada registro. Existem também outros benefícios de fazer backup/restore,descritos na seção própria deste artigo. Falando em limpeza do lixo, muitos programadores não se dão conta da necessidade de iniciar e terminar (START e COMMIT) suas transaçõescom o banco de dados. Abrir transações impede que a varredura periódica complete a limpeza do lixo, e a performance irá sofrer progressivamente com o tempo.
Normalize seu banco de dados
Projete seu banco de dados com uma normalização adequada dos dados. Registros que têm muitos grupos de campos repetidos são maiores que deveriam ser, podem aumentar o custo de ordenação e ainda podem causar a ocupação de mais páginas do que o necessário,resultando em uma maior fragmentação de páginas e um banco de dados enorme sem necessidade.
Pense nas transações
Projete sua aplicação para que resolva o mais rápido possível as transações depois de abertas. Freqüentemente os programadores de aplicação abrem uma transação e apresentam uma tela de entrada de dados para o usuário. Ao invés disso, pegue os dados com o usuárioantes, abra uma transação para dar o INSERT e então dê o COMMIT na transação imediatamente. O propósito disto é diminuir o tempo de duração das transações, que diminui a probabilidade de duas aplicações concorrentes conflitarem em um bloqueio de registro. Isto também ajuda a evitar muitos ROLLBACKs e tráfego de rede, já que a sua aplicação decide quando submeter os dados ao banco ou descartá-los.
Programe com a API do Firebird
Um programa escrito em C com SQL embutido responde melhor que uma aplicação cliente Firebird escrita em Paradox, Delphi ou outra ferramenta visual. A idéia é programar diretamente na API do Firebird ao invés de adicionar camadas intermediárias com mais um protocolo de rede sobre ele.
