[firebase-br] Muitas Versoes

[Carlos H. Cantu]

Quando você deleta uma grande quantidade de registros em uma tabela, o
espaço que eles ocupavam só poderá ser reaproveitado após a coleta de
lixo. Isso pode ocorrer quando o sweep é executado, ou quando um
comando (ex: select) é disparado contra a tabela. O fato é que em
ambos os casos, a coleta só será realizada nesses registros se não
houver transações abertas ainda interessadas neles.

O sintoma que vc descreve é justamente a coleta de lixo acontecendo.
Parece que travou, mas na verdade o que está ocorrendo é a coleta de
lixo... se vc tiver paciência de esperar, verá que depois de um tempo
(que varia de acordo com a qtde de registros, indices, etc) o sistema
voltará a responder.

Meu conselho para você é estudar a possibilidade de usar uma GTT no
lugar dessa tabela. Se não for possível, agende um sweep manual de
madrugada ou num horário onde o servidor esteja ocioso e tenha certeza
que nesse horário não exista transações ativas que possam bloquear a
coleta de lixo na tabela em questão. Se for viável, rode um "delete
from mon$attachments" antes de rodar o sweep, pra derrubar qualquer
conexão que ainda exista. Vc diz que já faz um sweep de madrugada,
então provavelmente a coleta não está sendo feita por ele devido a
transações ativas que impedem que a coleta seja realizada de forma
completa.

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

DAD> Tenho em meu sistema de MRP uma tabela com 2.134.102 registros. Esta tabela
DAD> é usada no cálculo do MRP, é diariamente neste processo todos os seus
DAD> registros são apagados, em seguida eles são recriados para o novo período
DAD> com valores zerados, e em seguida atualizados com base na situação atual
DAD> das ordens de produção e de compra e na posição de estoque da empresa. O
DAD> processo de cálculo é feito através de diversas stored procedures e
DAD> triggers que atualizam estes registros. Este processo é disparado pelo
DAD> Delphi e está todo ele dentro de uma transação, sendo dado commit no final
DAD> do processo. Usamos dbx.

DAD> O processo todo funciona legal, porém tem um problema. Acredito que tenha a
DAD> ver com as Versões de registros, e o fato de eu deletar frequentemente
DAD> todos eles. O processo de cálculo funciona legal, até que fazemos um
DAD> recálciulo de estatísticas de indices, que tem sido feito uma vez por mes,
DAD> em média. Na verdade não sei se é devido a isto, ou se é apenas pelo fato
DAD> de parar o banco e reinicia-lo que causa o problema, mas é o seguinte: Após
DAD> fazer esta parada, ao retornar o sistema, ao acessar esta tabela o sistema
DAD> simplesmente trava, congela. Se eu der o seguinte comando:
DAD> select first 1 * from MMRP_PROJECOES
DAD> ele já congela. Eu acreditava que ele estava fazendo sweep automatico, por
DAD> isto desativei o sweep automatico ele e passei a fazer à noite, antes do
DAD> backup. Mas, não resolveu. E já ficamos esperando MUITO tempo para ver se
DAD> voltava, mas não retornou, só matando o processo do usuário conseguimos
DAD> voltar. Porém, se acessarmos novamente a tabela, o mesmo travamento
DAD> acontece... A única solução que tenho encontrado é recriar a tabela, e em
DAD> seguida fazer novo cálculo. Mas, devido às inúmeras dependencias, temos que
DAD> dropar e depois recriar diversas outras tabelas, procedures e triggers...

DAD> Eu até adquiri o IBAnalyst (da IBSurgeon) para tentar entender o que
DAD> acontece, e ele nos reporta o seguinte a respeito desta tabela, em sua
DAD> análise (situação após alguns cálculos efetuados):

DAD> "...
DAD> Massive deleted/updated tables: 3.
DAD> These tables have version count more than 1000, and version count is
>> 10% than record count. Also there are maximum 1 version (MaxVer)
DAD> for each record. All these conditions points that there were "packet"
DAD> deletes/updates applied on that tables.
DAD> This can affect performance in two ways:
DAD> 1. Versions will not be garbage collected until they are read. So
DAD> table size will remain the same. If you will run backup without -g
DAD> option right now, it will inhibit garbage collection, and backup
DAD> process will last much longer than usual.
DAD> 2. Reading record versions can cause garbage collection. If there are
DAD> non-unique (bad) indices on that table, garbage collection will be
DAD> very slow.
DAD> If Record length less than Version length - there are deletes.
DAD> Otherwise versions generated by update.

DAD> Here is the list of tables that have a lot of updates/deletes:
DAD> Table                    Records Versions   RecVer  VerLen
DAD> MMRP_PROJECOES         2.134.102 1.920.388    2,79    27,81
DAD> ..."

DAD> Alguem teria alguma dica para me dar sobre como resolver isto ?


DAD> *Daniel A.Donaduzzi*
DAD> *Diretor*
DAD> *
DAD> *
DAD> *COLET - Sistemas de Gestão Empresarial*
DAD> *(51)3097-1210*