from:"Sergio Santi"





Na verdade a nossa empresa desenvolve o ERP que usa exclusivamente o
PostgreSQL e em função dele administramos bases dos mais diversos
tamanhos, servidores linux e principalmente windows, hardware com grife
e outros genéricos, etc.

Não estamos nem num ponto nem no outro. No momento toda base é 8.2.X.
Estamos removendo os motivos que nos impedem de fazer um backup no 8.2
e o restore no 8.4. É só uma questão de tempo. Pouco tempo ... espero.

Abraços,
Sergio Medeiros Santi


Em 06/05/2010 11:56, Fábio Telles Rodriguez escreveu:

  
  Em 6 de maio de 2010 11:43, Sergio Santi <sergio.tra...@gmail.com>
escreveu:
  
Gostei do
ponto ... e como dizia o poeta ...
gentileza gera gentileza ... ponto para você também.


  
  Thanks, :-)
   
  
Tenho a
firme proposição de montar um case com todo o material
necessário para poder oferecer a quem se dispor a analisar a principal
dificuldade é além dos volumes envolvidos a falta de atualização que
esta base de testes teria, mas uma coisa de cada vez ... De qualquer
forma vou me inscrever na lista que sugeristes e começar a me aculturar
com ela.


  
  Boa!
   
  
Não
entendi o que você quis dizer com "brigar com o fornecedor para
homologarem uma nova versão do PostgreSQL"? Se estivéssemos falando de
oracle, db2, ou outros proprietários em teria entendido, mas brigar com
o fornecedor do PostgreSQL?


  
  Hum, acho que me confundi com outra thread. Outra pessoa disse
que utiliza o 8.1.x Se você já utiliza o 8.4, claro que não é problema.
Alguns fornecedores de aplicações como ERPs, demoram muito para
homolgar novas versões do banco de dados. Conheço gente que só homologa
versões de mais de 5 anos. E ainda pagam pela manutenção...
  
  
  A questão é que a cada versão do PostgreSQL, o vacuum tem
