Uma ação importante, é analisar as consultas que representam um uso em maior escala pelos usuário de uma empresa antes de sair criando indices ou mesmo ações desesperadoras. Esta semana, consegui melhor em muito consultas que estavam muito lentas. Em uma delas foi anulado alguns relacionamentos *left join *e outras um simples indices que realmente precisava resolveu o problema de lentidão. É como disse um dos parceiros desta discursão, *"Cada caso é um caso"* * *Marcos André G.A Trabin Softwarre & Consulting
Em 5 de maio de 2010 23:11, Marcos - GMail <lgerardlu...@gmail.com>escreveu: > Uma ação importante, é analisar as consultas que representam um uso em > maior escala pelos usuário de uma empresa antes de sair criando indices ou > mesmo ações desesperadoras. Esta semana, consegui melhor em muito consultas > que estavam muito lentas. Em uma delas foi anulado alguns relacionamentos > *left join* > > Marcos André G.A > Trabin Softwarre & Consulting > > > > Em 5 de maio de 2010 20:34, Fábio Telles Rodriguez <fabio.tel...@gmail.com > > escreveu: > >> Em 5 de maio de 2010 17:11, Sergio Santi <sergio.tra...@gmail.com>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/<http://www.midstorm.org/%7Etelles/> >> e-mail / jabber: fabio.tel...@gmail.com >> >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
