Re: [pgbr-geral] Clonar base de dados

[Cicero Neto]

Oi, você poderia usar também p phppgadmin pelo navegador e executar um
export em txt, criar o banco novo e executar este script gerado.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 24 de junho de 2013 16:30, Matheus de Oliveira  escreveu:

> nem falando mal do top-posting... é, não tem jeito mesmo...
>
>
> 2013/6/24 Rebert Tomaz Aquino 
>
>> no caso enquanto tiver no dump ( uma base muito grande ) o banco continua
>> seu fuincionamento normal? leitura, escrita ... ?
>>
>>
> Sim, como um dump normal. Claro que a atividade do mesmo pode degradar um
> pouco a performance global, principalmente se restaurar no mesmo
> servidor/disco/etc.
>
>
>>
>> Em 24 de junho de 2013 16:21, Matheus de Oliveira <
>> matioli.math...@gmail.com> escreveu:
>>
>>>
>>>
>>>
>>> 2013/6/24 Giovani Rodrigues 
>>>
 Obrigado Matheus!

 Consegui clonar a base de dados utilizando o primeiro método que vc
 passou. Como hj só tem eu aqui, eu matei todas as sessões ativas e clonei!


>>> Ok. Só tome cuidado com o que eu falei antes (e ficou embaixo por causa
>>> do top-posting)...
>>>
>>> Em 24 de junho de 2013 15:42, Matheus de Oliveira <
>>> matioli.math...@gmail.com> escreveu:
>>>



 2013/6/24 Giovani Rodrigues 

> Boa tarde!
>
> Pessoal, como faço para clonar uma base de dados no postgres 9.2?
>
>
 Se não tiver usuários conectados você pode usar a base como template,
 exemplo:

 CREATE DATABASE dbclone TEMPLATE dboriginal;

 Se não, você pode usar o pg_dump:

 $ createdb dbclone
 $ pg_dump dboriginal | psql dbclone

 Eu quero clonar a base de produção para criar uma base de testes.
>
>
 Não use no mesmo servidor, nesse caso teria que usar mesmo o pg_dump:

 $ createdb nome_banco
  $ pg_dump -h  nome_banco | psql nome_banco

 Em ambos os casos lembre-se dos usuários e donos (owner) da base.


>>> Atenciosamente,
>>> --
>>> Matheus de Oliveira
>>> Analista de Banco de Dados
>>> Dextra Sistemas - MPS.Br nível F!
>>> www.dextra.com.br/postgres
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>>
>> --
>> Rebert Tomaz
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> 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] Warning quando da criação de um cluster

[Cicero Neto]

Este aviso é de segurança, apenas informa que durante o processo, tudo
ocorrerá no diretório tmp que não é seguro e o postgres sugere que você
pode mudar a pasta para um dirtório mais seguro, nada mais.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 24 de junho de 2013 16:19, Matheus de Oliveira  escreveu:

>
>
>
> On Mon, Jun 24, 2013 at 4:06 PM, Paulo Bastos wrote:
>
>> Senhores(as),
>>
>> Ao criar um cluster com o comando abaixo:
>>
>>  pg_createcluster -e Latin1 -u dbasocic -d /u1/jap/base 9.2 socic
>>
>> Recebi o seguinte warning:
>>
>>  Creating new cluster 9.2/socic ...
>>   config /etc/postgresql/9.2/socic
>>   data   /u1/jap/base
>>   locale pt_BR
>>   Warning: The socket directory for owners other than 'postgres'
>>   defaults to /tmp. You might want to change the unix_socket_directory
>> parameter
>>   in postgresql.conf to a more secure directory.
>>   port   5432
>>
>> O cluster foi criado. Aparentemente está tudo ok.
>>
>> Alguem poderia esclarecer o warning?
>>
>>
>
> Você alterou o dono do cluster para um usuário que não era postgres, isso
> significa que o usuário dbasocic do SO é que vai "rodar" esse cluster.
> Entretanto, o diretório padrão do PostgreSQL para Unix Domain Socket [1] no
> pacote Debian é /var/run/postgresql, cujo o dono é o usuário postgres (do
> SO). No seu caso ele está usando /tmp/, pois o usuário dbasocic não terá
> permissão de escrita em /var/run/postgresql/.
>
> A dúvida é: por que você não está usando o usuário postgres?
>
>
> [1] https://www.google.com/search?q=unix+domain+socket
>
> Atenciosamente,
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> 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] Warning quando da criação de um cluster

[Cicero Neto]

