Re: [pgbr-geral] gráficos e estatísticas de desemp enho
Luciano Mittmann escreveu: Pessoal, Disponibilizei o endereço http://www14.pr.gov.br/cedrus para quem ainda não conhece o cedrus. Só pra ter uma idéia de seu funcionamento. Luciano Legal Luciano, Eu ainda estou tentando colocá-lo para funcionar aqui. [ ]s Guedes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Backup
Olá pessoal!! Tenho uma base de dados em um micro e este pegou vírus. A pessoa que formatou, ao invés de fazer um dump copiou apenas as pastas do postgres com o windows em modo de segurança. Tem alguma possibilidade de eu conseguir restaurar essa base de dados? SO: Windows xp PostgreSQL: 8.0 Obrigada pela atenção! -- --- Márcia Regina ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] gráficos e estatísticas de desemp enho
Luciano, O Cedrus é show, mas voce sabe se ele funciona em versoes de 8.2 a 8.3 ? Obrigado. --- Luciano Mittmann [EMAIL PROTECTED] escreveu: Pessoal, Disponibilizei o endereço http://www14.pr.gov.br/cedrus para quem ainda não conhece o cedrus. Só pra ter uma idéia de seu funcionamento. Luciano Em 11/03/08, Dickson Guedes [EMAIL PROTECTED] escreveu: Tiago N. Sampaio escreveu: (...) Se vc quer tudo pronto, sem ter que fazer nenhum esforço, use programas M$ like, que ai vc pode comprar suporte e tudo mais.. Uma coisa é vir tudo pronto, outra coisa é uma ferramenta que está em desenvolvimento e que foi cedida à comunidade SL para estudos, aperfeiçoamentos, etc. Além do mais, a compra de suporte se dá também para empresas que prestam serviços utilizando SL. Agora não é tambem porque é software livre que tem que ser trabalhoso. Claro, eu entendi sei comentário Tiago, sei que esforços podem ser exigidos para alguns casos (dependencias de pacotes por exemplo), mas se algo pode ser automatizado deve-se pensar seriamente em fazê-lo. Se esse ainda não é o estágio do Cedrus, é porque ele ainda não chegou nesse ponto. O Cedrus é isso, uma ferramenta que ainda está em fase de desenvolvimento, iniciado para a realidade de uma empresa em específico, mas que já comprovou ser funcional para outras realidades, com um esforço para colocá-lo em funcionamento. O Hjort não pôde dar continuidade, mas acredito que muitos possuem capacidade de fazê-lo. [ ]s Guedes ___ 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 Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.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] Backup
2008/3/12, Márcia Regina da Silva Pimentel [EMAIL PROTECTED]: Tenho uma base de dados em um micro e este pegou vírus. A pessoa que formatou, ao invés de fazer um dump copiou apenas as pastas do postgres com o windows em modo de segurança. Tem alguma possibilidade de eu conseguir restaurar essa base de dados? Sim! Pesquise os arquivos da lista do último mês ou dois. E troque de SO... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problemas com SQL
E ai galera, estou com uma demora nesta consulta abaixa Tenho alguma coisa que possa ser melhorado de acordo com o explain? Nested Loop (cost=0.00..114.69 rows=1 width=20) (actual time=1.251..7335.952 rows=5493 loops=1) - Nested Loop (cost=0.00..27.23 rows=1 width=24) (actual time=0.826..371.070 rows=5493 loops=1) - Nested Loop (cost=0.00..22.64 rows=1 width=31) (actual time=0.689..162.554 rows=5493 loops=1) - Nested Loop (cost=0.00..16.52 rows=1 width=40) (actual time=0.535..105.706 rows=5494 loops=1) - Nested Loop (cost=0.00..12.17 rows=1 width=30) (actual time=0.372..34.648 rows=5494 loops=1) - Index Scan using basffcalculos_pkey on basffcalculos basffc (cost=0.00..7.82 rows=1 width=20) (actual time=0.214..5.705 rows=1001 loops=1) Index Cond: ((seqexercicio = 2008) AND (seqcontrolcalc = 16) AND (seqdecalculo = 1000)) - Index Scan using basffparcelasdocalculo_pkey on basffparcelasdocalculo basffpc (cost=0.00..4.34 rows=1 width=20) (actual time=0.013..0.023 rows=5 loops=1001) Index Cond: ((2008 = basffpc.seqexercicio) AND (basffpc.codsistema = outer.codsistema) AND (16 = basffpc.seqcontrolcalc) AND (basffpc.seqdecalculo = outer.seqdecalculo)) - Index Scan using basffsacadodocalculo_pkey on basffsacadodocalculo basffsc (cost=0.00..4.34 rows=1 width=20) (actual time=0.010..0.011 rows=1 loops=5494) Index Cond: ((2008 = basffsc.seqexercicio) AND (basffsc.codsistema = outer.codsistema) AND (16 = basffsc.seqcontrolcalc) AND (basffsc.seqdecalculo = outer.seqdecalculo)) - Index Scan using issffcalculo_pkey on issffcalculo issffc (cost=0.00..6.08 rows=2 width=31) (actual time=0.008..0.008 rows=1 loops=5494) Index Cond: ((2008 = issffc.seqexercicio) AND (issffc.codsistema = outer.codsistema) AND (16 = issffc.seqcontrolcalc) AND (issffc.seqdecalculo = outer.seqdecalculo)) - Index Scan using idx_issinscricacaocadastral on issinscricaocadastral issic (cost=0.00..4.58 rows=1 width=14) (actual time=0.035..0.036 rows=1 loops=5493) Index Cond: ((issic.numinscricaocadastral)::text = (outer.inscrcadastral)::text) Filter: (idexclusao = 0) - Index Scan using idx_isscadastrocontribuintes on isscadastrocontribuintes isscc (cost=0.00..87.46 rows=1 width=4) (actual time=0.499..1.266 rows=1 loops=5493) Index Cond: (isscc.seqcontribuinte = outer.seqcontribuinte) Filter: (idexclusao = 0) Total runtime: 7337.988 ms ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com SQL
2008/3/12, Rodrigo Gomes Santana [EMAIL PROTECTED]: E ai galera, estou com uma demora nesta consulta abaixa Por favor, forneça a estrutura das tabelas, volumes de dados das mesmas, distribuição dos mesmos, texto da consulta, e cole o explain sem quebras de linha... -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Obter nome da coluna de um tipo RECORD
Gostaria de saber como obter os nomes das colunas de um RECORD. Gostaria de fazer algo parecido, pseudo codigo: for each nomeColuna in record begin valorColuna = record.nomeColuna insert into tabela_auditoria(id , nomeColuna , valorColuna ) end http://www.postgresql.org/docs/8.1/interactive/plpgsql-declarations.html#PLPGSQL-DECLARATION-RECORDS PS : Osvaldo Rosario Kussama, value pela ajuda, Passar para o PostgreSQL um identificador do Cliente? , atendeu e funcionou beleza. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Array de composite types
Alguém sabe como criar arrays de composite types?
Eu sei que o PG atualmente não suporta este tipo de construção, mas estava
imaginando se alguém pode sugerir alguma forma de contornar isso.
Pretendo utilizar este array como parâmetro de entrada/saída em procedures.
Minha idéia é criar procedures que serão chamadas a partir de aplicações java
(através de JDBC). Tais procedures devem manipular parâmetros de entrada/saída
que sejam do tipo composite_type[].
Uma construção parecida, em Oracle, seria assim:
SQL:
CREATE OR REPLACE TYPE TESTOBJ AS OBJECT
(
NAME VARCHAR2(100) ,
AGE INTEGER,
STATIC FUNCTION AUTOCREATE RETURN TESTOBJ
)
CREATE OR REPLACE TYPE BODY TESTOBJ AS
STATIC FUNCTION AUTOCREATE RETURN TESTOBJ IS
REC TESTOBJ;
BEGIN
REC := TESTOBJ(NULL, NULL);
RETURN REC;
END AUTOCREATE;
END;
CREATE OR REPLACE TYPE ARRAYTESTOBJ AS TABLE OF TESTOBJ
Java:
stmt = conn.prepareCall({ call PROC_TESTOBJ(?,?,?,?,?) });
stmt.setData(1, typeTestObj);
stmt.registerOutputParameter(2, Types.ARRAY);
stmt.execute;
Sem mais,
Artur Sampaio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Backup
Em 12/03/08, Márcia Regina da Silva Pimentel[EMAIL PROTECTED] escreveu: Olá pessoal!! Tenho uma base de dados em um micro e este pegou vírus. *** MEDO *** A pessoa que formatou, ao invés de fazer um dump copiou apenas as pastas do postgres com o windows em modo de segurança. Tem alguma possibilidade de eu conseguir restaurar essa base de dados? Claro... você só precisará: De um servidor com o mesmo SO, mesmo sistema de arquivos, mesmo PostgreSQL instalado com os mesmos parâmetros. Feito isso, substitua o cluster inteiro do novo servidor pelo cluster do seu backup. Verifique antes, é claro, se a estrutura de diretórios do seu backup está parecida com a do seu backup. * Faça a cópia com o banco desligado!!! SO: Windows xp PostgreSQL: 8.0 Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] dblink+acentuacao
Olá! Estou usando o dblink para pergar dados de um banco e inserir em outro, o q ocorre é q quando executo uma query e os dados retornados contém acentos ou ç a linha é simplesmente ignorada como se ela nao existisse na tabela. Os dois banco são SQL_ASCII. Alguem sabe como resolver isso? []'s Heloisa - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Opnião sobre esta declaração
Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.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] Opnião sobre esta declaração
O que seria uma camada de pool + cache? Alguma camada de persistencia? 2008/3/12 Nilson Chagas [EMAIL PROTECTED]: Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.com.br ___ 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] Opnião sobre esta declaração
2008/3/12 Jorge Vilela [EMAIL PROTECTED]: O que seria uma camada de pool + cache? Alguma camada de persistencia? Acho que ele disse *gentilmente* que você reestruturasse sua aplicação para que ela tivesse menos acesso ao banco... -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Então, o site atual não fui eu quem fiz... vou desenvolver o site novo. Eu falei para os proprietários do site, que um grande problemas que eles tinham estava relacionado ao mal uso do banco de dados, que atualmente é mysql. Para o novo site pedirão que fosse feito em postgresql, o qual não conhecia. Agora o hostmaster, me diz q podemos ter mais problemas com o postgresql do que com o mysql, veio um ponto de interrogação na mente. 2008/3/12, Sebastian SWC [EMAIL PROTECTED]: 2008/3/12 Jorge Vilela [EMAIL PROTECTED]: O que seria uma camada de pool + cache? Alguma camada de persistencia? Acho que ele disse *gentilmente* que você reestruturasse sua aplicação para que ela tivesse menos acesso ao banco... -- Atenciosamente, Sebastian Selau Webber Colombo ___ 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] Opnião sobre esta declaração
Uma camada intermediária entre as requisições (SQL do PHP) e o acesso ao banco, que se posicionasse de forma a receber requisições, utilizar uma conexão persistida para as queries (através de uma singleton, por exemplo), e devolver as respostas, logando as ações de cada usuário que fez a requisição. Seria uma forma bem viável de resolver o problema da criação de processos do postgres, que realmente é grave e inapto pra soluções desse tipo. Envolve um overhead desnecessário pra criação de processos que inviabilizaria a solução. -- --- Bruno Simioni Caiena - Soluções em Gestão do Conhecimento --- On 3/12/08, Jorge Vilela [EMAIL PROTECTED] wrote: O que seria uma camada de pool + cache? Alguma camada de persistencia? 2008/3/12 Nilson Chagas [EMAIL PROTECTED]: Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Em relação o PostgreSQL ao criar um processo servidor para cada aplicação eu não sei te responder. Em sistemas Web, com grande número de requisições, devemos criar um cache (armazenar na memória do servidor Web) os dados que são mais acessados, para não ter requisições ao banco toda vez que alguém solicitar, por exemplo, uma lista de preços. Em java eu utilizo EhCache. Se houver alguma atualização no banco de dados o cache também é atualizado (tem de programar isso). Vou tentar resumir da forma mais simples. Pela sua explanação, me parece que o seu sistema acessa diretamente o banco de dados pela camada de apresentação. O pool de conexão é tu ter um interface (camada model) que acessa o seu banco de dados através das requisições da camada de controle. Se houver mais de uma mesma requisição, essa camada faz apenas uma chamada ao banco de dados e responde a todas requisições. E o cache nada mais é do que reter essa requisição em memória, respondendo a outras requisições com esses dados. Toda requisição de dados é solicitado a camada model que se tiver as informações em cache essas serão enviadas, ou faz uma nova requisição ao banco. Espero ter respondido sua questão, Alecindro Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.com.br ___ 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] Opnião sobre esta declaração
Nilson Chagas escreveu: (...) Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. (...) Como ele mesmo citou, é uma opnião dele. Na minha opnião, ele poderia tentar comprová-la com testes de carga. []s Guedes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Bom, temos números para o problema? Número máximo de conexões simultâneas? Existe intranet (área que exija autenticação)? As transações possuem um equilíbrio ou inserção/atualização é mais freqüente? Qual o hardware para dar suporte a tais requisições? Qualquer servidor mal-configurado gerará problemas. E nem todos são ligados diretamente com a solução de banco de dados. O apache por exemplo, possui um cache de conexões. O que quero dizer é que esse tipo de decisão demanda de um conhecimento maior sobre o problema a ser enfrentado e, principalmente, entendimento técnico das soluções a serem usadas. E quanto à opinião do administrador da hospedagem, bem, ou ele gosta do MySQL e não quer aprender nada do postgresql, ou possui apenas uma máquina rodando tudo... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Vc e o Bruno me deram uma boa visão sobre o problema, e pelo que entendi vou ter que desenvolver isto por meio do PHP, não e algo que eu possa fazer no banco de dados. Correto?? Uma pergunta, a utilização de view amenizaria o problema??? Em 12/03/08, [EMAIL PROTECTED] [EMAIL PROTECTED] escreveu: Em relação o PostgreSQL ao criar um processo servidor para cada aplicação eu não sei te responder. Em sistemas Web, com grande número de requisições, devemos criar um cache (armazenar na memória do servidor Web) os dados que são mais acessados, para não ter requisições ao banco toda vez que alguém solicitar, por exemplo, uma lista de preços. Em java eu utilizo EhCache. Se houver alguma atualização no banco de dados o cache também é atualizado (tem de programar isso). Vou tentar resumir da forma mais simples. Pela sua explanação, me parece que o seu sistema acessa diretamente o banco de dados pela camada de apresentação. O pool de conexão é tu ter um interface (camada model) que acessa o seu banco de dados através das requisições da camada de controle. Se houver mais de uma mesma requisição, essa camada faz apenas uma chamada ao banco de dados e responde a todas requisições. E o cache nada mais é do que reter essa requisição em memória, respondendo a outras requisições com esses dados. Toda requisição de dados é solicitado a camada model que se tiver as informações em cache essas serão enviadas, ou faz uma nova requisição ao banco. Espero ter respondido sua questão, Alecindro Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Dead block ou deadlock? São coisas bem diferentes. Nilson Chagas wrote: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Um servidor roda o webserver e o outro os bancos mysql e pgsql. Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Em 12/03/08, *William Leite Araújo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escreveu: Bom, temos números para o problema? Número máximo de conexões simultâneas? Existe intranet (área que exija autenticação)? As transações possuem um equilíbrio ou inserção/atualização é mais freqüente? Qual o hardware para dar suporte a tais requisições? Qualquer servidor mal-configurado gerará problemas. E nem todos são ligados diretamente com a solução de banco de dados. O apache por exemplo, possui um cache de conexões. O que quero dizer é que esse tipo de decisão demanda de um conhecimento maior sobre o problema a ser enfrentado e, principalmente, entendimento técnico das soluções a serem usadas. E quanto à opinião do administrador da hospedagem, bem, ou ele gosta do MySQL e não quer aprender nada do postgresql, ou possui apenas uma máquina rodando tudo... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br mailto:pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- -- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email [EMAIL PROTECTED] fone 55 19 3288 0466 begin:vcard fn:Benedito A. Cruz n:Cruz;Benedito A. email;internet:[EMAIL PROTECTED] version:2.1 end:vcard ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Ameniza o trabalho do banco de dados em selecionar os dados solicitados , mas cada vez que você fizer uma requisição, todos os dados serão carregados na memória do servidor Web. Eu não entendo nada de PHP, mas o princípio é o mesmo em qualquer aplicação. Vou tentar criar um guia: - Você fará uma interface que faz a solicitação ao banco de dados do que é solicitado. - Essa interface é uma thread; Por exemplo: - Você faz uma solicitação de login e senha e carrega num array. - A toda solicitação, essa interface pesquisa o array. - Caso o dado pesquisado não esteja no array, é procurado no banco. Para amenizar o tamanho do array, você criaria uma view com os logins mais acessados. Essa interface responde a todas requisições de login. Agora, deve ter algum framework que possibilita tu fazer isso de forma mais dinâmica. Esse guia é para tu ter uma idéia da forma como isso acontence. O servidor de aplicações JBOSS possui um sistema chamado JBOSS Cache. Não sei se esse sistema trabalha com outro tipo de servidor de aplicações. Alecindro Vc e o Bruno me deram uma boa visão sobre o problema, e pelo que entendi vou ter que desenvolver isto por meio do PHP, não e algo que eu possa fazer no banco de dados. Correto?? Uma pergunta, a utilização de view amenizaria o problema??? Em 12/03/08, [EMAIL PROTECTED] [EMAIL PROTECTED] escreveu: Em relação o PostgreSQL ao criar um processo servidor para cada aplicação eu não sei te responder. Em sistemas Web, com grande número de requisições, devemos criar um cache (armazenar na memória do servidor Web) os dados que são mais acessados, para não ter requisições ao banco toda vez que alguém solicitar, por exemplo, uma lista de preços. Em java eu utilizo EhCache. Se houver alguma atualização no banco de dados o cache também é atualizado (tem de programar isso). Vou tentar resumir da forma mais simples. Pela sua explanação, me parece que o seu sistema acessa diretamente o banco de dados pela camada de apresentação. O pool de conexão é tu ter um interface (camada model) que acessa o seu banco de dados através das requisições da camada de controle. Se houver mais de uma mesma requisição, essa camada faz apenas uma chamada ao banco de dados e responde a todas requisições. E o cache nada mais é do que reter essa requisição em memória, respondendo a outras requisições com esses dados. Toda requisição de dados é solicitado a camada model que se tiver as informações em cache essas serão enviadas, ou faz uma nova requisição ao banco. Espero ter respondido sua questão, Alecindro Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Obrigado. -- []s Nilson Chagas --- Visite: Fundamental: www.amados.com.br Dúvidas:http://nilsoftware.blogspot.com/ Obrigatório: www.saopaulofc.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Em 12/03/08, Nilson Chagas [EMAIL PROTECTED] escreveu: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Máquinas boas, mas como havia dito, uma má-configuração das mesmas gera problemas. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Bom, na minha opinião os servidores deveriam ter um link interno gigabit entre eles para agilizar as requisições. Um servidor roda o webserver e o outro os bancos mysql e pgsql. Isso é muito comum. E caso as máquinas sejam exclusivas (o que acredito que não sejam), realmente estão mal-configuradas. Ou então as requisições da aplicação são muito pesadas... Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Hum... que estranho... já trabalhei num ambiente com 1000 clientes simultâneos usando postgresql e máquinas semelhantes e não tive problema... Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Bom, volto a acreditar na preferência dele por MySQL. E estou achando que, ou o MySQL está mal configurada, ou a aplicação é muito pesada... (mas acho mais provável a primeira opção). Uma sugestão: peça a ele para testar a carga do Postgresql usando o LOG de queries do MySQL do horário de pico... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Nilson Chagas wrote: RSRSRSRS' Foi mal este negocio me deixou muito pensativo. Veja o que ele me passou no dia que deu problema apos o upgrade dos servidores: Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na outra e vice versa, condição que nunca termina. Apenas uma duvida, o mysql trava a tabela em ações IUD ou consulta automaticamente? Acredito que não. Provavelmente a aplicação está travando a tabela. Talvez seja apenas você não travar as tabelas. Assim não terá mais dead lock. Se esse (o dead lock) for seu unico problema, não deve ser tão dificil de resolver. No PostgreSQL a tabela só trava se você mandar. acredito que você nunca terá dead lock por excesso de acesso (estou certo??) Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Os servidores são dedicados sim. Eu achei que para o numero de acessos teria que ser uma maquina com 4GB de RAM. O site é este www.saopaulofc.com.br, no dia da contratação do Adriano o site caiu 3 vezes (no servidor antigo). No servidor novo, quando passou de 500 ele caiu simplesmente. Apesar, quando arrumou a questão da velocidade da net o site ainda naum caiu. Mas ele diz estar lento. Só postei esta mensagem mesmo, pensando no fato dele ter dito que vamos ter mais problemas no postgresql, mas pelo que tenho visto aqui, é uma visão de alguém que não conhece o banco. Em 12/03/08, William Leite Araújo [EMAIL PROTECTED] escreveu: Em 12/03/08, Nilson Chagas [EMAIL PROTECTED] escreveu: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Máquinas boas, mas como havia dito, uma má-configuração das mesmas gera problemas. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Bom, na minha opinião os servidores deveriam ter um link interno gigabit entre eles para agilizar as requisições. Um servidor roda o webserver e o outro os bancos mysql e pgsql. Isso é muito comum. E caso as máquinas sejam exclusivas (o que acredito que não sejam), realmente estão mal-configuradas. Ou então as requisições da aplicação são muito pesadas... Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Hum... que estranho... já trabalhei num ambiente com 1000 clientes simultâneos usando postgresql e máquinas semelhantes e não tive problema... Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Bom, volto a acreditar na preferência dele por MySQL. E estou achando que, ou o MySQL está mal configurada, ou a aplicação é muito pesada... (mas acho mais provável a primeira opção). Uma sugestão: peça a ele para testar a carga do Postgresql usando o LOG de queries do MySQL do horário de pico... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ 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] gráficos e estatísticas de desemp enho
Ainda não testei ! Em 12/03/08, Mr J.L. [EMAIL PROTECTED] escreveu: Luciano, O Cedrus é show, mas voce sabe se ele funciona em versoes de 8.2 a 8.3 ? Obrigado. --- Luciano Mittmann [EMAIL PROTECTED] escreveu: Pessoal, Disponibilizei o endereço http://www14.pr.gov.br/cedrus para quem ainda não conhece o cedrus. Só pra ter uma idéia de seu funcionamento. Luciano Em 11/03/08, Dickson Guedes [EMAIL PROTECTED] escreveu: Tiago N. Sampaio escreveu: (...) Se vc quer tudo pronto, sem ter que fazer nenhum esforço, use programas M$ like, que ai vc pode comprar suporte e tudo mais.. Uma coisa é vir tudo pronto, outra coisa é uma ferramenta que está em desenvolvimento e que foi cedida à comunidade SL para estudos, aperfeiçoamentos, etc. Além do mais, a compra de suporte se dá também para empresas que prestam serviços utilizando SL. Agora não é tambem porque é software livre que tem que ser trabalhoso. Claro, eu entendi sei comentário Tiago, sei que esforços podem ser exigidos para alguns casos (dependencias de pacotes por exemplo), mas se algo pode ser automatizado deve-se pensar seriamente em fazê-lo. Se esse ainda não é o estágio do Cedrus, é porque ele ainda não chegou nesse ponto. O Cedrus é isso, uma ferramenta que ainda está em fase de desenvolvimento, iniciado para a realidade de uma empresa em específico, mas que já comprovou ser funcional para outras realidades, com um esforço para colocá-lo em funcionamento. O Hjort não pôde dar continuidade, mas acredito que muitos possuem capacidade de fazê-lo. [ ]s Guedes ___ 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 Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Bom, não conheço mysql, e não faço questão nenhuma de conhecer. Mas se você esta falando que o postgresql só trava se eu mandar, então pode deixar que eu não mando. rsrsrs Falando sobre view, e aproveitando a tread. Uma vez me falaram que o postgresql seria uma oracle menor, e tb li que banco de dados free, não possui view materalize(??). O fato da view dos banco de dados free, nào serem materializadas, constitui em um erro de performance na view, ao ponto de não haver diferença entre acessar a tabela e a view??? Em 12/03/08, Evandro Ricardo Silvestre [EMAIL PROTECTED] escreveu: Nilson Chagas wrote: RSRSRSRS' Foi mal este negocio me deixou muito pensativo. Veja o que ele me passou no dia que deu problema apos o upgrade dos servidores: Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na outra e vice versa, condição que nunca termina. Apenas uma duvida, o mysql trava a tabela em ações IUD ou consulta automaticamente? Acredito que não. Provavelmente a aplicação está travando a tabela. Talvez seja apenas você não travar as tabelas. Assim não terá mais dead lock. Se esse (o dead lock) for seu unico problema, não deve ser tão dificil de resolver. No PostgreSQL a tabela só trava se você mandar. acredito que você nunca terá dead lock por excesso de acesso (estou certo??) Evandro ___ 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] Opnião sobre esta declaração
Algum de vocês conhece algum framework para PHP que faça esse tipo de coisa? spool + cache? Estou pensando em melhorar o acesso ao banco de dados das minhas aplicações pois estão ficando muito pesadas também... E hoje trabalho com php/postgres... []'s Jorge 2008/3/12 Nilson Chagas [EMAIL PROTECTED]: RSRSRSRS' Foi mal este negocio me deixou muito pensativo. Veja o que ele me passou no dia que deu problema apos o upgrade dos servidores: Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na outra e vice versa, condição que nunca termina. Abaixo segue a lista de conexões que estavam ativas. Vou reiniciar o banco, porque o web server não estou nem conseguindo logar na máquina em função disto. Será necessário analisar o que pode estar ocorrendo, haja vista que as configurações basicamente são as mesmas. A única alteração é a versão do PHP (4-5) e do MySQL ( 4-5). Agnaldo mysql show processlist; +-++--+-+-+--++- -+ | Id | User | Host | db | Command | Time | State | Info | +-++--+-+-+--++- -+ | 1299383 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47183 | 1040db2 | Sleep | 45 || NULL | | 1299393 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47193 | 1040db2 | Sleep | 74 || NULL | | 1299402 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47202 | 1040db2 | Sleep | 16 || NULL | | 1299412 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47212 | 1040db2 | Sleep | 74 || NULL | | 1299421 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47221 | 1040db2 | Query |9 | Locked | SELECT count(uid) FROM spnet_users WHERE uid=14065 and banned='N' and moderate | Em 12/03/08, Benedito A. Cruz [EMAIL PROTECTED] escreveu: Dead block ou deadlock? São coisas bem diferentes. Nilson Chagas wrote: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Um servidor roda o webserver e o outro os bancos mysql e pgsql. Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Em 12/03/08, *William Leite Araújo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escreveu: Bom, temos números para o problema? Número máximo de conexões simultâneas? Existe intranet (área que exija autenticação)? As transações possuem um equilíbrio ou inserção/atualização é mais freqüente? Qual o hardware para dar suporte a tais requisições? Qualquer servidor mal-configurado gerará problemas. E nem todos são ligados diretamente com a solução de banco de dados. O apache por exemplo, possui um cache de conexões. O que quero dizer é que esse tipo de decisão demanda de um conhecimento maior sobre o problema a ser enfrentado e, principalmente, entendimento técnico das soluções a serem usadas. E quanto à opinião do administrador da hospedagem, bem, ou ele gosta do MySQL e não quer aprender nada do postgresql, ou possui apenas uma máquina rodando tudo... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br mailto:pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Nilson Chagas wrote: Falando sobre view, e aproveitando a tread. Sugiro criar uma nova thead. Uma vez me falaram que o postgresql seria uma oracle menor, e tb li que banco de dados free, não possui view materalize(??). O postgresql tem view materalize, procure em discussões passadas. Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Se utilizar smaty, ele não possui um cache??? Não estaria resolvendo o problema de varias requisições??? Desculpe perguntar isto aqui, mas como já estamos no assunto. Em 12/03/08, Jorge Vilela [EMAIL PROTECTED] escreveu: Algum de vocês conhece algum framework para PHP que faça esse tipo de coisa? spool + cache? Estou pensando em melhorar o acesso ao banco de dados das minhas aplicações pois estão ficando muito pesadas também... E hoje trabalho com php/postgres... []'s Jorge 2008/3/12 Nilson Chagas [EMAIL PROTECTED]: RSRSRSRS' Foi mal este negocio me deixou muito pensativo. Veja o que ele me passou no dia que deu problema apos o upgrade dos servidores: Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na outra e vice versa, condição que nunca termina. Abaixo segue a lista de conexões que estavam ativas. Vou reiniciar o banco, porque o web server não estou nem conseguindo logar na máquina em função disto. Será necessário analisar o que pode estar ocorrendo, haja vista que as configurações basicamente são as mesmas. A única alteração é a versão do PHP (4-5) e do MySQL ( 4-5). Agnaldo mysql show processlist; +-++--+-+-+--++- -+ | Id | User | Host | db | Command | Time | State | Info | +-++--+-+-+--++- -+ | 1299383 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47183 | 1040db2 | Sleep | 45 || NULL | | 1299393 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47193 | 1040db2 | Sleep | 74 || NULL | | 1299402 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47202 | 1040db2 | Sleep | 16 || NULL | | 1299412 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47212 | 1040db2 | Sleep | 74 || NULL | | 1299421 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47221 | 1040db2 | Query |9 | Locked | SELECT count(uid) FROM spnet_users WHERE uid=14065 and banned='N' and moderate | Em 12/03/08, Benedito A. Cruz [EMAIL PROTECTED] escreveu: Dead block ou deadlock? São coisas bem diferentes. Nilson Chagas wrote: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Um servidor roda o webserver e o outro os bancos mysql e pgsql. Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Em 12/03/08, *William Leite Araújo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escreveu: Bom, temos números para o problema? Número máximo de conexões simultâneas? Existe intranet (área que exija autenticação)? As transações possuem um equilíbrio ou inserção/atualização é mais freqüente? Qual o hardware para dar suporte a tais requisições? Qualquer servidor mal-configurado gerará problemas. E nem todos são ligados diretamente com a solução de banco de dados. O apache por exemplo, possui um cache de conexões. O que quero dizer é que esse tipo de decisão demanda de um conhecimento maior sobre o problema a ser enfrentado e, principalmente, entendimento técnico das soluções a serem usadas. E quanto à opinião do administrador da hospedagem, bem, ou ele gosta do MySQL e não quer aprender nada do postgresql, ou possui apenas uma máquina rodando tudo... -- William Leite Araújo Analista de Banco de Dados - QualiConsult ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br mailto:pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___
Re: [pgbr-geral] Opnião sobre esta declaração
BLZ, nem precisa de nova tread. Vou pesquisar o assunto. Pessoal, obrigado a todos, pelas ótimas informações, agora vou para o grupo de discussão do PHP e ver o que posso conseguir sobre cache. 2008/3/12, Evandro Ricardo Silvestre [EMAIL PROTECTED]: Nilson Chagas wrote: Falando sobre view, e aproveitando a tread. Sugiro criar uma nova thead. Uma vez me falaram que o postgresql seria uma oracle menor, e tb li que banco de dados free, não possui view materalize(??). O postgresql tem view materalize, procure em discussões passadas. Evandro ___ 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] Opnião sobre esta declaração
2008/3/12 Nilson Chagas [EMAIL PROTECTED]: Desculpe já chegar sugando dos companheiros. Mas gostaria de opinião dos colegas sobre esta declaração do administrador da hospedagem: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. Seu administrador está redondamente enganado e mal informado sobre as diferenças entre arquiteturas de threads e múltiplos processos. Em sistemas como Linux, threads não passam de processos ligeiramente mais leves, cuja área de memória, descritores de arquivos, etc são compartilhados. Isso torna trocas de contexto entre diferentes threads de um mesmo processo ligeiramente mais rápidas. Há desvantagens também. Um problema numa thread pode vir a trazer o processo inteiro abaixo, já que é o mesmo processo. Sincronização e travas podem ser mais complexas. Hacks preguiçosos são mais fáceis de acontecer, visto que programadores são por natureza preguiçosos e há a tentação de botar cada vez mais no escopo global para ser ser acessado por todas as threads, eliminando a ligeira vantagem das trocas de contexto. Para comunicação entre processos, como no PostgreSQL, usa-se memória compartilhada, sinais e outros mecanismos que são bem entendidos e definidos. O bom uso de múltiplos processos é mais trabalhoso do que usar threads, daí a popularidade de threads com a nova geração de programadores next-next-finish. O time do PostgreSQL fez uma decisão consciente de continuar a usar múltiplos processos por que eles valorizam as vantagens do modelo de múltiplos processos para escalabilidade, confiabilidade e performance. Dizer que por que um programa usa threads e o outro usa múltiplos processos, que o que usa threads é automáticamente mais rápido ou mais eficiente é pura burrice. No Linux a criação de processos é extremamente rápida. Em Windows a coisa é diferente. Vide os testes da tweakers.net com escalabilidade do PostgreSQL 8.2 e MySQL 5.0.2 em máquinas com múltiplos processadores com múltiplos cores: http://tweakers.net/reviews/649/7 É óbvio que neste teste quem explodiu foi o MySQL 5.0, enquanto o PostgreSQL segurou muito bem a porrada e manteve escalabilidade linear. O seu administrador está certo que um connection pooler (como se diz isso em português?) ajudará, mas ele ajudaria QUALQUER banco de dados, por que o estabelecimento de uma nova conexão com um SGBD é caro, e não por que o modelo de múltiplos processos do PostgreSQL é ineficiente ou mais lento. Para o PostgreSQL existem vários: pgBouncer, pgpool-2, etc. Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, Nilson Chagas [EMAIL PROTECTED]: Que este novo site, use algum sistema de cache entre o site e o banco (cache de dados + pool de conexão), pois o problema deste site atual, e da grande maioria dos sistemas em php é a ausência desta camada essencial em sites com grande volume de acesso. Vixe! Vejamos. Cache de dados o PostgreSQL já faz — por isso ele consome bastante memória, é o cache; os processos em si não ocupam tanta memória. Pool de conexão é função do servidor de aplicações (antigos monitores de processamento de transações). Isso era um grande problema na época do CGI, e ainda pode ser com PHP de fato. Mas é uma questão de arquitetura e configuração de servidor de aplicação, não de programação nem de base de dados. A questão com programação PHP em si costuma ser segurança e maus modelos de dados. Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai ficar pior porque ele cria um processo servidor para cada conexão. Deste modo, se a cada request for criada uma conexão, consumido dados, e fechada a conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o servidor do banco vai não literalmente 'explodir'. Passei estas impressões para o Shiro a muito tempo atras, quando recomendei outra plataforma para este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é claro, redução da dependência do banco para renderizar cada página), não antecipo um período de tranquilidade. É verdade — mas o gargalo com o MySQL é a própria base. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, Roberto Mello [EMAIL PROTECTED]: Seu administrador está redondamente enganado e mal informado sobre as diferenças entre arquiteturas de threads e múltiplos processos. Em sistemas como Linux Roberto, eu disse que ele tinha razão — porque estou pressupondo, com o nível de conhecimento demonstrado, que estão em MS Windows! ;-) -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Em php tem o adodb que tenho ctz que faz cache. e o metabase, que não tenho ctz. ambos são classes de abstração de banco de dados.. Abraços Jorge Vilela wrote: Algum de vocês conhece algum framework para PHP que faça esse tipo de coisa? spool + cache? Estou pensando em melhorar o acesso ao banco de dados das minhas aplicações pois estão ficando muito pesadas também... E hoje trabalho com php/postgres... []'s Jorge 2008/3/12 Nilson Chagas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: RSRSRSRS' Foi mal este negocio me deixou muito pensativo. Veja o que ele me passou no dia que deu problema apos o upgrade dos servidores: Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na outra e vice versa, condição que nunca termina. Abaixo segue a lista de conexões que estavam ativas. Vou reiniciar o banco, porque o web server não estou nem conseguindo logar na máquina em função disto. Será necessário analisar o que pode estar ocorrendo, haja vista que as configurações basicamente são as mesmas. A única alteração é a versão do PHP (4-5) e do MySQL ( 4-5). Agnaldo mysql show processlist; +-++--+-+-+--++- -+ | Id | User | Host | db | Command | Time | State | Info | +-++--+-+-+--++- -+ | 1299383 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47183 http://ds-1040-1.dedicados.laniway.com.br:47183/ | 1040db2 | Sleep | 45 || NULL | | 1299393 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47193 http://ds-1040-1.dedicados.laniway.com.br:47193/ | 1040db2 | Sleep | 74 || NULL | | 1299402 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47202 http://ds-1040-1.dedicados.laniway.com.br:47202/ | 1040db2 | Sleep | 16 || NULL | | 1299412 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47212 http://ds-1040-1.dedicados.laniway.com.br:47212/ | 1040db2 | Sleep | 74 || NULL | | 1299421 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47221 http://ds-1040-1.dedicados.laniway.com.br:47221/ | 1040db2 | Query |9 | Locked | SELECT count(uid) FROM spnet_users WHERE uid=14065 and banned='N' and moderate | Em 12/03/08, *Benedito A. Cruz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escreveu: Dead block ou deadlock? São coisas bem diferentes. Nilson Chagas wrote: Isto foi me passado: São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de RAM. Os servidores estão (deveriam estar) conectados à internet a uma velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto). Um servidor roda o webserver e o outro os bancos mysql e pgsql. Cada servidor tem uma franquia de tráfego de 1.5TB. O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. Então ele me mandou aquela alertando que o problema no postgresql, pode ser pior, se não for feito um tratamento com um cache. Em 12/03/08, *William Leite Araújo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] escreveu: Bom, temos números para o problema? Número máximo de conexões simultâneas? Existe intranet (área que exija autenticação)? As transações possuem um equilíbrio ou inserção/atualização é mais
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, Nilson Chagas [EMAIL PROTECTED]: Vc e o Bruno me deram uma boa visão sobre o problema, e pelo que entendi vou ter que desenvolver isto por meio do PHP, não e algo que eu possa fazer no banco de dados. Correto?? Uma pergunta, a utilização de view amenizaria o problema??? Pelo contrário, fora do PostgreSQL só o servidor de aplicações e seu /pool/ de conexões. Se você puder colocar toda a lógica no SGBD e deixar a aplicação só para apresentação é que teria uma situação ideal. E sim, VIEWs podem ser uma (pequena) parte da solução. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, Nilson Chagas [EMAIL PROTECTED]: O problema no site atual começou acontecer depois de dois dias do novo servidor no ar. Quando o site passava de 500 usuarios estava dando dead block no banco que é mysql. /Dead locks/ (travamento cruzado) é problema de aplicação, não de banco. Vale a pena você estudar. Para resumir, o processo 1 trava o dado A e pede para travar o B, enquanto o processo 2 trava o B e pede o A. Um fica esperando o outro. Mas de fato o modelo de controle de transações do MySQL é mais sujeito a esse tipo de situações que o do PostgreSQL com seu MVCC. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, [EMAIL PROTECTED] [EMAIL PROTECTED]: Te recomendo outra coisa. Colocar uma placa de rede (de preferência 3 Com) A marca não importa. Importa sim que tenha um bom processador de E/S embutido que não carregue a CPU. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12 Bruno Simioni [EMAIL PROTECTED]: Uma camada intermediária entre as requisições (SQL do PHP) e o acesso ao banco, que se posicionasse de forma a receber requisições, utilizar uma conexão persistida para as queries (através de uma singleton, por exemplo), e devolver as respostas, logando as ações de cada usuário que fez a requisição. PHP já tem conexões persistentes. Já vi várias aplicações em PHP mal escritas que simplesmente não funcionam quando têm conexões persistentes habilitadas. Mas isso é um problema da aplicação, não do PHP ou do banco de dados. Além das conexões persistentes, há também intermediários como o pgbouncer, que mantém um pool de conexões persistentes ao banco, asssim eliminando a necessidade de modificações na aplicação. Para evitar ir ao banco de dados toda hora para solicitar dados freqüentes que não mudam, ora a solução é um bom uso de cache. Não é trabalho do banco de dados adivinhar quais dos seus dados ele deve fazer cache. Ele tenta, mas obviamente é a um nível bem menos específico do que você pode criar conhecendo os detalhes e nuances da sua aplicação. Existem várias soluções nessa área, o memcache sendo uma que vem à mente que é bem suportada no PHP. Seria uma forma bem viável de resolver o problema da criação de processos do postgres, que realmente é grave e inapto pra soluções desse tipo. Envolve um overhead desnecessário pra criação de processos que inviabilizaria a solução. Você tem algum conjunto de dados que demonstre que o uso de múltiplo processos do PostgreSQL é um problema e ainda por cima grave? Me desculpe, sem ofensa, mas dizer que o fato de uma aplicação ser desenhada ao redor do modelo de múltiplos processos é um problema é pura e exclusiva ignorância. Informe-se antes de fazer afirmações de tamanha grandiosidade e consequência. Isso simplesmente não é verdade, e há centenas de aplicações e dados que demonstram isso. Vide o link que postei anteriormente dos testes da tweakers.net. Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
2008/3/12, Evandro Ricardo Silvestre [EMAIL PROTECTED]: No PostgreSQL a tabela só trava se você mandar. acredito que você nunca terá dead lock por excesso de acesso (estou certo??) No PostgreSQL travam-se tuplas sob demanda implícita. Problemas aparecem com transações que atualizam os mesmos dados em ordens inversas, principalmente se faz-se trava explícita (SELECT FOR UPDATE, por exemplo). O mais seguro é desenvolver tudo em nível de isolamento serializável, evita surpresas desagradáveis a um custo bem aceitável. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] dblink+acentuacao
2008/3/12, Heloisa Fernanda [EMAIL PROTECTED]: Estou usando o dblink para pergar dados de um banco e inserir em outro, o q ocorre é q quando executo uma query e os dados retornados contém acentos ou ç a linha é simplesmente ignorada como se ela nao existisse na tabela. Os dois banco são SQL_ASCII. ASCII são sete bits, não contempla acentuação. Migre para ao menos ISO-8859-15, de preferência UTF-8. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Visões materializáveis (Era: Opnião sobre esta declaração)
2008/3/12, Nilson Chagas [EMAIL PROTECTED]: Veja que o que tenho exposto, não só nesta mas na outra tread, são opiniões de terceiros que estou expondo numa lista direcionada ao assunto para ouvir opiniões, não estou falando que compartilho com elas. Sim, entendi — mas realmente é bom saber quem andou escrevendo essas coisa, a gente vai calibrando a credibilidade que atribui a cada fonte. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Opnião sobre esta declaração
Olá Roberto, Seguindo o mesmo raciocínio colocado por Leandro Dutra, há alguns emails atrás, de que não importa qual a marca da placa de rede a ser colocada, mas sim seu desempenho em relação ao processo em si, coloquei o comentário sobre a criação de processos pra esse modelo de aplicação onde há a necessidade de um grande volume de consultas. Atente-se que não estou defendendo a idéia de que é ruim ou inapropriado a criação de vários processos pra cada conexão, em todos os casos. Acho-as necessárias por vezes, onde há a necessidade de separá-las dessa forma. Estou defendendo que pra esse tipo de aplicação seria mais viável uma outra abordagem, que não essa. Não me importa o montante de dados pra demonstrar o que estou defendendo, que graças a sua má interpretação, foi definido como fruto da ignorância. O simples fato de alocar mais memória, paginá-la, ou mesmo, mais uma interrupção no kernel pra relocá-la (no caso de ambientes unix-like), gastaria tempo e memória que, uma simples camada intermediária resolveria o mesmo problema de uma outra forma. Colocando dessa forma, ainda seria possível a construção de uma estrutura de cache que pudesse ser avisado sobre mudanças na base de dados, ou mesmo, de uma maneira mais burra, questionar sobre mudanças no sgbd. Bruno. 2008/3/12 Roberto Mello [EMAIL PROTECTED]: 2008/3/12 Bruno Simioni [EMAIL PROTECTED]: Uma camada intermediária entre as requisições (SQL do PHP) e o acesso ao banco, que se posicionasse de forma a receber requisições, utilizar uma conexão persistida para as queries (através de uma singleton, por exemplo), e devolver as respostas, logando as ações de cada usuário que fez a requisição. PHP já tem conexões persistentes. Já vi várias aplicações em PHP mal escritas que simplesmente não funcionam quando têm conexões persistentes habilitadas. Mas isso é um problema da aplicação, não do PHP ou do banco de dados. Além das conexões persistentes, há também intermediários como o pgbouncer, que mantém um pool de conexões persistentes ao banco, asssim eliminando a necessidade de modificações na aplicação. Para evitar ir ao banco de dados toda hora para solicitar dados freqüentes que não mudam, ora a solução é um bom uso de cache. Não é trabalho do banco de dados adivinhar quais dos seus dados ele deve fazer cache. Ele tenta, mas obviamente é a um nível bem menos específico do que você pode criar conhecendo os detalhes e nuances da sua aplicação. Existem várias soluções nessa área, o memcache sendo uma que vem à mente que é bem suportada no PHP. Seria uma forma bem viável de resolver o problema da criação de processos do postgres, que realmente é grave e inapto pra soluções desse tipo. Envolve um overhead desnecessário pra criação de processos que inviabilizaria a solução. Você tem algum conjunto de dados que demonstre que o uso de múltiplo processos do PostgreSQL é um problema e ainda por cima grave? Me desculpe, sem ofensa, mas dizer que o fato de uma aplicação ser desenhada ao redor do modelo de múltiplos processos é um problema é pura e exclusiva ignorância. Informe-se antes de fazer afirmações de tamanha grandiosidade e consequência. Isso simplesmente não é verdade, e há centenas de aplicações e dados que demonstram isso. Vide o link que postei anteriormente dos testes da tweakers.net. Roberto ___ 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] Opnião sobre esta declaração
2008/3/12, Bruno Simioni [EMAIL PROTECTED]: Não me importa o montante de dados pra demonstrar o que estou defendendo, que graças a sua má interpretação, foi definido como fruto da ignorância. O simples fato de alocar mais memória, paginá-la, ou mesmo, mais uma interrupção no kernel pra relocá-la (no caso de ambientes unix-like), gastaria tempo e memória que, uma simples camada intermediária resolveria o mesmo problema de uma outra forma. O que o Roberto está atacando, Bruno, é o que chamo de otimização precoce, assim como uma aplicação inadequada de conceitos MS Windows a ambientes GNU/Linux. Explicando, preocupar-se com pool de conexões sem saber números é otimização precoce; podem ser umas poucas dúzias de conexões que não farão nem cosquinha. E dizer a priori que criar conexões em processos (PostgreSQL) versus ramos (MySQL) ignorando que em GNU/Linux essa distinção não tem o peso que tem no MS Windows foi, sim, ignorância do tal SysAdmin cuja declaração ensejou o início desta discussão. CQD. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Obter nome da coluna de um tipo RECORD
for each nomeColuna in record
begin
valorColuna = record.nomeColuna
insert into tabela_auditoria(id , nomeColuna , valorColuna )
end
plperl Com plpgsql creio que não será possivel ... Com plperl é assim:
my %newrow = %{$_TD-{new}};
while (($column,$value) = each %newrow)
{
# CODIGO
}
--
Att:
Thiago Risso
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] lista php
Pessoal, Alguem poderia me indicar um lista de PHP boa em portugues, por favor. Tenho que descobrir uma maneira de quando clicar no stop do navegador, dar um pg_cancel_query, cancelar a query. Como cancelar a query é sussi, o problema ta em identificar qnd deu o stop. valeu. Obrigado. Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.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] lista php
http://groups.yahoo.com/group/php-brasilia/ On Wed, Mar 12, 2008 at 5:16 PM, Mr J.L. [EMAIL PROTECTED] wrote: Pessoal, Alguem poderia me indicar um lista de PHP boa em portugues, por favor. Tenho que descobrir uma maneira de quando clicar no stop do navegador, dar um pg_cancel_query, cancelar a query. Como cancelar a query é sussi, o problema ta em identificar qnd deu o stop. valeu. Obrigado. Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Obter nome da coluna de um tipo RECORD
Valter Lobo - Imaginary Software System wrote: for each nomeColuna in record begin valorColuna = record.nomeColuna insert into tabela_auditoria(id , nomeColuna , valorColuna ) end Em pl/pgsql, ainda não é possível fazer isso. E mesmo se isso funcionasse você precisaria de uma conversão explícita de tipo para valorColuna. Por que não utilizas o código do exemplo 38-3 [1] ? [1] http://www.postgresql.org/docs/8.3/static/plpgsql-trigger.html#PLPGSQL-TRIGGER-AUDIT-EXAMPLE -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