melhorado muito. Todos sabem que ele não devia existir, que ele é um
fardo que o PostgreSQL carrega (vide entrevista que fiz com o Josh
Berkus em http://www.midstorm.org/~telles/2007/01/13/entrevista-com-josh-berkus/).
Então o que está sendo feito é diminuir gradativamente o seu impacto e
permitir um melhor ajuste dele.
  
  
  Thats all folks.
  
  
  []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
  



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RE S: RES: Melhorando o desempenho do PostGre





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 
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
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

Re: [pgbr-geral] RES: RES: RES: Melhorando o desempenho do PostGre





Concordo que é um bom caminho. Depois envie as
conclusões.

Sucesso,

Sergio Medeiros Santi


Em 06/05/2010 11:35, Marcio Maestrello escreveu:

  
  
  

  
  Caros amigos,
   
  Agradeço a todos as explicações e acredito que essa
discussão é
salutar, mostrando os diversos caminhos que podemos percorrer para
atingirmos a
eficácia.
  Da minha parte, não tenho novidades, porem desisti de
fazer a
separação de índices e estou contatando um DBA aqui na região para
avaliar e
realizar os procedimentos citados nas mensagens por vocês encaminhadas.
Acredito que seja o melhor caminho.
  Agradeço muito a atenção de todos e estou atento a todos
os
comentários feitos.
   
   
  Marcio - TI
  
  

___
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

Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre





Gostei do ponto ... e como dizia o poeta ...
gentileza gera gentileza ... ponto para você também.

Tenho a firme proposição de montar um case com todo o material
necessário para poder oferecer a quem se dispor a analisar a principal
dificuldade é além dos volumes envolvidos a falta de atualização que
esta base de testes teria, mas uma coisa de cada vez ... De qualquer
forma vou me inscrever na lista que sugeristes e começar a me aculturar
com ela.

Não entendi o que você quis dizer com "brigar com o fornecedor para
homologarem uma nova versão do PostgreSQL"? Se estivéssemos falando de
oracle, db2, ou outros proprietários em teria entendido, mas brigar com
o fornecedor do PostgreSQL?

Abraços,

Sergio Medeiros Santi


Em 06/05/2010 11:28, Fábio Telles Rodriguez escreveu:
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 <sergio.tra...@gmail.com>
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
  <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

Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre

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 expectati

Re: [pgbr-geral] RE S: RES: Melhorando o desempenho do PostGre





A base após um vacuum analyse OCUPAVA 200 GB e após
um BDCR passou a OCUPAR 80 GB.

Que bom que o problema relatado não aconteceu com você, que bom também
que tem pessoas que morrem sem terem ficado doentes, mas acontece que
tem gente com esse problema acontecendo em suas bases, como tem gente
adoecendo e precisando ir ao médico. Ninguém escolhe ter problemas nas
suas bases mas eles ocorrem e lembro de 2 ou 3 oportunidades onde o
assunto e as configurações do postgresql foram discutidas até a
exaustão e que resolveu e continua resolvendo foi o BDCR. 

Acho que esta lista tem os maiores conhecedores de postgresql do pais,
acredito que boa parte deles participou da discussão, mas as sugestões
não produziram efeito enquanto o patinho feio do BDCR tem resolvido.
Vamos fazer o que parar de usar o BDCR e deixarmos os bancos se
arrastarem até parar e ainda usarem isto para denegrir a imagem do
postgresql ou vamos usar o BDCR até que alguém consiga entender /
resolver seja lá qual for o problema?

No caso que relatei e antes de postar o caso na lista o banco foi
auditado por um experiente DBA postgresql que também não encontrou
explicação para o problema.

Então não vamos ser simplistas em excesso. Eu tenho pelo menos uns 2 ou
3 pontos sem explicação que já discuti com especialistas, com os
membros desta lista, mas que continuarão num terreno nebuloso e
desconhecido até que se faça a luz sobre eles.

Também é preciso lembrar que existe a possibilidade dos seus 1 TB terem
características que não exercitaram o caminho onde o problema se
manifesta e que talvez essas bases bem menores tenham conseguido
exercitar. Esta situação é um clássico da engenharia de software.

A propósito: A pessoa que deu origem a esta discussão tem algum fato
novo sobre o problema?
Sergio Medeiros Santi


Em 06/05/2010 10:03, mateusgra escreveu:

  
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 < 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 alg

Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre





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 <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/
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

Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre

2010-05-05 Por tôpico Sergio Santi





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.

Abraços,


Sergio Medeiros Santi


Em 05/05/2010 11:29, Marcio Maestrello escreveu:

  
  
  

  
  Pessoal,
   
  Segue as respostas abaixo. Agradeço muito as repostas
enviadas e
segue as respostas as perguntas efetuadas
  
1. qual é seu hardware?
      R: Servidor Dell Power Edge 1950III com processador
Intel
Quad Core Xeon, 2,33 GHz, 2x6Mb cachê, 3 Gb RAM
   3 discos SAS (RAID 5) de 73 Gb cada um deles.
  2. SO?
    LINUX Red Hat
   
  3. versão do Postgresql?
      R:  Versao 8.2
   
  
4. Tamanho
ocupado pelo banco?
      R.:  11 GB
   
  
5. Número
de acessos simultâneos?
      R.: São 80 usuários utilizando o sistema e acessando
o BD.
  
6. se isto passou a ocorrer de repente ou veio piorando durante o tempo?
      R.: Vem ocorrendo há algum tempo e piorando durante o
tempo
  
7. se é feito vacuum analyse e com que regularidade?
   R. Não é feito
  
8. se o autovacuum esta ativo?
    R.: Não 
  
9. se já foi feito um backup, drop, create e restore desta base?
   R.: Neste item, acredito que nada foi feito em
relação a
isso.
  
  
Abraços,
  
  
  Sergio Medeiros Santi
  
Em 05/05/2010 00:16, Marcal Hokama escreveu: 
   
   
  
    
  
From: mar...@npsistemas.com.br
To: pgbr-geral@listas.postgresql.org.br
Date: Tue, 4 May 2010 19:01:55 -0300
Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre
 
Utilizamos o Postgres na empresa há dois anos,
em um sistema completo (ERP).
 
Acontece que de uns tempo pra cá o sistema
se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais
que antes era bem rápido, agora se tornou muito lento nas pesquisas e nas
inclusões. Eliminamos todos os problemas de redes e infraestrutura, chegando a
conclusão que se trata do banco de dados.
 
O DBA comentou que a solução seria a separação dos índices do banco de
dados. Assim, teríamos dois discos, um com os índices e outro com o banco de
dados. Esse procedimento é complexo, visto que terei que desmontar um RAID 5 e
refazê-lo e não tenho certeza que isso dará um desempenho maior no sistema.
 
Gostaria de saber se alguém já utiliza essa
solução de índices separados e se realmente vale arriscar todo arranjo já
feito para se montar algo assim.
 
Será que com a separação terei mais
desempenho??
 
Marcio - TI
    
  
   
  Olá Marcio,
   
  Não sei com quantos discos físicos você está montando seu RAID 5, mas geralmente essa questão de separação de índices e dados é útil quando você tem os dois no mesmo disco físico, e o hardware não consegue dar conta do grande número de requisições ao dispositivo, gerando conteção e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados são distribuídos entre os discos físicos, minimizando a questão da contenção em um único disco físico (mas depende também de quantos discos físicos formam o seu volume).
   
  Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode não ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situações, mas acredito que possa servir também para PostgreSQL:
   
  http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c=my&l=en&s=k12
   
  Outra idéia pode ser verificar qual é a tecnologia dos seus discos físicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situação, pensar num upgrade.
   
  Marçal de Lima Hokama
  --
  e-mail: mhok...@hotmail.com            
  _
  CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA.
  http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregador&ocid=Hotmail:MSN:Messenger:Tagline:1x1:agregador:-
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresq

Re: [pgbr-geral] RES: Melhorando o desempenho do PostGre

2010-05-05 Por tôpico Sergio Santi





Pessoal e Márcio principalmente.

Não acompanhei toda a discussão, mas vocês mencionou:

1. qual é seu hardware?
2. SO?
3. versão do Postgresql?
4. tamanho ocupado pelo banco?
5. número de acessos simultâneos?
6. se isto passou a ocorrer de repente ou veio piorando durante o tempo?
7. se é feito vacuum analyse e com que regularidade?
8. se o autovacuum esta ativo?
9. se já foi feito um backup, drop, create e restore desta base?

Abraços,
Sergio Medeiros Santi


Em 05/05/2010 00:16, Marcal Hokama escreveu:

  



  
  
From: mar...@npsistemas.com.br
To: pgbr-geral@listas.postgresql.org.br
Date: Tue, 4 May 2010 19:01:55 -0300
Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre


Utilizamos o Postgres na empresa há dois anos,
em um sistema completo (ERP).

Acontece que de uns tempo pra cá o sistema
se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais
que antes era bem rápido, agora se tornou muito lento nas pesquisas e nas
inclusões. Eliminamos todos os problemas de redes e infraestrutura, chegando a
conclusão que se trata do banco de dados.

O DBA comentou que a solução seria a separação dos índices do banco de
dados. Assim, teríamos dois discos, um com os índices e outro com o banco de
dados. Esse procedimento é complexo, visto que terei que desmontar um RAID 5 e
refazê-lo e não tenho certeza que isso dará um desempenho maior no sistema.

Gostaria de saber se alguém já utiliza essa
solução de índices separados e se realmente vale arriscar todo arranjo já
feito para se montar algo assim.

Será que com a separação terei mais
desempenho??


Marcio - TI

  
  
Olá Marcio,
 
Não sei com quantos discos físicos você está montando seu RAID 5, mas geralmente essa questão de separação de índices e dados é útil quando você tem os dois no mesmo disco físico, e o hardware não consegue dar conta do grande número de requisições ao dispositivo, gerando conteção e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados são distribuídos entre os discos físicos, minimizando a questão da contenção em um único disco físico (mas depende também de quantos discos físicos formam o seu volume).
 
Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode não ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situações, mas acredito que possa servir também para PostgreSQL:
 
http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c=my&l=en&s=k12
 
Outra idéia pode ser verificar qual é a tecnologia dos seus discos físicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situação, pensar num upgrade.
 
Marçal de Lima Hokama
--
e-mail: mhok...@hotmail.com 		 	   		  
_
CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA.
http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregador&ocid=Hotmail:MSN:Messenger:Tagline:1x1:agregador:-
___
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

Re: [pgbr-geral] Certificação

2010-04-16 Por tôpico Sergio Santi

Com relação a isto eu recebi o e-mail a seguir a
alguns dias, talvez lhe interesse.

Obrigada por seu interesse em PostgreSQL e em EntepriseDB.

EnterpriseDB continua a crescer. Nós temos agora escritórios nos EUA, na Europa, no India e no Paquistão.

A fim de suportar nossos clientes em Brasil, EnterpriseDB tem um novo parceiro em Brasilia, Tecnisys. Com um quadro de profissionais com conhecimentos e certificações nas diversas áreas de tecnologia, planejamento e gestão, a Tecnisys presta consultoria na estruturação das áreas tecnológicas e implanta soluções que buscam reduzir o prazo de entrega e a otimizar recursos. http://www.tecnisys.com.br

Para lanç esta parceria, EnterpriseDB estará oferecendo o treinamento e certificação em PostgreSQL nos escritórios de Tecnisys em Brasília no mês de maio, 2010. Este treinamento é de 9 - 5 segunda-feira a sexta-feira.

Se você gostaria de receber detalhes neste treinamento, responda por favor a este email, ou chame por favor Giovanni Celho da Silva em Tecnisys Brasil (61)3039 9700.

Obrigada por sua consideração.

Atenciosamente,

Angela Smith
Account Manager
EnterpriseDB Corporation
The Enterprise Postgres Company
Join us at PG East the premier Postgres community and user event this spring!
To learn more or register visit this link: http://www.enterprisedb.com/community/pg-east-2010.do

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

Em 16/04/2010 00:15, Pedro Espíndola - GMAIL escreveu:

Boa noite,
Sei q este assunto é batido, pesquisei no
histórico, mas n
me senti satisfeito com o que li. Como andam as certificações
postgreSQL ? vue
? enterprisedb ? qual a mais adotada ? alguma já homologada ?
Abs
pen

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Configuração Ideal - Postgre

2010-03-08 Por tôpico Sergio Santi





Boa tarde Leonardo.

Se olhares o histórico da lista perceberas que já houveram discussões
homéricas sobre este assunto. Eu particularmente acredito que todos que
tem bases funcionando com boa performance descobriram uma heurística
que equacionou sua necessidade. Todos já procuraram e ninguém até então
apresentou um modelo consistente para um .conf cientificamente gerado.
É tentativa e erro mesmo. Mas se tiveres a curiosidade de verificar no
histórico vais achar diversos exemplos bem razoáveis para a tua
configuração.

Boa sorte.

Sergio Medeiros Santi


Em 08/03/2010 14:50, Leonardo Cezar escreveu:

  2010/3/8 marcos thomaz :
  
  
Pessoal, temos um servidor aqui que está rodando Postgre (exclusivo para o
banco), apesar de terem sido feitas alterações na configuração (e ter havido
uma melhora no desempenho), gostaria de saber de vocês qual a configuração
ideal (na opinião de vocês), para uma máquina abaixo:
Servidor IBM
2 Processadores Xeon 3.0 Ghz
FSB 1333
4 HD's de 500 GB SAS 15.000 rpm (atualmente com RAID 0+1)
8 GB memória RAM - ECC
Sistema Operacional Linux - CentOS
Como eu disse antes essa máquina roda apenas o banco de dados (não existem
serviços como apache e outros rodando).

  
  
Em tese, praticamente impossível dar uma resposta sensata.

Existem tantas outras variáveis (tipo de ambiente, transações
concorrentes, número de usuários, tipo de aplicação, SO, &ca) a
considerar para se realizar uma configuração adequada.

Se quer ter uma configuração básica de acordo com os parâmetros que
passou, tente o utilitário pgtune[1], mas não considere que é a
solução para todos os seus problemas.

1) http://pgfoundry.org/projects/pgtune/