Simj, mas só durante a operação depois fica tudo nas tablespaces definidas
no banco

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 24 de junho de 2013 23:23, Matheus de Oliveira  escreveu:

>
>
> 2013/6/24 Cicero Neto 
>
>> Este aviso é de segurança, apenas informa que durante o processo, tudo
>> ocorrerá no diretório tmp que não é seguro e o postgres sugere que você
>> pode mudar a pasta para um dirtório mais seguro, nada mais.
>>
>>
> "tudo" ??
>
>
>>
>> Em 24 de junho de 2013 16:19, Matheus de Oliveira <
>> matioli.math...@gmail.com> escreveu:
>>
>>>
>>>
>>>
>>> On Mon, Jun 24, 2013 at 4:06 PM, Paulo Bastos wrote:
>>>
>>>> Senhores(as),
>>>>
>>>> Ao criar um cluster com o comando abaixo:
>>>>
>>>>  pg_createcluster -e Latin1 -u dbasocic -d /u1/jap/base 9.2 socic
>>>>
>>>> Recebi o seguinte warning:
>>>>
>>>>  Creating new cluster 9.2/socic ...
>>>>   config /etc/postgresql/9.2/socic
>>>>   data   /u1/jap/base
>>>>   locale pt_BR
>>>>   Warning: The socket directory for owners other than 'postgres'
>>>>   defaults to /tmp. You might want to change the unix_socket_directory
>>>> parameter
>>>>   in postgresql.conf to a more secure directory.
>>>>   port   5432
>>>>
>>>> O cluster foi criado. Aparentemente está tudo ok.
>>>>
>>>> Alguem poderia esclarecer o warning?
>>>>
>>>>
>>>
>>> Você alterou o dono do cluster para um usuário que não era postgres,
>>> isso significa que o usuário dbasocic do SO é que vai "rodar" esse cluster.
>>> Entretanto, o diretório padrão do PostgreSQL para Unix Domain Socket [1] no
>>> pacote Debian é /var/run/postgresql, cujo o dono é o usuário postgres (do
>>> SO). No seu caso ele está usando /tmp/, pois o usuário dbasocic não terá
>>> permissão de escrita em /var/run/postgresql/.
>>>
>>> A dúvida é: por que você não está usando o usuário postgres?
>>>
>>>
>>> [1] https://www.google.com/search?q=unix+domain+socket
>>>
>>> Atenciosamente,
>>> --
>>> Matheus de Oliveira
>>> Analista de Banco de Dados
>>> Dextra Sistemas - MPS.Br nível F!
>>> www.dextra.com.br/postgres
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MPS.Br nível F!
> www.dextra.com.br/postgres
>
>
> ___
> 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] Restaurar base linux em windows

[Cicero Neto]

Olá! você pensou em gerar um ARQ.sql a partir do phppgadmin em localhost.
Esta ferramenta via navegador gera um txt (ou .sql),  da estrutura e dos
dados.
Você pode aplicar este arquivo em um phppgadmin no seu windows ou quaquer
ferramenta que leia um arquivo.sql, inclusive o pgAdmin III.

O que acha?

Espero ter ajudado!



Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 27 de junho de 2013 11:32, Jean Domingues escreveu:

> >Eu tenho o seguinte senário:
> >
> >
> >Servidor: Linux 64bits, Postgres 9.1
> >
> >
> >Maquina desenvolvimento: Windows 64bits, Postgres 9.1
> >
> >
> >Para administrar as bases utilizo PgAdmin3 no Windows, faço backup e
> restore tranquilamente entre as máquinas.
> >
> >
> >Utilizo o Codepage UTF-8 atualmente
>
>
> Marcelo, você está se referindo a dump. Eu me refiro a cópia física da
> pasta de dados.
> ___
> 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] Erro: "Could Not Receive Data From Client"

[Cicero Neto]

Olá Bruno.

Posso estar enganado, mas isso parece ser problema de FRONT-END, TIME-OUT
de conexão, persistência e coisas do tipo.
O PostGreSQL está tão somente logando ocorrencias e essas são do cliente.

A conexão é via ODBC, JAVA, PERL, PYTON, UNIXODBC.
O FRONT-END é WEB, CLIENT-SERVER, 3 CAMADAS?

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 27 de junho de 2013 12:59, Bruno Damasceno escreveu:

