Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?

[Sergio Medeiros Santi]

Fábio! Pelos seus comentários imagino que você imagine que o postgres está rodando em linux, o que não é verdade. Alias este é um dos problema de se recortar uma mensagem. Detalhes relevantes acabam cortados. Tudos que citei até o momento está sendo testado em W2K. Notei esta demora quando em uma manutenção preventiva, fiz um backup, dropei o banco e fiz o restore. A pesar do banco ser grande achei o tempo de restore demasiado grande. A partir da comecei a realizar testes em um servidor backup que não está em produção, com isso tenho a certeza de que nenhum outro processo o está acessando. Como testei em dois servidores com processadores, memória e disco distintos não acredito que o problema advenha de alguma falha física. Inclusive o servidor em produção é um dual xeon, 4G, SAS e o backup é um xeon, 2G, SAS e diferença entre eles no tempo total de execução é inferior a 10%. Eu particularmente suspeito que ou é uma mancada minha ou do postgres está sendo exercitado em algum ponto cego e desconhecido que produz esta preformance incompatível com o banco. Se ele levasse 85% do tempo total para criar um índice eu até poderia engolir, mas para aplicar uma constraint que relaciona um campo que possui índice com outro que é chave primária ... tá difícil. Mas ainda tenho testes a realizar ... espero, em breve, dar notícias conclusiva. Como eu, não desanimem, e continuem enviando sugestões. Abraços, Sergio Medeiros Santi Fabio Telles escreveu: 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

_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral