Em 13/12/07, Sergio Medeiros Santi<[EMAIL PROTECTED]> escreveu: > > Pessoal, vou responder meu próprio e-mail para evitar responder um a um. > Desde já o meu obrigado a todos. > > Eu particularmente gosto muito deste trabalho investigativo. Eu também! :-)
Normalmente > quando descobrimos o que houve percebemos que é possível usar a descoberta > em outros pontos com expressivos resultados. Infelizmente o PG anda tem > alguns mistérios a resolver. O principal deles é desenvolver um configurador > que reuna informações sobre o hardware e sugira uma configuração razoável. > Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das > apresentações do PGCon a coisa continua mais ou menos igual, não existe > ciência nisto, mas alguma recomendações (poucas infelizmente). > É meu caro... vida de DBA é difícil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parâmetros documentados, fora uma miríade de parâmetros que só eles conhecem (medo!). Não há muito como fazer uma configurador automático confiável. Houve uma thread na lista pg_performance há uns meses atrás com um esquema para sugerir algumas configurações. Sei que o pessoal da SUN e da EnterpriseDB também está correndo atrás disso. Mas mesmo assim não é algo simples. Um bom DBA sempre vai fazer seus próprios testes e não irá nunca confiar num configurador automático. É claro que seria um bom ponto de partida ou algo melhor que nada para quem não tem experiência. Mas quando você tem um banco de dados maiores (em volume de dados, conexões ou complexidade de consultas), só mesmo um bom DBA salva a pátria. Nenhum fornecedor de SGDB conseguiu substituir a inteligência do DBA até hoje... e olhe que eles vivem tentando e prometendo isso! > - Fábio. O autovacuum não é utilizado, mas diariamente é disparado um > backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, > mas este foi abandonado porque em algumas oportundades ele não terminava e o > banco ficava travado para os usuário no dia seguinte. O que tenho procurado > fazer é um backup seguido de restore com alguma periodicidade. Alias é este > procedimento que me fez questionar esta aplicação de constraint absurdamente > lenta. Bom, uma vez que o autovacuum está desligado, mas você tem problemas com o vacuum full (que realmente não deve ser realizado com frequência), sugiro você exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. É uma operação realmente delicada, mas se houver algum problema na estrutura de armazenamento, você deve resolver com isso. Espero que você tenha um ou mais discos/partições para seus dados. Se for o caso, bem, seria o caso de desmontar a partição e fazer uma varredura no disco (antes de recriar o cluster), só para ter certeza de que está tudo bem e você não tem nenhum bad block no caminho. Aliás, qual FS você está utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estará na hora de uma investigação realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