> Pessoal, boa noite! Estou ingressando na área de administração PostgreSQL e
> ainda estou adquirindo conhecimento. Pois bem, hoje já recebi uma questão
> pra analisar, segue abaixo:
>
> No log do PostgreSQL, estão logando dois erros:
>
> 2013-06-26 09:43:10 LOG:  unexpected EOF on client connection
> 2013-06-26 09:43:10 LOG:  could not receive data from client: No connection
> could be made because the target machine actively refused it.
>
> 2013-06-26 12:32:00 LOG:  incomplete startup packet
> 2013-06-26 16:10:32 LOG:  could not receive data from client: No connection
> could be made because the target machine actively refused it.
>
>
> O cliente relata que a aplicação trava consulta e inserção de dados, sendo
> necessário reiniciar o serviço do PostgreSQL para voltar a funcionar.
>
> Esse ambiente está rodando o PostgreSQL 8.2.9 em um Windows Server 2008. Já
> alertei que será necessário atualizar a versão, mas estou analisando os
> possíveis impactos para atualizar para 9.2.4.
>
>
> Alguém pode me ajudar com esses erros acima, por favor?
>
> Um abraço!
>
> Bruno Damasceno
>
> ___
> 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: Erro: "Could Not Receive Data From Client"

[Cicero Neto]

Isso ajuda sim.
Veja na configração de TIME-OUT da conexão ODBC do servidor e ou do cliente.
O padrão é de 300 a 600 milisegundos tente dobrar este tempo como algo
entre 600 a 1200 milisegundos.
Atente que um tempo muito grande pode deixar a comunicação mais lenta, pois
mantem um buffer maior na estação e ou no servidor.
Pode verificar também se o driver ODBC está atualizado, pois, ele suporta
versões anteriores do postgreSQL.
Veja atualizar o banco de dados não é necessáriamente a solução do
problema, tenho bases postgres 8.0. "bolinha",  funcionando sem problemas.

Tente isso, qualquer coisa vamos nos falando.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 27 de junho de 2013 13:50, Bruno Damasceno escreveu:

> Cicero, boa tarde!
>
> Não tenho certeza, mas creio que seja via ODBC. Alguma dica?
>
> Abraços!
>
> Bruno Damasceno
>
> --
> De: pgbr-geral [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em
> nome
> de Cicero Neto
> Enviada em: quinta-feira, 27 de junho de 2013 13:45
> Para: Comunidade PostgreSQL Brasileira
> Assunto: Re: [pgbr-geral] Erro: "Could Not Receive Data From Client"
>
> Olá Bruno.
> Posso estar enganado, mas isso parece ser problema de FRONT-END, TIME-OUT
> de
> conexão, persistência e coisas do tipo.
> O PostGreSQL está tão somente logando ocorrencias e essas são do cliente.
> A conexão é via ODBC, JAVA, PERL, PYTON, UNIXODBC.
> O FRONT-END é WEB, CLIENT-SERVER, 3 CAMADAS?
>
>
> Seja Livre!
> Use OpenSource!
> LineOn, Tecnologia da Informação!
> http://lineonti.wordpress.com
>
> Em 27 de junho de 2013 12:59, Bruno Damasceno 
> escreveu:
> Pessoal, boa noite! Estou ingressando na área de administração PostgreSQL e
> ainda estou adquirindo conhecimento. Pois bem, hoje já recebi uma questão
> pra analisar, segue abaixo:
>
> No log do PostgreSQL, estão logando dois erros:
>
> 2013-06-26 09:43:10 LOG:  unexpected EOF on client connection
> 2013-06-26 09:43:10 LOG:  could not receive data from client: No connection
> could be made because the target machine actively refused it.
>
> 2013-06-26 12:32:00 LOG:  incomplete startup packet
> 2013-06-26 16:10:32 LOG:  could not receive data from client: No connection
> could be made because the target machine actively refused it.
>
>
> O cliente relata que a aplicação trava consulta e inserção de dados, sendo
> necessário reiniciar o serviço do PostgreSQL para voltar a funcionar.
>
> Esse ambiente está rodando o PostgreSQL 8.2.9 em um Windows Server 2008. Já
> alertei que será necessário atualizar a versão, mas estou analisando os
> possíveis impactos para atualizar para 9.2.4.
>
>
> Alguém pode me ajudar com esses erros acima, por favor?
>
> Um abraço!
>
> Bruno Damasceno
>
> ___
> 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
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tabela já nasceu lenta, pode?

[Cicero Neto]

Complementando, verifique se tabelas mais lentas estão nas mesmas
tablespaces que as mais rápidas, veja também o número de índices que esta
tabelas possuem.
SELECT "*" é o PIOR plano de execução que o KERNEL pode executar, opte
sempre por SELECT CAMPO1,2,3,4,...N.
Caso use a clausura WHERE pririze-a INVERTENTO a ordem dos campos EXE:-
WHERE CAMPO4,3,2,1.

T+

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 15 de julho de 2013 21:28, Flavio Henrique Araque Gurgel <
fla...@4linux.com.br> escreveu:

> > Algumas tabelas do meu banco acabam sendo mais lentas para abrir do
> outras, o
> > que pode ser?
>
> Vários fatores.
>
> > Sei que muito coisa pode influenciar em ralação a hardware e
> configuração,
> > mas uma tabela ser "melhor" que outra ainda não tinha visto.
> > Por exemplo, tenho a tabela de clientes com media de 5mil registros num
> > select * from tabela, sem nenhum filtro ele demora 1617ms para abrir, já
> > outra tabela com 103 registros demora 3927ms
> >
> > Como pode isso ?
>
> Um dos argumentos abaixo:
> 1) Como as tabelas são pequenas, o uso de cache influencia muito o
> desempenho de um select sem parâmetros como o seu. Uma tabela pode estar
> inteiramente em cache e ser lida muito rapidamente.
> 2) O que importa não é o número de linhas (ou registros, se preferir) mas
> quantos bytes são retornados. Uma única linha num bytea de 500 MiB vai
> demorar 500 vezes mais para ser lida do disco do que uma linha de 5 MiB.
> 3) Inchaço (bloat) da tabela. Uma tabela com centenas de updates e vai ter
> mais espaço ocupado em disco, obrigando a fazer muito I/O. Logo, um select
> nela vai demorar mais.
>
> > Meu servidor deve estar com problema de "balanceamento", rs ?
> > Observando ambas as tabelas não existe nada de extraordinário entre elas,
> > ambas foram criadas do mesmo modo e seus indices são somente em campos
> mais
> > utilizados em selects, porem meus testes foram em select simples, sem
> > filtro.
> >
> > Não estou entendendo porque a lentidão em apenas algumas tabelas. (com
> poucos
> > registros)
>
> Nada a ver. Desencana, isso é normal. Um teste desses em tabelas pequenas
> vai apresentar o comportamente que você está vendo. Se você repetir os
> mesmos selects após limpar o cache do S.O. e reiniciar o PostgreSQL vai dar
> números completamente diferentes. E, se repetir a consulta diversas vezes,
> também.
>
> Mande-nos um explain analyze de seus SELECTs e dará pra ver direitinho o
> custo de cada uma delas.
>
> []s
>
> __
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: fla...@4linux.com.br
> __
> FREE SOFTWARE SOLUTIONS
>
> ___
> 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] Tabela já nasceu lenta, pode?

