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

Moacir - Softin Sistemas moacir em softin.com.br
Sex Set 5 18:20:49 -03 2014


Kurt,

O firebird trabalha com versionamento de registros, ou seja, a cada
update/delete que você realiza, o mesmo
Cria um novo registro.É o famoso garbage(lixo). Por isso, quando você
realiza Backup/restore estes lixos são removidos fisicamente.

Att,
Moacir



-----Mensagem original-----
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

*www.controlsoft.com.br <http://www.controlsoft.com.br>*
______________________________________________
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