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 ....

Já tive um caso onde uma base com quase 200GB sobre a qual era executado vacuum analyse diário, após o BDCR ficou com 80GB.

Outro fato que procurei deixar claro é que uma semana sem o vacuum analyse deixa esta base retornando aos usuários com uma velocidade de 3 a 5 vezes pior e este tempo aumenta proporcionalmente ao tempo em que não é executado até que o banco pode ser considerado "travado". Portanto o vacuum analyse é fundamental, mas infelizmente não faz tudo o que devia, ou não certas "faxinas" não fazem parte das suas atribuições e isto não está corretamente documentado.

Quem tiver olhos para ver, que veja, basta pegar uma base sobre a qual é feito um vacuum analyse diariamente e pegue o tamanho da base. Então faça um BDCR e pegue novamente o tamanho da base. Muita gente não vai acreditar na redução de tamanho e no ganho de performance que isto vai gerar. Experimentem e divulguem seus resultados.

Abraços,
Sergio Medeiros Santi

Em 05/05/2010 20:34, Fábio Telles Rodriguez escreveu:
Em 5 de maio de 2010 17:11, Sergio Santi <[email protected]> escreveu:
Bem, essas informações permitem dar algumas sugestões.

Considerando que o tamanho do banco não é nada demais, mas que o número de usuários é significativo e que não especificasses que tipo de acesso esses 80 usuários fazem eu sugiro o seguinte:

1. Se a empresa para durante a noite faça hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se não der para fazer a noite use o final de semana, um feriado, ...
2. Rotineiramente faça um vacuum analyse no período de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites.

Eu acho que dá até para colocar a mão no fogo que isto vai resolver teu problema, exceto se de algum tempo para cá o volume de dados tenha crescido muito acima da média ou o número de usuários, ou pior ainda ambas as coisas.

Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1.

Não. Isso não é um procedimento razoável. Não dá para imaginar que você precisa recriar o banco de dados toda a semana. Melhor mesmo é descobrir onde está o problema e não dar tiro de escopeta em mosquito.

Você não precisa fazer isso se souber: 
  • Rodar o vacuum e o analyze;
  • Rodar um reindex em objetos específicos em certos momentos;
  • Clusterizar tabelas específicas em certos momentos;
São rotinas de manutenção. Todo SGDB precisa de manutenção. Recriar o banco de dados é como formatar o HD toda vez que o SO dá problema. Sei que tem muita gente que se acostuma com esse tipo de coisa, mas não é algo normal em ambiente corporativo, certo?

[]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


_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a