[Cicero Neto]

Isso nada tem a ver com postgres, mas sim com SQL, vide...

http://pt.wikipedia.org/wiki/SQL

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 17 de julho de 2013 11:38, Marcelo da Silva  escreveu:

> Eu já li com respeito ao campos com dados repetitivos, estes aconselha-se
> a vir primeiro para otimizar a consulta.
> Por exemplo:
>
> Tabela Clientes
>   cod_cli integer
>   nome varchar(50)
>   cidade varchar(50)
>   estado char(1)
>
> select * from clientes
> where (estado not in('SP'))
>   and(cidade = 'VARGEM')
>
> Dessa forma como "estado" possui muitos valores duplicados ele já elimina
> muitos registros...
>
> Mas isso lí em matéria para o MySQL, não sei se é aplicavel no Postgres
> (imagino que sim)
> Também vejo que tudo vai depender da disposição dos indices também, já que
> normalmente não se cria indices para capos tipo Flag (S/N, UF, V/F e etc)
>
> Bem, qualquer dica é bem vinda :)
>
>
> Marcelo Silva
> 
>
>
>
> Em 17 de julho de 2013 11:15, Fabiano Machado Dias <
> fabi...@wolaksistemas.com.br> escreveu:
>
>>  Em 16-07-2013 09:03, Cicero Neto escreveu:
>> --corte--
>>
>> Caso use a clausura WHERE pririze-a INVERTENTO a ordem dos campos EXE:-
>> WHERE CAMPO4,3,2,1.
>>
>> --corte--
>>
>>
>> Bom dia,
>>
>> Você pode indicar alguma documentação onde informa isto?
>>
>> Já li toda a documentação do PostgreSQL, principalmente a parte de
>> otimização e reescrita de SQL e não lembro de algo informando que a ordem
>> de campos no WHERE tem impacto no desempenho, inclusive já fiz testes e
>> nunca observei alteração.
>>
>> Como já faz um tempo que li gostaria de saber de onde você tirou esta
>> informação, posso estar enganado, mas acredito que não exista nenhuma
>> relação na ordem do WHERE em relação a desempenho na consulta.
>>
>> Abraço,
>> Fabiano Machado Dias
>>
>>- Português - detectado
>>- Inglês
>>- Português
>>
>>
>>- Inglês
>>- Português
>>
>><#13fed11745a84581_13fecfcefe68618b_>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> Marcelo Silva
> 
> Desenvolvedor Delphi / PHP
> My Postgres database
> Cel.: (11) 99693-4251
>
> ___
> 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] Firebird para PostgreSQL

