[firebase-br] Versões de registros

[Marcos R. Weimer]

Ola!

Me intrometendo na discussão, pois estava lendo e fiquei com duvidas.

Cantu, quando você disse:

"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. "

Situações:

1 - delete * from tabela; select * from tabela
2 - delete * from tabela; select campo1, campo2 from tabela
3 - delete * from tabela where campo1 = 1; select * from tabela
4 - delete * from tabela where campo1 = 1. select campo1, campo2 from tabela
5 - select * from tabela (sem delete)
6 - select campo1, campo2 from tabela

Pelo que entendi nas situações 5 e 6 não é feita a coleta de lixo, e nas
demais é feita, ou estou enganado ?

Dependendo da resposta já penso em otimizar alguns processos para evitar a
coleta de lixo (executando manualmente em horarios pré-determinados (já
fazemos isso))


-=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 15:16, Carlos H. Cantu <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.
>
> 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
>
>