:: Active Delphi http://www.activedelphi.com.br/print.php?

sid=29

Dicas para melhorar a performance do servidor Firebird

Data: Thursday, March 06 @ 22:51:20
Tópico Administrador

Confira esta matéria enviada pelo nosso colaborador Celso Rodrigues.

cdelphi@terra.com.br
Use índices corretamente

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

1 de 3 15/05/2009 14:53
:: Active Delphi http://www.activedelphi.com.br/print.php?sid=29

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 <meubanco>.GDB faz o banco de
dados usar a gravação forçada (forced writes), e o comando GFIX –WRITE ASYNC <meubanco>.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

2 de 3 15/05/2009 14:53
:: Active Delphi http://www.activedelphi.com.br/print.php?sid=29

com mais um protocolo de rede sobre ele.

Digitado por :: Active Delphi

http://www.activedelphi.com.br/

A URL para esta notícia é:

http://www.activedelphi.com.br/modules.php?op=modload&name=News&file=article&sid=29

3 de 3 15/05/2009 14:53