Abraço!

-Leo
  



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PostgreSQL 8.0.x apresentando len tidão gradual no Windows XP

2010-02-03 Por tôpico Sergio Santi





Pessoal, eu já passei por isso!!!

Algum tempo atrás eu postei algo bem parecido na lista. Na oportunidade
lembro de um outro colega que tinha o mesmo problema. 

O problema não ocorre apenas na 8.0, talvez nela seja pior, mas ocorre
também na 8.2. Depois de muita discussão sem resultado prático cheguei
a conclusão que o vacuum não faz bem o seu trabalho. Como nenhuma luz
se fez o jeito é fazer um backup e um restore de tempos em tempos.
Observe o tamanho do seu banco antes e depois. A diferença chegou a 50%
menor no meu caso. Inclusive o tempo de vacuum que estava em 10 horas
passou para 30 minutos. Depois ... com o tempo ... a coisa vai
degenerando até que um novo backup seguido de restore restaura a
sanidade.

Estou fazendo testes com a 8.4 para ver se isto foi resolvido, mas
ainda não tenho nenhuma conclusão.

Abraços,


Sergio Medeiros Santi
Em 03/02/2010 13:11, Euler Taveira de Oliveira escreveu:

  Ricardo escreveu:
  
  
Alguém teria uma explicação técnica para isso? Seria um problema ou uma 
incompatibilidade entre o sistema de arquivos do Windows com o tipo de 
armazenamento que o postgres faz?


  
  Porque foi a primeira versão do PostgreSQL para esta plataforma. Existem
diversos problemas que foram resolvidos nas versões subsequentes; por isso,
não recomendamos [1] o uso de uma versão inferior a 8.2 nesta plataforma.

Eu lhe aconselharia utilizar no mínimo a 8.2.x no Windows. Não só por questões
de performance mas por questões de suporte também. É claro que você deve
testar e homologar a aplicação para isso.

Quanto a explicação técnica, é porque a API base (fork, sinais, pipe, etc) da
arquitetura do PostgreSQL é emulada naquele SO; além disso, a abertura de
processos no Windows é custosa.


[1] http://www.postgresql.org/about/news.865


  


-- 




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ERP em Postgres

2010-01-19 Por tôpico Sergio Santi





Quando precisei disto estive procurando e todos que
eu encontrava disponibilizavam PG 8.1 ou 7.4. Acabei optando pela
Locaweb por disponibilizar a 8.2.

ETA

Em 19/01/2010 16:10, Celso Jose Salustiano escreveu:

  

  
Olá,

Nosso foco é em um DC que mantenha o PostgreSQL, inclusive a
administração do
servidor. Através de indicações avaliei alguns sites, porém, mereceu
minha atenção
o site da Net4biz, que além de hospedagem de páginas Web, fornece
hospedagem e
administração de base de dados em Postgres, mas, estou avaliando outros
DCs.

--- Em ter, 19/1/10, JotaComm 
escreveu:

De: JotaComm 
Assunto: Re: [pgbr-geral] ERP em Postgres
Para: "Comunidade PostgreSQL Brasileira"

Data: Terça-feira, 19 de Janeiro de 2010, 8:36
  
  Olá,
  
  2010/1/18 Celso Jose Salustiano 
  

  

  
  Na empresa onde eu trabalho utilizamos um ERP
com banco de dados Postgres. Pretendemos hospedar o banco de dados em
um DC que ofereça suporte a este banco. O Google não listou nenhuma
empresa. Alguém poderia indicar alguma?
  

  

  
  
  
  Vocês desejam um DC com suporte para PostgreSQL ou vocês
apenas tem interessam de locar um Data Center e vocês cuidariam da
administração do PG? 
  

  

  
   
  
  CJS
  

  



Veja quais são os assuntos do momento no
Yahoo! + Buscados: Top
10 - Celebridades
- Música
- Esportes

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  
  
  
  
[]s
-- 
JotaComm
  http://jotacomm.wordpress.com
  
  
-Anexo incorporado-
  
  ___
pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


  

  
  
  Veja quais são os assuntos do momento no Yahoo! +
Buscados: Top
10 - Celebridades
- Música
- Esportes
  

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parar postgres no linux através de estação windows





Já tenho o putty instalado e funcionando. Apenas
quero saber se é possível e neste caso realizar um teste.



Em 13/01/2010 08:23, Glênio Côrtes Himmen escreveu:

  
  
  
  Faça o download na Internet do
Putty, monte a conexão com seu servidor, logue nele e faça o stop do
banco.
   
  Diretoria de Tecnologia da Informação 
