[firebase-br] RES: Firebird 2.5 Super Classic - Comportamento Estranho ao UPDATE

[Gladiston Santana]

O funcionamento esperado é o seguinte, cada insert/update/delete não
elimina fisicamente a informação anterior, pois a mesma -  mesmo após um
commit - ainda é mantida no database,
Imagina que seu banco tenha um sinistro, por exemplo, falta de energia, e
parte das ultimas informações foram perdidas porque não chegaram a ser
escritas no disco ou se corromperam, então nesse caso o próprio FB
retornará as versões de registros que chegaram a um mesmo checkpoint e que
estejam saudáveis.
Por isso, é pouco recomendável que você faça um sweep antes do backup, pois
num sinistro, o FB não contará com esse versionamento dos registros para
atuar de forma automática.
Quem deve estar agendado é o backup e em intervalos regulares que forem
seguros para a aplicação levando em conta este ciclo.
Quando fizer um backup, se seu backup for concluído com 100% de sucesso, o
sweep então acontecerá de forma automática porque o FB agora sabe que você
contém um backup até aquele momento e inicia um novo ciclo.
Isso não fará o seu banco de dados cair de tamanho, pois os espaço liberado
com a exclusão de 'lixo' (sweep) será reaproveitado, então demorará para
ele novamente crescer e atingir o ápice que estava antes.
Não é necessário um restore, ele só deve acontecer se realmente ocorrer um
sinistro, mas algumas pessoas fazem porque erroneamente pensam que
'diminuindo' a base obtêm melhor performance, mas existem motivos legitimos
para realizar essa operação para por exemplo: (1) o arquivo de dados tá
muito fragmentado no disco e isso realmente diminui a performance, (2)
reaninhar os indices, (3) testar o processo de backup/restore, mas neste
caso não sobrepoe o arquivo antigo e tantos outros.


Se você tem uma base que cresce, cresce e cresce todo dia, mesmo o backup
sendo diário, talvez seja melhor olhar o firebird.conf e ajustar o
parametro que determina a taxa desse crescimento, talvez esteja em 256M e
isso é pouco para seu sistema, aumentar isso para por exemplo 4GB permitirá
menos fragmentação de seu arquivo de dados e com menos paradas para fazer o
processo de crescimento. Não se importe com o tamanho do arquivo no disco,
o tamanho do seu banco de dados não é o mostrado pelo sistema de arquivos,
mas a quantidade de páginas ocupadas. Se tiver que fazer isso, realmente
recomendaria o primeiro backup seguido do restore porque é provável que seu
arquivo de dados esteja muito fragmentado.

inte+

Em 8 de setembro de 2014 07:23, Kurt Schneider <
kurt.schneider em controlsoft.com.br> escreveu:

> Prezados,.
>
> Agradeço muito o esclarecimento de vocês.
>
> A questão passa a ser agora, algo diferente, e preocupante.
>
> Os dados que enviei para vocês são reais, de um banco em operação. Não
> posso considerar aquilo normal
> visto que 888 pages foram alocadas, mas nao liberadas (Garbage Colletion??)
>
> Ou seja, em um cliente com muitas atividades ocorrendo sobre a mesma
> tabela, como recalculo
> de Saldo - que é meu caso, terei que fazer backup - restore a cada 15 dias,
> caso contrário a base e a operação
> tendem a ficar lentos.
>
> Isso ja ocorreu com vcs.?
>