[firebase-br] Versões de registros

[Gabriel Bonzanini]

Obrigado pela breve resposta Cantu, sou seu fã hehehehe

Estou fazendo testes através de um editor de SQL simples (IBExpert),
excluindo 140 mil registros e incluindo-os novamente (com commit a cada 50
inserts). A cada nova execução, o banco fica com 25Mb a mais de tamanho, e
o processo fica cada vez mais lento, até que chega um momento em que não é
mais possível executá-lo.

Questão: Este é um volume de dados/operações considerado grande para o
Firebird? Há algo que eu possa colocar no próprio SQL para reduzir este
"inchaço"?

Abraço.

Em 16 de maio de 2018 18:47, Carlos H. Cantu <listas em warmboot.com.br>
escreveu:

> O espaço ocupado pelas versões temporárias de registro são liberados
> para reutilização através da coleta de lixo. A coleta de lixo é um
> processo natural e constante do banco de dados, mas se o seu controle
> transacional não estiver OK, a coleta não será feita, ou será feita de
> forma incompleta.
>
> Use o gstat -h para ver se transações estão ficando presas por muito
> tempo, e se for o caso, altere a lógica do controle transacional da
> sua aplicação, de forma que finalize as transações com Commit/Rollback
> deixando-as abertas pelo menor tempo possível. Assim, nunca haverá
> grande quantidade de lixo a ser coletado, e o Firebird não ficará
> sobrecarregado com cadeias de versões de registros.
>
> PS: Sweep não vai resolver se houver transações presas.
>
> []s
> Carlos H. Cantu
> eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
>
> GB> Boa tarde!
>
> GB> Primeiramente, agradeço por terem me aceito na lista de discussões. Já
> GB> obtive muita ajuda através dos materiais postados no site Firebase.
>
> GB> Estou com um problema antigo em meu sistema de gestão, e com o passar
> do
> GB> tempo (devido ao volume de dados que sempre aumenta nos clientes) está
> se
> GB> tornando insustentável: as versões de registro criadas pelo Firebird.
>
> GB> Nossa tabela de estoque é sempre bastante acionada por todos os tipos
> de
> GB> documentos existentes, e muitas vezes o usuário altera movimentações
> GB> antigas, fazendo com que o sistema refaça as movimentações
> posteriores. O
> GB> que acontece é que chega um momento em que a tabela em questão
> simplesmente
> GB> trava (nenhum select, mesmo que simples, é  concluído), e não há nada a
> GB> fazer senão um backup/restore lentíssimo, que deixa o cliente sem poder
> GB> utilizar o sistema nesse período, já que o banco precisa ser recriado.
>
> GB> Já tentei adicionar um sweep manual, executado uma vez por dia, porém
> não
> GB> tem o mesmo efeito. Já tentei os mais diversos comandos do utilitário
> gfix,
> GB> porém nada parece resolver. Por falta de opção, estamos tendo que
> entrar em
> GB> contato com os clientes periodicamente para efetuar um backup/restore
> GB> preventivo.
>
> GB> Isso me leva há duas questões:
>
> GB> * Há como liberar as versões de registro sem um backup/restore
> completo?
> GB> * Há como desativar a criação dessas versões através de alguma
> configuração
> GB> do Firebird ou então através de algum parâmetro na transação?
>
> GB> Desde já agradeço a atenção.
>
> GB> Gabriel Bonzanini
> GB> Elementare Software.
> GB> ______________________________________________
> GB> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> GB> Para saber como gerenciar/excluir seu cadastro na lista, use:
> GB> http://www.firebase.com.br/fb/artigo.php?id=1107
> GB> Para consultar mensagens antigas:
> GB> http://www.firebase.com.br/pesquisa_lista.html
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://www.firebase.com.br/
> pesquisa_lista.html
>