Prefeitura Municipal de Aparecida de Goiânia 
Rua Gervasio Pinheiro, Residêncial Solar Central Parque 
Aparecida de Goiânia-GO - CEP - 74.968-500 
Glênio Côrtes Himmen - glenio.116...@aparecida.go.gov.br
  
  http://www.aparecida.go.gov.br
  
 
Não declines nem para a direita nem
para a esquerda, retira o teu pé do mal.
 
Pv. 4:27
  
-
Original Message - 
From:
Sergio Santi 
To:
Comunidade
PostgreSQL Brasileira 
Sent:
Wednesday, January 13, 2010 8:07 AM
Subject:
[pgbr-geral] Parar postgres no linux através de estação windows


Pessoal:

Desculpem a pergunta um tanto boba, mas é possível fazer o stop do
postgresql rodando no linux a partir de uma estação windows? Imagino
que o pg_ctl possa fazer isto. Alguém tem uma linha de comando para eu
testar?

Sergio Medeiros Santi

 
 ___
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
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parar postgres no linux através de estação windows





E verdade. Neste caso retiro o atalho e escondo a
linha de comando e a deixo em um local que apenas eu conheça. Minha
memória. 

Mas pela resposta deduzo que é perfeitamente possível. Terias uma
sugestão de linha de comando. Prometo mantê-la em segurança e longe de
curiosos.

Antecipo agradecimentos,

Em 13/01/2010 08:43, JotaComm escreveu:
Olá,
  
  2010/1/13 Sergio Santi <sergio.tra...@gmail.com>
  
Obrigado
pelas duas respostas. Esse era meu plano B,
para o caso de não ter jeito de parar e iniciar o banco através de uma
estação.

A idéia é ter um atalho no windows para em determinados casos parar e
iniciar o postgresql sem precisar contato com o servidor linux.

  
  
  
  Assim qualquer pessoa mal intencionada que tenha acesso ao
computador onde tem o atalho é quiser parar o serviço do PostgreSQL
seria possível.
  

Abraços,

Em 13/01/2010 08:27, JotaComm escreveu:


Olá,
  
  2010/1/13 Sergio Santi <sergio.tra...@gmail.com>
  
Pessoal:

Desculpem a pergunta um tanto boba, mas é possível fazer o stop do
postgresql rodando no linux a partir de uma estação windows? Imagino
que o pg_ctl possa fazer isto. Alguém tem uma linha de comando para eu
testar?

  
  
  
  Faça uma conexão remota ao servidor e execute o pg_ctl stop. 
  

Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  
  
  
  
[]s
-- 
JotaComm
  http://jotacomm.wordpress.com
  
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  




-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  
  
  
  
[]s
-- 
JotaComm
  http://jotacomm.wordpress.com
  

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parar postgres no linux através de estação windows





Obrigado pelas duas respostas. Esse era meu plano B,
para o caso de não ter jeito de parar e iniciar o banco através de uma
estação.

A idéia é ter um atalho no windows para em determinados casos parar e
iniciar o postgresql sem precisar contato com o servidor linux.

Abraços,

Em 13/01/2010 08:27, JotaComm escreveu:
Olá,
  
  2010/1/13 Sergio Santi <sergio.tra...@gmail.com>
  
Pessoal:

Desculpem a pergunta um tanto boba, mas é possível fazer o stop do
postgresql rodando no linux a partir de uma estação windows? Imagino
que o pg_ctl possa fazer isto. Alguém tem uma linha de comando para eu
testar?

  
  
  
  Faça uma conexão remota ao servidor e execute o pg_ctl stop. 
  

Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  
  
  
  
[]s
-- 
JotaComm
  http://jotacomm.wordpress.com
  

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Parar postgres no linux através de estação windows





Pessoal:

Desculpem a pergunta um tanto boba, mas é possível fazer o stop do
postgresql rodando no linux a partir de uma estação windows? Imagino
que o pg_ctl possa fazer isto. Alguém tem uma linha de comando para eu
testar?

Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Eliminar Conexões Perdidas

2010-01-05 Por tôpico Sergio Santi





Além disto tem o fato que mesmo que o servidor
devolva alguma coisa para uma estação desligada ele registra isto no
log, mas se mantém contando aquela conexão.

Não fiz ainda, mas vou fazer: O banco rodando sozinho fica com umas 4
conexões. Defino o max_connections para 5. Abro uma conexão e deixo em
idle. Arranco esta estação da tomada. Tento outra conexão. 

Acho que não vai permitir porque a conexão continua sendo considerada,
mas vou precisar testar uma hora dessas.

No mesmo caso anterior se abrir uma conexão e solicitar algo demorado,
por exemplo. Arrancar a estação da tomada. Aguardar o servidor devolver
a consulta e registrar que o cliente não está ativo e então fazer uma
nova conexão, acho que ela também será recusada e isto porque até onde
alcanço apesar de o servidor perceber que o cliente a quem ele tem que
entregar a informação não está mais lá ele não aceita uma requisição de
outra estação.



Em 05/01/2010 17:18, Tarcísio Sassara escreveu:

  Aaaah! Tem esse problema!

O keepalive idle só serve para os idles.

Se a sessão estiver fazendo alguma coisa ela não está idle. E continua
até terminar.
Só saberá que deu pau quando terminar a transação e retornar para o
cliente. Nisso vai dar pau e encerrar a conexão.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Eliminar Conexões Perdidas

2010-01-05 Por tôpico Sergio Santi





Pessoal, primeiramente parece-me que as conexões
ficam pendentes ou até mesmo presas, porque se fossem perdidas
o problema não estaria ocorrendo.

Bem, o keepalive se for possível pode ser um paliativo, mas não me
parece uma solução definitiva.

Não vejo problema em ter 70 estações que se conectam ao servidor pela
manhã e desconectam a noite e que me fazem ter um max_connection=100,
por exemplo. O que me incomoda é ter um no-break de 12 KWA que não
segura a rede durante um pico de entrada e que deixa 70 conexões ativas
no servidor. Então basta a energia voltar que apenas as 30 primeiras
máquinas conseguem conexão.

Pior ainda é que para resolver definitivamente (ou até o próximo pico
de energia) é necessário fazer um stop seguido de start no banco.

Eu sinceramente não consigo conceber o PostgreSQL recusando conexões
alegando que o número máximo de conexões foi atingido sem se dar conta
de que os clientes abortaram as conexões.

Ninguém nunca viu isso antes, na hackers ou outra do gênero?

Abraços, 

Em 05/01/2010 15:05, Fabrízio de Royes Mello escreveu:

  2010/1/4 Tarcísio Sassara 
  


Se o aplicativo que faz uso do postgres abre uma conexão e mantem está
até o fechamento, provavelmente a sessão passa uma boa parte do tempo
idle e pode ser uma boa configurar o keepalive.

