[firebase-br] RES: Firebird 2.5 Super Classic - Comportamento Estranho ao UPDATE

[Carlos H. Cantu]

O firebird reutiliza o espaço alocado para as versões temporárias dos
registros, tão logo eles sejam liberados pela coleta de lixo. Se vc
realiza diversas operações que criam novas versões, sem que a coleta
de lixo aconteça nesse meio tempo, obviamente mais páginas serão
alocadas. Isso é normal.

Hoje temos HDs de terabytes, portanto não vejo problema no aumento do
tamanho da base de dados, lembrando que é muito menos custoso para o
firebird reutilizar espaço já alocado do que ficar alocando mais
espaço.

O importante é ter certeza que a coleta de lixo está sendo feita
apropriadamente, e que não haja transações de longa duração impedindo
que ela seja feita por completo.

No seu exemplo com os updates, faça um novo teste:

Rode a primeira sequência de updates, depois commit na transação, e
antes de rodar a próxima sequência de updates, rode um select count(*)
na tabela toda. Isso fará com que a coleta de lixo seja disparada.
Após o select retornar, rode a próxima sequencia de updates, e repita
isso (update -> commit -> select -> commit -> update -> etc) quantas vezes quiser.
Muito provavelmente a base não crescerá na mesma proporção que você reportou
inicialmente.

PS: De preferência, faça o teste com conexão exclusiva, pra evitar que
outras transações possam estar impedindo a coleta de lixo de fazer seu
trabalho.

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


>> > De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Kurt
>> Schneider
>> > Enviada em: sexta-feira, 5 de setembro de 2014 18:10
>> > Para: FireBase
>> > Assunto: [firebase-br] Firebird 2.5 Super Classic - Comportamento
>> Estranho
>> > ao UPDATE
>> >
>> > Prezados
>> >
>> > Bom dia.
>> >
>> > Estou com uma duvida em relação ao processo ou resultado do Statistics do
>> > Firebird, no quesito PageSize (aumento do tamanho da Base de Dados).
>> >
>> >
>> > O servidor onde esta Rodando o Firebird 2.5 SuperClassic é um iCore7, 16
>> GB
>> > de RAM, dedicado somente para o Banco de Dados; O Exe da minha Aplicação
>> é
>> > em Delphi 2007,
>> > usando ADO e ADOQuery. Uso Windows Server 2012 Standart. O Arquivo
>> > firebird.conf não
>> > esta configurado ou " tunado " para esta máquina - esta usando o arquivo
>> > que vem junto na instalação. Sweep esta agendado par todo dia, as 02:00
>> da
>> > manhã
>> >
>> > A Base tem 1.3 GB (Backup e Restore feitos para o Teste que vou
>> > apresentar). O Start do teste
>> > se da com 447 Pages para a Tabela TB_CCLANCA, descrita abaixo, que possui
>> > 18.922 registros Fisicos.
>> >
>> > Pages Size MB (Size / 1024) Slots Fill Records
>> > 447 3.661.824 3.576 447 87 18.922
>> > T1 - 455 (5 Lcto) 3.727.360 3.640 455     88 18.922
>> > T2 - 459 (2 Lcto) 3.760.128 3.672 459   89 18.922
>> > T3 - 466 (6 Lcto) 3.817.472 3.728 466   90 18.922
>> > T4 - 469 (1 Lcto) 3.842.048 3.752 469   90 18.922
>> > T5 - 475 (1 Lcto) 3.874.816 3.784 473   90 18.922
>> > B_R - 477 3.661.824 3.576 447   87 18.922
>> >
>> >
>> > Fiz 5 Testes de UPDATE (T1 a T5), e somente update na tabela, trocando o
>> > conteúdo
>> > de 3 campos
>> >
>> > DataCompensacao
>> > Compensado
>> > Saldo
>> >
>> > Se vocês observarem, a cada T, o Banco vai alocando pages para os Update
>> e
>> > aumentando (Size) o tamanho da Tabela (Fisicamente), sendo que o numero
>> de
>> > registro não aumenta.
>> >
>> > Entendo que sejam necessário alocar recursos para as operações de Update,
>> > mas estes recursos não deveria ser liberados apos o fim do processo?
>> >
>> > Esclarecendo. A minha transação tem inicio e fim, (BeginTrans,
>> > CommitTrans), as querys são
>> > fechadas e destruídas com FreeAndNil e o exe, em tempo de execução, não
>> > ultrapassa os 11 MB. Mesmo ao fechar o EXE, nada muda.
>> >
>> > Realizei as manutenções indicadas, que contemplam SWEEP, Limbo
>> Transaction
>> > e afins.. e a tabela continuou com os mesmo Pages e Size. Só voltou ao
>> > normal quando foi realizado novo Backup - Restore (B_R - 477), voltando
>> > assim ao tamanho original (o que achei que deveria ocorrer após cada
>> > operação de Update).
>> >
>> > Aceito sugestões, indicações de artigos, livros, links... e opiniões dos
>> > colegas, visto que, ao meu entender, caso nao seja feito um backup
>> restore
>> > na base, e eu fizer apenas updates,a  mesma vai aumentar de tamanho em
>> > inserir sequer um registro.
>> >
>> > A titulo de comparação, no ultimo Backpu Restore desta base, Pages estava
>> > 1335, a após o Restore 447.
>> >
>> > Att
>> >
>> > --
>> >
>> > *Kurt Schneider*
>> > Gerente de Programação
>> > (49) 3329 1878 / (49) 9148-4809