[firebase-br] Versões de registros

Carlos H. Cantu listas em warmboot.com.br
Qui Maio 17 15:16:38 -03 2018


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

Você precisa entender como funciona o versioning. Temos artigos no
site sobre isso.

Quando vc apaga os registros, enquanto a coleta de lixo não for feita,
esse espaço ocupado por ele continuará existindo... só será
reaproveitado após a coleta de lixo marcar ele como "liberado".

Faça outro teste:

Após apagar os registros, dê um commit na transação e rode um select *
na tabela onde eles estavam. Isso fará com que o firebird dispare a
coleta de lixo nessa tabela (o lixo só será coletado se não houver
transações ativas anteriores a do "delete"). Após o retorno do comando
(que será nada, pois a tabela está vazia), dê um commit na transação e
proceda com a nova inserção.


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

É um volume ridículo. Sei de bases de dados Firebird em produção com
mais de 400GB. O problema, como eu apontei anteriormente, deve estar
no seu controle transacional que está bloqueando a coleta de lixo.

Leia os artigos sobre versioning/mvcc/controle de concorrência no
site.

[]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> Em 16 de maio de 2018 18:47, Carlos H. Cantu
GB> <listas em warmboot.com.br> escreveu:

GB> O espaço ocupado pelas versões temporárias de registro são liberados
GB>  para reutilização através da coleta de lixo. A coleta de lixo é um
GB>  processo natural e constante do banco de dados, mas se o seu controle
GB>  transacional não estiver OK, a coleta não será feita, ou será feita de
GB>  forma incompleta.

GB>  Use o gstat -h para ver se transações estão ficando presas por muito
GB>  tempo, e se for o caso, altere a lógica do controle transacional da
GB>  sua aplicação, de forma que finalize as transações com Commit/Rollback
GB>  deixando-as abertas pelo menor tempo possível. Assim, nunca haverá
GB>  grande quantidade de lixo a ser coletado, e o Firebird não ficará
GB>  sobrecarregado com cadeias de versões de registros.

GB>  PS: Sweep não vai resolver se houver transações presas.

GB>  []s
GB>  Carlos H. Cantu
GB>  eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
GB> 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


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






Mais detalhes sobre a lista de discussão lista