Se for útil o keepalive, podemos discutir aqui uma boa configuração.

  
  
  
Vejamos se compreendi bem... dessa forma então eu precisaria modificar
também a minha aplicação, para verificar se a conexão está ativa no
momento de alguma transação com o banco de dados Pq se a conexao
ficar idle por algum tempo (o usuário entra numa tela e sai pra tomar
um café), com uma configuração diferenciada do keepalive a conexão será
desfeita então terei de tratar isso na aplicação... certo???
  
  
-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
  

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Eliminar Conexões Perdidas

2010-01-04 Por tôpico Sergio Santi





Boa tarde pessoal, espero que todos tenham tido um
Natal e Ano Novo onde a esperança tenha se renovado e que muito
realizemos neste 2010.

Bem, não pude deixar de notar que o colega esta passando por um
problema muito semelhante (se não igual) ao que venho tendo em algumas
situações. O caso é muito semelhante: existe um servidor cujo no-break
segura e máquinas clientes que em maior ou menor número ficam sem
energia. A conexão criada por esses clientes permanece ativa mesmo após
a queda das estações por falta de energia. Quando a energia volta os
usuários estabelecem novas conexões e dependendo do max_connections, do
número de estações afetadas pelo problema de energia e do número de
vezes que o problema ocorre e pimba temos um servidor recusando
conexões.

Olhando o log do banco existem diversos avisos das tentativas que o
banco fez de entregar resultados para estações que não estão mais na
outra pronta da conexão, mas nem assim a conexão é descartada. A saída
tem sido aumentar o max_connection para 2, 3 ou 4 vezes o número
necessário e dependendo do grau de pessimismo que se esteja no momento.

Acredito que alguém já tenha passado por isto e que tenha achado uma
forma "elegante" de resolver o caso.

Considerações serão bem vindas,

Abraços,

Sergio Medeiros Santi


Em 31/12/2009 09:52, Fabrízio de Royes Mello escreveu:
Pessoal,
  
Estou sofrendo com um problema de algumas conexões ficarem ativas com o
PostgreSQL após uma queda de energia onde todos os clientes foram
desligados e o servidor, por estar ligado a um nobreak não caiu, e com
isso ao ser restabelecida a energia elétrica (o servidor não foi
reiniciado) as estações começam a conectar novamente, só que como já
tem conexões ativas (que ficaram perdidas após a queda de energia)
acaba estourando o max_connections com as novas conexões...
  
Diante disso gostaria de trocar algumas idéias (ou se existe uma
solução pronta que eu desconheça fico agradecido) pois pensei em criar
algum script que verifique o client_addr e o client_port da
pg_stat_activity e verificar o status do socket no sistema operacional
com o "netstat", e caso ele não esteja como "ESTABELECIDO" efetuar a
eliminacao do processo...
  
Essa é uma alternativa viável ou existe alguma forma mais elegante de
contornar isso??
  
Sistema Operacional: Windows 2003
Versão do PostgreSQL: 8.2.14
  
-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.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

Re: [pgbr-geral] Um pendrive para quem traduzir este artigo

2009-09-04 Por tôpico Sergio Santi





Envio antes disto.

Abraços,

Fábio Telles Rodriguez escreveu:

  Eu espero até o pgcon:
http://pgcon.postgresql.org.br/2009/concurso.php

:-)

blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@gmail.com



2009/9/4 Sergio Santi :
  
  
Se for possível aguadares até o próximo dia útil eu posso traduzí-lo.

Abraços,

Sergio Medeiros Santi
www.trabin.com.br


fabio.tel...@gmail.com escreveu:

Olha só que artigo bacaninha...

http://www.postgresonline.com/journal/index.php?/archives/133-Database-Administration,-Reporting,-and-Light-application-development.html

[]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


--
Sergio Medeiros Santi

___
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

  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Um pendrive para quem traduzir este artigo

2009-09-04 Por tôpico Sergio Santi





Se for possível aguadares até o próximo dia útil eu
posso traduzí-lo.

Abraços,

Sergio Medeiros Santi
www.trabin.com.br


fabio.tel...@gmail.com escreveu:
Olha só que artigo bacaninha...
  
  
http://www.postgresonline.com/journal/index.php?/archives/133-Database-Administration,-Reporting,-and-Light-application-development.html
  
  
[]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
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Melhorar performance

2009-07-28 Por tôpico Sergio Santi





Pessoal:

Eu imaginava ter enviado as informações solicitadas. Inclusive estava
estranhando a demora de uma resposta, mas queria ficar incomodando. Se
houver mais alguma informação que eu possa fornecer não exitem em dizer?

Abraços,

Fábio Telles Rodriguez escreveu:

  
Isso implica que nem sempre um servidor com hardware melhor e mais
rápido e configurações maiores de PostgreSQL vai oferecer uma resposta
mais rápida? Isto é, sob condições mais "apertadas" o PostgreSQL faz
estimativas melhores e mais eficientes?


  
  Isto significa que tuning é algo mais complexo do que se imagina e que
fazer inferências sem todas as informações necessárias faz com que nós
incorramos em erros graves. O Euler pediu mais informações, no e-mail
anterior. Sem elas, fica difícil saber realmente o que está ocorrendo.
São muitas variáveis interagindo ao mesmo tempo para se afirmar
qualquer coisa.
 []s

  
  
--
Benedito A. Cruz
Centro de Referência em Informação Ambiental - CRIA
email b...@cria.org.br
fone 55 19 3288 0466


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


  
  


  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Melhorar performance

2009-07-14 Por tôpico Sergio Santi

roImpressoraNota")::text >= '0001'::text) AND
(("NumeroImpressoraNota")::text <= ''::text))"
"  ->  Bitmap Index Scan on
"NotaFiscal_CodigoOperacaoEstoque_I"  (cost=0.00..1265.69 rows=16956
width=0) (actual time=353598.739..353598.739 rows=747641 loops=1)"
"    Index Cond:
("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes")"
"Total runtime: 639124.536 ms"

-

Resultado do explain analyse no ServRapido

"GroupAggregate  (cost=971.00..971.08 rows=1 width=54) (actual
time=1153.322..1356.063 rows=35 loops=1)"
"  ->  Sort  (cost=971.00..971.00 rows=1 width=54) (actual
time=1151.227..1242.719 rows=89221 loops=1)"
"    Sort Key: "NotaFiscal"."NumeroImpressoraNota",
"NotaFiscal"."CodigoEmpresaNota""
"    ->  Nested Loop  (cost=640.78..970.99 rows=1 width=54)
(actual time=453.271..841.699 rows=89221 loops=1)"
"  ->  Index Scan using "Operacao_CodigoInterno_PK" on
"Operacao"  (cost=0.00..12.36 rows=1 width=4) (actual time=0.063..0.070
rows=1 loops=1)"
"    Filter: (("TipoOperacoes")::text = 'V'::text)"
"  ->  Bitmap Heap Scan on "NotaFiscal" 
(cost=640.78..958.62 rows=1 width=58) (actual time=453.201..793.978
rows=89221 loops=1)"
"    Recheck Cond:
(("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes") AND
("NotaFiscal"."DataEmissaoNota" >= '2009-05-01'::date) AND
("NotaFiscal"."DataEmissaoNota" <= '2009-05-30'::date))"
"    Filter: ((("ModuloOrigemNota")::text =
'TS-Fature'::text) AND (("NumeroImpressoraNota")::text >=
'0001'::text) AND (("NumeroImpressoraNota")::text <= ''::text)
AND ("SituacaoNota" IS NULL))"
"    ->  BitmapAnd  (cost=640.78..640.78 rows=80
width=0) (actual time=451.452..451.452 rows=0 loops=1)"
"  ->  Bitmap Index Scan on
"NotaFiscal_CodigoOperacaoEstoque_I"  (cost=0.00..300.31 rows=15961
width=0) (actual time=420.393..420.393 rows=539101 loops=1)"
"    Index Cond:
("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes")"
"  ->  Bitmap Index Scan on
"NotaFiscal_DataEmissao_I"  (cost=0.00..340.21 rows=15961 width=0)
(actual time=22.197..22.197 rows=89882 loops=1)"
"    Index Cond: (("DataEmissaoNota" >=
'2009-05-01'::date) AND ("DataEmissaoNota" <= '2009-05-30'::date))"
"Total runtime: 1357.815 ms"




