Re: [pgbr-geral] Sugestão de uso
Em 29/6/2011 21:40, Shander Lyrio escreveu: > Em 29/06/2011 20:07, Fabiano Machado Dias escreveu: O fato de você organizar as transações dentro de uma PLs é o mesmo exemplo já citado. Ao invés de eu ter um código de baixa de estoque em >> Inicia o bloco da transação antes da chamada da PL, chama a PL e encerra >> a transação. Se você usa PL achei que fazia isso. > Eu uso, mas para mim está muito claro que você disse "organizar > transações dentro de uma PL". "Dentro" para mim ainda é diferente de > "fora" como você citou agora. Leia por favor seus dois parágrafos acima, > achei que você tivesse lido. Toda a PL e os blocos de uma PL rodam numa transação, o que você não pode é alterar a transação dentro da PL, te dei um exemplo de como chamar várias PLs dentro de uma transação externa. "Organizar transações dentro de uma PL", ou seja, o que eu preciso que faça tudo ou não, ou baixa estoque ou não, ou quita uma duplicata ou não, ou grava ou não grava, ou dá ou desce!!! rsrsrsrs Não vejo o que você fala como dentro ou fora, como já disse você se tem os seus procedimentos em PL nada de impede de um chamar o outro. E tb não vi que tipo de coisa você estava esperando, se conhece o funcionamento de transações e do banco não pensei que teria que te explicar isso. Algumas referências: http://pgdocptbr.sourceforge.net/pg80/plpgsql-structure.html (Em português) http://www.postgresql.org/docs/9.0/static/plpgsql-structure.html (Mais atual, em inglês) http://pgbr.postgresql.org.br/2009/palestras/aud1/plpgsql-roberto-mello.pdf >> A diferença é que você tem o controle, quantas vezes vi gente quebrando >> a cabeça porque só queria alterar um valor numa coluna e o banco travou! >> Travou pq esqueceu ou nem sabia que tinha um gatilho lá fazendo um monte >> de coisa! > Não tem diferença de um gatilho chamando um outro e fazendo um monte de > coisa de uma procedure chamando outras e fazendo um monte de coisa. > Gatilhos nada mais são que chamadas para procedures. Sim, tecnicamente sim, a diferença é que uma PL você que chama e não é disparada quando troca o telefone de um cadastro de cliente por exemplo! >> Você escrever todo um sistema, um framework, as tuas regras de negócio >> em uma ferramenta e ver ele simplesmente morrer é um trauma pra qualquer >> desenvolvedor. > O SGDB também pode morrer. Uma linguagem inteira ou um SGDB inteiro é > menos propenso a morrer do que uma mera ferramenta como o Clarion. > Apostar todas as suas fichas em uma só tecnologia sempre será um risco, > quem faz isto em uma ferramenta somente assume um risco muito maior como > foi seu caso. > > Sinto muito pelo seu trauma, o que está fazendo hoje não resolve o > problema da melhor forma, apenas resolve. Tudo poderia ser mais simples, > mais testável e mais garantido que o que você tem hoje, se ser simples e > testável não tem tanto valor assim para você, então está valendo. Você conhece Clarion? Era uma linguagem inteira, na verdade vi o conceito de ferramenta RAD já incorporado no Clarion ainda em DOS. Era um espetáculo pra época, uma velocidade de desenvolvimento que nenhuma outra ferramenta tinha, pelo menos não as que conheci, e olha que já vi muita coisa. Nas versões Windows continuou até a 7 e morreu. A partir daí usei de tudo, fiz cursos disso e daquilo, trabalhei em outros projetos, olhei ferramentas livres, pagas, etc... Sabia que iria construir um novo software, para um outro ramo e em outra tecnologia e desta vez queria ficar o mais independente possível. (Ok, fiquei preso ao PG, mas isso eu já falei né) Quanto a você achar que tudo poderia ser mais simples e testável e garantido, bom te garanto que já tenho isso atualmente, apesar de você discordar, é sua opinião e respeito. >> Vou te dar só um exemplo. Você precisa alterar a forma do cálculo do >> custo de todos os insumos de uma ficha técnica. Se a tua regra é na >> aplicação, vai ter que recompilar, gerar uma nova versão, substituir teu >> executável ou coisa similar. Faço isso hoje, mantenho a versão original, >> modifico, atualizo, rodo e não envolvo nenhuma outra parte a aplicação. > Uma pequeno script em uma linguagem tipo o Python não era melhor? Não > envolveria nem a aplicação, nem alteração no banco de dados. Digo isto > porque uso algo deste tipo e uma aplicação minha. O script fica guardado > no banco de dados e pode ser alterado em uma tela do sistema. > > Vamos supor que você fez uma alteração na sua procedure de calculo de > custo na empresa A. Ok, um dia você percebe que tem um bug na procedure > de cálculo de custos geral, cria um script para corrigir ela em todos os > seus clientes e bam. Perdeu-se a alteração específica que está naquele > cliente. Ok ok, você pode argumentar que faz isto cliente por cliente > para ser mais personalizado, infelizmente não poderia aceitar isso > porque você também disse que faz as coisas para ser produtivo. Bom, aqui eu noto uma contradição sua, afinal ind
Re: [pgbr-geral] Postgresql + innosetup
Em 29-06-2011 20:44, Juliomar escreveu: > PostgreSQL 9.0.4 > > Windows XP,Vista e Seven > > em nenhum dos casos ele funcionou, ele fez a instalação > mas não criou o usário e nem instalou o serviço > O instalador é o da EnterpriseDB (One-Click Installer)? Qual o erro? Vide o final do arquivo %TEMP%\install-postgresql.log. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ 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
Em 29/06/2011 20:07, Fabiano Machado Dias escreveu: >>> O fato de você organizar as transações dentro de uma PLs é o mesmo >>> exemplo já citado. Ao invés de eu ter um código de baixa de estoque em > Inicia o bloco da transação antes da chamada da PL, chama a PL e encerra > a transação. Se você usa PL achei que fazia isso. Eu uso, mas para mim está muito claro que você disse "organizar transações dentro de uma PL". "Dentro" para mim ainda é diferente de "fora" como você citou agora. Leia por favor seus dois parágrafos acima, achei que você tivesse lido. > A diferença é que você tem o controle, quantas vezes vi gente quebrando > a cabeça porque só queria alterar um valor numa coluna e o banco travou! > Travou pq esqueceu ou nem sabia que tinha um gatilho lá fazendo um monte > de coisa! Não tem diferença de um gatilho chamando um outro e fazendo um monte de coisa de uma procedure chamando outras e fazendo um monte de coisa. Gatilhos nada mais são que chamadas para procedures. > Você escrever todo um sistema, um framework, as tuas regras de negócio > em uma ferramenta e ver ele simplesmente morrer é um trauma pra qualquer > desenvolvedor. O SGDB também pode morrer. Uma linguagem inteira ou um SGDB inteiro é menos propenso a morrer do que uma mera ferramenta como o Clarion. Apostar todas as suas fichas em uma só tecnologia sempre será um risco, quem faz isto em uma ferramenta somente assume um risco muito maior como foi seu caso. Sinto muito pelo seu trauma, o que está fazendo hoje não resolve o problema da melhor forma, apenas resolve. Tudo poderia ser mais simples, mais testável e mais garantido que o que você tem hoje, se ser simples e testável não tem tanto valor assim para você, então está valendo. > Vou te dar só um exemplo. Você precisa alterar a forma do cálculo do > custo de todos os insumos de uma ficha técnica. Se a tua regra é na > aplicação, vai ter que recompilar, gerar uma nova versão, substituir teu > executável ou coisa similar. Faço isso hoje, mantenho a versão original, > modifico, atualizo, rodo e não envolvo nenhuma outra parte a aplicação. Uma pequeno script em uma linguagem tipo o Python não era melhor? Não envolveria nem a aplicação, nem alteração no banco de dados. Digo isto porque uso algo deste tipo e uma aplicação minha. O script fica guardado no banco de dados e pode ser alterado em uma tela do sistema. Vamos supor que você fez uma alteração na sua procedure de calculo de custo na empresa A. Ok, um dia você percebe que tem um bug na procedure de cálculo de custos geral, cria um script para corrigir ela em todos os seus clientes e bam. Perdeu-se a alteração específica que está naquele cliente. Ok ok, você pode argumentar que faz isto cliente por cliente para ser mais personalizado, infelizmente não poderia aceitar isso porque você também disse que faz as coisas para ser produtivo. > Os ganhos vão além do código entende? Só um exemplo ok? Existem outros > casos, mas já tá no fim do dia e estou meio com preguiça pra escrever! rsrs Eu ainda não os vi. Sinto muito. Todos os ganhos que me citou até agora sempre trazem consigo uma grande carga de outros problemas. Você não resolve o problema deste jeito, apenas transfere ele para outro lugar. > Servidores superdomensionados? No que você roda as suas aplicações? > Esses servidores são os de mais baixo custo que existem, estão na faixa > de 4 a 7 mil. Tenho servidor com mais de 5 anos de idade trabalhando muito bem com carga bem maior. Mas isto é bem subjetivo e vou parar esta discussão já que foge do escopo da thread. > Durmo tranqüilo porque as várias decisões do projeto deram certo. > Construir do zero e construir errado não adianta nada! Dar certo não significa que é a melhor coisa a fazer. De qualquer forma a discussão já deu o que tinha que dar e daqui a pouco vamos entrar no Paradoxo de Tostines. >>> Talvez, mas fique a vontade para perguntar, se estiver no PGBR esse ano >>> fique a vontade também se quiser ver isso tudo na prática. >> Não poderei me dar este luxo, infelizmente. > > Uma pena, não sei de onde você é, mas se estiver em Porto Alegre pode > entrar em contato comigo caso seja de seu interesse! Não poderei me dar ao luxo de ir na PGBR. Mas já tirei todas as conclusões que precisava à respeito de seu modelo. Pelo menos o suficiente para continuar não aconselhando. Qualquer coisa que eu pontue irá mudar na próxima thread. Primeiro foi a modificação de um ERP que era de um jeito para outro mas o que vimos na verdade foi a construção de um outro ERP do zero, sem a maioria dos erros de modelagem do primeiro. Depois as transações que eram dentro das procedures e rapidamente mudaram para fora como se eu não estivesse lido claramente o que foi escrito. Está ficando sem graça esta caça ao rato. Fico por aqui, forte abraço, não haverão mais respostas minhas nesta thread. -- Sha
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
2011/6/29 Dickson S. Guedes : > Em 29 de junho de 2011 18:54, Leandro DUTRA > escreveu: Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso já discutimos tanto, aqui e alhures… deixa quieto. >> […] >>> Não sei como está hoje, mas até alguns meses atrás a aplicação estava >>> lá, funcionando internamente e conforme o que desejavam. >> >> Funcionando eu creio… mas o modelo ficou opaco… > > Não tão opaco assim, pelo menos pra mim, pois eles tinham DOMAINs, > CHECKs, FKs, UKs, PKs e até ENUMs bem definidos no PostgreSQL... e não > chegavam a 10 PLs e sim, duplicaram as algumas regras na aplicação. Opa, acho que cortei demais o contexto… não estava falando de código procedural, que nada tem a ver com o modelo, mas de chaves artificiais generalizadas. Tudo bem que o uso sistemático de chaves naturais declaradas como alternativas evita o modelo opaco, mas aí as chaves artificiais criadas sistematicamente, e não ad hoc, representam um peso a mais para o sistema, que não é sempre necessário. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Postgresql + innosetup
Boa Noite Bem lembrado amigo PostgreSQL 9.0.4 Windows XP,Vista e Seven em nenhum dos casos ele funcionou, ele fez a instalação mas não criou o usário e nem instalou o serviço Em 29/06/2011 17:58, Guilherme Groke escreveu: > Versão do PostgreSQL? Versão do Windows? > > GG > > > > > 2011/6/29 Juliomar: >> Boa tarde >> alguém já fez uma instalação silenciosa do postgresql no windows? >> >> li o manual mas não funcionou >> >> copiou todos os arquivos, mas na hora de criar o usuário e registrar no >> windows não fez. >> >> alguém sabe ou já fez.. >> >> desde já agradeço >> >> Juliomar Marchetti >> >> ___ >> 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] Avaliando a ordem de colunas em índices compostos
Em 29 de junho de 2011 18:54, Leandro DUTRA escreveu: > 2011/6/29 Dickson S. Guedes : [... corte ...] >> A questão na época era como melhorar a performance de duas aplicações >> em uso, sem tirar o HIbernate, tão pouco o ActiveRecord (do Rails). > > ¿Masoquismo? Ou sadismo, mesmo? Tem o caso da necessidade absoluta, também… O sistema já estava lá, o estudo era como conseguir otimizar certos processos utilizando as ferramentas em questão sem removê-las. Digo que muitos "for's" aninhados foram transformados em HQL e outros simplesmente abolidos e feitos em SQL puro mesmo. Os dois mundos estavam co-existindo. >>> Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso >>> já discutimos tanto, aqui e alhures… deixa quieto. > […] >> Não sei como está hoje, mas até alguns meses atrás a aplicação estava >> lá, funcionando internamente e conforme o que desejavam. > > Funcionando eu creio… mas o modelo ficou opaco… Não tão opaco assim, pelo menos pra mim, pois eles tinham DOMAINs, CHECKs, FKs, UKs, PKs e até ENUMs bem definidos no PostgreSQL... e não chegavam a 10 PLs e sim, duplicaram as algumas regras na aplicação. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ 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
Em 29/6/2011 17:38, Shander Lyrio escreveu: > Em 29/06/2011 15:35, Fabiano Machado Dias escreveu: > >> Não o fato de colocar tudo no "PostgreSQL" e sim o fato de usar >> cursores, offset, sequencias temporárias etc... Desculpe se não fui claro! > Ainda acredito que para a grande maioria das rotinas, e quando digo > grande maioria estou querendo dizer grande maioria mesmo, o uso de > cursores não faz sentido, salvo os casos em que um grande volume de > dados está sendo tratado de uma única vez, o que não me parece ser o caso. Cursores foi um exemplo, uso eles para paginação no browse de tela ou em algum relatório específico. >> O fato de você organizar as transações dentro de uma PLs é o mesmo >> exemplo já citado. Ao invés de eu ter um código de baixa de estoque em >> alguma tela, ou procedure em alguma camada intermediária eu tenho uma PL >> que faz isso! É um conjunto de soluções e não apenas o uso de PLs, >> tentei passar uma idéia geral de como fizemos o desenvolvimento. > Achava até hoje que o PostGreSql não permite controle de transações > dentro de uma procedure. Estou desatualizado?? Eu não vi nada na > documentação até hoje. Inicia o bloco da transação antes da chamada da PL, chama a PL e encerra a transação. Se você usa PL achei que fazia isso. >> O problema é quando um gatilho, dispara um gatilho que dispara outro >> E as vezes lá no quinto nível aquele quinto gatilho dispara o >> primeiro!!! Daí você tem além um baita problema uma produção parada! > Assim como uma procedure que dispara outra que dispara outra e as vezes > lá no quinto nível ela também pode disparar a primeira. Continuo não > encontrando um motivo técnico substancial que me faça preferir colocar > toda a lógica de negócios dentro do SGDB, aliás, não é só toda a lógica > de negócio, mas também a criação de i/u/d também à cargo do banco de dados. A diferença é que você tem o controle, quantas vezes vi gente quebrando a cabeça porque só queria alterar um valor numa coluna e o banco travou! Travou pq esqueceu ou nem sabia que tinha um gatilho lá fazendo um monte de coisa! Se você esteve na apresentação talvez tenha esquecido que o principal motivo de colocar a regra no banco foi para não ter que ficar dependente de nenhuma linguagem, tivemos uma experiência com o Clarion que não gostaria que acontecesse com ninguém. Você escrever todo um sistema, um framework, as tuas regras de negócio em uma ferramenta e ver ele simplesmente morrer é um trauma pra qualquer desenvolvedor. Eu tinha uma opinião parecida até com a sua, mas mudei depois disso. Hoje troco de linguagem em poucos meses sem muito trabalho, claro estou preso ao elefante, mas isso não me assusta nenhum pouco. Pelo contrário. 3 - Velocidade de desenvolvimento >>> Escrever PL's é mais rápido que escrever código em qualquer outra >>> linguagem?? Como fica o versionamento disso? Como são feitos testes >>> unitários? >> Existe diferença? PL/pgSql não é uma linguagem? Talvez você sinta falta >> de uma IDE, é isso? Temos uma IDE pra interface, Windev conhece? No mais >> uso o bom e velho pgadmin! >> >> As versões são controladas por um software que nós mesmos desenvolvemos, >> eu sou um dos responsáveis pelos testes de versão. > Não não é isto, seu tópico foi velocidade de desenvolvimento, e eu > argumentei que escrever código numa PL é o mesmo que escrever código na > sua linguagem favorita. Não vi ganhos de velocidade com a mudança de > linguagem, isto independe de IDE. Vou te dar só um exemplo. Você precisa alterar a forma do cálculo do custo de todos os insumos de uma ficha técnica. Se a tua regra é na aplicação, vai ter que recompilar, gerar uma nova versão, substituir teu executável ou coisa similar. Faço isso hoje, mantenho a versão original, modifico, atualizo, rodo e não envolvo nenhuma outra parte a aplicação. Os ganhos vão além do código entende? Só um exemplo ok? Existem outros casos, mas já tá no fim do dia e estou meio com preguiça pra escrever! rsrs 4 - Acesso rápido aos dados pelo cliente >>> Onde PL's ajudam nisto a não ser em casos muito especiais já citados >>> nesta thread diversas vezes? >> Já citei um exemplo acima, sem contar a facilidade de poder alterar o >> comportamento do sistema sem ter que interferir no desenvolvimento com >> as PLs customizadas que a PL manutenção procura! Vide palestra. > Acredito que esta complexidade que você criou de uma pl sair procurando > outras pl's customizadas seria mais facilmente definidas e teriam melhor > manutenção se escritas em uma linguagem OO apropriada. Não sei, mas respeito a sua opinião e minha é diferente. >> Não, foi um conjunto de fatores, não existe mágica né! A modelagem >> ajudou a simplificar o desenvolvimento das PLs, as duas coisas andam >> juntas. De nada me adianta ter uma modelagem boa e um framework lento e >> cheio de bugs! > E você não pode estar correndo o risco de atribuir esta melhoria ao > excesso de procedu
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
2011/6/29 Dickson S. Guedes : > Em 29 de junho de 2011 12:27, Leandro DUTRA > escreveu: >> 2011/6/28 Dickson S. Guedes : >>> Em tempo, tive bons contatos com ActiveRecord do Rails [2] […] > "bons contatos" ali não foi no sentido de benéficos,[…] e sim no sentido > de /alguem que leu e testou muitos codigos do ActiveRecord para > compreender como ele funciona, para então pode auxiliar um ex-aluno em > um projeto de TCC/ ... Ah, subitamente a realidade passa a fazer sentido! ;-) > A questão na época era como melhorar a performance de duas aplicações > em uso, sem tirar o HIbernate, tão pouco o ActiveRecord (do Rails). ¿Masoquismo? Ou sadismo, mesmo? Tem o caso da necessidade absoluta, também… >> Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso >> já discutimos tanto, aqui e alhures… deixa quieto. […] > Não sei como está hoje, mas até alguns meses atrás a aplicação estava > lá, funcionando internamente e conforme o que desejavam. Funcionando eu creio… mas o modelo ficou opaco… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Postgres e Servdor com 6 CPUS Quad - Melhor uso
Desculpem "faze" com z. é fase Bruno E. A. Silva. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
em média 50 clientes/conexões. O sistema ainda está em faze de implamtação e estamos usando o JMeter para simular uma média de 200 usuários no sistema. Bruno E. A. Silva. Analista de Sistemas. Certified Scrum Master LPIC-1 SCJP, SE 6 Novell CLA Novell DCTS ECR DBA Postgres --- “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” - Sábio Desconhecido "Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!" 2011/6/29 Flavio Henrique Araque Gurgel : > Em 29 de junho de 2011 18:16, Bruno Silva escreveu: >> O mesmo :D >> Já o fiz a uns 3 meses. Meu mentor DBA em Postgres já havia me dado essa >> dica. >> Acontece que o fato de se ter os fork do processo postgres não >> siginifica que cada um irá para um núcleo diferente. >> Talvez fazendo algum processo eu consiga determinar que novos >> processos do postgres usem outros cores. >> Mas por hora nada mudou. > > E qual é a carga do seu servidor? Tipo... mais ou menos, quantas > transações por segundo está fazendo, ou quantos clientes conectados à > aplicação estão de fato fazendo alguma coisa? > > []s > Flavio Gurgel > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
Em 29 de junho de 2011 18:16, Bruno Silva escreveu: > O mesmo :D > Já o fiz a uns 3 meses. Meu mentor DBA em Postgres já havia me dado essa dica. > Acontece que o fato de se ter os fork do processo postgres não > siginifica que cada um irá para um núcleo diferente. > Talvez fazendo algum processo eu consiga determinar que novos > processos do postgres usem outros cores. > Mas por hora nada mudou. E qual é a carga do seu servidor? Tipo... mais ou menos, quantas transações por segundo está fazendo, ou quantos clientes conectados à aplicação estão de fato fazendo alguma coisa? []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
O mesmo :D Já o fiz a uns 3 meses. Meu mentor DBA em Postgres já havia me dado essa dica. Acontece que o fato de se ter os fork do processo postgres não siginifica que cada um irá para um núcleo diferente. Talvez fazendo algum processo eu consiga determinar que novos processos do postgres usem outros cores. Mas por hora nada mudou. Bruno E. A. Silva. Analista de Sistemas. Certified Scrum Master LPIC-1 SCJP, SE 6 Novell CLA Novell DCTS ECR DBA Postgres --- “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” - Sábio Desconhecido "Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!" 2011/6/29 Leandro DUTRA : > 2011/6/29 Bruno Silva : >> Já o fiz. Mudei o mínimo para um número maior. > > ¿E o resultado foi…? > > > -- > Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org > +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 > sip:leand...@iptel.org 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 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
Luciano, Cogitamos esta possibilidade!!! Um middleware (seria este o nome?) que gerenciaria toda a regra de negócios e falaria diretamente com o banco de dados, vimos muitas vantagens mas para o modelo como estamos querendo não seria a melhor escolha. Em 29 de junho de 2011 17:48, Luciano Schardosim escreveu: > Senhores(as), > > essa discussão de onde deixar as regras de negócio muda muito. Mas uma > sugestões, se me permite, é trabalhar em camadas. Ou seja, aplicação, API de > dados, e banco de dados. Ou seja, use uma camada de abstração, dessa forma, > não importa a linguagem que você usa e não importa o SGBD que você usa. as > regras de negócio ficam na API. Stored Procedures são muito boas, mas tem > que ponderar uso destas pois o processamento das regras de negócio passam > para o SGBD e isso pode trazer maior lentidão nas transações, dependendo do > volume. Essa foi a solução adotada onde trabalho e tem dado certo. > > Espero ter contribuido. > > Abraços... > > > > Em 28 de junho de 2011 17:55, Roberto Mello escreveu: > >> 2011/6/28 Udlei Nattis >> >>> Neste caso o que queremos é permitir que a ferramenta seja feita em >>> qualquer linguagem, não apenas a que vamos desenvolver inicialmente. >>> >> >> Não seria uma otimização precoce? >> >> Como o Euler, eu também deixaria apenas as regras complexas para funções. >> O resto eu documentaria bem, de antemão, para criar uma API "modelo" que >> poderia ser mais facilmente portada para uma outra linguagem, e claro, com >> excelentes testes, tanto unitários como outros tipos. >> >> O mais difícil é conseguir iniciar com TDD (test-driver development). >> Depois o esforço extra se paga em pouco tempo. >> >> Também não estamos preocupados em esconder nada, inclusive é discutido na >>> empresa em montar o sistema em código aberto. Preferimos investir mais neste >>> hardware para garantir que transacoes, controle de estoque e geracao de >>> produtos sejam seguras do que deixar na mão dos programadores que geralmente >>> não entendem toda a complexidade do negócio. >>> >> >> Certo. Mas não esqueça que é mais difícil notar ineficiências/otimizar >> quando o SQL está enterrado dentro de funções. >> >> >>> Sabe me dizer onde encontro alguma documentação sobre? >>> >> >> Sobre o que? >> >> Roberto >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > > Prof Luciano Schardosim > Mobile 51 9603.2608 > Email schar...@gmail.com > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Att. Udlei Nattis Nixus Soluções Lojas Virtuais www.nixus.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgresql + innosetup
Versão do PostgreSQL? Versão do Windows? GG 2011/6/29 Juliomar : > Boa tarde > alguém já fez uma instalação silenciosa do postgresql no windows? > > li o manual mas não funcionou > > copiou todos os arquivos, mas na hora de criar o usuário e registrar no > windows não fez. > > alguém sabe ou já fez.. > > desde já agradeço > > Juliomar Marchetti > > ___ > 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] Postgresql + innosetup
Boa tarde alguém já fez uma instalação silenciosa do postgresql no windows? li o manual mas não funcionou copiou todos os arquivos, mas na hora de criar o usuário e registrar no windows não fez. alguém sabe ou já fez.. desde já agradeço Juliomar Marchetti ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
2011/6/29 Bruno Silva : > Já o fiz. Mudei o mínimo para um número maior. ¿E o resultado foi…? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
Senhores(as), essa discussão de onde deixar as regras de negócio muda muito. Mas uma sugestões, se me permite, é trabalhar em camadas. Ou seja, aplicação, API de dados, e banco de dados. Ou seja, use uma camada de abstração, dessa forma, não importa a linguagem que você usa e não importa o SGBD que você usa. as regras de negócio ficam na API. Stored Procedures são muito boas, mas tem que ponderar uso destas pois o processamento das regras de negócio passam para o SGBD e isso pode trazer maior lentidão nas transações, dependendo do volume. Essa foi a solução adotada onde trabalho e tem dado certo. Espero ter contribuido. Abraços... Em 28 de junho de 2011 17:55, Roberto Mello escreveu: > 2011/6/28 Udlei Nattis > >> Neste caso o que queremos é permitir que a ferramenta seja feita em >> qualquer linguagem, não apenas a que vamos desenvolver inicialmente. >> > > Não seria uma otimização precoce? > > Como o Euler, eu também deixaria apenas as regras complexas para funções. O > resto eu documentaria bem, de antemão, para criar uma API "modelo" que > poderia ser mais facilmente portada para uma outra linguagem, e claro, com > excelentes testes, tanto unitários como outros tipos. > > O mais difícil é conseguir iniciar com TDD (test-driver development). > Depois o esforço extra se paga em pouco tempo. > > Também não estamos preocupados em esconder nada, inclusive é discutido na >> empresa em montar o sistema em código aberto. Preferimos investir mais neste >> hardware para garantir que transacoes, controle de estoque e geracao de >> produtos sejam seguras do que deixar na mão dos programadores que geralmente >> não entendem toda a complexidade do negócio. >> > > Certo. Mas não esqueça que é mais difícil notar ineficiências/otimizar > quando o SQL está enterrado dentro de funções. > > >> Sabe me dizer onde encontro alguma documentação sobre? >> > > Sobre o que? > > Roberto > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Prof Luciano Schardosim Mobile 51 9603.2608 Email schar...@gmail.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] Sugestão de uso
Em 29/06/2011 15:35, Fabiano Machado Dias escreveu: > Não o fato de colocar tudo no "PostgreSQL" e sim o fato de usar > cursores, offset, sequencias temporárias etc... Desculpe se não fui claro! Ainda acredito que para a grande maioria das rotinas, e quando digo grande maioria estou querendo dizer grande maioria mesmo, o uso de cursores não faz sentido, salvo os casos em que um grande volume de dados está sendo tratado de uma única vez, o que não me parece ser o caso. > O fato de você organizar as transações dentro de uma PLs é o mesmo > exemplo já citado. Ao invés de eu ter um código de baixa de estoque em > alguma tela, ou procedure em alguma camada intermediária eu tenho uma PL > que faz isso! É um conjunto de soluções e não apenas o uso de PLs, > tentei passar uma idéia geral de como fizemos o desenvolvimento. Achava até hoje que o PostGreSql não permite controle de transações dentro de uma procedure. Estou desatualizado?? Eu não vi nada na documentação até hoje. > O problema é quando um gatilho, dispara um gatilho que dispara outro > E as vezes lá no quinto nível aquele quinto gatilho dispara o > primeiro!!! Daí você tem além um baita problema uma produção parada! Assim como uma procedure que dispara outra que dispara outra e as vezes lá no quinto nível ela também pode disparar a primeira. Continuo não encontrando um motivo técnico substancial que me faça preferir colocar toda a lógica de negócios dentro do SGDB, aliás, não é só toda a lógica de negócio, mas também a criação de i/u/d também à cargo do banco de dados. >>> 3 - Velocidade de desenvolvimento >> Escrever PL's é mais rápido que escrever código em qualquer outra >> linguagem?? Como fica o versionamento disso? Como são feitos testes >> unitários? > > Existe diferença? PL/pgSql não é uma linguagem? Talvez você sinta falta > de uma IDE, é isso? Temos uma IDE pra interface, Windev conhece? No mais > uso o bom e velho pgadmin! > > As versões são controladas por um software que nós mesmos desenvolvemos, > eu sou um dos responsáveis pelos testes de versão. Não não é isto, seu tópico foi velocidade de desenvolvimento, e eu argumentei que escrever código numa PL é o mesmo que escrever código na sua linguagem favorita. Não vi ganhos de velocidade com a mudança de linguagem, isto independe de IDE. >>> 4 - Acesso rápido aos dados pelo cliente >> Onde PL's ajudam nisto a não ser em casos muito especiais já citados >> nesta thread diversas vezes? > > Já citei um exemplo acima, sem contar a facilidade de poder alterar o > comportamento do sistema sem ter que interferir no desenvolvimento com > as PLs customizadas que a PL manutenção procura! Vide palestra. Acredito que esta complexidade que você criou de uma pl sair procurando outras pl's customizadas seria mais facilmente definidas e teriam melhor manutenção se escritas em uma linguagem OO apropriada. > Não, foi um conjunto de fatores, não existe mágica né! A modelagem > ajudou a simplificar o desenvolvimento das PLs, as duas coisas andam > juntas. De nada me adianta ter uma modelagem boa e um framework lento e > cheio de bugs! E você não pode estar correndo o risco de atribuir esta melhoria ao excesso de procedures ao invés da remodelagem? > Tenho clientes que vão desde atacados até indústria de couros e > componentes eletrônicos. Nos atacados temos a questão das filiais e > muita emissão de nota, algo em torno de 8 a 10 mil NFEs por mês, as > filais são interligadas via VPN, tenho outra que produz 5 a 7 mil peças > de couro por dia. Isso tudo contabilizando, gerando lote, baixando > estoque, alimentando pedidos e outros sistemas de apoio. Ok, já percebi que o volume é muito pequeno. > Nossos servidores são simples, Xeon Dual ou Quad, discos SAS de 10 e > 15k, memória entre 4 a 10 gigas! Servidores superdimensionados para tão pouco, a não ser que seja o banco de vários clientes rodando em um único servidor. > Sei lá se tamanho de banco é algo que possa servir de parâmetro mas não > é muito grande não, já o número de transações é alto. Tamanho do banco não importa muito mesmo, mas pelos volumes que citou acho que não devem haver nem transações concorrentes. Um mês teria aproximadamente 10560 minutos úteis. > O maior tá perto de 8 giga, que é de um atacado, está rodando desde 2009 > aliás não entendo como as bases de outras sistemas crescem tão rápido! Fácil, aqui 4 milhões de entregas por mês rastreadas passo a passo, desde a coleta até a entrega. Gerando rotas para distribuidores com vários entregadores em todo o país. Cada uma destas entregas com um identificador único, que é lido através de um leitor de código de barras cada vez que a entrega muda de status. > Hoje temos clientes que faturam 3x esse exemplo usando o sistema como um > todo, mas sei lá, me pergunte algo mais específico. Uma empresa do tipo fábrica pode fazer 5 notas de um milhão cada uma. Fatu
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
Já o fiz. Mudei o mínimo para um número maior. Bruno E. A. Silva. Analista de Sistemas. Certified Scrum Master LPIC-1 SCJP, SE 6 Novell CLA Novell DCTS ECR DBA Postgres --- “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” - Sábio Desconhecido "Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!" 2011/6/29 Flavio Henrique Araque Gurgel : >>> Pessoal, tenho atualmente dois servidores com 6 CPUS Quad. >>> E analisando o uso de recursos do sistema percebo que os núcleos estão >>> ficando ociosos enquanto um ou outro chega a 90% de uso. >>> Tenho uma aplicação rodando em JBoss e usando Hibernate ( e mal >>> implementado por sinal ). Utilizando Pool de conexões nativo do >>> próprio JBoss. >>> Qual a melhor forma de melhorar essa distribuição de carga? >> >> Veja, cada conexão no banco só pode ser executada por um processador. >> Portanto, se você tiver várias conexões ao mesmo tempo, ter muitos >> processadores ajuda muito, pois a carga vai ser distribuida entre >> eles. Mas se você tem apenas algumas poucas conexões, mas conexões com >> uma carga muito grande, ter vários processadores não vai lhe fazer a >> menor diferença. >> >> O PGPool2 tem um mecanismo para quebrar uma única sessão em vários >> pedaços e distribuir entre vários nós de um cluster. Esta seria uma >> forma de aproveitar melhor os processadores no caso de poucas sessões >> muito pesadas. > > Complementando o que o Fábio falou, verifique no JBoss o arquivo de > configuração do Datasource. > O padrão lá, se não me engano, é de 5 conexões na tag ou > . > Ajuste lá para valor mais alto para aproveitar melhor o número de > núcleos que você tem disponível. > > []s > Flavio Gurgel > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
>> Pessoal, tenho atualmente dois servidores com 6 CPUS Quad. >> E analisando o uso de recursos do sistema percebo que os núcleos estão >> ficando ociosos enquanto um ou outro chega a 90% de uso. >> Tenho uma aplicação rodando em JBoss e usando Hibernate ( e mal >> implementado por sinal ). Utilizando Pool de conexões nativo do >> próprio JBoss. >> Qual a melhor forma de melhorar essa distribuição de carga? > > Veja, cada conexão no banco só pode ser executada por um processador. > Portanto, se você tiver várias conexões ao mesmo tempo, ter muitos > processadores ajuda muito, pois a carga vai ser distribuida entre > eles. Mas se você tem apenas algumas poucas conexões, mas conexões com > uma carga muito grande, ter vários processadores não vai lhe fazer a > menor diferença. > > O PGPool2 tem um mecanismo para quebrar uma única sessão em vários > pedaços e distribuir entre vários nós de um cluster. Esta seria uma > forma de aproveitar melhor os processadores no caso de poucas sessões > muito pesadas. Complementando o que o Fábio falou, verifique no JBoss o arquivo de configuração do Datasource. O padrão lá, se não me engano, é de 5 conexões na tag ou . Ajuste lá para valor mais alto para aproveitar melhor o número de núcleos que você tem disponível. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
Em 29 de junho de 2011 16:59, Bruno Silva escreveu: > Pessoal, tenho atualmente dois servidores com 6 CPUS Quad. > E analisando o uso de recursos do sistema percebo que os núcleos estão > ficando ociosos enquanto um ou outro chega a 90% de uso. > Tenho uma aplicação rodando em JBoss e usando Hibernate ( e mal > implementado por sinal ). Utilizando Pool de conexões nativo do > próprio JBoss. > Qual a melhor forma de melhorar essa distribuição de carga? Veja, cada conexão no banco só pode ser executada por um processador. Portanto, se você tiver várias conexões ao mesmo tempo, ter muitos processadores ajuda muito, pois a carga vai ser distribuida entre eles. Mas se você tem apenas algumas poucas conexões, mas conexões com uma carga muito grande, ter vários processadores não vai lhe fazer a menor diferença. O PGPool2 tem um mecanismo para quebrar uma única sessão em vários pedaços e distribuir entre vários nós de um cluster. Esta seria uma forma de aproveitar melhor os processadores no caso de poucas sessões muito pesadas. []s Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
Pessoal, tenho atualmente dois servidores com 6 CPUS Quad. E analisando o uso de recursos do sistema percebo que os núcleos estão ficando ociosos enquanto um ou outro chega a 90% de uso. Tenho uma aplicação rodando em JBoss e usando Hibernate ( e mal implementado por sinal ). Utilizando Pool de conexões nativo do próprio JBoss. Qual a melhor forma de melhorar essa distribuição de carga? Bruno E. A. Silva. ___ 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
2011/6/29 Flavio Henrique Araque Gurgel : > Esta thread está ficando agradavelmente construtiva! Ufa! Já estava com medo do Teles pedir para eu baixar a bola… > E olha que, neste caso, nem estou falando d*o* case do milênio :) Nele > o banco de dados é praticamente um "saco de dados". E pensar que tem dinheiro público nisso… privatização já! Se querem desperdiçar dinheiro, que seja privado… mas, enfim, o setor privado às vezes me parece estar ainda mais atrasado que o público, no quesito liberdade de Informática… pelo menos, no caso de empresas estabelecidas ou que não são de Informática. > E o SGBD: Cata os dados, valida input, trata strings, verifica > consistência em todas as tabelas relacionadas, insere cada pedaço do > formulário em 10 tabelas diferentes, atualiza a tabela de histórico, > computa sequências, atualiza índices, checa as restrições locais e > estrangeiras e "comita tudo. Não parece coisa de clipeiro? Digo, fazendo proceduralmente o que poderia ser declarativo? Ou entendi errado? > Agora no duro: se a parte toda de validação de input e tratamento de > strings fosse na aplicação, a aplicação abrisse uma transação com o > banco e resolvesse sua vida, o processamento de cada passo no pl/pgsql > poderia muito bem ser dela, distribuindo bem melhor a carga entre seus > três servidores. Mas validação não costuma ser conformidade a tipos de dados e integridade referencial, pelo menos num sistema bem modelado? Nesse caso, se entendi direito, o que chamas de validação não tem de ser, em última instância, garantido pelo SGBD? Talvez tenhamos, aí, outra limitação tecnológica. O único sistema de desenvolvimento e execução de programas aplicativos realmente integrado ao SGBD e ao modelo relacional que conheço é o Alphora Dataphor — que, acho, infelizmente inda não foi portado nem para Mono, nem sequer para PostgreSQL —, e ele resolve essa questão exportando, automaticamente, as restrições de integridade da base para a interface, mesmo que cliente servidor; no caso, o cliente interpreta (ou compila, sei lá) o mesmo código D (D4) que a base, e é atualizado automaticamente quando a base muda. > Vamos então nomear melhor os bois: a regra tem que estar no SGBD sim, > ok. Restrições, regras e etc. Mas o processamento das informações > _antes_ de chegar no SGBD, isso não deveria estar com ele. E, neste > caso, está. Perfeito. > O agora Microsoft Skype tem um excelente caso de sucesso justamente > separando tudo: chamada remota de função com o plproxy é um sucesso. Sim, mas é um caso bem específico, de quase perversão da base para escalabilidade extrema. > E, juro, mandei estudo disso para o cliente. Era só modificar 70 > funções em pl/pgsql e a aplicação toda, mas ia ficar "da hora". O > custo foi proibitivo e ameaçaram trocar pelo RAC se fossem gastar a > grana toda :P De fato, uma das vantagens teóricas do modelo relacional que perdemos por causa das limitações do SQL, entre outros fatores, é não precisar alterar a aplicação por mudança no modelo físico… >> Pois é, mas se considerarmos que todas as regras de negócios devem ser >> implementadas como restrições, de preferência declarativas, fica >> contraditório >> ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não >> alcancei? > > Como falei acima, tô contigo na questão regra de negócio. O problema é > o processamento do negócio. IMHO, deve estar fora do SGBD. Pode me esclarecer o que consideras ‘processamento do negócio’ em contraposição a ‘regra de negócio’? Talvez eu não tenha entendido direito. > PostgreSQL é a melhor implementação da ISO, reconhecido e utilizado > academicamente por isso. Concordo, só não lembro se já passamos a conformidade do DB2 — que obviamente não serve para a Academia. > E olha que a comunidade não tem dinheiro pra ficar comprando norma. :-) > Aliás, norma, do jeito como é no nosso mundo, na minha opinião, é só > um jeito de ganhar dinheiro com patent war. Concordo — gênero, número & grau. E caso. Não contigo, com a gramática. > Existem sim. Os integrantes dessas equipes se chamam nerds. E eles > estão em alta no mercado de trabalho e até na vida afetiva. Não posso reclamar no afetivo, mas no mercado de trabalho acho que não fui /nerd/ suficiente, virei burocrata. > Claro que tem que ter um balanço: nerdice versus praticidade. > Não acho que o mundo deva ser 100% nerd pra fazer as coisas em TI. > Ninguém ganharia dinheiro. Eu proponho um balanço: bem feito na > medida, tem que ser bem feito mas tem que ser prático ou não vai pra > frente. Creio que, se todos fizessem bem feito, haveria inda mais dinheiro, que a demanda reprimida nunca cessa de crescer. > Vou te contar algo que vai te deixar bem chateado. A maioria das > aplicações Java EE usando Hibernate, normalmente, são independentes de > SGBD. Tendo o driver JDBC correto, elas falam o "dialeto" adequado. Eu sei, mas a que custo? Esse é o ponto. É sempre o uso dum mínimo denominador comum, por ex
Re: [pgbr-geral] Sugestão de uso
Em 29/6/2011 14:06, Shander Lyrio escreveu: > Em 29/06/2011 12:54, Fabiano Machado Dias escreveu: >> Sim, temos uma PL que controla os comandos DML, ou seja, a interface >> passa os campos e ela se encarrega do resto. > Sério? Sim, desenvolvemos o nosso próprio framework rsrs! Ela não faz só isso, além de escrever e controlar os comandos tem mais coisas que são controladas pela PL manutenção! >> Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem >> perder a performance que tínhamos em outra linguagem, performance de >> telas, acesso rápido via cursores etc. > Você está dizendo que colocar tudo no PostGreSql tornou suas telas mais > rápidas?? O que uma coisa tem haver com a outra? Não o fato de colocar tudo no "PostgreSQL" e sim o fato de usar cursores, offset, sequencias temporárias etc... Desculpe se não fui claro! >> Tudo deveria ter controle relacional, colocamos todas as restrições no >> banco e começamos a desenvolver as PLs básicas. > O que tem haver "controle relacional" com "lógica de negócio em > procedures para tudo" dentro do banco de dados? Conheço vários ERPs onde as restrições ficam na interface! Já vi bancos onde não existia uma constraint sequer, outros que só tinham 2 tipos de dados!!! O fato de você organizar as transações dentro de uma PLs é o mesmo exemplo já citado. Ao invés de eu ter um código de baixa de estoque em alguma tela, ou procedure em alguma camada intermediária eu tenho uma PL que faz isso! É um conjunto de soluções e não apenas o uso de PLs, tentei passar uma idéia geral de como fizemos o desenvolvimento. >> Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de >> dados não era no banco, vi vários problemas de transação ocorrendo, sem > Como assim a camada de dados não era o banco? Usava o PostGreSql para > que então? Era um sistema em 3 camadas, me referi mal, quis dizer que a camada de negócio não era no banco, existiam PLs que faziam alguns processos, mas a grande maioria era resolvida na camada intermediária e só gravava no banco. >> contar os problemas com gatilhos e a lentidão, então resolvemos que os >> processos seriam implementados totalmente dentro das PLs. > Resolveram assim do nada, sem tentar descobrir o real problema? Sim, descobrimos o problema, mas o sistema não era nosso e quando vimos o que o uso de gatilhos poderia causar tomamos a decisão e fazer diferente no nosso sistema. O problema é quando um gatilho, dispara um gatilho que dispara outro E as vezes lá no quinto nível aquele quinto gatilho dispara o primeiro!!! Daí você tem além um baita problema uma produção parada! >> O que queríamos era: >> >> 1 - Segurança nas transações, > Isso não tem nada haver com tudo feito por PL's dentro do banco de > dados. O Postgresql te garante isto de forma totalmente independente de > pl's; Sim, mas definimos que seria regra. >> 2 - Centralizar o desenvolvimento > Onde? no PostgreSql? Sim, nas PLs. >> 3 - Velocidade de desenvolvimento > Escrever PL's é mais rápido que escrever código em qualquer outra > linguagem?? Como fica o versionamento disso? Como são feitos testes > unitários? Existe diferença? PL/pgSql não é uma linguagem? Talvez você sinta falta de uma IDE, é isso? Temos uma IDE pra interface, Windev conhece? No mais uso o bom e velho pgadmin! As versões são controladas por um software que nós mesmos desenvolvemos, eu sou um dos responsáveis pelos testes de versão. >> 4 - Acesso rápido aos dados pelo cliente > Onde PL's ajudam nisto a não ser em casos muito especiais já citados > nesta thread diversas vezes? Já citei um exemplo acima, sem contar a facilidade de poder alterar o comportamento do sistema sem ter que interferir no desenvolvimento com as PLs customizadas que a PL manutenção procura! Vide palestra. >> Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a >> tão falada chave artificial para as PKs e fizemos as restrições devidas >> nas chaves naturais (UKs), assim conseguimos resolver os problemas do >> modelo físico e do lógico, claro que eles se misturam (não chegam ao >> usuário mas ao programador sim), mas pra nós não é problema, aliás nunca >> foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha >> resposta a pergunta do colega!) > Mas não respondeu, aliás, estou muito mais confuso agora. O que tem > haver a modelagem com o uso extensivo de PL's? Será que o problema > inicial já não era a modelagem e você está achando que seus ganhos foram > com o excesso de PL's mas na verdade foi com a mudança radical da modelagem? Não, foi um conjunto de fatores, não existe mágica né! A modelagem ajudou a simplificar o desenvolvimento das PLs, as duas coisas andam juntas. De nada me adianta ter uma modelagem boa e um framework lento e cheio de bugs! >> Depois de trabalhar com tabelas em que a PK era composta por 16 campos e > Acredito firmemente que você está confundindo
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 do>Criador? sem ironia. Entrando no 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 com arquitetura 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 feitos com a filosofia de tudo no servidor de aplicação onde grandes 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 ou>três profiças muito mais inteligentes, experientes e bem informados que eu ?>portabilidade total, dado que o SQL não é relacional e é muito mal>implementado no mundo extraelefantíaco, é um mito, cuja busca tipicamente>resulta em sistemas que nem são portáveis, nem corretos, nem manteníveis (eita>palavriña orroroza, alguém tem alguma melhor?), nem escaláveis, nem sequer>portá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é servir para 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), mas quem 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 saiu o 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 codificado de novo de qualquer forma. Abs,Leandro Henrique Pereira Neto Administração de bancos de dados - Serpro - "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] Avaliando a ordem de colunas em índices compostos
Em 29 de junho de 2011 12:27, Leandro DUTRA escreveu: > 2011/6/28 Dickson S. Guedes : >> Em tempo, tive bons contatos com ActiveRecord do Rails [2] > > Acho que és o primeiro DBA são que conheço que diz isso! :-) "bons contatos" ali não foi no sentido de benéficos, inesquecíveis ou fantásticos, nem foram do ponto de vista de um /DBA/, e sim no sentido de /alguem que leu e testou muitos codigos do ActiveRecord para compreender como ele funciona, para então pode auxiliar um ex-aluno em um projeto de TCC/ ... >> as técnicas que vi no mesmo mostram um amadurecimento cada vez maior e um >> uso mais efetivo do mesmo junto com o banco de dados. > > Bom, era tão ruim que só podia melhorar mesmo… piorar era praticamente > impossível, embora num mundo que tem o Hibernate fica difícil imaginar o que > seria o fundo do poço… não, me recuso a lembrar do Clipper… A questão na época era como melhorar a performance de duas aplicações em uso, sem tirar o HIbernate, tão pouco o ActiveRecord (do Rails). >> Claro que existem certas convenções do AR que não são tão bem vistas, como >> as SKs [3] por exemplo, mas para determinadas aplicações isso não é o fim do >> mundo em si. > > Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso > já discutimos tanto, aqui e alhures… deixa quieto. Bom eu disse ali "determinadas aplicações" e nao "todas as aplicações do mundo". O caso em questão na época era assim, todos os problemas foram aprensentados com os seus devidos prós e contras de todos e baseado nisso uma decisão em conjunto foi tomada pelos responsáveis. Não sei como está hoje, mas até alguns meses atrás a aplicação estava lá, funcionando internamente e conforme o que desejavam. []s -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ 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
Em 29/06/2011 12:54, Fabiano Machado Dias escreveu: > Sim, temos uma PL que controla os comandos DML, ou seja, a interface > passa os campos e ela se encarrega do resto. Sério? > Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem > perder a performance que tínhamos em outra linguagem, performance de > telas, acesso rápido via cursores etc. Você está dizendo que colocar tudo no PostGreSql tornou suas telas mais rápidas?? O que uma coisa tem haver com a outra? > Tudo deveria ter controle relacional, colocamos todas as restrições no > banco e começamos a desenvolver as PLs básicas. O que tem haver "controle relacional" com "lógica de negócio em procedures para tudo" dentro do banco de dados? > Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de > dados não era no banco, vi vários problemas de transação ocorrendo, sem Como assim a camada de dados não era o banco? Usava o PostGreSql para que então? > contar os problemas com gatilhos e a lentidão, então resolvemos que os > processos seriam implementados totalmente dentro das PLs. Resolveram assim do nada, sem tentar descobrir o real problema? > O que queríamos era: > > 1 - Segurança nas transações, Isso não tem nada haver com tudo feito por PL's dentro do banco de dados. O Postgresql te garante isto de forma totalmente independente de pl's; > 2 - Centralizar o desenvolvimento Onde? no PostgreSql? > 3 - Velocidade de desenvolvimento Escrever PL's é mais rápido que escrever código em qualquer outra linguagem?? Como fica o versionamento disso? Como são feitos testes unitários? > 4 - Acesso rápido aos dados pelo cliente Onde PL's ajudam nisto a não ser em casos muito especiais já citados nesta thread diversas vezes? > Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a > tão falada chave artificial para as PKs e fizemos as restrições devidas > nas chaves naturais (UKs), assim conseguimos resolver os problemas do > modelo físico e do lógico, claro que eles se misturam (não chegam ao > usuário mas ao programador sim), mas pra nós não é problema, aliás nunca > foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha > resposta a pergunta do colega!) Mas não respondeu, aliás, estou muito mais confuso agora. O que tem haver a modelagem com o uso extensivo de PL's? Será que o problema inicial já não era a modelagem e você está achando que seus ganhos foram com o excesso de PL's mas na verdade foi com a mudança radical da modelagem? > Depois de trabalhar com tabelas em que a PK era composta por 16 campos e Acredito firmemente que você está confundindo uma restrição unique com PK. Acho que é limitação do meu cérebro mas não consigo sequer imaginar uma entidade que precise de 16 campos para indicar sua unicidade. Acredito agora, ainda mais firmemente, que seu problema era de modelagem e não regras de negócio dentro ou fora do banco de dados. > tinha que juntar mais mais outras 20 tabelas, abolimos as PKs > compostas, isso me deu um ganho de performance bom e uma escrita rápida > também, a criação de índices também ficou fácil. Aboliu pk composta que não deveria ser pk composta. Mas uma vez acho que seu ganho foi a mudança de modelagem e nada teve haver com "toda" a lógica de negócios dentro do PostgreSql. > PLs que controlam a auditoria de outras PLs etc. Tem também um sistema difícil de se testar, difícil de versionar, difícil de encontrar gargalos de performance. Mas isto certamente funciona para sistema com pouco volume de dados. > Fizemos um uso muito restrito de gatilhos, dá pra contar nos dedos > quantos tem no sistema, afinal tenho o controle do que acontece nas PLs! Qual controle diferente tem em procedures que não poderia ter nos gatilhos. Os gatilhos nada mais são do que o chamado a procedures. > Bom, poderia te dar vários exemplos, dá uma olhada na palestra do pgcon > de 2009, lá tem casos mais específicos do que fizemos. Eu dei, inclusive diversas críticas técnicas ao que foi exposto e a resposta foi algo como "está rodando no cliente com faturamento de 5 milhões mensais" sem nenhuma explicação técnica que justificasse a escolha. O fato de estar rodando em um cliente deste porte não indica que esta é uma boa opção. No máximo, que vocês estão conseguindo manter o cliente feliz ou que ele ficou tão preso que não consegue mais mudar e eu não pretendo entrar no mérito desta questão. Se você não tem explicação técnica para esta decisão, para mim ela não vale como boa solução. > Posso te dizer que hoje coloco a cabeça no travesseiro e durmo > tranqüilo! rsrsrs Eu também faço isto sem precisar colocar tudo em procedures. > Nunca mais me preocupei com corrupções, dados inconsistentes, banco > travando etc!!! A sua falta de preocupação, dentro do que li foi pela correção do modelo de dados e não por coloc
Re: [pgbr-geral] Sugestão de uso
Esta thread está ficando agradavelmente construtiva! >> Meus dois centavos nesta discussão vão na direção contrária. > > Vou discordar, correndo o risco de parecer ridículo — afinal, tu representas > *o* caso de PostgreSQL do milênio… E olha que, neste caso, nem estou falando d*o* case do milênio :) Nele o banco de dados é praticamente um "saco de dados". > Claro que não tenho como questionar, não tenho informações suficientes nem, no > momento, quero ter… mas essa é uma questão interessante. Regras de negócio > causando uso total de processadores no servidor de bases de dados, na minha > experiência e na lógica que chego a alcançar, costuma indicar problemas de > codificação, principalmente por uso de modelos de programação descasados com o > modelo relacional, como o navigacional e o POG: respectivamente, tipicamente > representados pelos clipeiros e pelo Hibernate, claro que nem de longe > exclusiva, embora talvez majoritariamente. Esse sistema que estou falando foi feito em C, tudo CGI, não tem ORM e praticamente funciona assim: Aplicação em C: oi usuário, o que você quer fazer agora? Usuário: quero cadastrar uma pessoa. Aplicação em C: taqui o formulário pra você preencher. É só clicar o botão Ok no final, tá? Usuário preenche os dados e clica no Ok. Aplicação: ok usuário! vou mandar seus dados pro SGBD. Aplicação: SGBD, por favor, aqui estão os dados do cadastro: "SELECT cadastra_formulario(dados, dados, dados, dados, muitos dados,...);" E o SGBD: Cata os dados, valida input, trata strings, verifica consistência em todas as tabelas relacionadas, insere cada pedaço do formulário em 10 tabelas diferentes, atualiza a tabela de histórico, computa sequências, atualiza índices, checa as restrições locais e estrangeiras e "comita tudo. SGBD: Aplicação, "COMMIT". Aplicação: Obrigado SGBD. Usuário, Ok! Usuário esquece a tela aberta, ainda por cima. Agora imagina que: - o modelo de dados é bem elaborado, acadêmico _mesmo_; - usa-se pl/pgsql puro, sem outros wrappers para outras linguagens; - os índices são extremamente enxutos e _todos_ foram verificados junto às consultas. Aí a aplicação, tadinha, ela sofre tanto... deram três servidores parrudos só pra ela. O SGBD, ah, esse desgraçado! Tá comendo uma máquina inteira sozinho, humpf! Agora no duro: se a parte toda de validação de input e tratamento de strings fosse na aplicação, a aplicação abrisse uma transação com o banco e resolvesse sua vida, o processamento de cada passo no pl/pgsql poderia muito bem ser dela, distribuindo bem melhor a carga entre seus três servidores. > Claro que, muitas vezes, o pobre do DBA, que deveria receber adicional > de insalubridade por ser, na prática, gari de curva de rio, não tem como > garantir nem o modelo, nem a qualidade da programação. Mas creio que vale a Olha, neste caso eu tive acesso a tudo. Cada tabela, índice e procedure. Tudo muito bem escrito, juro, acadêmico. > pena mencionar para que não fique parecendo que a ‘culpa’ é da garantia das > regras de negócio no SGBD. Isso deveria ser um requisito conceitual absoluto, > embora nem sempre o SQL facilite e quase nunca a organização tenha competência > (ou as famosas ‘condições objetivas’) para alcançar. Vamos então nomear melhor os bois: a regra tem que estar no SGBD sim, ok. Restrições, regras e etc. Mas o processamento das informações _antes_ de chegar no SGBD, isso não deveria estar com ele. E, neste caso, está. >> Quando é necessário aumentar a escala de atendimento, é necessário colocar >> máquina mais poderosa. > > Hm, quando armazenamento de massa em memória /flash/ se tornar mais lugar > comum, conquistar nossa confiança, for bem aproveitada por nossos sistemas de > arquivos… quem sabe consigamos implementar os conceitos do saudoso (em parte) > /mainframe/, como as hierarquias de memórias e armazenamento. Note que o gargalo nesta aplicação que estou citando *não* é disco. O throughput nem é tão alto assim, a quantidade de WAL que é gerada lá é menos da metade do que o tal "case do milênio", tá tudo monitorado e o storage tá... coçando. Consegui bom ganho limitando bem o uso de conexões ao PostgreSQL com um pool usando o pgbouncer muito bem configurado. >> Se a regra de negócio estivesse na camada de aplicação, seria possível >> dividir dados usando alguma técnica de sharding com mais facilidade e >> menos alterações em código. > > Sim, com a tecnologia atual, sim. Pelo pouco que entendo do SQL‐MED, nem ele > chega a implementar de verdade um SGBDDistribuídas. Idealmente, poderíamos > programar, digamos, em SQL/PSM ou PL/Scheme ou o que bem entendêssemos, e > deslocar o código transparentemente entre servidores. Mesmo assim, a minha > expectativa seria de que, freqüentemente, descobriríamos que as regras de > negócio teriam melhor desempenho junto da base, por evitarem latências > decorrentes de mudanças de contexto, transferências de dados pela rede &c. O agora Microsoft Skype tem um excelente caso de sucesso justamente separa
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
Em 29 de junho de 2011 08:42, Leonardo Cezar escreveu: > 2011/6/28 Dickson S. Guedes : >> Em 28 de junho de 2011 22:52, Leandro DUTRA >> escreveu: >> [... corte ...] >>> A grande exceção era aquele de Python, como se chamava? SQL alguma >>> coisa ou algo SQL, mas até aí morreu o neves. >> >> Você está falando da fadinha [1] Dutra? Parece que ela(e) morreu mesmo. > > Não. Acho que ele está se referindo ao SQL Alchemy[1] que é um > framework ORM para Python, enquanto que SQL Fairy é desenvolvido em > Perl e funciona como uma espécie de ETL e AFAIK ele *não* está "morto" > – ou não entendi a piada. Acho que li uma coisa e entendi outra. Lendo novamente a thread percebi isso. -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ 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
2011/6/29 Fabiano Machado Dias : > Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a > tão falada chave artificial para as PKs e fizemos as restrições devidas > nas chaves naturais (UKs), assim conseguimos resolver os problemas do > modelo físico e do lógico, claro que eles se misturam (não chegam ao > usuário mas ao programador sim), mas pra nós não é problema, aliás nunca > foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha > resposta a pergunta do colega!) > > Depois de trabalhar com tabelas em que a PK era composta por 16 campos e > tinha que juntar mais mais outras 20 tabelas, abolimos as PKs > compostas, isso me deu um ganho de performance bom e uma escrita rápida > também, a criação de índices também ficou fácil. Esse é o plano B, melhor que as outras alternativas. O plano A, claro, seria usar chaves artificiais somente onde necessário, tipicamente mantendo as chaves compostas, onde não implicassem em perda de desempenho, como primárias. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
Em 29/6/2011 11:56, Shander Lyrio escreveu: > Em 29/06/2011 00:30, Fabiano Machado Dias escreveu: >> Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente >> piloto posso te dizer ficou acima do esperado. > Da mesma forma que o colega que postou a pergunta sugeriu? Tudo via > plpgsql?? Até mesmo as funções de insert, delete e update?? Eu também > faço uso de plpgsql direto, mas não tudo! > > O que você esperava com isto e oque ficou melhor? > > -- Sim, temos uma PL que controla os comandos DML, ou seja, a interface passa os campos e ela se encarrega do resto. Nós tínhamos um projeto audacioso pela frente, construir um software de gestão em menos de 2 anos, a contabilidade seria online (não existe exportação e geração, faz na hora!) e já atendendo as obrigatoriedades do governo. (NFE, SPED, e-Lalur, Ato Cotepe etc), fora os módulos principais do sistema. Queríamos automatizar as tarefas rotineiras do desenvolvimento mas sem perder a performance que tínhamos em outra linguagem, performance de telas, acesso rápido via cursores etc. Tudo deveria ter controle relacional, colocamos todas as restrições no banco e começamos a desenvolver as PLs básicas. Nós estávamos saindo de um projeto que usava PostgreSQL mas a camada de dados não era no banco, vi vários problemas de transação ocorrendo, sem contar os problemas com gatilhos e a lentidão, então resolvemos que os processos seriam implementados totalmente dentro das PLs. O que queríamos era: 1 - Segurança nas transações, 2 - Centralizar o desenvolvimento 3 - Velocidade de desenvolvimento 4 - Acesso rápido aos dados pelo cliente Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a tão falada chave artificial para as PKs e fizemos as restrições devidas nas chaves naturais (UKs), assim conseguimos resolver os problemas do modelo físico e do lógico, claro que eles se misturam (não chegam ao usuário mas ao programador sim), mas pra nós não é problema, aliás nunca foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha resposta a pergunta do colega!) Depois de trabalhar com tabelas em que a PK era composta por 16 campos e tinha que juntar mais mais outras 20 tabelas, abolimos as PKs compostas, isso me deu um ganho de performance bom e uma escrita rápida também, a criação de índices também ficou fácil. Também criamos uma estrutura de controle para separar as Filiais e usamos bastante array em conjunto a interface. Hoje tenho PLs que se modificam conforme a parametrização do sistema e que interagem com PLs que podem ser customizadas para atender uma determinada situação. PLs que controlam a auditoria de outras PLs etc. Fizemos um uso muito restrito de gatilhos, dá pra contar nos dedos quantos tem no sistema, afinal tenho o controle do que acontece nas PLs! Bom, poderia te dar vários exemplos, dá uma olhada na palestra do pgcon de 2009, lá tem casos mais específicos do que fizemos. Posso te dizer que hoje coloco a cabeça no travesseiro e durmo tranqüilo! rsrsrs Nunca mais me preocupei com corrupções, dados inconsistentes, banco travando etc!!! Estarei no PGBR esse ano, se alguém quiser ver isso funcionando de perto posso mostrar sem problemas. Um grande abraço! Fabiano Machado Dias > Shander Lyrio > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
2011/6/29 emerson lopes : > > Obrigado pelo apoio. Problema resolvido ! Killer elephants! -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
Em 29-06-2011 11:52, Leandro DUTRA escreveu: > Pelo pouco que entendo do SQL‐MED, nem ele > chega a implementar de verdade um SGBDDistribuídas. > O conceito de SGBD Distribuído é amplo; o SQL/MED alcança somente algumas de suas características. O que o SQL/MED propõe é a distribuição e acesso transparente de dados externos utilizando SQL. Por dados externos, entende-se que sejam dados que possam ser acessados pelo SGBD mas cujo gerenciamento é feito fora do SGBD (pode ser desde dados crus ou mesmo outros SGBDs). Então, o ponto chave é *transparência*, ou seja, não há necessidade de alteração na aplicação somente na arquitetura de banco de dados. Por exemplo, se a aplicação referencia uma tabela foo, não interessa se esta tabela está no SGBD que a aplicação acessa diretamente ou em outro gerenciador de banco de dados; o importante, é que os dados estejam acessíveis a aplicação. -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
2011/6/28 Dickson S. Guedes : > > Você está falando da fadinha [1] Dutra? Parece que ela(e) morreu mesmo. SQL Alchemy, na verdade. O SQL Fairy (sql::fairy para os íntimos) não morreu, que eu saiba, embora precise dum trato, sem dúvida — de qualquer maneira, o Fairy, creio, nada tem a ver com mapeamento objeto‐SQL (continuo objetando fortemente ao nome ORM). Me lembro duma ou outra tentativa de jogar para outros ambientes os conceitos do SQL Alchemy, mas não lembro quais eram nem no que deram. Acho que o grande senhor doutor Diogo Biazus me falara que o Ruby on Rails teria um mapeamento mais são na versão três, não lembro se tão bom quanto o SQL Alchemy. > Em tempo, tive bons contatos com ActiveRecord do Rails [2] Acho que és o primeiro DBA são que conheço que diz isso! :-) > as técnicas que vi no mesmo mostram um amadurecimento cada vez maior e um > uso mais efetivo do mesmo junto com o banco de dados. Bom, era tão ruim que só podia melhorar mesmo… piorar era praticamente impossível, embora num mundo que tem o Hibernate fica difícil imaginar o que seria o fundo do poço… não, me recuso a lembrar do Clipper… > Eagers e Lazys Joins quando bem utilizados realmente mudam consideravelmente > a performance. É, preciso voltar a ler e estudar. Boiei, confesso. > Claro que existem certas convenções do AR que não são tão bem vistas, como > as SKs [3] por exemplo, mas para determinadas aplicações isso não é o fim do > mundo em si. Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso já discutimos tanto, aqui e alhures… deixa quieto. > A questão em si é que quando mais você entende as ferramentas que usa, > melhor proveito você pode tirar delas. E, IMHO, o marketing feito > sobre certas 'facilidades' dos ORMs é que leva a muitos > desenvolvedores acharem que podem esquecer de tudo pois o ORM cuidará > disso pra você. Minha pergunta é só quando podemos declarar o início da IdT II (segunda Idade das Trevas), e quanto tempo durará… minha esperança é que comece ainda daqui a algumas gerações, e demore menos que o milênio que a IdT I durou. Ou que a Segunda Vinda seja antes. > [1] http://sqlfairy.sourceforge.net/ > [2] http://guides.rubyonrails.org/active_record_querying.html > [3] http://en.wikipedia.org/wiki/Surrogate_key -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Erro pg_class_oid_index
Senhores, Obrigado pelo apoio. Problema resolvido ! []'s Em 29 de junho de 2011 11:35, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > > Parece-me que alguns índices do catálogo estão corrompidos. Qual a versão > do > > PostgreSQL? Foi queda de energia ou desligamento abrupto? > > > > Tente algo assim: > > > > $ pg_ctl stop -D /path/to/pgdata > > $ postgres --single -P -D /path/to/data mydb > > > > PostgreSQL stand-alone backend 9.2devel > > backend> reindex system mydb; > > backend>^D > > $ pg_ctl start -D /path/to/pgdata > > Grande professor Euler! Eu juro que não me liguei que o erro era em > catálogo de sistema :( > Pelo menos fica mais fácil fazer um dump dos dados (se estiverem ok) e > restaurar num servidor bom caso o conserto via monousuário não > resolva. > > []s > Flavio > ___ > 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] Sugestão de uso
Em 29/06/2011 00:30, Fabiano Machado Dias escreveu: > Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente > piloto posso te dizer ficou acima do esperado. Da mesma forma que o colega que postou a pergunta sugeriu? Tudo via plpgsql?? Até mesmo as funções de insert, delete e update?? Eu também faço uso de plpgsql direto, mas não tudo! O que você esperava com isto e oque ficou melhor? -- Shander Lyrio ___ 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
2011/6/29 Flavio Henrique Araque Gurgel : > > Meus dois centavos nesta discussão vão na direção contrária. Vou discordar, correndo o risco de parecer ridículo — afinal, tu representas *o* caso de PostgreSQL do milênio… > - A idéia é péssima no sentido contrário: a aplicação tem centenas de > milhares de usuários e funciona em escala nacional. Como toda a regra > de negócio está no banco, o consumo de CPU é altíssimo, batendo em > 100% em máquinas bastante parrudas. Claro que não tenho como questionar, não tenho informações suficientes nem, no momento, quero ter… mas essa é uma questão interessante. Regras de negócio causando uso total de processadores no servidor de bases de dados, na minha experiência e na lógica que chego a alcançar, costuma indicar problemas de codificação, principalmente por uso de modelos de programação descasados com o modelo relacional, como o navigacional e o POG: respectivamente, tipicamente representados pelos clipeiros e pelo Hibernate, claro que nem de longe exclusiva, embora talvez majoritariamente. A outra grande causa de uso exagerado de recursos computacionais pelas regras de negócio costuma ser má modelagem, de novo por falta de entendimento do modelo relacional. Por exemplo, a famigerada ‘desnormalização’, o uso indiscriminado de chaves artificiais, a falta de uso dos tipos definidos por usuário (tipos ‘abstratos’ de dados) &c. Claro que, muitas vezes, o pobre do DBA, que deveria receber adicional de insalubridade por ser, na prática, gari de curva de rio, não tem como garantir nem o modelo, nem a qualidade da programação. Mas creio que vale a pena mencionar para que não fique parecendo que a ‘culpa’ é da garantia das regras de negócio no SGBD. Isso deveria ser um requisito conceitual absoluto, embora nem sempre o SQL facilite e quase nunca a organização tenha competência (ou as famosas ‘condições objetivas’) para alcançar. > Quando é necessário aumentar a escala de atendimento, é necessário colocar > máquina mais poderosa. Hm, quando armazenamento de massa em memória /flash/ se tornar mais lugar comum, conquistar nossa confiança, for bem aproveitada por nossos sistemas de arquivos… quem sabe consigamos implementar os conceitos do saudoso (em parte) /mainframe/, como as hierarquias de memórias e armazenamento. > Isso depois de muito tuning e uso de PostgreSQL 9 onde a parte de BI e > relatórios com consultas mais complicadas são feitas em servidor > hot-standby. Até aí, seguindo as regras, né? Morreu o Neves, quem faz diferente é quem tem de se explicar… > Para escalar horizontalmente esse ambiente, só há uma forma: modificar > toda a estrutura do banco quando estiver disponível totalmente a > implementação de SQL-MED, pra poder fazer com mais facilidade o uso de > dados remotos e separar fisicamente tabelas por regiões ou estados. Experiência com Oracle em telecom (operadoras de telefonia fixa & celular): mesmo uma implementação meia‐boca e mal compreendida, como é a da Oracle, pode trazer grandes ganhos. No caso, tínhamos as tabelas ditas ‘de referência’ em pequenos servidores localizados juntos a setores administrativos, de atendimento ao usuário &c, que salvavam a pele dos programas aplicativos cliente‐servidor. Está certo que eu, particularmente, não ‘acredito’ nem em cliente‐servidor nem em nenhum papai‐noel da vida, mas às vezes tem‐se de fazer malabarismo para impedir que o estrume alcance o proverbial ventilador… > Se a regra de negócio estivesse na camada de aplicação, seria possível > dividir dados usando alguma técnica de sharding com mais facilidade e > menos alterações em código. Sim, com a tecnologia atual, sim. Pelo pouco que entendo do SQL‐MED, nem ele chega a implementar de verdade um SGBDDistribuídas. Idealmente, poderíamos programar, digamos, em SQL/PSM ou PL/Scheme ou o que bem entendêssemos, e deslocar o código transparentemente entre servidores. Mesmo assim, a minha expectativa seria de que, freqüentemente, descobriríamos que as regras de negócio teriam melhor desempenho junto da base, por evitarem latências decorrentes de mudanças de contexto, transferências de dados pela rede &c. > Minha dica para novos sistemas é sempre assim: > - regra de negócio sempre numa camada fora do banco de dados; > - llinguagens procedurais devem e podem ser utilizadas, mas de forma > restrita para as funcionalidades de banco de dados (ex.: > particionamento, regras para suprir restrições, validação de dados não > possíveis por restrições, etc); Pois é, mas se considerarmos que todas as regras de negócios devem ser implementadas como restrições, de preferência declarativas, fica contraditório ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não alcancei? Sim, claro, o SQL não é relacional, isso impõe restrições e tudo o mais… mas o PostgreSQL, particularmente, é suficientemente próximo do ISO SQL:2008, e até do modelo relacional, para o desenvolvimento de um novo sistema aplicativo por uma equip
Re: [pgbr-geral] Erro pg_class_oid_index
> Parece-me que alguns índices do catálogo estão corrompidos. Qual a versão do > PostgreSQL? Foi queda de energia ou desligamento abrupto? > > Tente algo assim: > > $ pg_ctl stop -D /path/to/pgdata > $ postgres --single -P -D /path/to/data mydb > > PostgreSQL stand-alone backend 9.2devel > backend> reindex system mydb; > backend>^D > $ pg_ctl start -D /path/to/pgdata Grande professor Euler! Eu juro que não me liguei que o erro era em catálogo de sistema :( Pelo menos fica mais fácil fazer um dump dos dados (se estiverem ok) e restaurar num servidor bom caso o conserto via monousuário não resolva. []s Flavio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Em 29-06-2011 09:50, emerson lopes escreveu: > 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. > Parece-me que alguns índices do catálogo estão corrompidos. Qual a versão do PostgreSQL? Foi queda de energia ou desligamento abrupto? Tente algo assim: $ pg_ctl stop -D /path/to/pgdata $ postgres --single -P -D /path/to/data mydb PostgreSQL stand-alone backend 9.2devel backend> reindex system mydb; backend>^D $ pg_ctl start -D /path/to/pgdata -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
> Opa Fábio! > > Obrigado pela ajuda. Então, não estou conseguindo acessar o banco, ele > retorna a mensagem após pedir a senha no PSQL. No reindex tambem... E agora > ? hehe > > Att, Pelas mensagens no seu log seu banco de dados está com inconsistência, e o REINDEX está falhando porque encontrou dados duplicados na tabela. O índice parece corrompido também e por isso o REINDEX está sendo sugerido. Provavelmente você teve uma falha no servidor, falta de energia ou falha de hardware e: - fsync está em off no conf OU; - você está usando open_sync e usando um kernel Linux com bugs (atualize seu S.O. pra ter certeza, use um S.O. com suporte atual) OU; - a memória do seu servidor está com problemas (rode um memtest para ter certeza) OU; - seu sistema de arquivos está corrompido, ou seu HD está falhando (fsck pra ter certeza). O ideal no seu caso é restaurar um backup válido num servidor bom. Como o que está dando erros é um índice, pode ainda ser possível fazer um pg_dump caso você não tenha um backup e restaurar esse dump num PostgreSQL novo e limpo, num hardware bom e com configurações mais adequadas. Como o dump vai trazer dados duplicados porque a tabela parece estar assim, você terá de identificar o dado duplicado e removê-lo antes de recriar o índice. mas faça tudo isso num servidor reconhecidamente bom. Cheque o que eu disse aí em cima (memória, discos, S.O., sistema de arquivos, configuração de fsync e fsync method) e retorne pra gente se precisar de mais ajuda. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Desce o serviço do postgres e sobe novamente. - O serviço está no ar? - Os processos do postgres estão no ar? - O que diz o log? - Se está no ar, aí então tenta o reindexdb. Se não então você tem de subir o postgres na mão com o -P, vide: http://www.postgresql.org/docs/8.3/static/app-postgres.html Veja, você não me respondeu se alguém andou tentando um REINDEX antes... Mande os logs. []s Em 29 de junho de 2011 09:35, emerson lopes escreveu: > Opa Bruno! > > Esse banco em específico é 8.3 e o PGADMIN é 1.8.4. > > Realmente não sei como refazer o índice! Se puder me ajudar, fico grato, > > Emerson > > escreveu: >> >> > Senhores, >> > >> > Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma >> > luz >> > ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? >> > >> > >> > index "pg_class_oid_index" contains unexpected zero page at block 0 >> > >> > >> > Obrigado, >> > >> > Emerson Lopes >> >> ___ >> 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 > > -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ 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
>> Boa noite a todos, >> >> Estou chegando agora na discussão, mas posso falar sobre o tema, afinal >> criamos um ERP desta maneira, quem quiser pode conferir nos links abaixo. >> >> O que posso dizer é que no nosso caso foi a escolha mais certa que já >> fizemos, você precisa ter muito cuidado com a documentação, >> principalmente se o número de desenvolvedores for grande. >> >> Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente >> piloto posso te dizer ficou acima do esperado. >> >> Até hoje não tive problema de performance, o desenvolvimento é >> extremamente rápido, sem falar na questão da segurança e confiança nas >> transações! >> >> Na época lembro que muita gente falava que era loucura fazer desse >> jeito, e pelo que vi tem vários colegas da lista que pensam assim, o que >> posso dizer é que gostaria de ter enlouquecido bem antes, na época que >> segui o tal modelo 3 camadas e queria que minha aplicação fosse multi >> banco! >> >> Bom é só a minha humilde opinião, se precisar de alguma dica fique a >> vontade para perguntar, apesar do foco do seu sistema ser diferente acho >> que é a mesma idéia! > > Eu concordo. Mas tudo é uma questão de escala. > Utilizar funções para calcular em lote a folha de pagamento de 10 mil > funcionários é uma benção. Utilizar funções para todo e qualquer > processamento num ERP com centenas de transações ATIVAS, pode ser uma dor de > cabeça. > Veja que isso já foi pior em versões anteriores do Postgres, hoje já é > possível ajustar melhor a performance de funções e rastrear as estatísticas > destas, mas ainda dá mais trabalho. Queria saber a opinião de quem usa > pl/proxy em relação a isso, uma vez que você tem de encapsular tudo em > funções... > +2 cents. Meus dois centavos nesta discussão vão na direção contrária. Suporto um sistema *lotado* de pl/pgsql com praticamente todas as regras de negócio dentro do banco de dados. - A idéia é ótima no seguinte sentido: tudo o que está fora do banco é só apresentação. - A idéia é péssima no sentido contrário: a aplicação tem centenas de milhares de usuários e funciona em escala nacional. Como toda a regra de negócio está no banco, o consumo de CPU é altíssimo, batendo em 100% em máquinas bastante parrudas. Quando é necessário aumentar a escala de atendimento, é necessário colocar máquina mais poderosa. Isso depois de muito tuning e uso de PostgreSQL 9 onde a parte de BI e relatórios com consultas mais complicadas são feitas em servidor hot-standby. Para escalar horizontalmente esse ambiente, só há uma forma: modificar toda a estrutura do banco quando estiver disponível totalmente a implementação de SQL-MED, pra poder fazer com mais facilidade o uso de dados remotos e separar fisicamente tabelas por regiões ou estados. Se a regra de negócio estivesse na camada de aplicação, seria possível dividir dados usando alguma técnica de sharding com mais facilidade e menos alterações em código. Minha dica para novos sistemas é sempre assim: - regra de negócio sempre numa camada fora do banco de dados; - llinguagens procedurais devem e podem ser utilizadas, mas de forma restrita para as funcionalidades de banco de dados (ex.: particionamento, regras para suprir restrições, validação de dados não possíveis por restrições, etc); - camada de apresentação separada da camada de aplicação. Assim suprem-se as técnicas MVC modernas e ganha-se em portabilidade (fica mais fácil migrar de SGBD ou misturar SGBDs) e escalabilidade (usar linguagem procedural para movimentar dados de forma independente da aplicação). []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Opa Fábio! Obrigado pela ajuda. Então, não estou conseguindo acessar o banco, ele retorna a mensagem após pedir a senha no PSQL. No reindex tambem... E agora ? hehe Att, Em 29 de junho de 2011 10:13, Fábio Telles Rodriguez escreveu: > Rode um: > reindexdb -s postgres > > E mandar os logs gerados neste período. Veja se as coisas se normalizam. > > Se o postgres cair antes de concluir o teste, você vai ter de subir o > postgres sem utilizar os índices do catálogo, com a opção -P. Aí > começa a complicar um pouco... > > Veja no log que houve uma queda abrupta por aí: > 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last > known up at 2011-06-29 03:48:17 BRT > 2011-06-29 03:50:05 BRT LOG: database system was not properly shut > down; automatic recovery in progress > > Por outro lado, parece que outra pessoa já andou tentando um REINDEX > por aí, não? Foi você mesmo? Outra pessoa já andou tentando algo? > > []s > > 2011/6/29 emerson lopes > > > > Segue abaixo: > > > > > > 2011-06-29 03:50:05 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:50:05 BRT FATAL: the database system is starting up > > 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last known > up at 2011-06-29 03:48:17 BRT > > 2011-06-29 03:50:05 BRT LOG: database system was not properly shut down; > automatic recovery in progress > > 2011-06-29 03:50:05 BRT LOG: record with zero length at B8/CB5C4708 > > 2011-06-29 03:50:05 BRT LOG: redo is not required > > 2011-06-29 03:50:06 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:50:06 BRT FATAL: the database system is starting up > > 2011-06-29 03:50:07 BRT LOG: database system is ready to accept > connections > > 2011-06-29 03:50:07 BRT LOG: autovacuum launcher started > > 2011-06-29 03:50:07 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 07:01:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains > unexpected zero page at block 0 > > 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. > > 2011-06-29 07:01:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > > 2011-06-29 07:01:56 BRT HINT: Please REINDEX it. > > 2011-06-29 07:02:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > > 2011-06-29 07:02:56 BRT HINT: Please REINDEX it. > > 2011-06-29 07:03:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > > 2011-06-29 07:03:56 BRT HINT: Please REINDEX it. > > 2011-06-29 07:04:20 BRT LOG: received fast shutdown request > > 2011-06-29 07:04:20 BRT LOG: aborting any active transactions > > 2011-06-29 07:04:20 BRT LOG: autovacuum launcher shutting down > > 2011-06-29 07:04:20 BRT LOG: shutting down > > 2011-06-29 07:04:20 BRT LOG: database system is shut down > > 2011-06-29 03:24:09 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:24:10 BRT FATAL: the database system is starting up > > 2011-06-29 03:24:10 BRT LOG: database system was interrupted; last known > up at 2011-06-28 18:56:43 BRT > > 2011-06-29 03:24:10 BRT LOG: database system was not properly shut down; > automatic recovery in progress > > 2011-06-29 03:24:10 BRT LOG: record with zero length at B8/C3409208 > > 2011-06-29 03:24:10 BRT LOG: redo is not required > > 2011-06-29 03:24:11 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:24:11 BRT FATAL: the database system is starting up > > 2011-06-29 03:24:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:24:12 BRT FATAL: the database system is starting up > > 2011-06-29 03:24:12 BRT LOG: database system is ready to accept > connections > > 2011-06-29 03:24:12 BRT LOG: autovacuum launcher started > > 2011-06-29 03:24:13 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:25:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:25:59 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > > 2011-06-29 0
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
1) Não acho que ORM seja ruim SEMPRE, se bem usado pode ajudar. 2) Entre Active Record e DAO+Geração de Código, fico com o segundo. Em 29 de junho de 2011 08:42, Leonardo Cezar escreveu: > 2011/6/28 Dickson S. Guedes : > > Em 28 de junho de 2011 22:52, Leandro DUTRA > > escreveu: > > [... corte ...] > >> A grande exceção era aquele de Python, como se chamava? SQL alguma > >> coisa ou algo SQL, mas até aí morreu o neves. > > > > Você está falando da fadinha [1] Dutra? Parece que ela(e) morreu mesmo. > > Não. Acho que ele está se referindo ao SQL Alchemy[1] que é um > framework ORM para Python, enquanto que SQL Fairy é desenvolvido em > Perl e funciona como uma espécie de ETL e AFAIK ele *não* está "morto" > – ou não entendi a piada. > > Embora o SQLAlchemy possua uma implementação mais elegante de Data > Mapper (conceitos de álgebra relacional) ele não deixa de ser uma > evolução do modelo Active Record[2] definido por Martin Fowller e > também por isso trás impactos na produção para o DBA. > > [1] http://www.sqlalchemy.org/ > [2] http://martinfowler.com/eaaCatalog/activeRecord.html > > > Em tempo, tive bons contatos com ActiveRecord do Rails [2], e as > > técnicas que vi no mesmo mostram um amadurecimento cada vez maior e um > > uso mais efetivo do mesmo junto com o banco de dados. Eagers e Lazys > > Joins quando bem utilizados realmente mudam consideravelmente a > > performance. Claro que existem certas convenções do AR que não são tão > > bem vistas, como as SKs [3] por exemplo, mas para determinadas > > aplicações isso não é o fim do mundo em si. > > A conclusão que chego é a seguinte: ORM é muito bom para desenvolvedor > e ruim em qualquer hipótese para DBAs. > > Abraço! > > -Leo > > -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Erro pg_class_oid_index
Rode um: reindexdb -s postgres E mandar os logs gerados neste período. Veja se as coisas se normalizam. Se o postgres cair antes de concluir o teste, você vai ter de subir o postgres sem utilizar os índices do catálogo, com a opção -P. Aí começa a complicar um pouco... Veja no log que houve uma queda abrupta por aí: 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last known up at 2011-06-29 03:48:17 BRT 2011-06-29 03:50:05 BRT LOG: database system was not properly shut down; automatic recovery in progress Por outro lado, parece que outra pessoa já andou tentando um REINDEX por aí, não? Foi você mesmo? Outra pessoa já andou tentando algo? []s 2011/6/29 emerson lopes > > Segue abaixo: > > > 2011-06-29 03:50:05 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:50:05 BRT FATAL: the database system is starting up > 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last known up > at 2011-06-29 03:48:17 BRT > 2011-06-29 03:50:05 BRT LOG: database system was not properly shut down; > automatic recovery in progress > 2011-06-29 03:50:05 BRT LOG: record with zero length at B8/CB5C4708 > 2011-06-29 03:50:05 BRT LOG: redo is not required > 2011-06-29 03:50:06 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:50:06 BRT FATAL: the database system is starting up > 2011-06-29 03:50:07 BRT LOG: database system is ready to accept connections > 2011-06-29 03:50:07 BRT LOG: autovacuum launcher started > 2011-06-29 03:50:07 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 07:01:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. > 2011-06-29 07:01:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:02:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:02:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:03:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:03:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:04:20 BRT LOG: received fast shutdown request > 2011-06-29 07:04:20 BRT LOG: aborting any active transactions > 2011-06-29 07:04:20 BRT LOG: autovacuum launcher shutting down > 2011-06-29 07:04:20 BRT LOG: shutting down > 2011-06-29 07:04:20 BRT LOG: database system is shut down > 2011-06-29 03:24:09 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:10 BRT FATAL: the database system is starting up > 2011-06-29 03:24:10 BRT LOG: database system was interrupted; last known up > at 2011-06-28 18:56:43 BRT > 2011-06-29 03:24:10 BRT LOG: database system was not properly shut down; > automatic recovery in progress > 2011-06-29 03:24:10 BRT LOG: record with zero length at B8/C3409208 > 2011-06-29 03:24:10 BRT LOG: redo is not required > 2011-06-29 03:24:11 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:11 BRT FATAL: the database system is starting up > 2011-06-29 03:24:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:12 BRT FATAL: the database system is starting up > 2011-06-29 03:24:12 BRT LOG: database system is ready to accept connections > 2011-06-29 03:24:12 BRT LOG: autovacuum launcher started > 2011-06-29 03:24:13 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:25:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:25:59 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:27:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:28:19 BRT NOTICE: table "pg_class" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_features" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_implementation_info" was reindexed > 2011-06-29 03:28:19 BRT ERROR: could not create unique index > "pg_
Re: [pgbr-geral] Erro pg_class_oid_index
2011/6/29 emerson lopes > > > > 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. > > Aqui o PostgreSQL está dando uma dica a vc, informando que o índice "pg_class_oid_index" está com problemas e que vc precisa reindexá-lo, tente rodar o comando de dentro do psql: REINDEX INDEX "pg_class_oid_index"; > > > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > > 2011-06-29 03:27:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:28:19 BRT NOTICE: table "pg_class" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_features" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_implementation_info" was > reindexed > 2011-06-29 03:28:19 BRT ERROR: could not create unique index > "pg_statistic_relid_att_index" > 2011-06-29 03:28:19 BRT DETAIL: Table contains duplicated values. > 2011-06-29 03:28:19 BRT STATEMENT: reindex database postgres > > 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:28:19 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:28:42 BRT NOTICE: table "pg_class" was reindexed > 2011-06-29 03:28:42 BRT NOTICE: table "sql_features" was reindexed > 2011-06-29 03:28:42 BRT NOTICE: table "sql_implementation_info" was > reindexed > 2011-06-29 03:28:42 BRT ERROR: could not create unique index > "pg_statistic_relid_att_index" > 2011-06-29 03:28:42 BRT DETAIL: Table contains duplicated values. > 2011-06-29 03:28:42 BRT STATEMENT: reindex database postgres > > Não sei o que esta ocorrendo no seu servidor que está ocasionando esses problemas com os índices, o mais adequado é reindexar toda sua base: $ psql -U postgres nomedasuabase nomedasuabase=# REINDEX DATABASE nomedasuabase; Mas cuidado, pq dependendo do tamanho da sua base esse procedimento pode levar bastante tempo... ou se preferiri olhe atentamente o LOG e reindexe somente as tabelas/indices que estão apontando problemas. -- Fabrízio de Royes Mello >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Fabio, que você acha? Tá me parecendo base mesmo. Vê as ultimas 3 linhas, reclama de indice duplicado. Em 29/06/2011 09:51, "emerson lopes" escreveu: > Segue abaixo: > > > 2011-06-29 03:50:05 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:50:05 BRT FATAL: the database system is starting up > 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last known up > at 2011-06-29 03:48:17 BRT > 2011-06-29 03:50:05 BRT LOG: database system was not properly shut down; > automatic recovery in progress > 2011-06-29 03:50:05 BRT LOG: record with zero length at B8/CB5C4708 > 2011-06-29 03:50:05 BRT LOG: redo is not required > 2011-06-29 03:50:06 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:50:06 BRT FATAL: the database system is starting up > 2011-06-29 03:50:07 BRT LOG: database system is ready to accept connections > 2011-06-29 03:50:07 BRT LOG: autovacuum launcher started > 2011-06-29 03:50:07 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 07:01:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. > 2011-06-29 07:01:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:01:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:02:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:02:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:03:56 BRT ERROR: index "pg_class_oid_index" contains > unexpected zero page at block 0 > 2011-06-29 07:03:56 BRT HINT: Please REINDEX it. > 2011-06-29 07:04:20 BRT LOG: received fast shutdown request > 2011-06-29 07:04:20 BRT LOG: aborting any active transactions > 2011-06-29 07:04:20 BRT LOG: autovacuum launcher shutting down > 2011-06-29 07:04:20 BRT LOG: shutting down > 2011-06-29 07:04:20 BRT LOG: database system is shut down > 2011-06-29 03:24:09 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:10 BRT FATAL: the database system is starting up > 2011-06-29 03:24:10 BRT LOG: database system was interrupted; last known up > at 2011-06-28 18:56:43 BRT > 2011-06-29 03:24:10 BRT LOG: database system was not properly shut down; > automatic recovery in progress > 2011-06-29 03:24:10 BRT LOG: record with zero length at B8/C3409208 > 2011-06-29 03:24:10 BRT LOG: redo is not required > 2011-06-29 03:24:11 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:11 BRT FATAL: the database system is starting up > 2011-06-29 03:24:12 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:24:12 BRT FATAL: the database system is starting up > 2011-06-29 03:24:12 BRT LOG: database system is ready to accept connections > 2011-06-29 03:24:12 BRT LOG: autovacuum launcher started > 2011-06-29 03:24:13 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:25:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:25:59 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row > versions, but table contains 3011 row versions > 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:27:33 BRT LOG: loaded library > "$libdir/plugins/plugin_debugger.dll" > 2011-06-29 03:28:19 BRT NOTICE: table "pg_class" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_features" was reindexed > 2011-06-29 03:28:19 BRT NOTICE: table "sql_implementation_info" was > reindexed > 2011-06-29 03:28:19 BRT ERROR: could not create unique index > "pg_statistic_relid_att_index" > 2011-06-29 03:28:19 BRT DETAIL: Table contains duplicated values. > 2011-06-29 03:28:19 BRT STATEMENT: reindex database postgres > > 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" > contains 1853 row versions, but table contains 1937 row versions > 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. > 2011-06-29 03:28:19 BRT WARNING: index "id_acerto" cont
Re: [pgbr-geral] Erro pg_class_oid_index
Segue abaixo: 2011-06-29 03:50:05 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:50:05 BRT FATAL: the database system is starting up 2011-06-29 03:50:05 BRT LOG: database system was interrupted; last known up at 2011-06-29 03:48:17 BRT 2011-06-29 03:50:05 BRT LOG: database system was not properly shut down; automatic recovery in progress 2011-06-29 03:50:05 BRT LOG: record with zero length at B8/CB5C4708 2011-06-29 03:50:05 BRT LOG: redo is not required 2011-06-29 03:50:06 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:50:06 BRT FATAL: the database system is starting up 2011-06-29 03:50:07 BRT LOG: database system is ready to accept connections 2011-06-29 03:50:07 BRT LOG: autovacuum launcher started 2011-06-29 03:50:07 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 07:01:12 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 07:01:13 BRT FATAL: index "pg_class_oid_index" contains unexpected zero page at block 0 2011-06-29 07:01:13 BRT HINT: Please REINDEX it. 2011-06-29 07:01:56 BRT ERROR: index "pg_class_oid_index" contains unexpected zero page at block 0 2011-06-29 07:01:56 BRT HINT: Please REINDEX it. 2011-06-29 07:02:56 BRT ERROR: index "pg_class_oid_index" contains unexpected zero page at block 0 2011-06-29 07:02:56 BRT HINT: Please REINDEX it. 2011-06-29 07:03:56 BRT ERROR: index "pg_class_oid_index" contains unexpected zero page at block 0 2011-06-29 07:03:56 BRT HINT: Please REINDEX it. 2011-06-29 07:04:20 BRT LOG: received fast shutdown request 2011-06-29 07:04:20 BRT LOG: aborting any active transactions 2011-06-29 07:04:20 BRT LOG: autovacuum launcher shutting down 2011-06-29 07:04:20 BRT LOG: shutting down 2011-06-29 07:04:20 BRT LOG: database system is shut down 2011-06-29 03:24:09 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:24:10 BRT FATAL: the database system is starting up 2011-06-29 03:24:10 BRT LOG: database system was interrupted; last known up at 2011-06-28 18:56:43 BRT 2011-06-29 03:24:10 BRT LOG: database system was not properly shut down; automatic recovery in progress 2011-06-29 03:24:10 BRT LOG: record with zero length at B8/C3409208 2011-06-29 03:24:10 BRT LOG: redo is not required 2011-06-29 03:24:11 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:24:11 BRT FATAL: the database system is starting up 2011-06-29 03:24:12 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:24:12 BRT FATAL: the database system is starting up 2011-06-29 03:24:12 BRT LOG: database system is ready to accept connections 2011-06-29 03:24:12 BRT LOG: autovacuum launcher started 2011-06-29 03:24:13 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:25:33 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:25:59 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" contains 1853 row versions, but table contains 1937 row versions 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:26:14 BRT WARNING: index "pg_statistic_relid_att_index" contains 1853 row versions, but table contains 1937 row versions 2011-06-29 03:26:14 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row versions, but table contains 3011 row versions 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:26:17 BRT WARNING: index "id_acerto" contains 2832 row versions, but table contains 3011 row versions 2011-06-29 03:26:17 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:27:33 BRT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2011-06-29 03:28:19 BRT NOTICE: table "pg_class" was reindexed 2011-06-29 03:28:19 BRT NOTICE: table "sql_features" was reindexed 2011-06-29 03:28:19 BRT NOTICE: table "sql_implementation_info" was reindexed 2011-06-29 03:28:19 BRT ERROR: could not create unique index "pg_statistic_relid_att_index" 2011-06-29 03:28:19 BRT DETAIL: Table contains duplicated values. 2011-06-29 03:28:19 BRT STATEMENT: reindex database postgres 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" contains 1853 row versions, but table contains 1937 row versions 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:28:19 BRT WARNING: index "pg_statistic_relid_att_index" contains 1853 row versions, but table contains 1937 row versions 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:28:19 BRT WARNING: index "id_acerto" contains 2832 row versions, but table contains 3011 row versions 2011-06-29 03:28:19 BRT HINT: Rebuild the index with REINDEX. 2011-06-29 03:28:42 BRT NOTICE: table "pg_class" was reindexed 2011-06-29 03:28:42 BRT NOTICE: table "sql_features" was reindexed 2011-06-29 03:
Re: [pgbr-geral] Erro pg_class_oid_index
Via psql, conecta normalmente? Em 29/06/2011 09:36, "emerson lopes" escreveu: > Opa Bruno! > > Esse banco em específico é 8.3 e o PGADMIN é 1.8.4. > > Realmente não sei como refazer o índice! Se puder me ajudar, fico grato, > > Emerson > > escreveu: > >> >> > Senhores, >> > >> > Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma >> luz >> > ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? >> > >> > >> > index "pg_class_oid_index" contains unexpected zero page at block 0 >> > >> > >> > Obrigado, >> > >> > Emerson Lopes >> >> ___ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Em 29 de junho de 2011 09:35, emerson lopes escreveu: > Opa Bruno! > > Esse banco em específico é 8.3 e o PGADMIN é 1.8.4. > > Realmente não sei como refazer o índice! Se puder me ajudar, fico grato, > Bom, o problema parece estar no banco de dados, não no pgadmin. Mas isso é fácil de verificar, já tentou se conectar com o psql do próprio servidor onde o postgres está instalado? Tem como mandar o log do postgres? Se você estiver perdido, inseguro e esta base for importante, recomendo contratar um DBA. Dependendo do que você fizer, você pode piorar a situação. Se não for importante, mande o log e a gente vê se consegue lhe ajudar. > > Emerson > > escreveu: > >> >> > Senhores, >> > >> > Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma >> luz >> > ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? >> > >> > >> > index "pg_class_oid_index" contains unexpected zero page at block 0 >> > >> > >> > Obrigado, >> > >> > Emerson Lopes >> >> ___ >> 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 > > -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Vaga DBA - Brasília
Prezados colegas da lista, venho divulgar uma vaga para DBA PostgreSQL Pleno para Brasília. Requisitos: * Superior completo em TI; * 2 Anos de experiência como DBA; * PostgreSQL e MySQL; - Instalação (via código fonte) - Rotinas de Backup e Recovery - Monitoramento - Otmização de consultas e tunning * Linux (CentOS); - Shell script (básico) Desejável/Diferenciais: * SQL Server 2005 (Básico); * PostGIS; * Conhecimentos em ETL e migração de dados; Salário: ~ 4,5 K R$ - CLT Interessados enviar CV para marconepe...@gmail.com -- *Marcone Peres - DBA* http://www.linkedin.com/in/marconeperes *(61) 8146-0028* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Opa Bruno! Esse banco em específico é 8.3 e o PGADMIN é 1.8.4. Realmente não sei como refazer o índice! Se puder me ajudar, fico grato, Emerson escreveu: > > > Senhores, > > > > Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma > luz > > ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? > > > > > > index "pg_class_oid_index" contains unexpected zero page at block 0 > > > > > > Obrigado, > > > > Emerson Lopes > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro pg_class_oid_index
Voce nao está usando um pgAdmin desatualizado? Já vi cliente com esse problema por usar pgAdmin incompatível com a versão 9 do Postgres. Em 29/06/2011 09:26, "emerson lopes" escreveu: > Senhores, > > Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma luz > ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? > > > index "pg_class_oid_index" contains unexpected zero page at block 0 > > > Obrigado, > > Emerson Lopes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro pg_class_oid_index
Senhores, Estou com o seguinte erro no meu banco de dados. Alguem pode me dar uma luz ? Obs.: Não estou conseguindo acessar o PGADMIN, como proceder ? index "pg_class_oid_index" contains unexpected zero page at block 0 Obrigado, Emerson Lopes ___ 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
Em 29 de junho de 2011 00:30, Fabiano Machado Dias < fabi...@wolaksistemas.com.br> escreveu: > Boa noite a todos, > > Estou chegando agora na discussão, mas posso falar sobre o tema, afinal > criamos um ERP desta maneira, quem quiser pode conferir nos links abaixo. > > O que posso dizer é que no nosso caso foi a escolha mais certa que já > fizemos, você precisa ter muito cuidado com a documentação, > principalmente se o número de desenvolvedores for grande. > > Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente > piloto posso te dizer ficou acima do esperado. > > Até hoje não tive problema de performance, o desenvolvimento é > extremamente rápido, sem falar na questão da segurança e confiança nas > transações! > > Na época lembro que muita gente falava que era loucura fazer desse > jeito, e pelo que vi tem vários colegas da lista que pensam assim, o que > posso dizer é que gostaria de ter enlouquecido bem antes, na época que > segui o tal modelo 3 camadas e queria que minha aplicação fosse multi > banco! > > Bom é só a minha humilde opinião, se precisar de alguma dica fique a > vontade para perguntar, apesar do foco do seu sistema ser diferente acho > que é a mesma idéia! > Eu concordo. Mas tudo é uma questão de escala. Utilizar funções para calcular em lote a folha de pagamento de 10 mil funcionários é uma benção. Utilizar funções para todo e qualquer processamento num ERP com centenas de transações ATIVAS, pode ser uma dor de cabeça. Veja que isso já foi pior em versões anteriores do Postgres, hoje já é possível ajustar melhor a performance de funções e rastrear as estatísticas destas, mas ainda dá mais trabalho. Queria saber a opinião de quem usa pl/proxy em relação a isso, uma vez que você tem de encapsular tudo em funções... +2 cents. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
2011/6/28 Dickson S. Guedes : > Em 28 de junho de 2011 22:52, Leandro DUTRA > escreveu: > [... corte ...] >> A grande exceção era aquele de Python, como se chamava? SQL alguma >> coisa ou algo SQL, mas até aí morreu o neves. > > Você está falando da fadinha [1] Dutra? Parece que ela(e) morreu mesmo. Não. Acho que ele está se referindo ao SQL Alchemy[1] que é um framework ORM para Python, enquanto que SQL Fairy é desenvolvido em Perl e funciona como uma espécie de ETL e AFAIK ele *não* está "morto" – ou não entendi a piada. Embora o SQLAlchemy possua uma implementação mais elegante de Data Mapper (conceitos de álgebra relacional) ele não deixa de ser uma evolução do modelo Active Record[2] definido por Martin Fowller e também por isso trás impactos na produção para o DBA. [1] http://www.sqlalchemy.org/ [2] http://martinfowler.com/eaaCatalog/activeRecord.html > Em tempo, tive bons contatos com ActiveRecord do Rails [2], e as > técnicas que vi no mesmo mostram um amadurecimento cada vez maior e um > uso mais efetivo do mesmo junto com o banco de dados. Eagers e Lazys > Joins quando bem utilizados realmente mudam consideravelmente a > performance. Claro que existem certas convenções do AR que não são tão > bem vistas, como as SKs [3] por exemplo, mas para determinadas > aplicações isso não é o fim do mundo em si. A conclusão que chego é a seguinte: ORM é muito bom para desenvolvedor e ruim em qualquer hipótese para DBAs. Abraço! -Leo -- Leonardo Cezar http://postgreslogia.wordpress.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] Sugestão de uso
Eu também estou desenvolvendo um ERP com forte uso de PL/pgSQL e estou satisfeito. Em 29 de junho de 2011 00:30, Fabiano Machado Dias < fabi...@wolaksistemas.com.br> escreveu: > Boa noite a todos, > > Estou chegando agora na discussão, mas posso falar sobre o tema, afinal > criamos um ERP desta maneira, quem quiser pode conferir nos links abaixo. > > O que posso dizer é que no nosso caso foi a escolha mais certa que já > fizemos, você precisa ter muito cuidado com a documentação, > principalmente se o número de desenvolvedores for grande. > > Fizemos uso de PL/pgSQL direto, e hoje após quase 5 anos do cliente > piloto posso te dizer ficou acima do esperado. > > Até hoje não tive problema de performance, o desenvolvimento é > extremamente rápido, sem falar na questão da segurança e confiança nas > transações! > > Na época lembro que muita gente falava que era loucura fazer desse > jeito, e pelo que vi tem vários colegas da lista que pensam assim, o que > posso dizer é que gostaria de ter enlouquecido bem antes, na época que > segui o tal modelo 3 camadas e queria que minha aplicação fosse multi > banco! > > Bom é só a minha humilde opinião, se precisar de alguma dica fique a > vontade para perguntar, apesar do foco do seu sistema ser diferente acho > que é a mesma idéia! > > Um grande abraço, > Fabiano Machado Dias > > > > > http://www.4linux.com.br/noticias/2010/PostgreSQL/PGCon2009 > http://pgbr.postgresql.org.br/2009/palestras/aud2/ERP.pdf (Estava > funcionando, quem quiser pode me pedir a palestra que eu envio) > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
