[firebase-br] FW: Tamanho do DB

[Marcelo Richter]

Elton,

As informações do IBOConsole são as mesmas do gstat:

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

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. 

> 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?
	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.

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

	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.
 
> 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
marcelo em brs.ind.br