[firebase-br] FW: Tamanho do DB

Marcelo Richter marcelo em brs.ind.br
Seg Maio 31 15:58:37 -03 2010


Elton,

1) Sweep Interval = padrão, nunca foi alterado = 20.000

2) Realmente as páginas não estão totalmente preenchidas, gostaria também de
entender o motivo :)

3) Este número de transações não se iniciou em 1 no teste. Usei o mesmo DB
para fazer o desenvolvimento do sistema, acabei esvaziando ele e uso para
novas instalações. Mas vazio ele mostra 0 páginas alocadas para as tabelas
A, B e C.

4) Compreendo a diferença do Commit e CommitRetaining. Foi apenas um teste
para verificar se fazia alguma diferença. Não fez. Comentei que pretendia
fazer da mesma forma que o exemplo que deu (usando commit e depois iniciando
uma nova transação).

5) Vou verificar o motivo de não funcionar o restore, mas ele dá um erro ao
alterar o acesso para uma das procedures (GRANT).

Marcelo


> -----Original Message-----
> From: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br]
On
> Behalf Of Elton da Motta Barbosa
> Sent: segunda-feira, 31 de maio de 2010 15:13
> To: lista em firebase.com.br
> Subject: [firebase-br] FW: Tamanho do DB
> 
> Olá Marcelo,
> 
> > Elton,
> >
> > As informações do IBOConsole são as mesmas do gstat:
> >
> 
> Ahh legal. Eu não costumo usá-lo como mencionei antes. Mas
> provavelmente ele use algum componente administrativo IBO para acessar
> os dados.
> 
> > Database header page information:
> > 	Flags			0
> > 	Checksum		12345
> > 	Generation		157093
> > 	Page size		4096
> > 	ODS version		11.1
> > 	Oldest transaction	157084
> > 	Oldest active		157085
> > 	Oldest snapshot		157085
> > 	Next transaction	157087
> > 	Bumped transaction	1
> > 	Sequence number		0
> > 	Next attachment ID	2162
> > 	Implementation ID	16
> > 	Shadow count		0
> > 	Page buffers		0
> > 	Next header page	0
> > 	Database dialect	3
> > 	Creation date		Dec 3, 2009 12:03:18
> > 	Attributes		force write
> >
> 
> Não achei a informação sobre o sweep.
> Costuma aparecer assim
>     Variable header data:
>         Sweep interval:         20000
>         *END*
> 
>  Ele está desativado? Se estiver desativado, você precisa executá-lo
> manualmente. Assim então está explicado o motivo de seu Banco de dados
> não diminuir.
> 
> > A TABELA_A (dados a cada 5 minutos, para 1 ano):
> >
> >     Primary pointer page: 210, Index root page: 211
> >     Data pages: 1593, data page slots: 1593, average fill: 60%
> >     Fill distribution:
> > 	 0 - 19% = 1
> > 	20 - 39% = 0
> > 	40 - 59% = 1587
> > 	60 - 79% = 5
> > 	80 - 99% = 0
> >
> > A TABELA_B (1 dado a cada dia do ano)
> >
> >     Primary pointer page: 227, Index root page: 228
> >     Data pages: 365, data page slots: 697, average fill: 8%
> >     Fill distribution:
> > 	 0 - 19% = 365
> > 	20 - 39% = 0
> > 	40 - 59% = 0
> > 	60 - 79% = 0
> > 	80 - 99% = 0
> >
> > E a TABELA_C (1 dado a cada mês do ano)
> >
> >     Primary pointer page: 231, Index root page: 232
> >     Data pages: 3, data page slots: 3, average fill: 13%
> >     Fill distribution:
> > 	 0 - 19% = 3
> > 	20 - 39% = 0
> > 	40 - 59% = 0
> > 	60 - 79% = 0
> > 	80 - 99% = 0
> >
> > Agora pergunto...por que a média de preenchimento da página é tão baixo?
Há
> > alguma coisa a fazer para aumentar isto? Somente considerando o tamanho
dos
> > dados, cada record deveria ter 20 bytes (igual em todas as tabelas), mas
> > ocupa 62 na TABELA_A e muito mais nas demais tabelas.
> >
> Embora vale lembrar que há outros dados na página além dos dados da
> tabela, Note NÃO ocupam 62 bytes na página.
> As páginas não estão totalmente cheias. Algo está impedindo o
> preenchimento total das tabelas. Mas eu não tenho certeza do que possa
> ser. Talvez problemas com o GC ou Sweep. Veja a resposta anterior.
> Também os artigos na Firebase:
> 
> 
> 
> 
> > > Considerando que você tenha um número "X" (xis) de páginas alocadas,
> > > isso significa certamente que sua taxa de bytes/record vai variar
> >
> > 	Concordo, mas porque teria um número maior que o necessário de
> > páginas alocadas? Por que a tabela B aloca 365 páginas e preenche na
média
> > 8% delas? O DB não deveria tentar utilizar o máximo possível da página
antes
> > de alocar outra?
> 
> Sim. Concordo. Mas não posso afirmar com 100% de certeza o motivo de
> não estar fazendo isso. No entanto, um Backup seguido de restore
> resolveria. Veja meus comentários mais abaixo.
> 
> > 	Estes dados para teste foram gerados através de um aplicativo (único
> > acessando a base de dados) para o período de 1 ano.
> > 	Nenhum dado foi apagado da base, deixando páginas vazias...a
> > inserção de todos os dados foi feito em uma única execução do
aplicativo,
> > sem ninguém mais conectado ao DB.
> >
> 
> Uma única conexão? Mesmo assim o gstat mostra 157085 transações?
> 
> > > Não tenho certeza sobre o que disse, mas ao finalizar a inserção, você
> > > também finaliza a transação ou faz o commit do tipo CommitRetaining?
> >
> > 	As procedures que geram os dados da TABELA_B e C, após a inserção na
> > TABELA_A, antigamente usavam o DELETE e depois um INSERT. Isso duplicava
> o
> > tamanho dos dados, pois era necessário manter duas versões do record.
> > 	Ao alterar as procedures para usar o "INSERT OR UPDATE", este
> > problema foi resolvido.
> >
> 
> Embora eu concorde com sua alteração, a antiga forma de trabalho, para
> tabelas com tão pouca moviemtação não era lá de grande disperdício.
> Isso de ter duas versões do record não é problema para o Firebird. Ele
> utilizaria o espaço marcado como antigo assim que possível.
> 
> > 	Quanto ao Commit, o aplicativo que gerou os dados usava um único
> > Commit ao final das milhares de inserções. Alterei ele para
CommitRetaining
> > após cada inserção e não fez diferença alguma. Na operação normal do
> > sistema, pretendo alterar para um Commit, forçando a
inicialização de
> uma
> > nova transação para cada inserção. Utilizo o IBComponents do C++Builder
e
> > todos já sabem a lambança que fazem com as transações. Pretendo alterar
isso
> > futuramente ou utilizar alguma outra solução.
> >
> 
> Não sei se você compreendeu bem a diferença entre um Commit e um
> CommitRetaining. Essa alteração de 1 Commit para 1 CommitRetaining
> após cada inserção não altera o número de transações abertas, e não
> acho que faria alguma diferença para o que você procura. (Corrijam me
> outros caso eu esteja errado)
> 
> A melhor forma de implementar várias inserções é criar uma SQL
> parametrizável e fazer um Commit após um certo número de inserções (de
> 200 em 200 por exemplo). Mas no caso do seu programa que faz inserção
> a cada 5 minutos, o melhor me parece ser:
> 
> 1. AbreTransação
> 2. Insere Dado
> 3. Commit;
> 
> Passa 5 minutos
> 
> 1. abreTransação
> 2. Insere Dado
> 3. Commit;
> Passa 5 minutos
> 
> 1. abreTransação
> 2. Insere Dado
> 3. Commit;
> 
> E por aí vai...
> 
> > > Outra coisa que me ocorreu, o que acontece se você fizer um
> > > Backup/Restore? Qual o seu "Sweep interval" (olhe no gstat -h)?
> >
> > 	Não consigo fazer um backup/restore...estranhamente ocorre um erro
> > em algum trigger durante o restore. Não tive tempo para verificar isso
> > ainda.
> >
> > Abraço,
> >
> > Marcelo Richter
> 
> Rapaz se você não consegue fazer um Backup/Restore essa devia ser sua
> PRINCIPAL preocupação no momento. Isso significa que você tem um Banco
> de dados INCONSISTENTE e possivelmente COM FALHAS!
> 
> Seu problema de páginas mal utilizadas pode ser justamente esse.
> 
> Mande aí um outro e-mail postando os erros que acontecem no
> backup/restore, suas opções usadas no gbak, que o pessoal aqui vai ter
> prazer em ajudar no que for possível.
> 
> Não esqueça de verificar o Sweep Interval. Você não me respondeu sobre
> ele quando perguntei no email anterior.
> 
> abraço,
> 
> ______________________________________________
> 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