[firebase-br] Sweep

Ter Maio 27 15:01:24 -03 2008

Exatamente nos termos que você quer saber, não há como... mas
experimente utilizar frequentemente um gstat -h para entender como as
coisas funcionam...

sucesso,

Eduardo Jedliczka

Em Ter, 2008-05-27 às 11:26 -0300, Maciel Soncini Bueno escreveu:
> Saudações,
> 
> Existe alguma maneira de saber se o Sweep manual foi realizado, se foi realizado com sucesso e o que o mesmo fez no banco?
> 
> Atenciosamente,
> 
> Maciel Soncini Bueno
> 2M SOLUTIONS
> 11-4438-6891 / 8555-8507
> maciel em 2msolutions.com.br
> www.2msolutions.com.br
> 
> 
> 
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em nome de Eduardo Jedliczka - TeamFB
> Enviada em: segunda-feira, 26 de maio de 2008 20:52
> Para: FireBase
> Assunto: Re: [firebase-br] RES: Lentidão
> 
> Maciel, fiquei muito satisfeito de ver suas respostas... mais uma vez,
> peço-lhe desculpas pela aspereza em lhe responder (infelizmente, meu
> excesso de objetividade, causa muitas vítimas).
> 
> Sobre livros e documentação este é um problema sério do Firebird (à
> exemplo de muitas outras ferramentas open-source excepcionais), mas
> sugiro participar mais de fóruns (como este aqui, que há muitas pessoas
> capacitadas) e ler os livros do CANTU e da Hellen Borrie (Dominando o
> Firebird)... há alguns PDFs e artigos interessantes nos poucos sites
> específicos sobre firebird... Um ponto de partida é o próprio site da
> Firebase. outra sugestão é o site da IBPHOENIX (há artigos antigos quase
> todos pré-FB 1.0, mas muita informação importante sobre modelo
> transacional e garbage pode ser conseguido), porém toda documentação
> está em inglês.
> 
> Para ajudar, também há muitos problemas (quase todos relacionados à
> performance, por culpa do CommitRettaining) na dobradinha DBX +
> Firebird, e aparentemente aqui está o seu problema.
> 
> Como sugestão, experimente isolar transações de consulta das transações
> de manutenção (insert, deletes e updates). Sei que o DBX não possui
> auto-commit pois um hard commit fecha o dataset. Muitos desenvolvedores,
> diante desta informação, fazem uma especialização da query carregando os
> dados de um select dinamicamente para uma "Memory Table" fechando
> imediatamente a transação (e fazendo todos os sorts e buscas em
> memória). Mas é claro que isto funciona para pequenos volumes de
> informação, ou em parceiria com filtros extremamente eficases (limitando
> o máximo de informação num grid em menos de 200 linhas)
> 
> Antes de migrar do SuperServer para o Classic Server, recomendo que você
> procure entender bem as diferenças entre eles (e são muitas), não se
> envergonhe de perguntar na lista sobre pontos que não estejam claros (e
> a maioria das pessoas tem dificuldades ou dúvidas com o Classic). Comece
> estudando o Firebird.Conf (há muita informação lá) pois, diferente do
> SuperServer, o Classic exige o ajuste de alguns parâmetros para
> funcionar a contento.
> 
> A mesma regra acima vale ao trocar o firebird 1.5 pelo 2.0 ou 2.1. Há
> muitas coisas a considerar, e pode ser que a performance melhore muito,
> mas há muitos relatos (todos com o 2.0) de degradação de performance
> após a migração, pois tanto a construção do índice, quanto a adoção ou
> não dos mesmos foi extensamente trabalhada entre estas versões. Devido
> ao parâmetro do FB 2.1 para "relaxar" a ambiguidade de apelidos de
> tabelas, acho mais seguro e melhor migrar do 1.5 diretamente para o FB
> 2.1, mas deve-se prestar a atenção sobre a existência de collate nas
> tabelas de sistema, algo inexistente nas versões anteriores do FB.
> 
> Se os seus índices (todos eles, pks, fks, indexes) forem simples
> (principalmente com um único campo, ou com poucos campos) você terá um
> maior ganho de performance na migração, se os seus índices forem
> complexos (mais de 3 campos) você poderá perder performance - mas aqui
> depende de características do seu sistema, que só poderam ser definidas
> após uma análise mais profunda.
> 
> Mas o FB 2.1, por ter sido lançado recentemente, não está 100% livre de
> problemas... provavelmente teremos, ainda neste ano, um FB 2.1.1 com
> algumas correções e otimizações.
> 
> Aproveitando, quanto à uma de suas perguntas, o GBAK não interfere no
> resultado do GFIX -SWEEP (desde que não sejam feitos ao mesmo tempo).
> 
> Depois deste pequeno "livro", fico no aguardo de mais perguntas suas
> aqui na lista...
> 
> PS: Todos nós temos muito o que aprender... Não raro vejo situações
> novas aqui na lista que me instigam e rever os meus conceitos ou me
> motivam a descobrir coisas novas. Espero poder aprender muito com este
> seu problema... 
> 
> 
> Sucesso
> 
> Eduardo Jedliczka
> 
> 
> Em Seg, 2008-05-26 às 19:01 -0300, Maciel Soncini Bueno escreveu:
> > Saudações Eduardo,
> > 
> > Primeiramente gostaria de agradecer o seu retorno e dizer que em hipótese
> > alguma fiquei ofendido com seu e-mail.
> > 
> > Sobre contratar um desenvolvedor e um DBA ficará para uma próxima, vez que
> > já temos desenvolvedores/DBA´s na equipe.
> > 
> > O sistema em questão roda em dezenas de clientes e, somente em um está
> > apresentando os problemas mencionados por isso o questionamento para a
> > lista.
> > 
> > Como a lista é aberta para dúvidas de usuários leigos, intermediários,
> > avançados e, Firebird´s Mans que deve ser o seu caso, não me hesitei em
> > montar o e-mail e enviar para a lista.
> > 
> > Assim sendo, vou pesquisar sobre o que escreveu e depois divulgar os
> > resultados obtidos para a lista.
> > 
> > Tomo a liberdade de perguntar / comentar suas linhas:
> > 
> > "- suas transações estão extremamente longas (se é que está controlando
> > isto);"
> > - O que posso considerar como uma transação longa?
> >   Tenho transactions no sistema dentre elas, transactions que podem ficar
> > abertas por 05/10/15 minutos, por se tratar de um módulo de recepção de
> > pacientes (clínicas, hospitais, centros de diagnósticos);
> > "- Não está commitando os SELECTs (ou trabalha com CommitRetainnig com o
> > controle feito pelo DBExpress);"
> > Trabalho com o CommitRetainnig com o controle feito pelo DBExpress. Você
> > pode me sugerir um link ou documentação para que eu possa melhorar ou
> > entender melhor sobre isso?
> > "- Não configurou o horário do SWEEP do banco (deixou automático a cada
> > 20 mil transações);"
> > Estava automático. Já desliguei o automático e coloquei para ser executado
> > diariamente as 22h00. Neste horário não tem ninguém utilizando o sistema.
> > Pergunto: Faz diferença executar o sweep antes ou depois do backup? O gbak
> > está com a cláusula -G.
> > "- Adotou o SuperServer numa máquina dual-core;"
> > Pois é... Já tinha lido sobre o assunto, mas como no servidor antigo estava
> > SuperServer, quando instalaram, fizeram igual. Já estou solicitando a troca
> > de Super Server para Classic Server.
> > Haverá muita vantagem se mudar para o Firebird 2.0?
> > 
> > "- entre outros..."
> > Fale mais sobre entre outros....
> > 
> > "Mas isto é um ponto interessante.... muitas pessoas tem problemas de
> > performance com o FireBird... pois acham que todos os bancos de dados
> > são iguais, ou pior, acham que trabalhar com DBF, paradox ou tabelas em
> > memória é igual a trabalhar com bancos relacionais..."
> > 
> > Eduardo, eu não disse isso. Já trabalhei com DBF, Paradox, Oracle, Sql
> > Server e companhia. Sou fã do Firebird e trabalho com o mesmo desde 2002.
> > 
> > 
> > "o Firebird, quando bem utilizado, tem uma performance impressionante (em
> > rede local é claro... ainda tem um protocolo muito pesado e tagarela
> > para ser utilizado diretamente via internet). Só que muitos fatores
> > colaboram para a frustração dos desenvolvedores/utilizadores. É um banco
> > pequeno, simples, leve, gratuito e fácil de administrar, e por esta
> > razão, muitos não dão a devida importância. Não faze teste de stress,
> > não monitoram índices e principalmente não procuram entender as regras
> > transacionais ou o sistema de Versionning e Garbage Collection."
> > 
> > Como nunca tive problemas, nunca me preocupei mesmo, mas acho que há tempo
> > de melhorar, não é memsmo?!
> > 
> > Se puder me indicar link´s, livros, etc..., que me esclareçam melhor sobre
> > esses assuntos, agradeço.
> > 
> > Até mais,
> > 
> > Atenciosamente,
> > 
> > Maciel Soncini Bueno
> > 2M SOLUTIONS
> > 11-4438-6891 / 8555-8507
> > maciel em 2msolutions.com.br
> > www.2msolutions.com.br
> > 
> > 
> > -----Mensagem original-----
> > De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> > nome de Eduardo Jedliczka - TeamFB
> > Enviada em: segunda-feira, 26 de maio de 2008 14:30
> > Para: FireBase
> > Assunto: Re: [firebase-br] Lentidão
> > 
> > Para resolver seu problema, contrate um desenvolvedor e um DBA que saiba
> > trabalhar com o FIREBIRD.
> > 
> > Se isto parecer muito radical, recomendo que reveja a forma como o
> > aplicativo é escrito.... Posso estar enganado, mas os sintomas me levam
> > ao seguinte diagnóstico:
> > 
> > - suas transações estão extremamente longas (se é que está controlando
> > isto);
> > - Não está commitando os SELECTs (ou trabalha com CommitRetainnig com o
> > controle feito pelo DBExpress);
> > - Não configurou o horário do SWEEP do banco (deixou automático a cada
> > 20 mil transações);
> > - Adotou o SuperServer numa máquina dual-core;
> > - entre outros...
> > 
> > Mas isto é um ponto interessante.... muitas pessoas tem problemas de
> > performance com o FireBird... pois acham que todos os bancos de dados
> > são iguais, ou pior, acham que trabalhar com DBF, paradox ou tabelas em
> > memória é igual a trabalhar com bancos relacionais...
> > 
> > o Firebird, quando bem utilizado, tem uma performance impressionante (em
> > rede local é claro... ainda tem um protocolo muito pesado e tagarela
> > para ser utilizado diretamente via internet). Só que muitos fatores
> > colaboram para a frustração dos desenvolvedores/utilizadores. É um banco
> > pequeno, simples, leve, gratuito e fácil de administrar, e por esta
> > razão, muitos não dão a devida importância. Não faze teste de stress,
> > não monitoram índices e principalmente não procuram entender as regras
> > transacionais ou o sistema de Versionning e Garbage Collection.
> > 
> > Espero que não se sinta ofendido, e procure conhecer melhor o produto
> > que pretende utilizar. Abraço!
> > 
> > Eduardo Jedliczka
> > 
> > 
> > Em Seg, 2008-05-26 às 13:15 -0300, Maciel Soncini Bueno escreveu:
> > > Cenário:
> > > 
> > > - Sistema desenvolvido em Delphi 7 com DBExpress.
> > > - Banco de Dados Firebird 1.5 Super Sever.
> > > - Sistema Operacional Linux Debian 2.6
> > > - Processador Xeon Dual Core 2.66 GHZ
> > > - Memória 2 GB RAM
> > > - HD 250 GB SATA
> > > - Placa de Rede 1 Gigabit com servidor ligado a porta de 1 gigabit no
> > > switch.
> > > 
> > > Situação:
> > > 
> > > - Sistema muito lento.
> > > - Retorno das querys muito lento.
> > > - Reinicia o servidor e melhora, mas no dia seguinte está ruim novamente.
> > > - Já reconstruí o banco e não melhorou.
> > > 
> > > O que posso fazer para melhorar?
> > > Qual versão do Fireibird instalar?
> > > Qual modalidade (Super Server ou Classic)?
> > > Qual Page Size definir?
> > > Se instalar Firebird 2.0 deve atualizar os client´s também?
> > > Devo fazer alguma atualização no DBExpress se migrar para versão 2.0?
> > > Deve mexer alguma coisa no setup da máquina (bios) para melhorar a
> > > performance?
> > > 
> > > Já vi vários tópicos na lista sobre este assunto, mas se puderem me ajudar
> > > agradeço.
> > > 
> > > Atenciosamente,
> > > 
> > > Maciel Soncini Bueno
> > > 2M SOLUTIONS
> > > 11-4438-6891 / 8555-8507
> > > maciel em 2msolutions.com.br
> > > www.2msolutions.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
> > 
> > 
> > ______________________________________________
> > 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
> > 
> > 
> > ______________________________________________
> > 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
> 
> 
> ______________________________________________
> 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
> 
> 
> ______________________________________________
> 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