Euler Taveira de Oliveira escreveu:

  Sergio Santi escreveu:
  
  
Os planos de execução são muitíssimo diferentes e comparando o
postgres.conf de cada um, respectivamente, temos as seguintes diferenças
principais:


  
  EXPLAIN ANALYZE das consultas? Mostre também os parâmetros que não são padrão
no postgresql.conf. Sistema operacional?

  
  
effective_cache_size = 256MB 128M

  
  ^
Para máquinas com 4GB de RAM e somente isso de effective_cache_size? Se for
uma máquina exclusiva eu indicaria algo entre 1-2GB.


  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Melhorar performance

2009-07-14 Por tôpico Sergio Santi





Pessoal,

Eu imagino ter participado da discussão ocorrida "há um tempo atrás" e
é claro que como já fui e muitas vezes continuo sendo vítima de planos
mal escolhidos tenho um detalhe a acrescentar:

Um servidor Dell PowerEdge 1800, dual zeon, 4GB, 4 hds SAS em raid 10
executou uma consulta que mostra o valor faturado em 40 impressoras
fiscais em um único dia classificado por impressora fiscal em uns 4 a 5
minutos.

Um desktop core2duo, 4GB, 1 hd sata2 executou a mesma consulta sobre um
backup do primeiro equipamento restaurado no segundo em 1segundo.

Os planos de execução são muitíssimo diferentes e comparando o
postgres.conf de cada um, respectivamente, temos as seguintes
diferenças principais:

max_connections =       
   70   100
shared_buffers =  1000MB      32MB
work_mem =  64MB   1MB
maintenance_work_mem = 256MB      16MB
max_fsm_pages =    100    324000
checkpoint_segments =    3        10
effective_cache_size = 256MB 128M

Nas próximas semanas pretendo realizar novos testes, mas não é a
primeira vez que vejo isto e por isto se vê tanto ajuste pelo método de
tentativa e erro.

Abraços,


Mozart Hasse escreveu:

  Euler,

Eu escrevi:
  
  

  No meu caso o que sempre fez e continua fazendo uma falta desgraçada no
Postgres é um otimizador decente (...) Bem que se podia aproveitar a
  

  
  idéia aplicada no
  
  

  Oracle ou no SQL Server e ter um cache de planos (...)
  

  
  
  
  
Isso já existe: chama-se comandos preparados (aka _prepared statements_).

  
  
Isso ??!
http://jdbc.postgresql.org/documentation/83/server-prepare.html

Não, não estou falando de algo tão simplório. Prepared statements têm
diversas desvantagens em relação ao que o Oracle e o SQL Server fazem:

* Prepared statements funcionam dentro da mesma conexão. Logo, consultas
idênticas feitas por instâncias diferentes da mesma aplicação ou
aplicações diferentes que façam as mesmas consultas continuarão tendo um
custo alto recompilando dúzias de vezes os mesmos comandos. Isso, é claro,
assumindo que eu me dê ao trabalho de mexer na minha aplicação para fazer
todas as consultas através da mesma conexão. O ganho disso seria bastante
questionável considerando que isso implica em serializar operações que
podem correr em paralelo.

* Da documentação:
"(...)
Server side prepared statements are planned only once by the server. This
avoids the cost of replanning the query every time, but also means that the
planner cannot take advantage of the particular parameter values used in a
particular execution of the query. 
(...)"
Logo, Prepared statements usam o mesmo plano independente dos valores, o que
resulta em desastre. Isso é exatamente o *oposto* do que se espera de um
otimizador decente. O otimizador deveria ter uma lista de planos para a mesma
consulta e usar o mais adequado para cada uma.

  
  
É claro que você precisa manter a conexão mas nada que um aglomerador de
conexões (aka _pool_) não resolva.

  
  
Como expus acima, fazer isso, ainda por cima em larga escala, resulta em
desastre.

  
  
Como você mesmo disse, o tempo é relativamente pequeno em aplicações Web

  
  e
  
  
OLTP; em OLAP, algumas consultas com dezenas de junções esse tempo é
significativo (aumenta 2^n mas é para isso que temos o GEQO) mas mesmo

  
  assim
  
  
bem inferior ao de execução da consulta.

  
  
Dezenas de junções não são exclusividade de aplicações OLAP, muito pelo
contrário.
O fato de uma consulta cheia de junções exigir um enorme tempo de
planejamento de forma alguma implica em não valer a pena gastá-lo fazendo
isso. É exatamente nessas tabelas potencialmente grandes e cheias de índices
que uma escolha errada do otimizador resulta em planos catastróficos.
 
  
  
É fácil falar do otimizador mas é difícil mexer nele. ;)

  
  
Ora, ora, pelo menos nisso concordamos integralmente. A pergunta do tópico
foi quanto ao que se poderia melhorar em desempenho, só estou expondo a lista
para resolver os *meus* problemas. Afinal, custa-me acreditar que sou o único
interessado em desempenho por aqui.

  
  
Já tivemos essa discussão a um tempo atrás (...). Se eu me lembro bem,

  
  nenhuma das
  
  
consultas apresentadas por você produzia um plano que não era ideal.

  
  
Depende do que chamarmos de "ideal". Para mim o ideal é medir as consultas em
milissegundos para poder comparar com Oracle e SQL Server, e não em minutos.
OK, de fato não tenho no momento exemplos usando a última versão do
Postgres, quando tiver passo para a lista. Fazer testes comparativos de
desempenho é algo que consome tempo que é dificílimo de conseguir
considerando nossas experiências anteriores.

Atenciosamente,


Mozart Hasse


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

  


-- 
Sergio Me

Re: [pgbr-geral] RES: Base de dados de CEP

2009-01-19 Por tôpico Sergio Santi

Title: Mensagem

Bela iniciativa George! Domingo é um dia legal para
um monte de coisas que não temos tempo durante a semana.

