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 <sergio.tra...@gmail.com>
escreveu:
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 ....
Sérgio, minha intenção aqui é ajudar o Marcio que apareceu com
uma dúvida.
Veja que a coisa mais importante no caso dele é que ele faz o
Vacuum. Isso é a PRIMEIRA coisa que ele deve testar.
Não tenho acompanhado a lista com tanta frequência como eu
gostaria. Talvez algum problema seu tenha passado desapercebido por
alguns gurus aqui da lista. Recomendo enfaticamente tentar as listas
internacionais em casos extremos como o seu. De toda forma, eu jamais
colocaria todas as fichas no vacuum. Veja que eu citei também o
REINDEX[1] e o CLUSTER[2] e de cabeça poderia sugerir para mexer nos
parâmetros de storage de algumas tableas como o parâmetro fillfactor [3]. São algumas sugestões. É claro
que cada aplicação é uma aplicação. Se você realiza cargas monstruosas,
com frequência, realiza DELETEs em % significativa de registros de
grandes tabelas, tudo isso vai fazer o seu banco sofrer (não só o
PostgreSQL, como qualquer outro SGDB).
O
particionamento de tabelas pode lhe ajudar muito também. É sempre um
conjunto de técnicas que são utilizadas para manter um banco de dados
no ar com boa performance. Nunca é um único problema.
Por
fim, dizer publicamente que você precisa realizar um "DUMP, DROP,
CREATE, IMPORT" (estou trocando as palavras "backup" por "dump" e
"restore" por "import" para não fazer confusão com o backup físico)
seja um procedimento recomendável é dizer que o SGDB não presta
definitivamente. Eu não utilizaria um SGDB assim. Espero nunca ter de
me retratar por dizer isso, mas esta é a minha expectativa.
[]s
Fábio Telles
--
blog: http://www.midstorm.org/~telles/
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
|
