Em 6 de maio de 2010 08:48, Sergio Santi <[email protected]> escreveu:
> Primeiramente ninguém disse para fazer backup, drop, create e restore > (bdcr) toda a semana. Eu disse faça hoje a noite se possível, ou no próximo > final de semana. Eu tentei seguir essa teoria da manutenção tradicional, > mas quando isto não resolveu foi necessário apelar para esta medida > paleativa e "absurda", mas que resolveu o caso. > > Posso até concordar que não deveria ser necessário que o vacuum deveria dar > conta disto, mas não dá. Essa discussão já rolou umas duas vezes e ninguém > conseguiu mostrar que este procedimento não é útil de tempos em tempos. Em > bases pequenas não executo nunca, em bases médias (<30GB) 2 ou 3 vezes por > ano, já em bases grandes faço a cada 2 meses se existirem feriados > disponíveis. Na época em que tive essa experiência desagradável busquei > socorro nesta lista, tentei de tudo, e o que manteve o paciente vivo foi > essa "benzedura". Um dia os estudiosos do postgresql vão descobrir uma > explicação científica para isto, mas enquanto isto .... > > Sérgio, minha intenção aqui é ajudar o Marcio que apareceu com uma dúvida. Veja que a coisa mais importante no caso dele é que ele faz o Vacuum. Isso é a PRIMEIRA coisa que ele deve testar. Não tenho acompanhado a lista com tanta frequência como eu gostaria. Talvez algum problema seu tenha passado desapercebido por alguns gurus aqui da lista. Recomendo enfaticamente tentar as listas internacionais em casos extremos como o seu. De toda forma, eu jamais colocaria todas as fichas no vacuum. Veja que eu citei também o REINDEX[1] e o CLUSTER[2] e de cabeça poderia sugerir para mexer nos parâmetros de storage de algumas tableas como o parâmetro fillfactor [3]. São algumas sugestões. É claro que cada aplicação é uma aplicação. Se você realiza cargas monstruosas, com frequência, realiza DELETEs em % significativa de registros de grandes tabelas, tudo isso vai fazer o seu banco sofrer (não só o PostgreSQL, como qualquer outro SGDB). O particionamento de tabelas pode lhe ajudar muito também. É sempre um conjunto de técnicas que são utilizadas para manter um banco de dados no ar com boa performance. Nunca é um único problema. Por fim, dizer publicamente que você precisa realizar um "DUMP, DROP, CREATE, IMPORT" (estou trocando as palavras "backup" por "dump" e "restore" por "import" para não fazer confusão com o backup físico) seja um procedimento recomendável é dizer que o SGDB não presta definitivamente. Eu não utilizaria um SGDB assim. Espero nunca ter de me retratar por dizer isso, mas esta é a minha expectativa. []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [email protected]
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