Eu particularmente desconhecia este webservice. O interessante é que o
exe em delphi não funcionou, precisei compilar os fontes.

Agora para provar que quando alguém oferece a mão, já vão pegando o
braço ...

Alguém conhece algum outro serviço que dada a rua, cidade e estado
retorne os possíveis CEPs?

Um grande abraço a todos

George escreveu:

Bom dia gente !!! Hoje é domingo,
dia de são domingo.
Quem quiser ente nesta página, creio
irá acrescentar.
http://www.buscarcep.com.br/
Tem vários exemplos para a maioria
de ferramentas de programação.
Lembrando que irei pedir a eles para
incluir o CÓDIGO IBGE, isto é, irei ajudar tb.
Abraços
George

-
Original Message -
From:
Tatu
To:
'Comunidade
PostgreSQL Brasileira'
Sent:
Saturday, January 17, 2009 12:56 PM
Subject:
[pgbr-geral] RES: Base de dados de CEP

o que estou achando estranho em todo esse tema
do CEP..que por muito menos o pessoal desce o cano quando alguem
pergunta alguma coisa sobre postgreslai moderadores e genios de
plantão respondem "procura no google..que vc encontra...".. agora com
esse tema do CEP...que A MEU MODO DE ENTENDER ja extrapolou e muito os
limites do forum "postgresql" 2 ou 3 pessoas pediram para parar com
esse tema e nao lí nada...(ate porque estou excluindo todo o que tem a
ver com CEP e as vezes por engano apago outros tb...) minha sugestao
é...quem tiver dúvidas sobre o tema CEP...procure no google e pare de
encher caixas postais com esse tema, ou se preferir abra um forum de
discussão sobre CEP-BRASIL. Se alguem se sentir incomodado com meu
ponto vista, fique a bontade de responder em pvt t...@nsr.com.br com o "assunto" "nao concordo com vc"..porque tudo o que
vier sobre cep ja estou apagandose algum moderador se incomodar
tb...fique a bontade de me tirar da lista
Santiago
NSR Informática.

-Mensagem original-
De: pgbr-geral-boun...@listas.postgresql.org.br
[mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de renato
Enviada em: sábado, 17 de janeiro de 2009 09:16
Para: Comunidade PostgreSQL Brasileira
Assunto: Re: [pgbr-geral] Base de dados de CEP

Os Correios tem o direito de comercializar sua base de cep e nós somos
livres para comprar ou não. Não é essa a lei de mercado, não é assim
que as coisas funcionam?
Nada me impede de EU MESMO montar minha base. Formato a base do jeito
que achar melhor e pronto!

Essa discussão toda me lembrou de um caso que aconteceu há muitos anos
envolvendo o método de criptografia PGP desenvolvido pelo Phill
Zimmermann. O governo dos EUA proibiram de que o software fosse
exportado em forma eletrônica (cd, disquete, download, etc) para
qualquer país. No fim um grupo de hackers encontrou uma forma engenosa
de burlar a proibição. Lançaram o código do PGP em livro e como não
havia restrições na exportação de livros, o código PGP pode ir aos
quatro cantos do mundo. O único trabalho era que alguem digitasse o
conteúdo do livro.
Muito simples! :)

Renato

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
Sergio Medeiros Santi

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] OFF - Re: Base de dados de CEP

Cara!!!

Se leste minha primeira contribuição a esta estéril discussão deves ter
percebido que eu disse que isto ocorria lá por 2K2 ou 2K3, inclusive
foi baixado e utilizado em alguns projetos dos quais tive conhecimento.

Agora convenhamos ... insistires nessa história de pirataria e roubo,
quando as pessoas estão discutindo o que é razoável ou não já está me
parecendo doença e com esses não vale a penas discutir.

Em certos casos é necessário alguém ter o bom senso e a sanidade de se
afastar de discussões inócuas e pelo visto terei de ser eu.

É uma pena que este tipo de conversa seja desvirtuada por elementos que
pouco contribuem e se escondem sobre o mantra "Pirataria!!!",
"Roubo!!!".

Cuidado com o que acontece nos porões dos puritanos!

Abraços, desculpem os que tentaram contribuir e prometo não mais
replicar essas sandices.

Shander Lyrio escreveu:

Sergio Santi escreveu:

Também acho importante citar a fonte, alias foi o que fiz originalmente
como você pode ver, mas vamos repetir a fonte foi www.correios.com.br

Mande o link completo, neste que mandou não fala nada sobre nenhuma
campanha.

(...) De minha parte não
houve apologia ao crime mas a um justo direito dos reais empregadores e
financiadores do serviço público (os cidadãos, para quem não sabe) de se
posicionarem contra atos arbitrários frente a uma maioria. Faça uma
pequena estatística desta thread e verás que esta atitude que defendes é
minoria. Temos visto diariamente coisas que são legais mas que não são
"morais" sendo revistas. (...)

Levantar bandeira de minoria explorada não resolve os problemas do
mundo. Porque os "reais empregadores e financiadores" não discutem na
jutiça e quebram a patente do DNE?? Usar algo não justo para argumentar
justiça é hipocrisia!

Novamente uma distorção do anteriormente citado. Acredito que se alguém
por seu próprio esforço buscar dados de forma legal e através de métodos
lícitos do todo ou de parte do que constituem os CEPs e divulgá-los não
estaria infringindo nenhuma lei.

Baixar a base do DNE pirata da internet não é de forma legal e nem com
métodos lícitos. Assuma que está pirateando o bendito DNE, que está
roubando informações de softwares de terceiros para melhorar o seu, que
não está respeitando a propriedade intelectual e pronto, pare de se
fazer de minoria explorada.

Será que é ilegal alguém relacionar o CEP da sua residência, escritório, hospital, etc estará implicando em
crime? Já ouvi muito algoz da ditadura dizer que estava apenas cumprindo

Não, aí não, mas roubar o trabalho de alguém que fez isto é crime sim.

próprios pensamentos. Durante esta discussão não vi ninguém pedir ou
estimular a cópia pirata, mas ví várias pessoas defenderem suas posições
de que deveria haver uma versão "open source" dos CEPs mesmo que
representassem uma versão um tanto desatualizada.

Deveria haver, deveria sim, mas não há. Porque não inicia um projeto
deste? Mas sem começar roubando o DNE que já foi feito, se quiser, posso
percorrer o meu bairro e passar para ti a lista dos ceps para ajudar no
projeto.

Neste raro ponto eu concordo com você, inclusive acho que seria
plenamente legal (me corrija se eu estiver errado) a cada consulta
realizada pelo webservice manter um cache da informação como
contingência (afinal o webservice ou um dos links pode sair do ar).

O que não é proibido é permitido, basta olhar a licença do webservices
que foi disponibilizado.

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

--
Sergio Medeiros Santi

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Base de dados de CEP





