[firebase-br] Tamanho Fisico Banco dados Firebird

[Gladiston Santana]

Não é especifico para Firebird, mas os bancos de dados usam calculos que
medem o melhor custo/beneficio das operações observando vários critérios
sendo o mais significativo os índices, eles são calculados a medida que
submete sua query e então sua medição é guardada para ser usada
posteriormente em queries similares e a medida que você vai usando o banco
de dados então vai "aprendendo" e usufruindo do cache. Como você matou o
banco de dados anterior, ele teve de começar de novo, então é normal ser
mais lento no inicio, mas voltará ao normal com o tempo de uso.
Em sistemas SQL quanto mais tempo você estiver usando-o, mais rápido ele
vai ficando, por isso, uptime de um servidor diz muito sobre o sistema
operacional e os serviços que rodam nele.
O backup deve ter uma rotina, mas o restore sobre uma base em produção só
mesmo se houver um sinistro.
Ficar no backup/restore cria a impressão de banco de dados otimizado, e de
certa forma até fica porque o arquivo de dados fica desfragmentado no
Windows por isso alguns defendem seu uso, mas na *minha opinião* você tem
mais a perder do que a ganhar. Eu não uso restore a bastante tempo, apenas
cuido de que o backup seja feito periodicamente (alguns a cada 2h e outros
a cada 8h).

Estude o seu banco de dados e use o parametro DatabaseGrowthIncrement para
definir um tamanho que seja razoável e que forneça menos atividade de
autogrowing, pois a cada vez que seu banco cresce ele perderá performance
no instante que o fizer e fragmentará mais, não é culpa do FB, mas do
sistema de arquivos do Windows vai tentar achar um bloco vazio no disco
para o autogrowing. Alguns para obter melhor performance, desligam essa
opção e criam o database com tamanho de estimativas para vários anos já que
o servidor será dedicado e tem espaço de disco de sobra.

inte+

Em 26 de maio de 2015 13:58, André José <andrejoseo2008 em gmail.com> escreveu:

> Entendi o conceito referente ao crescimento do banco dados. Realmente muito
> interessante e que ainda não tinha conhecimento.
>
> Eu realmente pensei que era algum problema no banco dados e por isso não
> alterava o tamanho físico.
>
> Nós fizemos um teste com esse mesmo banco dados. Onde fizemos um
> backup/restore dessa base dados e percebemos uma lentidão no sistema depois
> disso. E por isso voltamos o banco dados atual.
>
> O que pode estar ter ocasionado lentidão nesta base dados que foi realizado
> backup/restore ? Por isso achei que poderia ser um problema no banco dados.
>
>