[Cicero Neto]

Bom dia André.
Qual plataforma de S.O. você está usando?
Qual o HardWare está utilizando?
Qual o tipo de aplicação está usando? Local ou Web?

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 18 de julho de 2013 09:24, André Geraldo dos Santos <
andresanto...@gmail.com> escreveu:

> Caros bom dia!
>
> Estou planejando uma virada de firebird para Postgresql 9.2, minha base de
> dados atualmente está com 30 GB e não estou vendo uma forma rápida e fácil
> de migrar esses dados.
>
> Alguém já passou por alguma situação semelhante, se passou como resolveu?
>
> Estou trocando de firebird para PostgreSQL em busca de melhor performance,
> escalabilidade e segurança.
>
> A minha base de dados Firebird vai ficando mais lenta a cada dia que
> passa, percebo que melhora um pouco após fazer um backup/restore mas, volta
> a ficar lenta em questão de 1 ou 2 semanas.
>
> Gostaria de contar com a contribuição de todos.
> Aguardo um retorno.
> --
>
> Atenciosamente,
>
> André Geraldo dos Santos
> Certified Delphi® Developer XE2
> Analista Desenvolvedor e Consultor
> Belo Horizonte / Minas Gerais
> E-mail:andresanto...@gmail.com
> Telefone : +55 31 3047-6506 8746-9651
>
>
> ___
> 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] Índice composto + Índice simples

[Cicero Neto]

Olá, sou DBA SR a mais de 15 anos e entendo que você poderia optar por um
índice com os 3 campos e quando precisar da pesquisa pelo campo "C",
utilize like.
Índices locais como uma PK são cravados direto na tabela e actualizados
sempre que houver alteração neste campo, como inclusão.
Índices não locais são ORBITAIS, ou seja, orbitam a tabela como arquivos
menores indicando onde está o registro.

*A questão de "onde está o registro", nada tem a ver com performance, o que
existe é  PLANO DE EXECUÇÃO, que o núcleo do postgres vai utilizar na hora
da pesquisa.*

Espero ter ajudado,
Caso precise de mais detalhe, passe o "CENÁRIO". Só ele pode esclarece qual
melhor forma.

*SQL É UM QUEBRA CABEÇA COM POUCAS PEÇAS!*
serve pára ORACLE, SQL SERVER, FIREBIRD, MYSQL, POSTGRES, TERADATA, INGRES,
INFORMIX, só não serve para PROGRESS.


T+

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 6 de dezembro de 2013 11:32, Matheus de Oliveira <
matioli.math...@gmail.com> escreveu:

