[firebase-br] RES: Estrutura do FB [era: Garbage Collection eSWEEP?????]

Ter Out 3 11:44:07 -03 2006

Nossa, eu não sabia disso tudo... só tinha ideia do que era... isso ira
resolver alguns problemas que tenho tido com varios clientes...

como seria um comando para dizer ao gfix para executar o sweep no banco de
dados quando executado?

Sucesso com o Firebird!

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Marcio Roberto Chiaveli
Enviada em: terça-feira, 3 de outubro de 2006 11:37
Para: FireBase
Assunto: Re: [firebase-br] Estrutura do FB [era: Garbage Collection
eSWEEP?????]

Eduardo muito obrigado, entendi o que precisa entender.
Parabens e sucesso.

2006/10/3, Eduardo Jedliczka (TeamFB) <jedyfb em gmail.com>:
> Depende do objetivo do sistema.
>
> Páginas grandes logicamente cabem mais informações, e faz com que exista
> menos links para continuidade dos dados em outras páginas. Numa única
> leitura, mais dados vem para memória. Em resumo, melhor desempenho num
> select.
>
> Páguinas pequenas, forçam a adoção de mais páginas e links entre elas para
> armazenar os dados, com isto, haverá menos lixo em cada página, e menor
> desperdício de tempo para encontrar um lugar vago para guardar informações
> de um insert ou update. Em resumo, melhor desempenho para aplicações com
> muitas alterações.
>
> Além do tamanho da página, existe o tamanho do cluster do sistema
> operacional, para otimizar a leitura é recomendado que eles sejam do mesmo
> tamanho. Isto causa um impacto sutil no desempenho de um banco grande, e
não
> é tão percepitível se o banco couber inteiro na memória (leia-se na cache
do
> SO).
>
> Sendo assim, valor como 4KB é interessante (bem equilibrado), mas muitos
> dizem que 8KB geram melhor desempenho (geralmente se tem muito mais
> consultas do que inserts num banco de produção). Acho que o interessante é
> cada um testar o seu banco com configurações diferentes e chegar a uma
> conclusão.
>
> ======================
> Eduardo Jedliczka
> Membro do TeamFB - FireBase
> Apucarana - PR
> ======================
> "Posso não concordar com nada do que dizes.
> Mas defenderei até a morte o seu direito de dizê-lo"
> (Voltaire 1694-1778)
> ----- Original Message -----
> From: "Marcio Roberto Chiaveli" <marcio.chiaveli em gmail.com>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Tuesday, October 03, 2006 10:50 AM
> Subject: Re: [firebase-br] Estrutura do FB [era: Garbage Collection e
> SWEEP?????]
>
>
> Obrigado Eduardo, me esclareceu bastante, era isso mesmo que eu
> precisava entender. Quanto as páginas, qual seria um valor adequado ou
> em que situação eu deveria altera-las.
>
> 2006/10/3, Eduardo Jedliczka (TeamFB) <jedyfb em gmail.com>:
> > Marcio,
> >
> > Acredito que você terá muitas dúvidas iniciais, pois o FireBird utiliza
um
> > paradigma de estrutura e gerenciamento de dados muito diferente dos
demais
> > SGDBs.
> >
> > Ele trabalha com o conceito de páginas.
> >
> > Uma página contém informações diversas como: informações de metadata,
> > tabelas de sistema, tabelas comuns, índices, stored procedures,
triggers,
> > views, etc..
> >
> > Uma página pode ter 1024 bytes, 2048, 4096, 8192 ou 16384 bytes.
> >
> > O banco gerencia sozinho quantas páginas ele precisa e de qual tipo
> > precisa.
> > Quando há falta de espaço, o arquivo Físico cresce, criando assim novas
> > páginas. Sendo assim 1 página pode guardar informações de vários indices
> > ou
> > de um único índice, e um índice pode usar várias páginas. A mesma coisa
> > vale
> > para um registro de uma tabela. Ela pode estar numa única página, ou em
> > várias páginas. E várias tabelas podem ter informações na mesma página.
> >
> > Quando um update é executado (ou um delete) as informações são
armazenadas
> > em locais diferentes dos utilizados originalmente, o que pode fazer com
> > que
> > o banco cresça um pouquinho, pois as informações antigas ainda são
> > importates, pois o cara pode dar um rollback, ou alguém pode estar
fazendo
> > um relatório analítico de 900 páginas que precisa das versões. Isto é
> > definido pela transação.
> >
> > Quando se cria uma transação (em FB todo e qualquer comando SQL, mesmo
um
> > select roda dentro de uma transação) o banco "congela" os dados, para
que
> > os
> > dados continuem íntegros (mesmo que momentaneamente defasados).
> >
> >  Após concluir uma transação, seja via rollback ou via commit, o banco
> > verifica quais lugares destas páginas não são mais necessários, e marca
> > aquilo como LIXO.
> >
> > Por isto, quanto mais longa as transações, mais o banco vai crescer e
> > ficar
> > lerdo, pois haverá muitas versões dos mesmos dados.
> >
> >  O Sweep, processo de reorganização da página e liberação do "lixo",
deve
> > ser realizado com alguma freqüência, para o banco reaproveitar o espaço
> > interno. No FB SuperServer, ele é automático (mas dá para desligar ou
> > alterar o valor), e executado geralmente a cada 20 mil transações
> > finalizadas. No FB classic, a coleta é feita a cada select que corre
> > aqueles
> > dados. Isto mantém o banco mais limpo, mas dependendo da quantidade de
> > usuários, e lixo gerado, pode ficar muito mais lento que o SuperServer,
> > mas
> > há casos em que a recíproca também é verdadeira, pois haverá muitas
> > versões
> > concorrentes a menos, ou seja, o acesso será mais imediato.
> >
> > De qualquer forma, dá para usar o GFIX e fazer o Sweep num horário
> > oportuno.
> >
> > Fazer o Garbage Colection no backup, indica basicamente que seu backup
não
> > irá levar informações desnecessárias (mas ele faz mais coisas), e NÃO É
de
> > forma alguma a mesma coisa que um SWEEP.
> >
> > Isto já deve te dar uma idéia inicial, qualquer coisa, é só perguntar.
> >
> > ======================
> > Eduardo Jedliczka
> > Membro do TeamFB - FireBase
> > Apucarana - PR
> > ======================
> > "Posso não concordar com nada do que dizes.
> > Mas defenderei até a morte o seu direito de dizê-lo"
> > (Voltaire 1694-1778)
> >
> > ----- Original Message -----
> > From: "Marcio Roberto Chiaveli" <marcio.chiaveli em gmail.com>
> > To: "FireBase" <lista em firebase.com.br>
> > Sent: Tuesday, October 03, 2006 9:46 AM
> > Subject: Re: [firebase-br] [Firebase] Garbage Collection e SWEEP ?????
> >
> >
> > Quando voce fala que o valor padrão para iniciar o sweep é 20.000, o
> > que significa este valor?
> >
> > Em 02/10/06, Sandro<oleber_itajai em yahoo.com.br> escreveu:
> > > O sweep é um processo de limpeza do banco de dados. Através dele, o
> > > Firebird
> > > libera espaços que não serão mais utilizados para que possam ser
> > > reaproveitados no servidor. Diferente do processo automático de
Garbage
> > > Collection, o sweep processa também os registros que foram descartados
> > > devido a um rollback de uma transação. O valor padrão para iniciar o
> > > sweep
> > > automático é 20.000, ou seja, quando a diferença entre o ID da próxima
> > > transação e a OIT for igual a 20.000, o sweep será disparado.
> > > Obviamente,
> > > após o término do sweep, o número da OIT será avançado.
> > >
> > > Fonte : Dbfreemagazine
> > >
> > >
> > > ----- Original Message -----
> > > From: "Marcio Roberto Chiaveli" <marcio.chiaveli em gmail.com>
> > > To: "FireBase" <lista em firebase.com.br>
> > > Sent: Monday, October 02, 2006 3:51 PM
> > > Subject: [firebase-br] [Firebase] Garbage Collection e SWEEP ?????
> > >
> > >
> > > Boa tarde Pessoal,
> > >
> > > O que é Garbage Collection e SWEEP no FB.
> > >
> > > ______________________________________________
> > > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > > Para editar sua configuração na lista, use o endereço
> > > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> > >
> > >
> > >
> > > _______________________________________________________
> > > Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu
> > > celular.
> > > Registre seu aparelho agora!
> > > http://br.mobile.yahoo.com/mailalertas/
> > >
> > >
> > >
> > >
> > > ______________________________________________
> > > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > > Para editar sua configuração na lista, use o endereço
> > > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> > >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para editar sua configuração na lista, use o endereço
> > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para editar sua configuração na lista, use o endereço
> > http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>

______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
Para consultar mensagens antigas: http://firebase.com.br/pesquisa