[firebase-br] RES: Muitas Versoes

Rodrigo Gomes da Silva rodrgomes em gmail.com
Ter Set 10 12:03:18 -03 2013


Vc precisa realmente apagar os registros? Não pode dar update com valores
atualizados? Ao deletar muitos registros de uma tabela ele gera um garbage
violento de registros antigos e ao fazer "select first 1 * from
MMRP_PROJECOES" ele vai fazendo garbage de todos os deletados 1 a 1 ate
encontrar o 1o nao deletado.. por isto a demora. Em uma 2a vez seria rapido.

É meio complicado a situção, comigo acontece regularmente em migracoes de
dados aonde tenho q rodar diversas vezes para acertar alguma coisa apagando
dados antigos. É tão chato que é mais pratico apagar a tabela e recriar, e
qnd não possivel faco um sweep forçado logo apos o delete.

Vc precisa acessar esta tabela de modo linear? Algum acesso dela a todos
registros ficaria lento, ou algo com max que faria passar por registros
deletados... mas um insert simples e depois acesso a registros dela por
meio de indices não daria lentidao. O garbage seria limpo a noite.
Sei la, outra alternativa seria vc deixar se usar ela e fazer procedure
selecionaveis que calcule o conteudo q hoje ela guarda sobre demanda.

Rodrigo


Em 10 de setembro de 2013 11:15, Moacir - Softin Sistemas <
moacir em softin.com.br> escreveu:

> 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
>
>
> ______________________________________________
> 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
>



Mais detalhes sobre a lista de discussão lista