>
>
>
> 2013/12/6 Fabrízio de Royes Mello 
>
>> On 06-12-2013 08:45, Matheus de Oliveira wrote:
>>
>>>
>>> 2013/12/5 Matheus Saraiva >> >
>>>
>>>
>>> Tendo os campos A, B, C
>>>
>>> digamos que eu crie um índice composto (A, B) e também crie um
>>> índice simples ( C ). Sei que se for feita uma consulta apenas com o
>>> campo A o indice (A, B) será usado. Mas se eu fizer uma consulta com
>>> filtro em (C, A), os dois índices separados serão usados?
>>>
>>>
>>> Eles poderão ser usados sim. Mas, como sempre, depende. Nesse caso irá
>>> depender de quão seletivo seu filtro é para cada campo.
>>>
>>> Vamos pensar num exemplo simples. Numa tabela com 10 milhões de
>>> registros, supondo que você faça:
>>>
>>>  SELECT ... FROM foo WHERE a = 10 AND c = 15;
>>>
>>> O PostgreSQL vai poder usar qualquer um dos índices que você criou. Mas
>>> para decidir qual (ou quais) usará, ele tentará "adivinhar" quantos
>>> registros cada filtro retornará, da seguinte forma:
>>>
>>> 1. Quantas tuplas somente o filtro `a = 10` retorna?
>>> 2. Quantas tuplas somente o filtro `c = 15` retorna?
>>> 3. Quantas tuplas ambos filtros, `a = 10 AND c = 15` retornam?
>>>
>>> Esse "adivinhar" é baseado nas estatísticas do banco de dados (vamos
>>> deixar essa pra outro momento). Vamos supor alguns exemplos baseados nos
>>> itens acima:
>>>
>>> 1. Existem aproximadamente 1 milhão de registros com `a = 10`.
>>> 2. Existem aproximadamente 5 mil registros com `c = 15`.
>>> 3. Existem aproximadamente mil registros com ambos.
>>>
>>> Nesse caso podemos dizer (um chute) que o PostgreSQL iria preferir usar
>>> somente o índice em (C). Com ele iria encontrar os 5 mil registros onde
>>> `c = 15`, em seguida, buscaria (da tabela mesmo) os (meros) mil
>>> registros onde `a = 10`. Vale mais a pena do que o trabalho extra para
>>> navegar nos dois índices. Agora, se pensarmos diferente:
>>>
>>> 1. Existem aproximadamente 1 milhão de registros com `a = 10`.
>>> 2. Existem aproximadamente 800 mil registros com `c = 15`.
>>> 3. Existem aproximadamente 2 mil registros com ambos.
>>>
>>> Nesse último caso, se ele pegar qualquer um dos dois índices unicamente,
>>> ainda teria muitas tuplas para pegar da tabela, para no final ficar com
>>> apenas 2 mil registros. Então ele irá preferir navegar pelos dois
>>> índices juntos, e pegar só o que interessa da tabela. Agora, como ele
>>> faz isso? Da seguinte forma:
>>>
>>> 1. Navega no índice em (A,B) e busca pelos campos onde `a = 10`. Com o
>>> resultado, gera um bitmap marcando as páginas que casam com 1 e que não
>>> casam com 0
>>> 2. Navega no índice em (C) e busca pelos campos onde `c = 15` e gera um
>>> bitmap desse resultado também.
>>> 3. Realiza uma operação de AND nos dois bitmaps, o que é bem rápido (são
>>> só bitmaps) e gera como resultado um novo bitmap, que mapeia quais são
>>> as páginas da tabela que contém ambos os valores.
>>> 4. Por fim, basta navegar nas páginas marcadas com o bitmap resultante
>>> do AND anterior. Nesse caso ele terá que "reverificar" cada tupla de
>>> cada página, mas veja que se a tabela tem 10 milhões e queremos apenas 2
>>> mil registros, estamos falando de cerca de apenas 0,02% da tabela.
>>>
>>> Vale ressaltar que o PostgreSQL usa dados estatísticos para encontrar
>>> esses possíveis valores de retorno. Nesse caso ele não precisa da
>>> quantidade **exata** de registros que cada filtro retorna, mas quanto
>>> mais próximo do real, melhor serão os planos de execução criados. Logo,
>>> manter as estatísticas atualizadas é uma tarefa muito importante.
>>>
>>>
>> Muito legal sua resposta Matheus, vc poderia transformar em post em seu
>> blog hein!!!
>>
>>
>
> ... Acho que eu estava inspirado, =P.
>
> Depois que eu mandei eu pensei exatamente nisso. Vou fazer logo que montar
> um exemplo real também.
>
> Valeu cara.
>
> Abraços.
>
> --
> Matheus de Oliveira
> Analista de Banco de Dados
> Dextra Sistemas - MP

Re: [pgbr-geral] BSD x Linux

[Cicero Neto]

CentOS, Debian, Oracle-Linux ou até mesmo um Free BSD são SOs estáveis e
sedimentados.

Mas isso é a opnião de um cara que já usou todos esses e ainda usa alguns
desses.

T+

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 9 de dezembro de 2013 18:20, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Na opinião de vocês, vale a pena o investimento em uma distribuição
 >>enterprise, motivado pela questão do hardware?