Também estou um tanto satisfeito com esse papo, mas
como não aguento intransigência acabo me metendo no que apenas
observava. Com relação a formas de obter uma base de CEPs e pelo visto
aqui, se andares de rua em rua anotando nomes, número e perguntando aos
moradores qual o seu CEP também deve constituir alguma ilegalidade e
provavelmente também não possa ser disponibilizada por infringir algum
brio, quero dizer lei.

Marcelo Costa escreveu:

  
  2009/1/16 Shander Lyrio 
  Marcelo
Costa escreveu:
> Se eu colocar um digitador para ler o site
digitar e eu modelar uma base
> de ceps  a partir dessas informações e quiser "DOAR" para alguém
eu não
> posso ? já que trata-se de informação pública disponível na
internet ?


       A informação que está disponível na internet não é pública, é
pirateada, roubada, se você usá-la pode ser indiciado como cúmplice.
  
Mesmo a que é exibida no site dos correios não é publica ? Então quer
dizer que se eu fizer uma consulta de cep e utilizar essa informação
para localizar um endereço eu estou roubando ?
  
Fala sério esse papo já foi longe de mais. 
  
Há outras formas que você certamente desconhece e que podem
perfeitamente montar uma base de ceps e logradouros. 
  
Alias a base de dados do DNE que vi é um lixo e tem um monte de tabelas
com ligação Wi-FI.
  
Esse assunto acabou e acho que esse papo já foi longe de mais. 
  
Nenhum de seus argumentos foram convincentes e bases de ceps e
logradouros sempre existirão e sempre serão compartilhadas a que possuo
foi montada a partir de várias fontes e está fidedigna não copiei
nenhum software de ninguém.
  
E feliz 2009 pra você também.
  
  
  
-- 
Marcelo Costa
  www.marcelocosta.net
-
"Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao
invés de alterarem as suas visões para se ajustarem aos fatos do mundo,
eles alteram os fatos para ajustá-los às suas visões.", 
  
Doctor Who.
  

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
  


-- 
Sergio Medeiros Santi



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] OFF - Re: Base de dados de CEP







Shander Lyrio escreveu:

  Sergio Santi escreveu:
  
  
Não posso fazer nada quanto a sua falta de memória, mas que havia, havia 
e além de access estava disponível também em formato xls!

  
  
	Se você quiser refrescar minha memória eu agradeço, mas trabalho 
diretamente com o Correio o tempo inteiro e tenho contato com pessoas do 
CPD, ao perguntar sobre o assunto eles informaram que nunca foi 
disponibilizado, o que existem são cópias piradas. Se puder indicar a 
fonte eu agradeço.

	A questão é que o CD com o DNE dos correios no início não era 
criptografado e era em Access o que permitiu que pessoas copiassem estas 
informações sem autorização,mas nunca foi gratuíta e nunca foi de 
domínio público. Em formato excel era apenas a exportação do Access.

	Por favor, sem esta de falar do que não sabe numa lista para não criar 
opiniões inconsistentes.

  

Também acho importante citar a fonte, alias foi o que fiz originalmente
como você pode ver, mas vamos repetir a fonte foi www.correios.com.br

  
  
Se os Correios adotassem esta postura vergonhosa não fariam campanhas 
pelo correto preenchimento do CEP, ou vocês está insinuando que as 
campanhas dos Correios são apenas uma cortina de fumaça sobre uma 
postura friamente mercantilista que deseja faturar duas vezes auxiliando 
e induzindo o usuário a errar na primeira tentativa? talvez  a próxima 

  
  
	Eu nunca vi este tipo de campanha por parte do correio e posto mais de 
1000 objetos/dia. Não estou dizendo que eles tem interesse mesquinho, 
apenas que para o Correio, você colocar o cep certo ou errado "não fede 
e nem cheira". Normalmente quem fazem estas campanhas são as próprias 
empresas, já vi muito banco fazendo este tipo de campanha para reduzir 
as devoluções e consequentemente os custos.

  

Realmente tua memória não anda boa. Quando o CEP foi criado ou alterado
(minha memória também não anda das melhores) houveram comerciais,
inclusive televisivos quanto ao assunto. Possivelmente você não esteja
a tempo suficiente neste negócio. Quanto a "feder" é uma questão de
sensibilidade "nasal".

  
  
É revoltante a passividade e conformidade de parte de nossa população 
diante de certas coisas! Omissão também é crime!

  
  
	Justificar um crime com outro?? Só porque não acho o preço de um 
produto justo vou roubá-lo??

  

Quem falou em crime foi você! As pessoas tem mania de falar das outras
se olhando no espelho e acham que são todos iguais. De minha parte não
houve apologia ao crime mas a um justo direito dos reais empregadores e
financiadores do serviço público (os cidadãos, para quem não sabe) de
se posicionarem contra atos arbitrários frente a uma maioria. Faça uma
pequena estatística desta thread e verás que esta atitude que defendes
é minoria. Temos visto diariamente coisas que são legais mas que não
são "morais" sendo revistas. Rever conceito é uma atitude digna que nos
diferes de outros seres!

  
  
Se alguém tiver conhecimento de algum repositório de dados referentes a 
CEP (e não me refiro a programas de acesso ou a informações estruturadas 
e/ou tabuladas) que por não estarem up to date sejam de domínio público 

  
  
	O fato de não estarem atualizadas não significa que são de domínio público.

  

Novamente uma distorção do anteriormente citado. Acredito que se alguém
por seu próprio esforço buscar dados de forma legal e através de
métodos lícitos do todo ou de parte do que constituem os CEPs e
divulgá-los não estaria infringindo nenhuma lei. Será que é ilegal
alguém relacionar o CEP da sua residência, escritório, hospital, etc
estará implicando em crime? Já ouvi muito algoz da ditadura dizer que
estava apenas cumprindo a lei e esconder-se atrás dela para justificar
idéias suspeitas.

  
  
(o que é relativamente comum com versões um pouco desatualizadas de 
programas e informações) por favor divulguem. Acredito que, como a mim, 

  
  
	Eu também peço um "por favor". Façam isto em PVT, me envergonha fazer 
parte de um grupo de profissionais que usam este tipo de prática, se é 
que podemos chamar piratas de profissionais. Eu não gostaria de perder o 
orgulho de falar que participo de uma lista de um software livre como o 
postgresql, não apoiem pirataria nesta lista! Escolhi trabalhar com o 
PostGreSql por filosofia e não posso contradizê-la roubando trabalho 
alheio, se fosse assim, porque não roubar um Oracle por R$ 10,00?

  

Se eu como você me envergonha-se por fazer parte um grupo que
reivindica o que lhe parece justo e correto, eu com certeza não faria
parte dessa lista nem a entupiria de comentários que parecem ecoar
apenas em mim e outros poucos. Agora mais uma vez você está ouvindo o
eco de seus próprios pensamentos. Durante esta discussão não vi ninguém
pedir ou estimular a cópia pirata, mas ví várias pessoas defenderem
suas posições de que deveria haver uma versão "open source" dos CEPs
mesmo que representassem u

Re: [pgbr-geral] OFF - Re: Base de dados de CEP