[firebase-br] RES: Muitas Versoes

[Moacir - Softin Sistemas]

Daniel,

Após efetuar uma manutenção na base ele também trava ao dar o SELECT?

Att,
Moacir

-----Mensagem original-----
De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Daniel
A.Donaduzzi
Enviada em: terça-feira, 10 de setembro de 2013 10:49
Para: FireBase
Assunto: [firebase-br] Muitas Versoes

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

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

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

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

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

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


*Daniel A.Donaduzzi*
*Diretor*
*
*
*COLET - Sistemas de Gestão Empresarial*
*(51)3097-1210*
______________________________________________
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://firebase.com.br/pesquisa