>>>
> Pra mim, não.
> O que importa é o que eu e minha equipe sabemos administrar bem.
>
>
>  >Depende de muitos fatores.  Há quem prefira montar seu equipamento, há
>>> >quem precise de toda essa cadeia de homologações e certificações pelo
>>> >fator de responsabilidade corporativa.
>>>
>>
> Eu sempre achei isso um monte de lorota. Hoje, felizmente, eu posso dizer
> que homologação, principalmente no Brasil, é o fator que mais atrapalha na
> hora de escolher componentes de hardware e software.
>
> Jogam-se fora excelentes oportunidades, funcionalidades e, principalmente,
> dinheiro, quando se está preso a uma plataforma dita homologada.
>
> Com versões do PostgreSQL, por exemplo, tive clientes que por terem
> homologado a versão X.Y (em alguns casos até .Z) ficaram sem atualizações
> importantes, sem funcionalidades importantes (tendo que recorrer a recursos
> esdrúxulos em alguns casos) e gastando rios de dinheiro em perda de tempo,
> pra manter a dita "homologação" em vez de gastar um pouco menos e atualizar
> a cadeia ou mesmo trocar de solução.
>
>
>  >Se eu fosse comprar agora, e não tivesse que me preocupar muito com
>>> >corporativismos, procuraria com carinho quem suporta Debian, mesmo que
>>> >fosse só a HP ou algum outro vendedor, menor que as grandes.  No teu
>>> >caso, é ainda mais difícil ter homologação no Brasil para BSD que para
>>> >Debian, creio; mas se eu tivesse algum SysAdmin muito dos bons na
>>> >equipe, daqueles que sabe mesmo o que está fazendo, talvez fosse até
>>> >pelo caminho de montar o equipamento internamente.
>>> >
>>> >Pena que a Oracle fagocitou a Sun.  A Sun também estava indo pelo
>>> >caminho de certificar Debian.
>>> >
>>> >Daqui a pouco isso tudo ficará ainda mais complicado, com os servidores
>>> ARM.
>>>
>> +1, concordo com a resposta dada.
>>
>
> Eu diria que quem quer seguir o caminho Debian tem que se preocupar em
> funcionamento, não homologação.
>
> A única coisa que vejo a se preocupar são:
> - garantia do hardware
> - atualização de (malditos) firmwares
>
> Se isso aí em cima for possível com Debian, vá de Debian. O resto é só
> testar e, se funcionar, vai funcionar pra sempre.
>
> Mas cada um é cada um. Siga o caminho que der mais conforto.
>
> []s
> Flavio Gurgel
>
> ___
> 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] Como resolver alta demanda de conexoes

[Cicero Neto]

Bom dia!
Olha, me parece improvável você ter esse problema, para um banco de dados
tão pequeno.
Acredito que seja necessário fazer um tunning na base de dados, rever
indices locais e orbitais, substituir consultas em tabelas por visões,
rever procs, gatilhos, etc.
Extraia planos de execução, veja se o acesso a base está correto. Sou DBA
SR e sinceramente, acredito que Hardware não resolve ou mascara o problema.

Att.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 1 de fevereiro de 2014 03:42, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
> > depois de vários testes, deixamos o PgBoucer passando 22 conexões para o
> PostgreSql. Passamos a ter melhor resposta mesmo. Com o teste de 500 users
> no Jmeter, o banco responde bem no PgAdmin, porém a aplicação web fica um
> pouco lenta.
>
> Fico feliz que tenha evoluído com seus resultados!
>
> Agora é hora de tirar o segundo truque da cartola do PgBouncer: crie mais
> um banco de dados "virtual" apontando pro mesmo banco real, e aponte sua
> aplicação web para esse banco "separado".
>
> Assim, você terá uma fila exclusiva para a aplicação web, que certamente
> tem perfil diferente da outra, e você pode controlar quantas conexões vai
> reservar pra cada lado.
>
> Tente e conte pra nós.
>
> []s
> Flavio Gurgel
>
> ___
> 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] Como resolver alta demanda de conexoes

[Cicero Neto]

*PARA OS DBAS jr* ou candidato há ..

ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .

SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada
aqui q

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 3 de fevereiro de 2014 11:54, Tiago Adami  escreveu:

> Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA,
> Leandro  escreveu:
> > 2014-02-03 Cicero Neto :
> >> rever indices locais e orbitais
> >
> > Alguém já entendeu o que o Cícero quer dizer com isso?
>
> Estava redigindo uma pergunta à lista quando sua mensagem apareceu -
> ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um
> momento me senti emburrecido por não conhecer a diferença entre os
> dois...
>
> TIAGO J. ADAMI
> http://www.adamiworks.com
> @tiadami
> ___
> 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] Vaga Analista de Suporte DBA

[Cicero Neto]

Jorge, boa tarde.
Por favor, me responda. A vaga é para DBA PostGres/Oracle, ou
Oracle/PostGres ou só postgress?

Grato a atenção.

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 3 de fevereiro de 2014 17:16, jorge  escreveu:

