Na verdade sua base não tinha 200GB e sim 80GB como vc disse. Tenho 1TB de base, que cresce en torno de 100 milhoes de registros mes. Nunca faço um BDCR.
Qdo crio uma replica nova ele continua com os mesmo 1TB. Então tinha alguma coisa errada nas suas confs do postgressql. Sergio Santi wrote: > > > > > > > > > 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 > > -- View this message in context: http://old.nabble.com/RES%3A-Melhorando-o-desempenho-do-PostGre-tp28454186p28473297.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
