FIREBIRD: Pesquisa em campo nome demora muito??

[JuNiNhO__ 0]

Pessoal, tenho um aplicação em Visual Basic 6, e uso o FireBird 1.5 como base de dados...tenho uma tabela CLIENTES com aproximadamente 150.000 registros... e quando eu vou executar um SELECT ele demora muito pra retornar a pesquisa....o que devo proceder ??ps: essa tabela esta com chave primaria na ID (Bigint)Aguardo resposta...

[Prog 183]

Algumas perguntas, que podem servir também como solução.

 

- Qual o tamanho do "Page Size" setado para esta base de dados?

- Quando você executa esta consulta, o processamento do servidor sobe muito? E a memória?

- Este campo é indexado? Se não for, considere indexa-lo.

[JuNiNhO__ 0]

Algumas perguntas, que podem servir também como solução.

 

- Qual o tamanho do "Page Size" setado para esta base de dados?

- Quando você executa esta consulta, o processamento do servidor sobe muito? E a memória?

- Este campo é indexado? Se não for, considere indexa-lo.

<{POST_SNAPBACK}>

Sim, o campo foi indexado..

mais sobre o PageSize... onde eu acho isso pra te informar... estou estudando ainda o BD...

 

brigadão

[Prog 183]

Esta usando qual ferramenta para acessar o banco de dados Firebird?

[JuNiNhO__ 0]

Esta usando qual ferramenta para acessar o banco de dados Firebird?

<{POST_SNAPBACK}>

Pra manipular o banco.. estou usando o IBExpert

[Prog 183]

No IBExpert, assim que você conecta ao seu banco de dados, ele mostra na parte de baixo as propriedades do banco de dados em questão, dentre estas propriedades, esta o "Page Size".

 

Um valor interessante é 4096.

[JuNiNhO__ 0]

No IBExpert, assim que você conecta ao seu banco de dados, ele mostra na parte de baixo as propriedades do banco de dados em questão, dentre estas propriedades, esta o "Page Size".

 

Um valor interessante é 4096.

<{POST_SNAPBACK}>

aha! Já achei aki.. mais não aonde você me indicou... fussei um pouquinho e achei... o valor eh de 1024...

 

o que influencia... e se eh preciso mudar isso... o que devo fazer??

[Prog 183]

Brow...

 

Seguinte, esta não é a unica opitimização que pode ser feita, mas para entender um pouco mais sobre performance em Firebird, leia os seguintes artigos:

http://www.firebase.com.br/cgi-bin/firebas...i/artigo?ID=222

http://www.firebase.com.br/cgi-bin/firebas...i/artigo?ID=148

http://www.firebase.com.br/cgi-bin/firebas...i/artigo?ID=150

http://www.firebase.com.br/cgi-bin/firebas...i/artigo?ID=126

 

Uma explicação sobre "Page Size":

Tamanho da Página (Page size)

 

O tamanho da página padrão utilizada pelo Interbase é de 1K. Há um aumento de performance de 25-30% se esse valor for alterado para 4K. Geralmente se fala que quanto maior a página, melhor é a performance, devido à razões que incluem :

 

    * Menos fragmentos de registros são dividos através das páginas

      É comum que os registros ocupem mais de 1K, significando que em uma página de 1K, o registro é divido e armazenado em múltiplas páginas. Acessar esse registro faz com que o servidor tenha de ler várias páginas do BD. Se o tamanho da página for aumentado, o número de registros fragmentados diminui e podem ser gravados de modo mais contínuo.

 

    * Index B-trees são superficiais

      Os índices são ponteiros em B-trees apontando para páginas de dados contendo porções dos valores indexados. Se a árvore B-tree for maior que 1 página, páginas adicionais são alocadas para a árvore de índice. Se as páginas de índices são maiores, algumas páginas adicionais são necesárias para armazenar os ponteiros. A árvore B-tree é facilmente alocada na memória pelo sistema de cache do BD, fazendo com que as procuras indexadas fiquem extremamente rápidas.

 

    * I/O é mais contínua

      Normalmente registros sucessivos em uma tabela são lidos pela mesma Query. Isso é feito, por exemplo, durante um scan por uma tabela, ou por uma Query que retorna ou agrega todos os registros de uma tabela. O Interbase armazena os registros na primeira página livre do BD, não garantindo que registros sucessivos sejam armazenados perto um do outro. Um scan em uma tabela pode exigir que o servidor "pule" por todo o Banco de Dados acessando os registros, oque pode influir negativamente na performance.

 

      Uma página do BD só pode armazenar registros de uma mesma tabela. Isso implica em que páginas maiores conterão mais dados de uma tabela e a leitura dessa página retornará dados mais relevantes.

 

    * Buffers maiores = mais memória de cache

      O cache do BD é alocado em número de páginas ao invés de uma quantidade fixa de bytes. Então, definindo uma página maior implicará no aumento do cache/memória que conterá uma porção maior do BD. Estatisticamente, as chances dos dados serem encontrados em um cache grande é maior do que em um cache pequeno.

 

    * A maior parte dos sistemas operacionais executam leituras em baixo nível em blocos de 4096bytes.

      Uma leitura de página é executado no nível do Sistema Operacional, lendo incrementos de 4096bytes independente do tamanho do BD. Definindo a página do BD em 4096 faz com que a leitura de uma página coincida com a leitura de baixo nível, garantindo uma melhor performance.

 

Voce pode mudar o tamanho padrão das páginas de um BD quando estiver criando ou restaurando um BD. A performance pode ser aumentada sem ter que mexer na arquitetura do BD. O tamanho das páginas é transparente para o cliente.

 

Embora 4K aparentemente seja o tamanho ideal para a maioria dos BDs, isso vai depender da estrutura de cada BD e do modo em que os aplicativos acessam esses dados, portanto, é aconselhável que voce faça alguns testes com outros valores para determinar o valor ideal para cada caso.

 

Compactando dados nas páginas para bancos de dados read-only

 

As páginas de dados armazenam múltiplas versões dos registros conforme os mesmos vão sendo atualizados. Quando um BD é restaurado, o GBAK preenche as páginas em até 80% do seu tamanho, deixando espaço para que novas versões dos registros possam ser armazenadas, com sorte, na mesma página que o registro original. No caso de um BD que é mais usado para leitura e nem tanto para inserção/atualização dos dados, esse espaço vago de 20% na página não é interessante. Nesse casos o melhor é restaurar os dados preenchendo 100% do espaço das páginas. Fazendo isso se reduzirá o número de registros fragmentados, bem como mais registros serão retornados durante a leitura de uma página. Para retaurar um BD com 100% de capacidade em cada página utilize a sintaxe :

 

GBAK -C -USE_ALL_SPACE backup_file.gbk database_file.gdb