[firebase-br] Versões de registros

[Marcos R. Weimer]

ok, obrigado pelo esclarecimento, vi um possível ponto a ser melhorado que
"não é possível", o mais importante é que entendi o processo.

-=Ma®©oS=-
Marcos R. Weimer
Pessoas quietas têm as mentes mais barulhentas - Stephen Hawking
http://eudoparana.blogspot.com.br/



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

>
> A coleta de lixo "natural" é feita sempre que o Firebird acessa uma
> página da base de dados devido a execução de algum comando (select,
> update, etc). Se ele detectar que tem lixo naquela página, ele checa
> se existe alguma transação ativa que ainda se interessa por esse
> "lixo". Se houver, ele não coleta. Se não houver, ele coleta.
>
> Querer que a coleta de lixo não aconteça não é uma boa idéia, salvo em
> situações muito específicas, pois com isso a quantidade de lixo que
> será "juntado" será cada vez maior e, portanto, quando a coleta
> acontecer, vai demorar muito mais tempo pra processar todo o lixo.
>
> A diferença da coleta de lixo "natural" e do sweep é que o sweep varre
> todas as tabelas da base de dados, e também avança a OIT (quando
> possível).
>
> []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
>
> MRW> Ola!
>
> MRW> Me intrometendo na discussão, pois estava lendo e fiquei com duvidas.
>
> MRW> Cantu, quando você disse:
>
> MRW> "Após apagar os registros, dê um commit na transação e rode um select
> *
> MRW> na tabela onde eles estavam. Isso fará com que o firebird dispare a
> MRW> coleta de lixo nessa tabela (o lixo só será coletado se não houver
> MRW> transações ativas anteriores a do "delete"). Após o retorno do comando
> MRW> (que será nada, pois a tabela está vazia), dê um commit na transação e
> MRW> proceda com a nova inserção.  "
>
>
> MRW> Situações:
>
>
> MRW> 1 - delete * from tabela; select * from tabela
>
> MRW> 2 - delete * from tabela; select campo1, campo2 from tabela
>
> MRW> 3 - delete * from tabela where campo1 = 1; select * from tabela
>
> MRW> 4 - delete * from tabela where campo1 = 1. select campo1, campo2 from
> tabela
>
> MRW> 5 - select * from tabela (sem delete)
>
> MRW> 6 - select campo1, campo2 from tabela
>
>
> MRW> Pelo que entendi nas situações 5 e 6 não é feita a coleta de
> MRW> lixo, e nas demais é feita, ou estou enganado ?
>
>
> MRW> Dependendo da resposta já penso em otimizar alguns processos
> MRW> para evitar a coleta de lixo (executando manualmente em horarios
> MRW> pré-determinados (já fazemos isso))
>
>
>
>
>
> MRW> -=Ma®©oS=-
> MRW> Marcos R. Weimer
> MRW> Pessoas quietas têm as mentes mais barulhentas - Stephen Hawking
> MRW> http://eudoparana.blogspot.com.br/
>
>
>
>
> MRW> Em 17 de maio de 2018 15:16, Carlos H. Cantu
> MRW> <listas em warmboot.com.br> escreveu:
>
> 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.
>
> MRW>  Você precisa entender como funciona o versioning. Temos artigos no
> MRW>  site sobre isso.
>
> MRW>  Quando vc apaga os registros, enquanto a coleta de lixo não for
> feita,
> MRW>  esse espaço ocupado por ele continuará existindo... só será
> MRW>  reaproveitado após a coleta de lixo marcar ele como "liberado".
>
> MRW>  Faça outro teste:
>
> MRW>  Após apagar os registros, dê um commit na transação e rode um select
> *
> MRW>  na tabela onde eles estavam. Isso fará com que o firebird dispare a
> MRW>  coleta de lixo nessa tabela (o lixo só será coletado se não houver
> MRW>  transações ativas anteriores a do "delete"). Após o retorno do
> comando
> MRW>  (que será nada, pois a tabela está vazia), dê um commit na transação
> e
> MRW>  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"?
>
> MRW>  É um volume ridículo. Sei de bases de dados Firebird em produção com
> MRW>  mais de 400GB. O problema, como eu apontei anteriormente, deve estar
> MRW>  no seu controle transacional que está bloqueando a coleta de lixo.
>
> MRW>  Leia os artigos sobre versioning/mvcc/controle de concorrência no
> MRW>  site.
>
> MRW>  []s
> MRW>  Carlos H. Cantu
> MRW>  eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
> MRW> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br
>
>
>
>
> ______________________________________________
> 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
>