Fabrízio de Royes Mello escreveu: > 1) Atualmente tenho o seguinte cenário de manutenção nas bases de dados > que gerencio: > > - auto_vacuum ativo > - vacuum analyze diário Por quê? Talvez a sua configuração esteja inadequada para tal cenário. Se o autovacuum está bem configurado você não precisa dessa rotina diária mas...
> - vacuum full analyze uma vez por semana > Por quê? O VACUUM FULL vai ficar obsoleto [1] daqui a algumas versões. Eu *nunca* recomendo o seu uso. Ao invés dele, utilize CLUSTER + REINDEX. > - PostgreSQL 8.2 Sugiro atualizar para 8.4. O autovacuum tem sérios problemas de escalabilidade até a 8.2; a partir da 8.3, a arquitetura do autovacuum mudou permitindo que ele ficasse mais robusto. Além disso, os parâmetros padrão do autovacuum da 8.2 são _muito_ agressivos para alguns cenários; os parâmetros do 8.3 já são mais conservadores. > Minha dúvida é relativa ao REINDEX... ele é realmente necessário dentro > dessas atividades de manutenção que realizo?? Caso positivo como eu devo > inseri-lo nessa programação? > Depende de quanto os seus índices estão inchadas (aka bloat). Vide [2] para saber quais os índices estão nessa situação. > Outra dúvida que tenho, e até pode parecer meio óbvia, é que se tenho o > auto_vacuum ativo creio que um VACUUM ANALYZE diário não é mais > necessário... correto? Pergunto isso pois há pouco tempo tenho > utilizado, e com bastante sucesso, o auto_vacuum = on, mas como > anterioremente eu não o utilizava e executava um VACUUM ANALYZE diário > este ficou assim mesmo... > Sim, o autovacuum executa ANALYZE, VACUUM ou VACUUM ANALYZE internamente. > 2) Outro cenário que tenho é o seguinte (esse cenário é mais problemático): > > - auto_vacuum desativado > - vacuum analyze diário > > - PostgreSQL 8.2 > - Sistema Operacional Windows 2003 Server > - OLTP > Como disse acima, migre para o 8.4. Especialmente utilizando SO Windows. Lembre-se que o 8.2 é a _última_ versão suportada nessa plataforma. Nessa plataforma, eu sempre executaria a última versão do PostgreSQL pois várias melhorias foram propostas ao longo das versões e, também, por ser a _última_ plataforma portada. > Nesse cenário o que tem acontecido é uma degradação gradual da > performance do PostgreSQL, tornando a base de dados maior (ocupação em > disco) os dumps e vacuums mais demorados (e por momentos o vacuum parece > travar na sua execução) e que aparentemente acaba se resolvendo > simplesmente com um DROP DATABASE e pg_restore. > Ugh? Como assim travamentos? O que os logs dizem? [1] http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959 [2] http://bucardo.org/check_postgres/ -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
