|
E eu concordo com você. E antes de descobrir que um BDCR "enxugava" a base eu e pelo menos outras 3 pessoas passamos algumas semanas debruçados sobre o material gerado pelo vacuum analyse, os logs do banco, enviando e-mail para esta lista, lendo as respostas, enfim fazendo de tudo para achar um procedimento que resolvesse o problema e que fizesse sentido. Conseguimos um paliativo que resolveu o problema (o tal BDCR) e continuamos trabalhando no que faça sentido. O pgagent não é utilizado. Boas soluções é o que todos queremos, mas é preciso manter o paciente vivo para termos tempo de pedir os exames necessários e então chegarmos a tão desejável solução ... Abraços, Sergio Medeiros Santi Em 06/05/2010 11:45, mateusgra escreveu: Concordo com Telles. Acho que o ideal antes de fazer um BDCR é achar o problema. Analisar o resultado dos vaccum analyze. Ja vi o pgagent inchar a base ele usa o pgagent ? Vericar se as tabelas temporarias estão sendo deletadas com o fechamento da sessão.Não quero gerar polemica e sim entender o problema e achar uma solução menos drastica. Fábio Telles Rodriguez wrote:Ok, você respondeu de forma equilibrada. Ponto para você. De toda forma, recomendo encaminhar o problema numa lista internacional. Pode ser mesmo que o você tenha encontrado algum problema crônico no PostgreSQL que valha a pena ser investigado e talvez até que uma melhoria nele deva ser desenvolvida. Pode ser também que algum ajuste passou desapercebido. Pode ser. De toda forma, sempre vale a pena ir atrás para descobrir a raiz do problema. Sei que nem sempre temos tempo para isso, mas se um dia destes tiver, recomendo entrar na http://archives.postgresql.org/pgsql-performance/e reportar o seu problema. Vale a pena também brigar com o fornecedor para homologarem uma nova versão do PostgreSQL. É bem possível que o seu problema tenha sido resolvido numa versão mais nova, quem sabe? Um grande abraço, Fábio Telles Em 6 de maio de 2010 11:14, Sergio Santi <[email protected]> escreveu:Fábio, minha intenção é a mesma tua, isto é, ajuda, mas de boas intenções o inferno está cheio e pode estar sendo o meu caso. No caso em questão o mal-falado BDCR me "manteve vivo" e em condições de procurar alternativas para esses e outros problemas que ainda tenho classificados como "inexplicados". Para você e os demais terem uma idéia: 1. Bases grandes que não são "enchugadas" pelo vacuum, mas que o são por um BDCR. 2. Vacuum que leva de 6 a 8 horas rodando, mas que após um restart do servidor rodam em 2 horas. 3. Índices não utilizados pelo otimizador que "escolhe" usar caminhos inexplicáveis e onerosos. 4. Critérios para definição de parâmetros do postgresql.conf. Todos esses temas já foram discutidos diversas vezes nesta excelente e por vezes salvadora lista e esses e outros casos que não lembro, muitas vezes são difíceis ou demorados de reproduzir e todos nós temos, via de regra, pouco tempo disponível, então o assunto acaba se esvaindo e a pobre vítima que se deparou com o problema precisa dar um jeito de sobreviver. Por exemplo, acredito que o particionamento de tabelas que estamos projetando possivelmente resolva ou atenue um ou mais desses problemas, mas isto quer dizer que contornei o problema e não que o identifiquei e resolví. Assim não acho que usar um BDCR em determinados casos e enquanto uma solução elegante não aparece seja um demérito ao banco. Pode ser um demérito nosso que ainda não achamos a solução adequada (por falta de tempo, etc), mas não do banco que utilizo largamente. A propósito é o único banco que tenho homologado com nosso ERP, mas isto não quer dizer que não existam coisas a serem criadas, melhoradas e corrigidas, que o digam as versões e releases ... Não quero polemizar com esse assunto, mas acho que temos que achar outra forma, mais produtiva de RESOLVER / encaminhar este tipo de caso que por vezes ocorre, porque normalmente as pessoas acabam cansando/desistindo de discutir o caso quando o esforço é grande e os resultados pequenos ou inexistentes e mais adiante o problema volta pelas mãos de outro membro. abraços, Sergio Medeiros Santi Em 06/05/2010 10:22, Fábio Telles Rodriguez escreveu: Em 6 de maio de 2010 08:48, Sergio Santi <[email protected]>escreveu: |
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