>  Bom dia pessoal,
>
> Preciso de um DBA Jr. e um Pleno para trabalhar em São Jose dos
> Pinhais - PR (Centro).
>
> A vaga é para a maior empresa de rastreamento de veículos do Brasil
> (SASCAR).
>
> Obrigatoriamente independente do nível, deve saber usar o Linux e
> Postgresql.
>
> Obrigatório Oracle (porem o nível não é diferencial no momento).
>
> Benefícios: Plano de saúde e odontológico Bradesco integral sem
> desconto em folha, VR ou VA + PPR
>
> Horário padrão -> segunda a sexta das 08:00 as 18:00 (porem pode
> ser
> um pouco flexível na entrada e saída dependendo das necessidades do
> candidato)
>
> Salários de 4k a 5k (vai depender do nível)
>
> Obs:
> Temos atualmente 2 datacenters  e em um deles Exadata e Exalogic
> (parte da Oracle), porem, o DBA em questão não tem foco nesta tecnologia a
> curto prazo (por isso vai precisar saber Oracle);
> Só usamos servidores Linux (varias distribuições);
> Atualmente estamos em 4 DBAs, porem, precisamos de mais;
>
> Obrigatório ficar de plantão e fazer sobreaviso (porem, quanto
> melhor fazer a lição de casa, não é acionado e ganha mesmo assim);
>
> Minha opinião que já estou a 7 anos na empresa (programador -> DBA
> -> DBA/Coordenador):
>
> Quem quer aprender e crescer profissionalmente esse é o
> lugar. Tecnologia de ponta, muitas possibilidades de aprendizado e
> liberdade
> para melhoria de processos.
> Empresa em constante crescimento e passando por um momento
> muito bom referente a parte de tecnologia e inovação.
>
>
> ___
> 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] Como resolver alta demanda de conexoes

[Cicero Neto]

que fico pasmo

"pas.mo
*sm* (*lat spasmu*) *1* Assombro, espanto, grande admiração. *2*
Desfalecimento,
desmaio. *3 **Vet V tétano. **4 **Reg* (Sul e Centro) Contração espasmódica
dos músculos maxilares, por excessiva sede da rês. *adj V pasmado*."

Entenderam???


Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 5 de fevereiro de 2014 14:27, Cicero Neto escreveu:

> *PARA OS DBAS jr* ou candidato há ..
>
> ÍNDICE LOCAL É QUANDO A INDEXAÇÃO É FÍSICA, OU SEJA DIRETO NA TABELA, COMO
> UMA PK, ÍNDICES ORBITAIS COM O PRÓPRIO NOME DIZ, ORBITAM A TABELA ,
> SÃO TABELAS DE ÍNDICES AUXILIARES COMO SE FOSSE O ÍNDICE DE UM LIVRO. ISSO
> GERA I/O (vocês sabem o que é I/O né?) no disco, sobrecarrega o BUFFER .
>
> SOU PROFISSIONAL DE TI A 30 ANOS, DBA SR A 15. leio muita coisa postada
> aqui q
>
> Seja Livre!
> Use OpenSource!
> LineOn, Tecnologia da Informação!
> http://lineonti.wordpress.com
>
>
>
> Em 3 de fevereiro de 2014 11:54, Tiago Adami  escreveu:
>
> Em 3 de fevereiro de 2014 11:50, Guimarães Faria Corcete DUTRA,
>> Leandro  escreveu:
>> > 2014-02-03 Cicero Neto :
>> >> rever indices locais e orbitais
>> >
>> > Alguém já entendeu o que o Cícero quer dizer com isso?
>>
>> Estava redigindo uma pergunta à lista quando sua mensagem apareceu -
>> ao mesmo tempo que inúmeras páginas do Google estavam abertas. Por um
>> momento me senti emburrecido por não conhecer a diferença entre os
>> dois...
>>
>> TIAGO J. ADAMI
>> http://www.adamiworks.com
>> @tiadami
>> ___
>> 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] Listar todas as tabelas

[Cicero Neto]

Select * from pg_tables

Seja Livre!
Use OpenSource!
LineOn, Tecnologia da Informação!
http://lineonti.wordpress.com



Em 12 de fevereiro de 2014 19:16, ALLAN YAHOO
escreveu:

>   Boa noite pessoal,
>
> Uma pergunta relativamente simples para vocês, mas complexa para mim. Como
> faço para listar todas as tabelas que tenho dentro do schema public ?
>
> Obrigado,
> Allan de Sá
>
> ___
> 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