Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL
Colegas,Acho que se vamos permitir a divulgação de vagas, devemos ter em mente que não é legal ficar questionando os critérios, valores salariais pela lista , etc. Qualquer coisa façam isto em private. O problema das profissões de TI em relação a salário, exigências e tipo de contratação é geral e ultrapassa a questão do PostgreSQL.Ats,Leandro Henrique Pereira Neto Administração de bancos de dados - SerproEm 10/01/2012 às 10:22 horas, pgbr-geral@listas.postgresql.org.br escreveu:Mais de 2 anos, contrato Jr, trabalhar sobre pressão , explica isto direito, trabalhar muitas horas e pagar pouco, é essa a mágica?Em 10 de janeiro de 2012 09:37, Fábio Gibon - Comex System gi...@comexsystem.com.br escreveu: Experiência de mais de 2 anos e continua como Jr? - Original Message - From: "Victor Hugo" vh.cleme...@gmail.com To: "Comunidade PostgreSQL Brasileira" pgbr-geral@listas.postgresql.org.br Sent: Monday, January 09, 2012 8:02 PM Subject: Re: [pgbr-geral] OFF-TOPIC - Vaga para DBA PostgreSQL Requisitos mínimos: - Capacidade de trabalhar em equipe e sob coordenação e pressão; - Disponibilidade de trabalhar em período integral (segunda a sexta, 8 horas diários); - Disponibilidade para atendimentos de plantão fora do horário normal de trabalho e disponível para viagens; - Experiência de mais de 2 anos com PostgreSQL; - Conhecimento em PL/PgSQL; - Habilidade e conhecimento para trabalhar com Linux ( Centos ) - Linux e Unix shell script; - Tunning de bancos de dados PostgreSQL; ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral - Esta mensagem do SERVIO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pblica federal regida pelo disposto na Lei Federal n 5.615, enviada exclusivamente a seu destinatrio e pode conter informaes confidenciais, protegidas por sigilo profissional. Sua utilizao desautorizada ilegal e sujeita o infrator s penas da lei. Se voc a recebeu indevidamente, queira, por gentileza, reenvi-la ao emitente, esclarecendo o equvoco. This message from SERVIO 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 laws penalties. If youre 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] Sugestão de uso
- camada de apresentação separada da camada de aplicação. Como manda o mítico manual que está no céu, no divino Braço Direito doCriador? sem ironia. Entrandono assunto ... o problema da área de informática é que vivem aparecendo novas soluções revolucionárias, novas ondas, novos modismos que são tratados como dogmas que se não forem seguindos ao pé da letra todos iremos para o infermo. ( sim com muita ironia, mas é verdade ) Um pouco de bom senso e flexibilidade nunca fizeram mal. Lógico que comarquitetura de 3 camandas dividir as camadas de apresentação, aplicação e dados é de maneira geral o melhor negócio. Porém isto não quer dizer que tudo precisa ir para a camada da aplicação, existem várias situações onde colocar parte da lógica de negócio no banco é simplemente a melhor solução em todos os aspectos. O que vejo de novos sistemas feitoscom a filosofia de tudo no servidor de aplicaçãoondegrandes volumes de dados são transferidos do banco para o servidor de aplicação para serem tratados não é brincadeira e depois o pessoal de desenvolvimento ainda reclama que o sistema tá lento. Quando questionados se aquele volume de dados não poderia ser tratado no banco e somente o resultado final enviado para o servidor de aplicação a resposta é a filosofia de separação de camadas e de independência de banco recitadas como um dogma que nunca pode ser alterado, sem capacidade de fazer uma analise do que é melhor para cada situação. Assim suprem-se as técnicas MVC modernas e ganha-se em portabilidade (fica mais fácil migrar de SGBD ou misturar SGBDs) Na minha opinião ? e constato, aliviado, que na opinião de pelo menos dois outrês profiças muito mais inteligentes, experientes e bem informados que eu ?portabilidade total, dado que o SQL não é relacional e é muito malimplementado no mundo extraelefantíaco, é um mito, cuja busca tipicamenteresulta em sistemas que nem são portáveis, nem corretos, nem manteníveis (eitapalavriña orroroza, alguém tem alguma melhor?), nem escaláveis, nem sequerportáveis? eu ia dar o exemplo do Propvs liga, mas aí é chutar cão defunto. Concordo esta onda de independencia de SGBD é o maior mito do mundo da informática, e que não passa de um ilusão da academia. Por até servirpara sistemas e base de dados pequenos onde pode até ser que o cliente aceite ficar mudando de base, mas no mundo real dificilmente mudamos de base de dados porque dá um trabalho imerso e o ganho para o cliente na maioria das vezes não é significativo. Um exemplo onde trabalho estamos um processo de downsizing de um grande, muito grande sistema do mainframe/ADABAS, que ficou uns 30 anos nesta plataforma, para banco relacional, arquitetura 3 camandas, etc. A previsão otimista é que vai levar 5 a 6 anos o projeto como um todo (lógico que ele vai ser implementado por partes), masquem acredita que depois de todo este trabalho, com todos os impactos normais que isto vai causar para o cliente, você vai chegar para ele daqui a 8 anos e dizer ele que agora saiuo SGBD xyz e que vamos migrar o sistema de novo para este novo SGBD ? Mesmo que a aplicação consiga ficar totalmente independente do SGBD, o que num sistema desde tamanho é quase impossível por questões de performance, só o trabalho de conversão dos dados de SGBD para o outro é uma grande trabalheira com riscos imersos. Na maioria das vezes grandes sistemas ficam décadas no mesmo SGBD, quando for necessário por algum motivo relevante a mudança da plataforma a tecnologia mudou tanto que aquele sistema que era teoricamente independente vai precisar ser todo codificadode novo de qualquer forma. Abs,Leandro Henrique Pereira Neto Administração de bancos de dados - Serpro - Esta mensagem do SERVIO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pblica federal regida pelo disposto na Lei Federal n 5.615, enviada exclusivamente a seu destinatrio e pode conter informaes confidenciais, protegidas por sigilo profissional. Sua utilizao desautorizada ilegal e sujeita o infrator s penas da lei. Se voc a recebeu indevidamente, queira, por gentileza, reenvi-la ao emitente, esclarecendo o equvoco. This message from SERVIO 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 laws penalties. If youre 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] Res: Falha em Oracle 11g libera pri vilégios a banco de dados - OFF TOPIC
Pessoal,Vocês não vão começar outra discussão do tipo "o meu é maior do que o seu" né ?Este tipo de comparação não leva a lugar nenhum. Podemos encontrar milhões de exemplo de soluções que funcionam muito bem em todos os aspectos sobre bancos de dados PostGreSQL, MySQL, Oracle, DB2, Adabas, SQL Server, etc assim como temos milhões de exemplo de coisas erradas em todos estes produtos.Que tal se nos concrentamos no assunto da lista e deixamos para lá estas comparações ?Muitas vezes até gosto de comparar soluções tecnologicas e suas vantagens e desvantagens porém não devemos ficar defedendo bandeiras como falou outro colega. Este tipo de comparação tecnologica é bom para entendemos melhor como as soluções funcionam, como usar melhor os recursos e definir qual a melhor ferramenta para cada caso. Mas quando queremos defender que produto XXX é melhor do que o produto YYY as coisas perdem o sentido. Abraços,Leandro Henrique Pereira Neto Administração de bancos de dados - SUPCD/CDSUT/CDSBB Em 05/02/2010 às 10:43 horas, pgbr-geral@listas.postgresql.org.br escreveu:Em 5 de fevereiro de 2010 10:33, MARCIO CASTRO<marciomouracas...@yahoo.com.br> escreveu: Caro colega: Você está se referindo à quais ajustes do 10g?Tem uma lista longa. Alguns pontos comuns:* Permissões nos executáveis do Oracle;* Acesso ao Listener;* Grants para PUBLIC em pacotes perigosos como UTL_TCP; De: Fábio Telles Rodriguez <fabio.tel...@gmail.com> Para: Comunidade PostgreSQL Brasileira <pgbr-geral@listas.postgresql.org.br> Enviadas: Sexta-feira, 5 de Fevereiro de 2010 8:22:50 Assunto: Re: [pgbr-geral] Falha em Oracle 11g libera privilégios a banco de dados - OFF TOPIC Não é a besteira quando o povo fala que o PostgreSQL é o banco de dados mais seguro em sua instalação padrão. Uma instalação do Oracle 10g por exemplo, exigem dezenas de ajustes para se tornar seguro após a instalação (que mito DBA desconhece). É claro que isso tem um preço: "Meu PostgreSQL não conecta", hehehehe. Atenciosamente, Fábio Telles Em 4 de fevereiro de 2010 13:29, Welington R. Braga <welrbr...@gmail.com> escreveu: Em 4 de fevereiro de 2010 13:13, Marcelo Costa <marcelojsco...@gmail.com> escreveu: Brecha ainda sem correção permite que usuário modifique privilégios e tenha total acesso ao banco de dados, alerta especialista na conferência Black Hat. http://computerworld.uol.com.br/seguranca/2010/02/03/falha-em-oracle-11g-libera-privilegios-a-banco-de-dados/ -- Marcelo Costa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Não gosto de rir da desgraça alheia porque nosso telhado é de vidro também, mas que aparece um leve sorriso no canto dos lábios com uma notícia dessas não tenha dúvidas: aparece sim. :) Só espero que resolvam logo o problema pois embora não tenha bases neste sistema, não posso garantir que meus dados bancários não estejam (Isso me faz perder o "leve sorriso") :( -- Welington Rodrigues Braga -- Web: http://www.welrbraga.eti.br MSN: welrbraga[*]msn·com Gtalk: welrbraga[*]gmail·com Yahoo / Skype: welrbraga PGP Key: 0x6C7654EB Linux User #253605 "Em tudo somos atribulados, porém não angustiados; perplexos, porém não desanimados; perseguidos, porém não desamparados; abatidos, porém não destruídos;" - 2Co 4:8,9 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- 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 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 -- 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 "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, esc
Re: [pgbr-geral] Ajuda Configuracao Cluster
Em 23/11/2009 às 14:40 horas, pgbr-geral@listas.postgresql.org.br escreveu:Olá Leandro,Esqueci de mencioar um detalhe.A versao que uso do pgsql é 8.2.4 e sou "refem" da vitavoom, ou seja, nao posso migrar para uma versao mais atual por que eles AINDA nao atualizaram o driver. Alguma outra idéia!?Obrigado,Márcio.Marcio,Já fez um roteiro como este abaixo Criação do agrupamento O primeiro passo para a criação de uma agrupamento é criar o diretório do agrupamento. Por motivo de segurança o diretório deve ter permissão somente para o usuário postgres. Depois deve ser iniciado o agrupamento com o utilitário initdb. Exemplo : mkdir -p /h30212001/pgsql/homol chown postgres.postgres /h30212001/pgsql/homol chmod -R 700 /h30212001/pgsql/homol initdb -D /h30212001/pgsql/homol Inicialização da instância de bancos de dados O serviço do SGBD deve ser ativado usando os comandos postmaster ou pg_ctl. Exemplo : pg_ctl -D /h62122001/pgsql/hsiape -o "-p 5434" startLeandro Henrique Pereira Neto Administração de bancos de dados - SUPCD/CDSUT/CDSBB (61) 2021-9359 "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
[pgbr-geral] Off topic (mensagem em HTML)
Em 13/11/2009 às 23:40 horas, pgbr-geral@listas.postgresql.org.br escreveu:2009/11/13 Leandro DUTRA <leandro.gfc.du...@gmail.com>: 2009/11/13 Leandro Henrique Pereira Neto <leandro-henrique.pere...@serpro.gov.br> Ah, evite HTML e responder acima. O tempo passa, o tempo voa, mas o Leandro Dutra continua numa boa... :-D Não muda nunca! :-D Xará Leandro Dutra,Estou respondendo a lista por uma ferramenta de WebMail corporativa livre (O Expresso do Mazoni) talvez vocês já tenham ouvindo falar. Antigamente usávamos o thunderbird como cliente do Expresso mas agora isto não é mais permitido. Nesta interface ainda não achei a opção para responder somente com texto sem HTML e também estou tendo dificuldade de responder em baixo. Acredito que outro colega do Serpro e da lista o João Cosme está com o mesmo problema. Assim por favor peço um pouco de compreensão e paciência. Há e desculpe o off - topic. "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] Off topic (mensagem em HTML)
Só para ficar claro nunca falei que eram defeitos, considero mais características da ferramenta. Na verdade na minha opinião é que com as ferramentas que temos hoje a lista ter como padrão receber somente e-mail em formato texto não é uma coisa meio ultrapassada não ?Agora a questão do responder no final, acho realmente que precisamos modificar o expresso pois é muito chato. Leandro Henrique Pereira Neto Administração de bancos de dados - SUPCD(61) 2021-9359Em 16/11/2009 às 15:42 horas, pgbr-geral@listas.postgresql.org.br escreveu: Com certeza irão ser corrigidos :)O expresso é uma ferramenta livre, o código não pertence a A,B,C e sim a comunidade no qual o SERPRO também participa( como membro do comitê gestor), e uma das suas participações é através de melhorias e implementações do código.:)João Cosme de Oliveira Júnior Seja inteligente, use Software-livre!!! LPI Certified LPI000185554 Em 16/11/2009 às 14:19 horas, pgbr-geral@listas.postgresql.org.br escreveu:2009/11/16 Leandro Henrique Pereira Neto <leandro-henrique.pere...@serpro.gov.br> Estou respondendo a lista por uma ferramenta de WebMail corporativa livre (O Expresso do Mazoni) talvez vocês já tenham ouvindo falar. Antigamente usávamos o thunderbird como cliente do Expresso mas agora isto não é mais permitido. Nesta interface ainda não achei a opção para responder somente com texto sem HTML e também estou tendo dificuldade de responder em baixo. Acredito que outro colega do Serpro e da lista o João Cosme está com o mesmo problema. Conseguiram me deixar curioso. Afinal, a contrapartida da liberdade em sistemas deveria ser a aderência a padrões... espero que esses defeitos do Expresso sejam corrigidos logo! -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral "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." "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] Merlho forma para conectar banco PG com Oracle
Tem uns produtos chamados HSODBC e DG4ODBC que permitem criar um DBLINK entre postgres - oracle. Porém ele é pago. Leandro Henrique Pereira Neto Administração de bancos de dados SUPCD/CDSUT/CDSBB 61 20219359 Leandro DUTRA escreveu: 2009/11/13 Pablo Sánchez phack...@gmail.com: Preciso conectar 2 bancos de dados, um PG e outro Oracle. Tabelas distintas onde a fonte é em um momento o PG, e no outro o Oracle. Encontrei a DBLink e a DBILink. Alguém sabe me dizer qual desses dois seria a melhor solução e porquê? DB links são apenas entre duas bases PostgreSQL, que eu me lembre... 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] SET DEADLOCK_PRIORITY
Mozart Hasse escreveu: Olá, Por acaso o Postgres tem o equivalente a este comando do SQL Server? Ele se aplica à conexão e indica qual a prioridade do processo corrente caso ele se envolva num deadlock. Eu preciso *muito* ter o controle sobre isso para poder rodar alguns processos de baixa prioridade sem *nunca* comprometer transações de processos críticos. Respostas antecipadas: * Não, tentar rodar de novo a transação no processo crítico é desastroso, tanto em desempenho quanto em esforço de programação. * Não, eu não posso evitar completamente o deadlock entre esses dois processos (baixa x alta prioridade). Já sacrifiquei tudo o que poderia de paralelismo fazendo os processos de alta prioridade não causarem deadlocks entre si. * Não, eu não vou esquartejar minhas transações em pedaços menores tão cedo, se é que algum dia eu vou fazer isso só por um capricho do Postgres. Atenciosamente, Mozart Hasse Mozart, Sei que não é a resposta esperada, mas a verdade a vezes doí, deadlock é problema de lógica da aplicação. Você pode ter milhares de transações em paralelo e não ter deadlock, assim como ter somente dois processos e gerar deadlock. Para resolver problemas deadlock não é necessário sacrificar paralelismo e sim rever a lógica de aquisição de locks da aplicação. Uma dica simples é adquirir os locks nos objetos sempre na mesma ordem. Para defender o postgresql posso ter informar que por exemplo o bancos de dados bam-bam do mercado (Oracle) não tem comando similar a este e isto não é um problema. Leandro. 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] BLOQUEIO DE REGISTRO
Jota, Eu tinha entendido somente reforcei a questão porque como o colega está migrado de ADABAS para o PostgreSQL ele pode pensar que é uma limitação do PostgreSQL, quando na verdade é uma característica de funcionamento deste tipo de banco SQL. Leandro Henrique Pereira Neto Administração de bancos de dados JotaComm escreveu: Olá, Leandro Acho que você resumiu bem a questão. Apenas um comentário, quando falei do PostgreSQL é que estamos falando do PostgreSQL, porém concordo com você que o conceito é de SQL e não especificamente do PostgreSQL. Derrepente não me expressei bem. 2009/8/11 Leandro Henrique Pereira Neto leandro-henrique.pere...@serpro.gov.br mailto:leandro-henrique.pere...@serpro.gov.br Pelo que conheço não é uma questão do PostgreSQL e sim de bancos padrão SQL, pelo menos nos mais populares (SqlServer, Oracle, MySQL, PostgreSQL e DB2). O SELECT simples nunca é bloqueado (somente se usar for update). Porém usar todos os SQL com FOR UPDATE pode travar todo o seu sistema rapidinho já que somente uma transação poderá ler os dados de cada vez, como em sistema OLTP temos normalmente mais leitura do que alteração a coisa acaba ficando complicada. O que tem são os conceitos de transação e de consistência de leitura. Talvez seja o caso de você pensar o sistema em temos de bancos SQL e não tentar fazer no PostgreSQL o que um banco como o Adabas faz pois estruturas de funcionamento e implementação totalmente diferentes. Leandro Henrique Pereira Neto Administração de bancos de dados Charly Frankl escreveu: Miguel, boa noite... Para você bloquear os selects, faça todos com FOR UPDATE ... Ai você tem opções, onde para retornar logo que está ocupado utilize NOWAIT. Att, 2009/8/11 JotaComm jota.c...@gmail.com mailto:jota.c...@gmail.com Olá, Miguel Já comentei no email anterior e fiz uma pequena descrição de como isso funciona. Você deu uma olhada no exemplo que mandei? O PostgreSQL não bloqueia a leitura (SELECT), apenas operações de escrita (UPDATE e DELETE). 2009/8/11 MIGUEL JOSE DE LIMA mig...@inlocsistemas.com.br mailto:mig...@inlocsistemas.com.br Oi Mário, Este é o problema a leitura nunca é bloqueada. Fiz os testes pedidos, mas para mim não mudou nada! Veja: - Na sessão 1: db_teste=# BEGIN WORK; BEGIN db_teste=# LOCK TABLE tab_material IN ROW EXCLUSIVE MODE NOWAIT; LOCK TABLE db_teste=# UPDATE tab_material SET desc_serma = 'LAPIS Y' where codg_serma='10'; UPDATE 1 db_teste=# *** aguardando novo comando *** - Na sessão 2: db_teste=# BEGIN WORK; BEGIN db_teste=# SELECT * FROM tab_material where codg_serma='10'; codg_empr | codg_serma | id_serma | desc_serma ---++++--+-- 202 | 10 | 202010 | LAPIS Y| É isso ai!!!?? Obrigado. 2009/8/11 Mário Oshiro mario.osh...@gmail.com mailto:mario.osh...@gmail.com Em SQLServer, fiz um teste parecido com o seu. Qdo vc faz um lock de registro ou trabela, ele nao bloqueia a leitura de outras sessoes, ate' que a sessao de posse do lock, faça um update de algum dado do registro. Para bloquear o select que vc fez, faca em seguida um update com a mesmo where assim : db_teste=# SELECT * FROM tab_material where codg_serma='10' FOR UPDATE; update tab_material set codg_serma='10' where codg_serma='10' ; teste la e depois envie o resultado. até mais. MIGUEL JOSE DE LIMA wrote: Caros, participantes... Sou iniciante neste mundo do PostgreSQL. Trabalho com outro Banco de Dados - ADABAS (UNIX SOLARIS/MAINFRAME), mas me incubiram de fazer testes no PostgreSQL para bloquer registros. Então... Estou precisando de ajuda para bloquear a leitura de um registro, ou seja, em um cenário como: Atualização de Estoque de um Material : Antes de atualizar o estoque do material selecionado eu preciso bloquear o registro para que nenhuma outra sessão possa obter o dado do registro. PRECISO DE UMA LEITURA EXCLUSIVA - TOTALMENTE
Re: [pgbr-geral] validação de CNPJ em SQL
Li seu artigo Fabio e gostaria de colocar minha visão. Já trabalhei dos dois lados : desenvolvedor e nos últimos 11 anos como DBA. Na época que eu era desenvolvedor ainda trabalhávamos com a arquitetura de 2 camadas, então tínhamos como boa prática dividir o processamento nas duas camadas (cliente e banco) colocando muita coisa dentro do banco de dados. Interagindo com as equipes de desenvolvimento atuais, vejo a clara tendência de não colocar código dentro do banco de dados, e até entendo o motivo, porém o problema é que está havendo um exagero nesta forma de trabalho. Usar o banco somente como repositório de dados causa problemas de performance, vejo códigos de programas onde uma quantidade grande de linhas de uma tabela são transferidas para servidor de aplicação para somente aí serem processadas. Neste caso a perda de performance é muito grande, I/O de rede é muito mais lento do que processar dentro do banco. Com o Fabio coloca no seu artigo precisamos usar do bom senso. Por exemplo no caso da validação do CNPJ e CPF acho melhor fazer-la do lado do cliente. No caso de um processamento onde somente com o SQL não consigo executar tudo que preciso é melhor fazer uma procedure dentro do banco que tenha um cursor e trabalhe dentro do banco o processamento necessário retornando para o cliente somente o resultado final. Fazer o cursor no servidor de aplicação e ficar transferindo várias linhas para ele via rede não é uma boa solução em termos de performance. Se vamos trabalhar a arquitetura de 3 camadas (cliente, servidor de aplicação e servidor de banco) precisamos ser suficientemente inteligentes para dividir bem o processamento por todas estas camadas de abstração, programar tudo dentro do servidor de aplicação não é sempre a melhor solução. Abraços, Leandro Henrique Pereira Neto Administração de bancos de dados SUPCD/CDSUT/CDSBB Fábio Telles Rodriguez escreveu: Mas a validação do CNPJ no lado servidor não acarretaria um processamento a mais?? qual a vantagem de usar no lado do servidor ?? O tema é para lá de polêmico... mas há um tempo atrás tentei escrever um pouco sobre o tema: http://www.midstorm.org/~telles/2006/11/23/inteligncia-em-bancos-de-dados/ Veja o que você acha e conversamos depois, ok? []s Fábio Telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 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] Arquivos temporários pgsql_tmp
Wagner Bonfiglio escreveu: Entendi sim Danilo, valeu... Mas a questão é que aumentei até para 8192 (8MB) e continua criando arquivo atrás de arquivo na tal pasta!! Ta estranho isso... Procure ver pelo outro lado. Identifique quais os comandos estão precisando de área temporária e porque. Pode existir algum desvio na elaboração destes comandos SQL ou na modelagem do banco. Por exemplo se todos os usuários fizerem ao mesmo tempo um SQL que faz order by em todas as linhas de uma tabela grande, não vai adiantar muito ficar alterando o tamanho da work_mem. 2009/5/22 Danilo - InfoCont Sistemas Integrados dan...@infocont.com.br mailto:dan...@infocont.com.br Wagner, só para esclarecer (caso não saibas). Para cada select, é reservado um espaço na memória para o order by... se o order by for maior que esse espaço reservado, vai usar arquivo. Como esse espaço resevado deve estar sendo pequeno, os vários select's estão criando um monte de arquivo (pois vários deles estão ultrapassando 1 MB)... por isso que apenas 2 MB possa resolve (ou no mínimo dimuniur). Blz? Espero ter ajudado. JotaComm escreveu: Olá, Tem tudo a ver. Se o work_mem for suficiente ele não vai criar os arquivos temporários, caso não seja suficiente ele vai criar os arquivos temporários. 2009/5/22 Wagner Bonfiglio wmbonfig...@gmail.com mailto:wmbonfig...@gmail.com Opa, valeu, vou tentar!! Mas me diz uma coisa... Se está crescendo na casa dos GB em pouco tempo (chutando pelo que eu me lembro da ultima checagem, coisa de 5GB em meia hora), esse valor de 2MB pode ser que seja pequeno? Ou uma coisa não tem nada a ver com a outra e 2MB deve resolver?? De qualquer maneira vou tentar 2MB agora, qualquer coisa aumento depois... Valeu cara!! 2009/5/22 JotaComm jota.c...@gmail.com mailto:jota.c...@gmail.com Olá, Isso acontece quando o parâmetro work_mem é ultrapassado. O parâmetro work_mem define o quanto de memória serÁ utilizado para ordenação e o valor padrão deste parâmetro é 1MB. Os arquivos estão sendo gerados porque está sendo requisitado um valor maior do que o valor padrão, e ai a ordenação é feita em disco. Para diminuir o crescimento é interessante aumentar o valor de work_mem. Você pode mudar de três maneiras: 1) Arquivo de configuração postgresql.conf 2) Por sessão: SET WORK_MEM TO 2MB; 3) Por usuário: ALTER ROLE postgres SET WORK_MEM TO 2MB; 2009/5/22 Wagner Bonfiglio wmbonfig...@gmail.com mailto:wmbonfig...@gmail.com Boa tarde senhores.. Dentro do diretório /var/lib/pgsql/data/base/NUMERO_BASE/pgsql_tmp/ estão sendo criados vários arquivos no formato pgsql_tmpXXX.YY (sendo XXX e YY numeros) continuamente, e eles chegam a ocupar 99% do espaço em disco... Quando limpo esse diretório cai para menos de 10% da capacidade do disco... Eu li por aí que esses arquivos são temporários e servem para ajudar nos order by da vida... O problema que eles estão ficando muito grandes e eu não sei exatamente para que servem, por que demoram para ser excluídos (no caso quando não tem mais espaço em disco), por que crescem tanto, etc... Alguém poderia me dar mais informações sobre ele? E principalmente como posso limitar o crescimento deles? Desde já agradeço... Att, Wagner Bonfiglio ___ 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 []s -- JotaComm http://jotacomm.wordpress.com http://www.dextra.com.br/postgres ___ 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 ___ 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 []s -- JotaComm http://jotacomm.wordpress.com http://www.dextra.com.br/postgres
Re: [pgbr-geral] [OFF] Listas Mysql/Oracle
Para Oracle em português a melhor que conheço é a oracle_br do yahoo grupos. Mas as melhores informações você encontra no https://metalink.oracle.com e http://www.oracle.com/technology/index.html Wagner Bonfiglio escreveu: Seguinte, peço desculpas caso eu fira alguma regra da lista, mas gostaria de algumas informações. Enquanto eu trabalhava com POSTGRESQL (/eu era programador e cuidador do banco de dados de um site/) essa lista foi muito útil para mim, mas hoje eu estou como DBA de uma empresa que usa PROGRESS, ORACLE e MYSQL... Como estamos abandonando o PROGRESS em breve, eu gostaria de saber se existem listas de discussão tão profissionais quanto essa para os bancos MYSQL e ORACLE, já que eu procurei e não achei nada nem perto deste nível (alias, só achei de spam / banco de vagas / abandonadas)... Agradeço a atenção, Wagner Mariotto Bonfiglio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 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] Master-Slave na mesma máquina
2008/11/25 Euler Taveira de Oliveira [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Wagner Bonfiglio escreveu: Então a questão é se existe alguma maneira simplificada de rodar duas instâncias de postgres na mesma máquina, apenas mandando executar novamente com outras configurações Algumas dicas de como fazer isto. *Conceito* No PostgreSQL a primeira etapa para criação de um servidor de bancos de dados é inicialização da área em disco para o armazenamento dos dados (database cluster), ou no padrão do SQL ANSI o agrupamento de catálogos (catalog cluster). Neste área ficam os arquivos de configuração e de dados de um conjunto de bancos de dados gerenciados por uma única instância do servidor de banco de dados. Os bancos de dados gerenciados por um mesmo agrupamento compartilham as definições de configuração de acesso, de memória, de área de armazenamento, de dicionário de dados e outras definições. É possível ter vários agrupamentos / instâncias executandos de forma concorrente na mesma máquina. Cada agrupamento pode ter uma configuração diferente de memória, área em disco, etc. Observação : para efeitos didáticos podemos dizer que o conceito agrupamento de bancos de dados do PostgreSQL? https://wiki.serpro/unidades/supcd/artigos-tecnicos/bancos-de-dados/postgresql/AgrupamentoDeBancosDeDados/createform?page=PostgreSQL é equivalente ao conceito de instância do banco de dados Oracle. A recomendação é a criação de agrupamentos diferentes de acordo com os serviços a serem implantados, de preferência cada serviço deve possui seu próprio agrupamento de banco de dados ou no casos de serviços semelhantes, por exemplo do mesmo cliente, eles podem vir a compartilhar o agrupamento. *Padrão de nome de agrupamento / instância* Em termos operacionais o agrupamento é o nome do diretório sobre o qual os dados são armazenados. No diretório principal do agrupamento (PGDATA) ficam os arquivos e diretórios de configuração do PostgreSQL? https://wiki.serpro/unidades/supcd/artigos-tecnicos/bancos-de-dados/postgresql/AgrupamentoDeBancosDeDados/createform?page=PostgreSQL O nome do agrupamento terá no máximo 15 caracteres e deve indicar a finalidade do agrupamento. Exemplo: siape siafi O nome do diretório de dados (PGDATA) seguirá o padrão : filesystem/pgsql/nome do agrupamento/ onde filesystem é o nome do filesystem de acordo com o padrão definido. Recomenda-se que o diretório do PGDATA seja criado no filesystem de sequência 001. nome do agrupamento é o nome do agrupamento de dados. Exemplo : /h21110001/pgsql/homologacao /m9001/pgsql/siape *Criação do agrupamento* O primeiro passo para a criação de uma agrupamento é criar o diretório do agrupamento. Por motivo de segurança o diretório deve ter permissão somente para o usuário postgres. Depois deve ser iniciado o agrupamento com o utilitário initdb. Exemplo : mkdir -p /h30212001/pgsql/homol chown postgres.postgres /h30212001/pgsql/homol chmod -R 700 /h30212001/pgsql/homol initdb -D /h30212001/pgsql/homol *Inicialização da instância de bancos de dados* O serviço do SGBD deve ser ativado usando os comandos postmaster ou pg_ctl. Exemplo : pg_ctl -D /h62122001/pgsql/hsiape -o -p 5434 start Nos sistemas operacionais Red Hat podemos configurar um serviço para controlar a inicialização do servicos do postgres. Para isto os seguintes passos são necessários : 1. Conecte como superusuário do sistema operacional (root) 2. Crie no diretório /etc/sysconfig/pgsql um arquivo texto contendo as informaçoes do PGDATA do agrupamento de dados e a porta de conexão. O padrão de nome deste arquivo é : postgres_nome de do agrupamento 3. Crie no diretório /etc/rc.d/init.d/ uma copia do arquivo postgres colocando o mesmo nome do arquivo de configuração criado no /etc/sysconfig/pgsql 4. Execute o comando chkconfig para cadastrar o novo serviço nos arquivos de configuração do Red Hat. 5. Como usuário root podemos usar o script postgres para controlar os serviços do postgres (start, stop, status, etc) Exemplo : Configurar o sistema para iniciar o agrupamento homologacao 1. Criar o arquivo /etc/sysconfig/pgsql/postgres_homologacao com o seguinte conteúdo PGDATA=/h43344001/pgsql/homologacao PGPORT=5435 2. Criar uma cópia do arquivo /etc/rc.d/init.d/postgres cp /etc/rc.d/init.d/postgres /etc/rc.d/init.d/postgres_homologacao 3. Cadastrar o serviço chkconfig --add postgresql_homologacao 4. Agora o serviço pode ser controlado pelo script /etc/rc.d/init.d/postgres_homologacao ou pelo utilitário service /etc/rc.d/init.d/postgresql_homologacao start /etc/rc.d/init.d/postgresql_homologacao stop /etc/rc.d/init.d/postgresql_homologacao status service postgresql_homologacao stop service postgresql_homologacao start service postgresql_homologacao status Leandro Henrique Pereira Neto Administração de bancos de dados - DBA/OC SUPCD/CDSUT/CDSBB Esta
Re: [pgbr-geral] RES: backup POSTGRES 8.3
COLD não é recomendada para serviços com requisitos de operação 24/7, nem em grandes bancos de dados onde o tempo de indisponibilidade do sistema para realização da cópia será muito alto. Cópias de segurança físicas HOT só podem ser recuperadas de forma consistente com a recuperação dos arquivos de WAL. Implementação Os processos de cópia física são implementados utilizando-se utilitários do sistema operacional e um conjuntos de procedimentos e scripts de configuração e execução padronizados. Leandro Henrique Pereira Neto Administração de bancos de dados - DBA/OC SUPCD/CDSUT/CDSBB 61 21059359 ELIAS JUNIOR escreveu: *pensei que pg_dump não fosse backup!!!* 2008/11/12 Shander Lyrio [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Emerson Casas Salvador wrote: Mateus escreveu: pg_dump -Fc -d nomedobanco -f backup.bck Bom dia Mateus não encontrei na documentação[1] objeção ao uso de direcionamento, aliás tem vários exemplos com , é algum caso específico? [1] http://www.postgresql.org/docs/8.3/static/app-pgdump.html Quando você manda para o terminal e depois direciona para o arquivo você cria uma etapa a mais na hora do backup, além disso o backup não é compactado, a não ser que você direcione novamente o stream para o gzip. Isso pode não causar muita diferença em bancos pequenos, mas em grandes temos uma melhora considerável no tempo de backup. Desta forma você joga o dump diretamente para o arquivo e já compactado sem intermediários. -- Shander Lyrio ___ 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral 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
