[pgbr-geral] [ANÚNCIO] São Paulo Perl Work shop 2010
Begin forwarded message: From: Thiago Rondon thi...@aware.com.br Date: 17 de maio de 2010 23:53:52 BRT To: Sao Paulo Perl Mongers saopaulo...@mail.pm.org, Perl Mongers Rio de Janeiro rio...@pm.org, Cascavel Perl Mongers cascavel...@pm.org, recife...@pm.org Subject: [Cascavel-pm] [ANÚNCIO] São Paulo Perl Workshop 2010 Reply-To: Cascavel Perl Mongers cascavel...@pm.org Tema: Desenvolvimento Web Corporativo A São Paulo Perl Mongers promove em parceria com o IG, um Workshop com o tema Desenvolvimento Web Corporativo, onde serão abordadas as tecnologias mais produtivas e elegantes do mundo Perl voltadas para a criação de aplicações para Internet. O evento irá contar com a participação do londrino Tomas Doran, no qual é um dos desenvolvedores core do Catalyst e irá falar sobre arquitetura de grandes plataformas em Perl, além dos frameworks e monitoramento de performance em tempo real. Também iremos contar com a participação especial de Eden Cardim, no qual irá tratar sobre técnicas para construção de formulários web, com validação e verbosidade, como listas de ítens selecionáveis, wizards e múltipla submissão. O evento será realizado na sede do IG na rua Amauri, 299 (Itaim) - São Paulo no próximo dia 10 de julho, das 13:00hs às 17:30hs. As inscrições são gratuitas e limitadas e podem ser realizadas através do site http://sao-paulo.pm.org. -- wallace reis/wreis http://www.linkedin.com/in/wallacereis ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Monitoramento Automatico
Bom dia, existe algum serviço no postgresql q monitora o banco e qq comportamento anormal ele dispara email alertando ? Se sim, qual seria ? Abs Pedro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Slony com 3 Slaves
No terceiro nodo vc tem que mudar o parâmetro receiver para 3 e não 2 como estava. subscribe set ( id = 1, provider = 1, receiver = 3, forward = no); Faz aí e diz se funcionou. []s --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony com 3 Slaves Para: pgbr-geral@listas.postgresql.org.br Data: Segunda-feira, 17 de Maio de 2010, 17:17 Olá a todos! Talvez possa me ajudar. Consegui fazer o slony replicar master para um slave, porem quando eu fui tentar replicar de um master para varios slaves o terceiro nodo não recebe a replicação. Abaixo segue a conf do arquivo que comunica com o cluster. #!/bin/sh CLUSTER=sief #DEFINA AQUI O NOME DO SEU CLUSTER DB1=sief #NOME DO BANCO DE DADOS DO COMPUTADOR1 DB2=sief #NOME DO BANCO DE DADOS DO COMPUTADOR2 DB3=sief #NOME DO BANCO DE DADOS DO COMPUTADOR3 H1=192.168.1.254 #HOSTNAME (NOME DA MAQUINA), DO COMPUTADOR1 H2=192.168.1.29 #HOSTNAME DO SEGUNDO COMPUTADOR H3=192.168.10.10 #HOSTNAME DO SEGUNDO COMPUTADOR U=postgres #USUARIO PARA A REPLICAÇÃO, PADRÃO: POSTGRES SENHA=SENHA slonik _EOF_ cluster name = $CLUSTER; node 1 admin conninfo = 'dbname=$DB2 host=$H1 user=$U password=$SENHA port=5573'; node 2 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; init cluster (id = 1, comment = 'Cluster Master'); #especifica o set de replicacao create set (id = 1, origin = 1, comment = 'objetos replicados'); #tabelas que seram replicadas set add table(set id=1,origin=1,id=10,full qualified name='public.adm_enroll'); #no escravo e caminho que ele fara, especificar event node ! store node (id = 3, event node= 1,comment = 'Slave'); store path (server = 1, client = 2,conninfo = 'dbname=$DB1 host=$H1 port=5573 user=$U password=$SENHA'); store path (server = 2, client = 1,conninfo = 'dbname=$DB2 host=$H2 port=5573 user=$U password=$SENHA'); store path (server = 3, client = 1,conninfo = 'dbname=$DB3 host=$H3 port=5573 user=$U password=$SENHA'); store listen (origin = 1, provider = 1, receiver = 2); store listen (origin = 2, provider = 2, receiver = 1); store listen (origin = 3, provider = 2, receiver = 1); Este script eu rodo no servidor, ja nos 2 cliente eu rodo este script de sicronizar abaixo: #!/bin/sh CLUSTERNAME=sief MASTERDBNAME=sief SLAVEDBNAME=sief REPLICATIONUSER=postgres SENHA=SENHA MASTERHOST=192.168.1.254 SLAVEHOST=192.168.1.29 slonik _EOF_ # # This defines which namespace the replication system uses # cluster name = $CLUSTERNAME; # # Admin conninfo's are used by the slonik program to connect # to the node databases. So these are the PQconnectdb arguments # that connect from the administrators workstation (where # slonik is executed). # node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST port=5573 user=$REPLICATIONUSER password=$SENHA'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port 5573 user=$REPLICATIONUSER password=$SENHA'; # # Node 2 subscribes set 1 # subscribe set ( id = 1, provider = 1, receiver = 2, forward = no); _EOF_ Segundo slave: #!/bin/sh CLUSTERNAME=sief MASTERDBNAME=sief SLAVEDBNAME=sief REPLICATIONUSER=postgres SENHA=SENHA MASTERHOST=192.168.1.254 SLAVEHOST=192.168.10.10 slonik _EOF_ # # This defines which namespace the replication system uses # cluster name = $CLUSTERNAME; # # Admin conninfo's are used by the slonik program to connect # to the node databases. So these are the PQconnectdb arguments # that connect from the administrators workstation (where # slonik is executed). # node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST port=5573 user=$REPLICATIONUSER password=$SENHA'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port 5573 user=$REPLICATIONUSER password=$SENHA'; # # Node 2 subscribes set 1 # subscribe set ( id = 1, provider = 1, receiver = 2, forward = no); _EOF_ Alguem sabe o que pode ser? lembrando que se eu retirar o 3 nodo replica 100%. -Anexo incorporado- ___ 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] IV Conferência global PostgreSQL
Transmitindo direto de Ottawa, via Google Buzz. Sugestões, perguntas? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Criar visão entre bancos no postgre sql
Prezados, Tenho dois bancos no Postgresql. Preciso criar uma visão em um banco referenciando uma tabela no outro. Procurei na documentação do Postgresql porém não consegui ver nenhuma solução. Alguma sugestão? -- Emanoel Tadeu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Criar visão entre bancos no postgre sql
Use o DBlink para isso. Tem na documentação oficial: http://www.postgresql.org/docs/9.0/static/contrib-dblink-connect.html [] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Criar visão entre bancos no postgre sql
Se são duas bases na mesma instância de Banco de dados, bastaria dar um grant de select em uma base para ser visível pela outra. A partir daí seria possível criar uma view com um select referenciando a tabela da outra base. Alex Em 18 de maio de 2010 10:14, Emanoel Tadeu emanoelta...@gmail.comescreveu: Prezados, Tenho dois bancos no Postgresql. Preciso criar uma visão em um banco referenciando uma tabela no outro. Procurei na documentação do Postgresql porém não consegui ver nenhuma solução. Alguma sugestão? -- Emanoel Tadeu ___ 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] IV Conferência global PostgreSQL
2010/5/18 Leandro DUTRA leandro.gfc.du...@gmail.com: Transmitindo direto de Ottawa, via Google Buzz. Sugestões, perguntas? Mudei para Identi.ca, http://identi.ca/leandrod/all — espero que o silêncio seja porque estão todos concentrados lá! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento Automatico
Opa, esse ai eu quero saber tambem Em 18 de maio de 2010 09:00, Pedro Espíndola pespindo...@gmail.comescreveu: Bom dia, existe algum serviço no postgresql q monitora o banco e qq comportamento anormal ele dispara email alertando ? Se sim, qual seria ? Abs Pedro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att., Eduardo Amaral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Monitoramento Automatico
Bem... Raramente o usuário trabalha diretamente com o banco de dados, utilizando instruções sql para tratar as situações. Normalmente é o aplicativo ponte que faz isso. E esse aplicativo é que deve, eventualmente, disparar email ou qualquer outro aviso para o usuário ou administrador. De se ressaltar que, comportamento anormal normalmente é verificado através de log de atividade, mas isso é outra coisa. Por outro lado, as ações básicas para o banco de dados são inserção, alteração, exclusão e consulta. No meu caso, a consulta não é relevante, então não fiz o tratamento da mesma, mas sei que é possível. Quanto as demais ações, fiz o seguinte: Criei uma função trigger que dispara uma notificação (notify) com o nome da tabela quando a mesma é alterada, ou seja, há uma inserção, alteração ou exclusão de registro. Essa notificação somente é disparada se tiver algum usuário ouvindo. Assim, quando o meu aplicativo obtém os dados da tabela, ele também dispara uma audição (listen) com o nome da mesma. De tempos em tempos, verifico se há alguma notificação com o nome da tabela. Se ela existe é porque a tabela foi alterada, ainda que para conter os mesmíssimos dados. Daí aviso o usuário que os dados visualizados podem estar desatualizados, solicitando um 'refresh' dos mesmos. No final da utilização disparo um unlisten e pronto. Mas dependendo do aplicativo, dá pra fazer muiito mais. Como dizia o Ramalho, esse mesmo, do Clipper, é sempre bom programar defensivamente. Verifique o comportamento anormal previsível e impeça-o ou elimine-o antes que aconteça. E as situações são muitas... Se não quer que o usuário x faça alterações na tabela y, não dê autorização ao mesmo para fazê-lo, seja através do próprio postgresql ou o seu aplicativo. Se não quer que o usuário x tenha acesso ou visualize informações da tabela y, não dê autorização ao mesmo para fazê-lo, seja através do próprio postgresql ou o seu aplicativo. Pronto... MarceloG Em 18/05/2010 12:35, Eduardo Amaral escreveu: Opa, esse ai eu quero saber tambem Em 18 de maio de 2010 09:00, Pedro Espíndola pespindo...@gmail.com mailto:pespindo...@gmail.com escreveu: Bom dia, existe algum serviço no postgresql q monitora o banco e qq comportamento anormal ele dispara email alertando ? Se sim, qual seria ? Abs Pedro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br mailto:pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att., Eduardo Amaral ___ 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] Slony com 3 Slaves
OláAgradeço sua ajuda.Fiz o que você me sugeriu, fui no nodo 3, e alterei ultimo arquivo abaixo o receiver de 2 para 3 e mesmo assim o node 3 não sicronizou com o node 1.Tem alguma outra ideia do que pode ser?Desde já agradeço atenção. No terceiro nodo vc tem que mudar o parâmetro receiver para 3 e não 2 como estava. subscribe set ( id = 1, provider = 1, receiver = 3, forward = no); Faz aí e diz se funcionou. []s --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony com 3 Slaves Para: pgbr-geral@listas.postgresql.org.br Data: Segunda-feira, 17 de Maio de 2010, 17:17 Olá a todos! Talvez possa me ajudar. Consegui fazer o slony replicar master para um slave, porem quando eu fui tentar replicar de um master para varios slaves o terceiro nodo não recebe a replicação. Abaixo segue a conf do arquivo que comunica com o cluster. #!/bin/sh CLUSTER=sief #DEFINA AQUI O NOME DO SEU CLUSTER DB1=sief #NOME DO BANCO DE DADOS DO COMPUTADOR1 DB2=sief #NOME DO BANCO DE DADOS DO COMPUTADOR2 DB3=sief #NOME DO BANCO DE DADOS DO COMPUTADOR3 H1=192.168.1.254 #HOSTNAME (NOME DA MAQUINA), DO COMPUTADOR1 H2=192.168.1.29 #HOSTNAME DO SEGUNDO COMPUTADOR H3=192.168.10.10 #HOSTNAME DO SEGUNDO COMPUTADOR U=postgres #USUARIO PARA A REPLICAÇÃO, PADRÃO: POSTGRES SENHA=SENHA slonik _EOF_ cluster name = $CLUSTER; node 1 admin conninfo = 'dbname=$DB2 host=$H1 user=$U password=$SENHA port=5573'; node 2 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; init cluster (id = 1, comment 'Cluster Master'); #especifica o set de replicacao create set (id = 1, origin = 1, comment = 'objetos replicados'); #tabelas que seram replicadas set add table(set id=1,origin=1,id=10,full qualified name='public.adm_enroll'); #no escravo e caminho que ele fara, especificar event node ! store node (id = 3, event node= 1,comment = 'Slave'); store path (server = 1, client = 2,conninfo = 'dbname=$DB1 host=$H1 port=5573 user=$U password=$SENHA'); store path (server 2, client = 1,conninfo = 'dbname=$DB2 host=$H2 port=5573 user=$U password=$SENHA'); store path (server = 3, client = 1,conninfo = 'dbname=$DB3 host=$H3 port=5573 user=$U password=$SENHA'); store listen (origin = 1, provider = 1, receiver 2); store listen (origin = 2, provider = 2, receiver = 1); store listen (origin = 3, provider = 2, receiver = 1); Este script eu rodo no servidor, ja nos 2 cliente eu rodo este script de sicronizar abaixo: #!/bin/sh CLUSTERNAME=sief MASTERDBNAME=sief SLAVEDBNAME=sief REPLICATIONUSER=postgres SENHA=SENHA MASTERHOST=192.168.1.254 SLAVEHOST=192.168.1.29 slonik _EOF_ # # This defines which namespace the replication system uses # cluster name = $CLUSTERNAME; # # Admin conninfo's are used by the slonik program to connect # to the node databases. So these are the PQconnectdb arguments # that connect from the administrators workstation (where # slonik is executed). # node 1 admin conninfo 'dbname=$MASTERDBNAME host=$MASTERHOST port=5573 user=$REPLICATIONUSER password=$SENHA'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port 5573 user=$REPLICATIONUSER password=$SENHA'; # # Node 2 subscribes set 1 # subscribe set ( id = 1, provider = 1, receiver = 2, forward = no); _EOF_ Segundo slave: #!/bin/sh CLUSTERNAME=sief MASTERDBNAME=sief SLAVEDBNAME=sief REPLICATIONUSER=postgres SENHA=SENHA MASTERHOST=192.168.1.254 SLAVEHOST=192.168.10.10 slonik _EOF_ # # This defines which namespace the replication system uses # cluster name = $CLUSTERNAME; # # Admin conninfo's are used by the slonik program to connect # to the node databases. So these are the PQconnectdb arguments # that connect from the administrators workstation (where # slonik is executed). # node 1 admin conninfo 'dbname=$MASTERDBNAME host=$MASTERHOST port=5573 user=$REPLICATIONUSER password=$SENHA'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST port 5573 user=$REPLICATIONUSER password=$SENHA'; # # Node 2 subscribes set 1 # subscribe set ( id = 1, provider = 1, receiver = 2, forward = no); _EOF_ Alguem sabe o que pode ser? lembrando que se eu retirar o 3 nodo replica 100%. -Anexo incorporado- ___ 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
Re: [pgbr-geral] Monitoramento Automatico
Para esta tarefa, pensando em uma solução simples, poderia ser feito um script que monitore o arquivo de log do postgres, filtrando o termo ERR, PANIC, etc... , talvez com o comando grep, enviando um email com este conteúdo através do comando mail. Poderia ser um job no crontab ou ainda um script que fique residente no rc.local. Alex Em 18 de maio de 2010 12:35, Eduardo Amaral edu.ama...@gmail.com escreveu: Opa, esse ai eu quero saber tambem Em 18 de maio de 2010 09:00, Pedro Espíndola pespindo...@gmail.comescreveu: Bom dia, existe algum serviço no postgresql q monitora o banco e qq comportamento anormal ele dispara email alertando ? Se sim, qual seria ? Abs Pedro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att., Eduardo Amaral ___ 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] Criar visão entre bancos no postgre sql
O dblink funcionou perfeitamente. Em 18 de maio de 2010 10:21, Juliano Atanazio sp_juli...@yahoo.com.brescreveu: Use o DBlink para isso. Tem na documentação oficial: http://www.postgresql.org/docs/9.0/static/contrib-dblink-connect.html [] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Emanoel Tadeu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Visão do oracle no postgresql
Prezados, Depois de ter feito a visão entre dois bancos no postgresql, preciso fazer a visão de um banco oracle no postgresql. É possível isso? Não consegui ver na documentação do postgresql como fazer isso, mesmo com o dblink. Sugestões? -- Emanoel Tadeu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Visão do oracle no postgresql
procura dbilink.João Cosme de Oliveira Júnior "Lembre-se que da conduta de cada um depende o destino de todos." Seja inteligente, use Software livre!!! LPI Certified LPI000185554 Em 18/05/2010 às 13:58 horas, pgbr-geral@listas.postgresql.org.br escreveu:Prezados,Depois de ter feito a visão entre dois bancos no postgresql, preciso fazer a visão de um banco oracle no postgresql. É possível isso? Não consegui ver na documentação do postgresql como fazer isso, mesmo com o dblink. Sugestões? -- Emanoel Tadeu "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco." "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Visão do oracle no postgresql
O contrário não serve? Dá prá fazer um dblink no Oracle apontando para o PostgreSQL, usando a biblioteca unixodbc no Linux. No Postgres acho que para isso seria o dbi-link... Alex Em 18 de maio de 2010 13:58, Emanoel Tadeu emanoelta...@gmail.comescreveu: Prezados, Depois de ter feito a visão entre dois bancos no postgresql, preciso fazer a visão de um banco oracle no postgresql. É possível isso? Não consegui ver na documentação do postgresql como fazer isso, mesmo com o dblink. Sugestões? -- Emanoel Tadeu ___ 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] Monitoramento Automatico
Otimas as sugestoes. Para citar o DB2 fornce um servico de notificação na página Mail Server do wizard. Ele pode mandar um e-mail ou uma mensagem para um pager automaticamente se um problema ou uma condição não-operacional for detectada. Bastando configurar um servidor SMTP disponível para que o DB2 possa utilizar para enviar e-mails. Estava procurando algo similar. Obr pelas contribuicoes. Pedro 2010/5/18 Alexsandro Haag alexsandro.h...@gmail.com: Para esta tarefa, pensando em uma solução simples, poderia ser feito um script que monitore o arquivo de log do postgres, filtrando o termo ERR, PANIC, etc... , talvez com o comando grep, enviando um email com este conteúdo através do comando mail. Poderia ser um job no crontab ou ainda um script que fique residente no rc.local. Alex Em 18 de maio de 2010 12:35, Eduardo Amaral edu.ama...@gmail.com escreveu: Opa, esse ai eu quero saber tambem Em 18 de maio de 2010 09:00, Pedro Espíndola pespindo...@gmail.com escreveu: Bom dia, existe algum serviço no postgresql q monitora o banco e qq comportamento anormal ele dispara email alertando ? Se sim, qual seria ? Abs Pedro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att., Eduardo Amaral ___ 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] Visão do oracle no postgresql
Pra mim não serve...tenho q estar no postgresql pra ler o oracle. Vi sobre o dbi-link em http://pgfoundry.org/projects/dbi-link/ no entanto não vi nada falando sobre ele permitir uma visão do oracle dentro do postgresql. Em 18 de maio de 2010 14:12, Alexsandro Haag alexsandro.h...@gmail.comescreveu: O contrário não serve? Dá prá fazer um dblink no Oracle apontando para o PostgreSQL, usando a biblioteca unixodbc no Linux. No Postgres acho que para isso seria o dbi-link... Alex Em 18 de maio de 2010 13:58, Emanoel Tadeu emanoelta...@gmail.comescreveu: Prezados, Depois de ter feito a visão entre dois bancos no postgresql, preciso fazer a visão de um banco oracle no postgresql. É possível isso? Não consegui ver na documentação do postgresql como fazer isso, mesmo com o dblink. Sugestões? -- Emanoel Tadeu ___ 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 -- Emanoel Tadeu ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Slony com 3 Slaves
Bom... analisando um pouquinho melhor achei outra coisa errada; node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; Repare que vc colocou como host H2 ao invés de H3. Para dar certo o que vc quer fz, tudo o que for feito para o primeiro slave deverá ser feito igualmente para os outros conforme suas características próprias. Tenho um exemplo aqui e me guio sempre por ele. Dá uma olhada: $SLONIK _EOF_ # # Define o nome do cluster de replicação cluster name = $CLUSTERNAME; # # As configurações admin conninfo são usadas pelo slonik para conectar aos nodos node 1 admin conninfo = 'dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'; node 3 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'; # # Inicia o primeiro nodo, o qual deve ser 1. Isso cria o schema _$CLUSTERNAME contendo todos os objetos específicos # do sistema de replicação init cluster ( id=1, comment = 'Nodo Master'); # # O Slony-I organiza tabelas dentro de conjuntos. # CREATE SET # ID = ival - ID do conjunto (set) a ser criado # ORIGIN = ival - Nodo de origem inicial do conjunto create set (id=1, origin=1, comment='Todas as tabelas'); # SET ADD TABLE # SET ID = ival - ID do nodo em que a tabela será adicionada # ORIGIN = ival - Nó de origem para este conjunto. # ID = ival - ID único da tabela. # FULLY QUALIFIED NAME = 'string' - esquema.tabela set add table (set id=1, origin=1, id=1, fully qualified name = 'public.tb_1', comment='tabela 1'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.tb_2', comment='tabela 2'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tb_3', comment='tabela 3'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.tb_4', comment='tabela 4'); # # Criação do segundo nodo (slave1) diz aos dois nodos como se conectar ao outro e como eles devem ouvir para eventos # STORE NODE # ID = ival - O único, imutável ID numérico do novo nodo. O ID é imutável por ser usado como base para comunicação # entre os nodos. # COMMENT = 'description' - Um texto descritivo adicionado à entrada do nodo na tabela sl_node # EVENT NODE = ival - O ID do nodo usado para criar a configuração de evento que notifica a todos os nodo existentes # sobre o novo nodo. store node (id=2, comment = 'Nodo slave 1', event node=1); # STORE PATH # SERVER = ival - ID do nodo de banco de dados para conectar. # CLIENT = ival - ID do nodo do daemon de replicação se conectar. # CONNINFO = string - PQconnectdb() argumento para estabelecer a conexão. # CONNRETRY = ival - Número em segundos para aguardar outra tentativa para conectar é feita em caso servidor # indisponível. Padrão é 10. store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'); # Criação do terceiro nodo (slave2) store node (id=3, comment = 'Nodo slave 2', event node=1); store path (server = 1, client = 3, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 3, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'); _EOF_ --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony com 3 Slaves Para: pgbr-geral@listas.postgresql.org.br Data: Segunda-feira, 17 de Maio de 2010, 17:17 Olá a todos! Talvez possa me ajudar. Consegui fazer o slony replicar master para um slave, porem quando eu fui tentar replicar de um master para varios slaves o terceiro nodo não recebe a replicação. Abaixo segue a conf do arquivo que comunica com o cluster. #!/bin/sh CLUSTER=sief #DEFINA AQUI O NOME DO SEU
Re: [pgbr-geral] Dúvida sobre configuração
Desculpem pela demora no retorno. Pelo que entendi seriam essas mudanças: --- postgresql.conf --- log_temp_files = 0 shared_preload_libraries = 'auto_explain' custom_variable_classes = 'auto_explain' auto_explain.log_min_duration = '3s' effective_cache_size = 10G --- fim --- A respeito do 'effective_cache_size' vi a recomendação em mensagens anteriores na lista de 2/3 da ram, como também no site [1]. Vou tentar levantar as mudanças hoje a noite. Alguém teria mais alguma sugestão? Abraços, Aldrey Galindo [1]- http://www.midstorm.org/~telles/2006/10/21/checklist-de-performance-do-postgresql-80/ Em 15 de maio de 2010 11:35, Aldrey Galindo aldreygali...@gmail.comescreveu: Euler, Essa semana vou ativar o 'auto_explain' e log do 'log_temp_files', para vê o real consumo da memória. Em alguns momentos do mês temos picos de acessos, o volume fica realmente alto. Em relação ao 'effective_cache_size', como poderia ver o valor mais adequado? Abraços, Aldrey Galindo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Slony com 3 Slaves
Valeu novamente pela ajuda.Fiz o que você me informou, esta alteração errada, corrigir, porem o mesmo não replicou.Segui este script abaixo que você postou, este mesmo e rodando no servidor que esta o banco, então adaptei para os IPs e nomes e o quando vou rodar o mesmo da esta mensagem abaixo:stdin:7: ERROR: syntax error at or near clusterValeu novamente. Bom... analisando um pouquinho melhor achei outra coisa errada; node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; Repare que vc colocou como host H2 ao invés de H3. Para dar certo o que vc quer fz, tudo o que for feito para o primeiro slave deverá ser feito igualmente para os outros conforme suas características próprias. Tenho um exemplo aqui e me guio sempre por ele. Dá uma olhada: $SLONIK _EOF_ # #Define o nome do cluster de replicação cluster name = $CLUSTERNAME; # # As configurações admin conninfo são usadas pelo slonik para conectar aos nodos node 1 admin conninfo = 'dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'; node 3 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'; # # Inicia o primeiro nodo, o qual deve ser 1. Isso cria o schema _$CLUSTERNAME contendo todos os objetos específicos # do sistema de replicação init cluster ( id=1, comment = 'Nodo Master'); # # O Slony-I organiza tabelas dentro de conjuntos. # CREATE SET # ID = ival - ID do conjunto (set) a ser criado # ORIGIN = ival - Nodo de origem inicial do conjunto create set (id=1, origin=1, comment='Todas as tabelas'); # SET ADD TABLE # SET ID = ival - ID do nodo em que a tabela será adicionada # ORIGIN = ival - Nó de origem para este conjunto. # ID = ival - ID único da tabela. # FULLY QUALIFIED NAME = 'string' - esquema.tabela set add table (set id=1, origin=1, id=1, fully qualified name = 'public.tb_1', comment='tabela 1'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.tb_2', comment='tabela 2'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tb_3', comment='tabela 3'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.tb_4', comment='tabela 4'); # # Criação do segundo nodo (slave1) diz aos dois nodos como se conectar ao outro e como eles devem ouvir para eventos # STORE NODE # ID = ival - O único, imutável ID numérico do novo nodo. O ID é imutável por ser usado como base para comunicação # entre os nodos. # COMMENT = 'description' - Um texto descritivo adicionado à entrada do nodo na tabela sl_node # EVENT NODE = ival - O ID do nodo usado para criar a configuração de evento que notifica a todos os nodo existentes # sobre o novo nodo. store node (id=2, comment = 'Nodo slave 1', event node=1); # STORE PATH # SERVER = ival - ID do nodo de banco de dados para conectar. # CLIENT = ival - ID do nodo do daemon de replicação se conectar. # CONNINFO = string - PQconnectdb() argumento para estabelecer a conexão. # CONNRETRY = ival - Número em segundos para aguardar outra tentativa para conectar é feita em caso servidor # indisponível. Padrão é 10. store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'); # Criação do terceiro nodo (slave2) store node (id=3, comment = 'Nodo slave 2', event node=1); store path (server = 1, client = 3, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 3, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'); _EOF_ --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony com 3 Slaves Para: pgbr-geral@listas.postgresql.org.br Data: Segunda-feira, 17 de Maio de
Re: [pgbr-geral] Slony com 3 Slaves
Favor desconsiderar este e-mail.Era caca minha aqui, irei trabalhar mais nele. Valeu novamente pela ajuda.Fiz o que você me informou, esta alteração errada, corrigir, porem o mesmo não replicou.Segui este script abaixo que você postou, este mesmo e rodando no servidor que esta o banco, então adaptei para os IPs e nomes e o quando vou rodar o mesmo da esta mensagem abaixo:stdin:7: ERROR: syntax error at or near clusterValeu novamente. Bom... analisando um pouquinho melhor achei outra coisa errada; node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573'; Repare que vc colocou como host H2 ao invés de H3. Para dar certo o que vc quer fz, tudo o que for feito para o primeiro slave deverá ser feito igualmente para os outros conforme suas características próprias. Tenho um exemplo aqui e me guio sempre por ele. Dá uma olhada: $SLONIK _EOF_ # #Define o nome do cluster de replicação cluster name = $CLUSTERNAME; # # As configurações admin conninfo são usadas pelo slonik para conectar aos nodos node 1 admin conninfo = 'dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'; node 3 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'; # # Inicia o primeiro nodo, o qual deve ser 1. Isso cria o schema _$CLUSTERNAME contendo todos os objetos específicos # do sistema de replicação init cluster ( id=1, comment = 'Nodo Master'); # # O Slony-I organiza tabelas dentro de conjuntos. # CREATE SET # ID = ival - ID do conjunto (set) a ser criado # ORIGIN = ival - Nodo de origem inicial do conjunto create set (id=1, origin=1, comment='Todas as tabelas'); # SET ADD TABLE # SET ID = ival - ID do nodo em que a tabela será adicionada # ORIGIN = ival - Nó de origem para este conjunto. # ID = ival - ID único da tabela. # FULLY QUALIFIED NAME = 'string' - esquema.tabela set add table (set id=1, origin=1, id=1, fully qualified name = 'public.tb_1', comment='tabela 1'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.tb_2', comment='tabela 2'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tb_3', comment='tabela 3'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.tb_4', comment='tabela 4'); # # Criação do segundo nodo (slave1) diz aos dois nodos como se conectar ao outro e como eles devem ouvir para eventos # STORE NODE # ID = ival - O único, imutável ID numérico do novo nodo. O ID é imutável por ser usado como base para comunicação # entre os nodos. # COMMENT = 'description' - Um texto descritivo adicionado à entrada do nodo na tabela sl_node # EVENT NODE = ival - O ID do nodo usado para criar a configuração de evento que notifica a todos os nodo existentes # sobre o novo nodo. store node (id=2, comment = 'Nodo slave 1', event node=1); # STORE PATH # SERVER = ival - ID do nodo de banco de dados para conectar. # CLIENT = ival - ID do nodo do daemon de replicação se conectar. # CONNINFO = string - PQconnectdb() argumento para estabelecer a conexão. # CONNRETRY = ival - Número em segundos para aguardar outra tentativa para conectar é feita em caso servidor # indisponível. Padrão é 10. store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'); # Criação do terceiro nodo (slave2) store node (id=3, comment = 'Nodo slave 2', event node=1); store path (server = 1, client = 3, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 3, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'); _EOF_ --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony
Re: [pgbr-geral] Slony com 3 Slaves
tem um script la pra gerar as confsjoaocosme.wordpress.comJoão Cosme de Oliveira Júnior "Lembre-se que da conduta de cada um depende o destino de todos." Seja inteligente, use Software livre!!! LPI Certified LPI000185554 Em 18/05/2010 às 17:19 horas, pgbr-geral@listas.postgresql.org.br escreveu:Valeu novamente pela ajuda.Fiz o que você me informou, esta alteração errada, corrigir, porem o mesmo não replicou.Segui este script abaixo que você postou, este mesmo e rodando no servidor que esta o banco, então adaptei para os IPs e nomes e o quando vou rodar o mesmo da esta mensagem abaixo:stdin:7: ERROR: syntax error at or near clusterValeu novamente. Bom... analisando um pouquinho melhor achei outra coisa errada; "node 3 admin conninfo = 'dbname=$DB2 host=$H2 user=$U password=$SENHA port=5573';" Repare que vc colocou como host "H2" ao invés de "H3". Para dar certo o que vc quer fz, tudo o que for feito para o primeiro slave deverá ser feito igualmente para os outros conforme suas características próprias. Tenho um exemplo aqui e me guio sempre por ele. Dá uma olhada: $SLONIK _EOF_ # #Define o nome do cluster de replicação cluster name = $CLUSTERNAME; # # As configurações "admin conninfo" são usadas pelo slonik para conectar aos nodos node 1 admin conninfo = 'dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'; node 2 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'; node 3 admin conninfo = 'dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'; # # Inicia o primeiro nodo, o qual deve ser "1". Isso cria o schema _$CLUSTERNAME contendo todos os objetos específicos # do sistema de replicação init cluster ( id=1, comment = 'Nodo Master'); # # O Slony-I organiza tabelas dentro de conjuntos. # CREATE SET # ID = ival - ID do conjunto (set) a ser criado # ORIGIN = ival - Nodo de origem inicial do conjunto create set (id=1, origin=1, comment='Todas as tabelas'); # SET ADD TABLE # SET ID = ival - ID do nodo em que a tabela será adicionada # ORIGIN = ival - Nó de origem para este conjunto. # ID = ival - ID único da tabela. # FULLY QUALIFIED NAME = 'string' - esquema.tabela set add table (set id=1, origin=1, id=1, fully qualified name = 'public.tb_1', comment='tabela 1'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.tb_2', comment='tabela 2'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tb_3', comment='tabela 3'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.tb_4', comment='tabela 4'); # # Criação do segundo nodo (slave1) diz aos dois nodos como se conectar ao outro e como eles devem ouvir para eventos # STORE NODE # ID = ival - O único, imutável ID numérico do novo nodo. O ID é imutável por ser usado como base para comunicação # entre os nodos. # COMMENT = 'description' - Um texto descritivo adicionado à entrada do nodo na tabela sl_node # EVENT NODE = ival - O ID do nodo usado para criar a configuração de evento que notifica a todos os nodo existentes # sobre o novo nodo. store node (id=2, comment = 'Nodo slave 1', event node=1); # STORE PATH # SERVER = ival - ID do nodo de banco de dados para conectar. # CLIENT = ival - ID do nodo do daemon de replicação se conectar. # CONNINFO = string - PQconnectdb() argumento para estabelecer a conexão. # CONNRETRY = ival - Número em segundos para aguardar outra tentativa para conectar é feita em caso servidor # indisponível. Padrão é 10. store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST1'); # Criação do terceiro nodo (slave2) store node (id=3, comment = 'Nodo slave 2', event node=1); store path (server = 1, client = 3, conninfo='dbname=$MASTERDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$MASTERHOST'); store path (server = 3, client = 1, conninfo='dbname=$SLAVEDBNAME user=$REPLICATIONUSER password=$PASSWORD host=$SLAVEHOST2'); _EOF_ --- Em seg, 17/5/10, gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br escreveu: De: gilmarli...@agrovale.com.br gilmarli...@agrovale.com.br Assunto: [pgbr-geral] Slony com 3 Slaves Para: pgbr-geral@listas.postgresql.org.br Data: Segunda-feira, 17 de Maio de 2010, 17:17 Olá a todos! Talvez possa me ajudar. Consegui fazer o slony replicar
Re: [pgbr-geral] Slony com 3 Slaves
Ok, se nao me engano ate tentei usar o script, mas o mesmo nao rodou deu ums erros.mesmo instalando as bibliotecas em perl e o dialog.Usei o mesmo script que vcpostou, porem ele esta dando este erro aki:./teste2.sh stdin:52: ERROR: syntax error at or near Nodo slave 1'Obs: Usei o mesmo script, só criei as variaveis com os ips e nomes que estao aki, ja o restante deixei tudocomo esta.Você tem alguma ideia do que seja este erro? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] dúvida sobre índices
-- Considerem as duas tabelas que seguem: CREATE TABLE usuario ( usuario_cod INT, usuario_nome VARCHAR( 50 ), CONSTRAINT usuario_pk PRIMARY KEY( usuario_cod ) ); INSERT INTO usuario( usuario_cod, usuario_nome ) VALUES( 1, 'Divino André' ); INSERT INTO usuario( usuario_cod, usuario_nome ) VALUES( 2, 'Fábio Araújo' ); INSERT INTO usuario( usuario_cod, usuario_nome ) VALUES( 3, 'Mauro Sérgio' ); CREATE TABLE conta ( conta_cod INT, usuario_cod INT, CONSTRAINT conta_pk PRIMARY KEY( conta_cod ), CONSTRAINT conta_fk FOREIGN KEY( usuario_cod ) REFERENCES usuario( usuario_cod ) ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 1, 1 ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 2, 1 ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 3, 2 ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 4, 2 ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 5, 3 ); INSERT INTO conta( conta_cod, usuario_cod ) VALUES( 6, 3 ); -- E as duas consultas que seguem: -- Consulta A SELECT c.conta_cod, ( SELECT usuario_nome FROM usuario WHERE usuario_cod = c.usuario_cod ) from conta c -- Consulta B SELECT c.conta_cod, u.usuario_nome from conta c inner join usuario u on c.usuario_cod = u.usuario_cod /* Ao executar o explain nas duas consultas notei que o custo e, aparentemente, o tempo de execução da consulta A são bem inferiores que os da consuta B, contrariando minhas espectativas. Analisando, notei que a consulta A faz uso do índice ( usuario_pk ) enquanto que a consulta B não faz uso de índice e ainda faz busca seuquencial em ambas as tabelas. Outra coisa. Sempre imaginei que consultas internas dentro da cláusula SELECT de uma consulta externa seria executada o número de vezes igual ao número de registros retornados na consulta externa. Mas agora vejo que isso não é verdade. Pois bem, alguém poderia, por favor, me explicar porque a consulta A usa índice e a B não? Outra perguntinha, há alguma forma de obrigar o uso do índice da chave primária( usuario_pk ) na consulta B ( usando INNER JOIN )? Obrigado! */ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Slony com 3 Slaves
Descobri, o problema que estava faltando o igual = entre o comente e o Nodo slave 1,l igual ta abaixo store node (id=2, comment='Nodo slave 1', event node=1);Valeu Ok, se nao me engano ate tentei usar o script, mas o mesmo nao rodou deu ums erros.mesmo instalando as bibliotecas em perl e o dialog.Usei o mesmo script que vcpostou, porem ele esta dando este erro aki:./teste2.sh stdin:52: ERROR: syntax error at or near Nodo slave 1'Obs: Usei o mesmo script, só criei as variaveis com os ips e nomes que estao aki, ja o restante deixei tudocomo esta.Você tem alguma ideia do que seja este erro? ___ 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] Otimizar consulta com LEFT JOIN
Obrigado pelas dicas tanto a do Marcos que faz pensar que quando iniciar um projeto novo já planejar essas functions e a solução do Mozart que implementei e deu certo a query demorava 25segundos caiu para 2 3 segundos. vlw... Att Vinicius Perroni ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Artigo Banco de Dados
Ola pessoal, Estou montando um artigo para a pós-graduação e preciso fazer uma pesquisa de campo com algumas perguntas referentes a backups, tive essa idéia a partir de outro artigo criado pelo Fabio Telles (muito bom), acho que ja devem ter vistos pois foi postado aqui mesmo com o titulo Dump não é backup. http://www.midstorm.org/~telles/2010/05/06/dump-nao-e-backup/ Aquele que tiver interesse pelo artigo ou responder as perguntas, me mande um email para rogeriogra...@planin.com.br, que encaminharei logo após o termino. Nome da empresa (opcional)? Qual Banco de Dados é utilizado pela empresa? Qual o tamanho atual da base de dados principal? Por quanto tempo você pode ficar com o banco de dados indisponível? Você pode perder dados relativos a quanto tempo de operação? Qual forma de Backup é utilizada pela empresa, tipo Dump, Servidor Stand By, cópia de arquivos, etc., e se utiliza replicação, qual a forma utilizada síncrona ou assíncrona? Os backups são feitos com o sistema em execução ou não frio ou a quente ou ambos? Quanto tempo leva para se restaurar esse backup? Qual a forma de armazenamento dos backups? Fita, Hds, Pendrivers, DVDs, CDs, etc.? Existe alguma estratégia para a ocorrência de falha de hardware ou software? Qual? Qual ferramenta utilizada para realizar os backups? Informe se é paga ou free. Já houve algum tipo de falha com necessidade de restaurar um backup? Qual tipo de falha ocorreu (humana, software, hardware)? O que ocasionou o problema? Obrigado pela colaboração de todos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
Seria assim: CREATE VIEW vw_uniao as SELECT campoA, campoB, null as c FROM a INNER JOIN b ON (a.id= b.id) UNION ALL SELECT campoA, campoB, null as c FROM a WHERE NOT EXISTS (SELECT 1 FROM a WHERE a.id= b.id) UNION ALL SELECT campoA, null as b, campoC FROM a INNER JOIN c ON (a.id= c.id) UNION ALL SELECT campoA, null as b, campoC FROM a WHERE NOT EXISTS (SELECT 1 FROM a WHERE a.id= c.id) Ocorreu duas linhas por regitros quando tem registro so em A e C ou A e B. Mozart Hasse wrote: Olá Vinicius, From: vinicius perroni vinicius...@gmail.com Subject: [pgbr-geral] Otimizar consulta com LEFT JOIN Estou com um velho problema uma consulta minha utiliza muitos LEFT JOINS tornandoa lenta demais. A consulta é mais ou menos assim tenho uma tabela de orçamentos, uma de ordens de compras e outra de Notas Fiscas, três tabelas sendo o unico registro que certamente existe é o orçamento. Junto elas com LEFT JOIN ... Pensei em usar UNION mas ainda não realizei testes alguem tem alguma ideia para substituir os LEFT JOINS e otimizar a consulta? Aplique a idéia de usar UNION ALL. Isso funciona em qualquer servidor SQL e nunca vi piorar o desempenho da consulta. O que faço é o seguinte: para CADA LEF OUTER JOIN da sua consulta, substitua por duas cópias da mesma query separadas por UNION ALL (não union, tem de ser UNION ALL), sendo que numa delas você vai trocar o LEFT OUTER JOIN por um INNER JOIN e na outra você vai tirar fora o LEFT OUTER da tabela e incluir lá na cláusula WHERE a condição AND NOT EXISTS(SELECT 1 FROM suatabeladoleft WHERE joins que estavam no LEFT). Provavelmente você vai notar que ao por INNER na tabela que antes era OUTER você poderá trocar um monte de OUTERs por INNERs nas tabelas filhas dela também, o que ajudará ainda mais a melhorar o desempenho. A implicação disso é que, se tua query tem 2 LEFT OUTER, a combinação de todos com todos vai resultar em 4 consultas separadas por UNION ALL. Nunca precisei de mais do que 8. Não se assuste porque valerá a pena. Sua query vai ficar grande, porém mesmo seis vezes maior ainda ficará muito mais rápida que a original. Faço isso aqui direto com ótimos resultados. Minha aplicação não sofreu nenhuma alteração na modelagem por conta disso, porém com essas trocas para UNION ALL, o LEFT OUTER JOIN está virando lenda por aqui, praticamente ninguém mais usa. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Otimizar-consulta-com-LEFT-JOIN-tp28583265p28604012.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Otimizar consulta com LEFT JOIN
Correção: Seria assim: SELECT campoA, campoB, null as c FROM a INNER JOIN b ON (a.id= b.id) UNION all SELECT campoA, null as b, null as c FROM a WHERE NOT EXISTS (SELECT 1 FROM b WHERE a.id= b.id) UNION all SELECT campoA, null as b, campoC FROM a INNER JOIN c ON (a.id= c.id) UNION all SELECT campoA, null as b, null as c FROM a WHERE NOT EXISTS (SELECT 1 FROM c WHERE a.id= c.id) Ocorreu duas linhas por registro. mateusgra wrote: Seria assim: CREATE VIEW vw_uniao as SELECT campoA, campoB, null as c FROM a INNER JOIN b ON (a.id= b.id) UNION ALL SELECT campoA, campoB, null as c FROM a WHERE NOT EXISTS (SELECT 1 FROM a WHERE a.id= b.id) UNION ALL SELECT campoA, null as b, campoC FROM a INNER JOIN c ON (a.id= c.id) UNION ALL SELECT campoA, null as b, campoC FROM a WHERE NOT EXISTS (SELECT 1 FROM a WHERE a.id= c.id) Ocorreu duas linhas por regitros quando tem registro so em A e C ou A e B. Mozart Hasse wrote: Olá Vinicius, From: vinicius perroni vinicius...@gmail.com Subject: [pgbr-geral] Otimizar consulta com LEFT JOIN Estou com um velho problema uma consulta minha utiliza muitos LEFT JOINS tornandoa lenta demais. A consulta é mais ou menos assim tenho uma tabela de orçamentos, uma de ordens de compras e outra de Notas Fiscas, três tabelas sendo o unico registro que certamente existe é o orçamento. Junto elas com LEFT JOIN ... Pensei em usar UNION mas ainda não realizei testes alguem tem alguma ideia para substituir os LEFT JOINS e otimizar a consulta? Aplique a idéia de usar UNION ALL. Isso funciona em qualquer servidor SQL e nunca vi piorar o desempenho da consulta. O que faço é o seguinte: para CADA LEF OUTER JOIN da sua consulta, substitua por duas cópias da mesma query separadas por UNION ALL (não union, tem de ser UNION ALL), sendo que numa delas você vai trocar o LEFT OUTER JOIN por um INNER JOIN e na outra você vai tirar fora o LEFT OUTER da tabela e incluir lá na cláusula WHERE a condição AND NOT EXISTS(SELECT 1 FROM suatabeladoleft WHERE joins que estavam no LEFT). Provavelmente você vai notar que ao por INNER na tabela que antes era OUTER você poderá trocar um monte de OUTERs por INNERs nas tabelas filhas dela também, o que ajudará ainda mais a melhorar o desempenho. A implicação disso é que, se tua query tem 2 LEFT OUTER, a combinação de todos com todos vai resultar em 4 consultas separadas por UNION ALL. Nunca precisei de mais do que 8. Não se assuste porque valerá a pena. Sua query vai ficar grande, porém mesmo seis vezes maior ainda ficará muito mais rápida que a original. Faço isso aqui direto com ótimos resultados. Minha aplicação não sofreu nenhuma alteração na modelagem por conta disso, porém com essas trocas para UNION ALL, o LEFT OUTER JOIN está virando lenda por aqui, praticamente ninguém mais usa. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- View this message in context: http://old.nabble.com/Otimizar-consulta-com-LEFT-JOIN-tp28583265p28604052.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
