Re: [pgbr-geral] RES: Melhorando o desempenho do PostGre
Bom dia Márcio, além do que já foi dito é importantíssimo também verificar o comportamento da sua aplicação, pois seus dados estão crescendo e talvez alguns problemas de modelagem de dados da sua aplicação não fossem perceptíveis com a amostragem de dados que possuía. Normalmente um tuning de aplicação dá bem mais resultado do que upgrade de hardware. Alex Em 04-05-2010 19:01, Marcio Maestrello escreveu: Utilizamos o Postgres na empresa há dois anos, em um sistema completo (ERP). Acontece que de uns tempo pra cá o sistema se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais que antes era bem rápido, agora se tornou muito lento nas pesquisas e nas inclusões. Eliminamos todos os problemas de redes e infraestrutura, chegando a conclusão que se trata do banco de dados. O DBA comentou que a solução seria a separação dos índices do banco de dados. Assim, teríamos dois discos, um com os índices e outro com o banco de dados. Esse procedimento é complexo, visto que terei que desmontar um RAID 5 e refazê-lo e não tenho certeza que isso dará um desempenho maior no sistema. Gostaria de saber se alguém já utiliza essa solução de índices separados e se realmente vale arriscar todo arranjo já feito para se montar algo assim. Será que com a separação terei mais desempenho?? Agradeço os comentários. Marcio - TI ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Melhorando o desempenho do PostGre
Pessoal e Mrcio principalmente. No acompanhei toda a discusso, mas vocs mencionou: 1. qual seu hardware? 2. SO? 3. verso do Postgresql? 4. tamanho ocupado pelo banco? 5. nmero de acessos simultneos? 6. se isto passou a ocorrer de repente ou veio piorando durante o tempo? 7. se feito vacuum analyse e com que regularidade? 8. se o autovacuum esta ativo? 9. se j foi feito um backup, drop, create e restore desta base? Abraos, Sergio Medeiros Santi Em 05/05/2010 00:16, Marcal Hokama escreveu: From: mar...@npsistemas.com.br To: pgbr-geral@listas.postgresql.org.br Date: Tue, 4 May 2010 19:01:55 -0300 Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre Utilizamos o Postgres na empresa h dois anos, em um sistema completo (ERP). Acontece que de uns tempo pra c o sistema se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais que antes era bem rpido, agora se tornou muito lento nas pesquisas e nas incluses. Eliminamos todos os problemas de redes e infraestrutura, chegando a concluso que se trata do banco de dados. O DBA comentou que a soluo seria a separao dos ndices do banco de dados. Assim, teramos dois discos, um com os ndices e outro com o banco de dados. Esse procedimento complexo, visto que terei que desmontar um RAID 5 e refaz-lo e no tenho certeza que isso dar um desempenho maior no sistema. Gostaria de saber se algum j utiliza essa soluo de ndices separados e se realmente vale arriscar todo arranjo j feito para se montar algo assim. Ser que com a separao terei mais desempenho?? Marcio - TI Ol Marcio, No sei com quantos discos fsicos voc est montando seu RAID 5, mas geralmente essa questo de separao de ndices e dados til quando voc tem os dois no mesmo disco fsico, e o hardware no consegue dar conta do grande nmero de requisies ao dispositivo, gerando conteo e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados so distribudos entre os discos fsicos, minimizando a questo da conteno em um nico disco fsico (mas depende tambm de quantos discos fsicos formam o seu volume). Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode no ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situaes, mas acredito que possa servir tambm para PostgreSQL: http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c=myl=ens=k12 Outra idia pode ser verificar qual a tecnologia dos seus discos fsicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situao, pensar num upgrade. Maral de Lima Hokama -- e-mail: mhok...@hotmail.com _ CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA. http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregadorocid=Hotmail:MSN:Messenger:Tagline:1x1:agregador:- ___ 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] RAID 10
Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RAID 10
Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.comescreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RAID 10
Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RAID 10
Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.comescreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] pg_listener
Olá pessoal, meu sistema se utiliza do catálogo pg_listener para verificar a duplicidade de usuário (do sistema). Dessa forma, realizada a conexão e identificado o usuário (do sistema), é disparada a seguinte audição. LISTEN NOMEDOUSUARIO Assim, é só pesquisar o catálogo pg_listener e ver quem está conectado, utilizando apenas um usuário do PostgreSql. E quando a conexão é fechada, o registro do catálogo é automaticamente excluído. Entretanto, recentemente, houve queda de energia com desligamento anormal do servidor. Logo, o pg_listener não foi atualizado, deixando o citado usuário gravado. Consegui detectar o problema e remover manualmente o registro do catálogo. Todavia, acho que, na inicialização do servidor, o catálogo deveria ser limpado evitando audição desnecessária. Com a palavra os nobres colegas... MarceloG Ao conectar-se om o nome do usuário ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RAID 10
Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] RAID 10
Em 5 de maio de 2010 09:27, Pedro Espíndola pespindo...@gmail.comescreveu: Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. Este é um setup básico bastante razoável, acredito eu. Mas nada lhe impede de fazer um único RAID 10 com os 6 discos. Neste caso, o particionamento não tem influência no desempenho, a não ser que você opte por utilizar sistemas de arquivos diferentes e ajustes específicos em cada partição. Algo que eu guardo na manga só para quem tem uma boa equipe de apoio. Algumas sugestões no final da minha palestra do PGCon Brasil 2009: http://www.slideshare.net/gofull/slideshow/discos-cia-em-postgresql []s Fábio Telles Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] RAID 10
Maravilha Fábio valiosas informações. Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 5 de maio de 2010 09:27, Pedro Espíndola pespindo...@gmail.com escreveu: Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. Este é um setup básico bastante razoável, acredito eu. Mas nada lhe impede de fazer um único RAID 10 com os 6 discos. Neste caso, o particionamento não tem influência no desempenho, a não ser que você opte por utilizar sistemas de arquivos diferentes e ajustes específicos em cada partição. Algo que eu guardo na manga só para quem tem uma boa equipe de apoio. Algumas sugestões no final da minha palestra do PGCon Brasil 2009: http://www.slideshare.net/gofull/slideshow/discos-cia-em-postgresql []s Fábio Telles Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ 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 -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] Melhorando o desempenho do PostGre
Em 4 de maio de 2010 22:01, Mozart Hasse mozart.ha...@usa.net escreveu: corte * _entupa_ suas tabelas de índices (a minha de notas tem mais de 50), pelo menos dois por chave estrangeira mais as combinações de consultas frequentes. Não, não acho que a gravação será responsável pelo seu gargalo nem com o dobro do que eu costumo colocar; corte Caro Mozart, Não pude deixar de ver esse comentário sobre entupir as tabelas de índices e gostaria de saber exatamente o porque disso e trocar alguma idéia... Atualmente trabalho no desenvolvimento e manutenção um ERP para órgãos públicos (prefeituras, camaras, autarquias, fundações, etc) e temos mais de 2mil tabelas sendo que a que mais tenho índices totalizam 12, e isso que não é a minha maior tabela, pois as duas maiores uma tenho 5 indices e outra 8 indices... Que fique bem claro que não estou de maneira alguma criticando a sua forma de ge renciar esses objetos ou querendo dizer que a minha forma de trabalho seja mais adequada, mas gostaria muito de saber os motivos até para trocar experiência e poder validar o que estamos fazendo... e até mesmo porque não conheço o seu cenário e vice-versa, portanto é complicado alguém dizer que a minha ou a sua forma de trabalho é melhor ou pior... acredito que trocando experiências todos iremos somar em seus ambientes (esse parágrafo é para evitar algum *flame* e acabarem desviando a conversa como as vezes acontece) Cordialmente, -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] RAID 10
Fábio só mais uma pergunta com relação a separação: Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. tablespace: vc se refere ao q eu criar com tablespace ficar nesta área ? o q são os archives e os datafiles ? obr Pedro 2010/5/5 Pedro Espíndola pespindo...@gmail.com: Maravilha Fábio valiosas informações. Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 5 de maio de 2010 09:27, Pedro Espíndola pespindo...@gmail.com escreveu: Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. Este é um setup básico bastante razoável, acredito eu. Mas nada lhe impede de fazer um único RAID 10 com os 6 discos. Neste caso, o particionamento não tem influência no desempenho, a não ser que você opte por utilizar sistemas de arquivos diferentes e ajustes específicos em cada partição. Algo que eu guardo na manga só para quem tem uma boa equipe de apoio. Algumas sugestões no final da minha palestra do PGCon Brasil 2009: http://www.slideshare.net/gofull/slideshow/discos-cia-em-postgresql []s Fábio Telles Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem antes de planejar a sua divisão. Atualmente a divisão é feita mais por razões de segurança do que desempenho. Ok, por desempenho também, mas isso é para quem tem mitos discos para brincar. Dê uma olhada em: http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/ []s Fábio Telles abs Pedro 2010/5/4 Marcal Hokama mhok...@hotmail.com: Date: Tue, 4 May 2010 08:55:39 -0300 From: pespindo...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] RAID 10 Bom dia pessoal, temos um servidor com 6 discos (100 GB), nossa intenção é dividir as informações em 3 partes, ou seja, cada uma em 1 disco, pensamos em implementar RAID 10. A minha pergunta é como esta implementação no final fica visível para nós, para podermos setar as informações cada uma em um disco, conforme planejamos. Ou o fato de ter RAID 0 no final vou ter visivelmente apenas 1 disco com 300GB ? Não sei se ficou claro, mas obrigado Abs Pedro Olá Pedro, Isso. Após a configuração do controlador RAID, ficará visível apenas 1 disco com 300 GB. Marçal de Lima Hokama --- mhok...@hotmail.com POR DIA 63.912 COMPUTADORES SÃO INFECTADOS POR VÍRUS. LEIA DICAS DE SEGURANÇA. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br
Re: [pgbr-geral] pg_listener
Em 5 de maio de 2010 09:27, MarceloG nrhce...@teleon.com.br escreveu: Olá pessoal, meu sistema se utiliza do catálogo pg_listener para verificar a duplicidade de usuário (do sistema). Dessa forma, realizada a conexão e identificado o usuário (do sistema), é disparada a seguinte audição. LISTEN NOMEDOUSUARIO Assim, é só pesquisar o catálogo pg_listener e ver quem está conectado, utilizando apenas um usuário do PostgreSql. E quando a conexão é fechada, o registro do catálogo é automaticamente excluído. Entretanto, recentemente, houve queda de energia com desligamento anormal do servidor. Logo, o pg_listener não foi atualizado, deixando o citado usuário gravado. Consegui detectar o problema e remover manualmente o registro do catálogo. Todavia, acho que, na inicialização do servidor, o catálogo deveria ser limpado evitando audição desnecessária. Com a palavra os nobres colegas... Não seria o caso de verificar pela view pg_stat_activity se o processo ainda está ativo??? E apagar caso o pg_listener.listenerpid não existir na pg_stat_activity.procpid ??? -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] RAID 10
Em 5 de maio de 2010 10:41, Pedro Espíndola pespindo...@gmail.comescreveu: Fábio só mais uma pergunta com relação a separação: Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. tablespace: vc se refere ao q eu criar com tablespace ficar nesta área ? Entenda o tablespace como a sua área de dados. Por padrão, quando você cria um cluster com o initdb são criados 2 tablespaces, veja: postgres=# \db+ Lista das tablespaces Nome| Dono | Local | Privilégios de acesso | Descrição +--+---+---+--- pg_default | postgres | | | pg_global | postgres | | | (2 linhas) É claro que você pode criar novos tablespaces. Veja novamente outra palestra sobre melhores práticas que eu fiz no PGCon Brasil 2008: http://www.slideshare.net/gofull/slideshow/fazendo-um-elefante-passar-debaixo-da-porta-pgconbr-presentation o q são os archives e os datafiles ? Vejamos: os datafiles, como o nome diz, são os arquivos de dados que estão contidos no seu tablespace. Simples assim. Os archives ou o arquivamento dos logs do WAL, são cópias dos logs do Write Ahead Log. Toda base OLTP deve ter o arquivamento ativado. Faça um favor a si mesmo e leia com atenção este capítulo da documentação: http://www.postgresql.org/docs/9.0/static/high-availability.html (aqui, da versão 9.0 que está para sair) Em resumo, os archives são fundamentais para a recuperação de desastres com a técnica de Point In Time Recovery, ou simplesmente PITR. Sem isso, você pode perder os seus dados às 19h, voltar o backup feito às 2h e recuperar toda a sua base até às 18:59. Fora as funcionalidades de Stand By que ele promove. Então, se você acha que backup é tudo igual, leia sobre isso na documentação, estude, aprenda e seja feliz, principalmente no dia em que seus discos decidirem te sacanear... e é claro que isso VAI acontecer um dia. []s Fábio Telles obr Pedro 2010/5/5 Pedro Espíndola pespindo...@gmail.com: Maravilha Fábio valiosas informações. Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 5 de maio de 2010 09:27, Pedro Espíndola pespindo...@gmail.com escreveu: Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. Este é um setup básico bastante razoável, acredito eu. Mas nada lhe impede de fazer um único RAID 10 com os 6 discos. Neste caso, o particionamento não tem influência no desempenho, a não ser que você opte por utilizar sistemas de arquivos diferentes e ajustes específicos em cada partição. Algo que eu guardo na manga só para quem tem uma boa equipe de apoio. Algumas sugestões no final da minha palestra do PGCon Brasil 2009: http://www.slideshare.net/gofull/slideshow/discos-cia-em-postgresql []s Fábio Telles Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos, por exemplo, indices no disco 1, catálogo no disco 2 e log no disco 3. Para utilizar desta forma devo usar apenas RAID 1, ok ? qual seria outra configuração viavel qdo temos 6 discos ? Pense bem
Re: [pgbr-geral] RAID 10
Tranquilo, achei que fosse isto mesmo, só não estava familiarizado com o termo archives para os logs do WAL. Obr Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 5 de maio de 2010 10:41, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio só mais uma pergunta com relação a separação: Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. tablespace: vc se refere ao q eu criar com tablespace ficar nesta área ? Entenda o tablespace como a sua área de dados. Por padrão, quando você cria um cluster com o initdb são criados 2 tablespaces, veja: postgres=# \db+ Lista das tablespaces Nome | Dono | Local | Privilégios de acesso | Descrição +--+---+---+--- pg_default | postgres | | | pg_global | postgres | | | (2 linhas) É claro que você pode criar novos tablespaces. Veja novamente outra palestra sobre melhores práticas que eu fiz no PGCon Brasil 2008: http://www.slideshare.net/gofull/slideshow/fazendo-um-elefante-passar-debaixo-da-porta-pgconbr-presentation o q são os archives e os datafiles ? Vejamos: os datafiles, como o nome diz, são os arquivos de dados que estão contidos no seu tablespace. Simples assim. Os archives ou o arquivamento dos logs do WAL, são cópias dos logs do Write Ahead Log. Toda base OLTP deve ter o arquivamento ativado. Faça um favor a si mesmo e leia com atenção este capítulo da documentação: http://www.postgresql.org/docs/9.0/static/high-availability.html (aqui, da versão 9.0 que está para sair) Em resumo, os archives são fundamentais para a recuperação de desastres com a técnica de Point In Time Recovery, ou simplesmente PITR. Sem isso, você pode perder os seus dados às 19h, voltar o backup feito às 2h e recuperar toda a sua base até às 18:59. Fora as funcionalidades de Stand By que ele promove. Então, se você acha que backup é tudo igual, leia sobre isso na documentação, estude, aprenda e seja feliz, principalmente no dia em que seus discos decidirem te sacanear... e é claro que isso VAI acontecer um dia. []s Fábio Telles obr Pedro 2010/5/5 Pedro Espíndola pespindo...@gmail.com: Maravilha Fábio valiosas informações. Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 5 de maio de 2010 09:27, Pedro Espíndola pespindo...@gmail.com escreveu: Estamos analisando a possibilidade de já termos este disco Hot Spare sim ! com relação ao questionamento anterior, vc escolheria partições ou discos, leia-se, RAID 10 ou RAID 1 ? Você pode ter um RAID 10 com 4 discos contendo tablespaces e um RAID1 com 2 discos contendo o SO + pgxlog + archives + dump. Este é um setup básico bastante razoável, acredito eu. Mas nada lhe impede de fazer um único RAID 10 com os 6 discos. Neste caso, o particionamento não tem influência no desempenho, a não ser que você opte por utilizar sistemas de arquivos diferentes e ajustes específicos em cada partição. Algo que eu guardo na manga só para quem tem uma boa equipe de apoio. Algumas sugestões no final da minha palestra do PGCon Brasil 2009: http://www.slideshare.net/gofull/slideshow/discos-cia-em-postgresql []s Fábio Telles Abs Pedro 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Bom... era uma boa idéia começar a pensar nisso o que você acha? Ok, se você tem um sysadmin que monitora os logs do servidor todo santo dia, e tem um HD em mãos para substituir assim que aparecer o problema. Até que você pode viver sem um Hot Spare. Mas... se você tem um HD em mãos, não é melhor colocar ele como Hot Spare logo? []s Fábio Telles Em 5 de maio de 2010 09:11, Pedro Espíndola pespindo...@gmail.com escreveu: Não ! 2010/5/5 Fábio Telles Rodriguez fabio.tel...@gmail.com: Você colocou algum Hot Spare na sua conta? Atenciosamente, Em 5 de maio de 2010 08:53, Pedro Espíndola pespindo...@gmail.com escreveu: Fábio ótimo material, levando em consideração 6 discos: seria preferivel usar RAID 10, existirá apenas 1 disco lógico, então particionamos esse disco em áreas correspondentes ao nosso plano de armazenamento (Logs de transação e archives uma área, datafiles outra área, ...) ou usamos RAID 1, e ficamos limitados as 3 unidades lógicas e fazemos o mesmo processo de divisão das informações nestes 3 discos ? abs Pedro 2010/5/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 4 de maio de 2010 15:01, Pedro Espíndola pespindo...@gmail.com escreveu: só ratificando, então para o meu caso, o RAID 10 não serve se eu quiser fisicamente dividir minhas informações em 3 discos,
[pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Pessoal, Segue as respostas abaixo. Agradeço muito as repostas enviadas e segue as respostas as perguntas efetuadas 1. qual é seu hardware? R: Servidor Dell Power Edge 1950III com processador Intel Quad Core Xeon, 2,33 GHz, 2x6Mb cachê, 3 Gb RAM 3 discos SAS (RAID 5) de 73 Gb cada um deles. 2. SO? LINUX Red Hat 3. versão do Postgresql? R: Versao 8.2 4. Tamanho ocupado pelo banco? R.: 11 GB 5. Número de acessos simultâneos? R.: São 80 usuários utilizando o sistema e acessando o BD. 6. se isto passou a ocorrer de repente ou veio piorando durante o tempo? R.: Vem ocorrendo há algum tempo e piorando durante o tempo 7. se é feito vacuum analyse e com que regularidade? R. Não é feito 8. se o autovacuum esta ativo? R.: Não 9. se já foi feito um backup, drop, create e restore desta base? R.: Neste item, acredito que nada foi feito em relação a isso. Abraços, Sergio Medeiros Santi Em 05/05/2010 00:16, Marcal Hokama escreveu: From: mar...@npsistemas.com.br To: pgbr-geral@listas.postgresql.org.br Date: Tue, 4 May 2010 19:01:55 -0300 Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre Utilizamos o Postgres na empresa há dois anos, em um sistema completo (ERP). Acontece que de uns tempo pra cá o sistema se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais que antes era bem rápido, agora se tornou muito lento nas pesquisas e nas inclusões. Eliminamos todos os problemas de redes e infraestrutura, chegando a conclusão que se trata do banco de dados. O DBA comentou que a solução seria a separação dos índices do banco de dados. Assim, teríamos dois discos, um com os índices e outro com o banco de dados. Esse procedimento é complexo, visto que terei que desmontar um RAID 5 e refazê-lo e não tenho certeza que isso dará um desempenho maior no sistema. Gostaria de saber se alguém já utiliza essa solução de índices separados e se realmente vale arriscar todo arranjo já feito para se montar algo assim. Será que com a separação terei mais desempenho?? Marcio - TI Olá Marcio, Não sei com quantos discos físicos você está montando seu RAID 5, mas geralmente essa questão de separação de índices e dados é útil quando você tem os dois no mesmo disco físico, e o hardware não consegue dar conta do grande número de requisições ao dispositivo, gerando conteção e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados são distribuídos entre os discos físicos, minimizando a questão da contenção em um único disco físico (mas depende também de quantos discos físicos formam o seu volume). Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode não ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situações, mas acredito que possa servir também para PostgreSQL: http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c= my http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c =myl=ens=k12 l=ens=k12 Outra idéia pode ser verificar qual é a tecnologia dos seus discos físicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situação, pensar num upgrade. Marçal de Lima Hokama -- e-mail: mhok...@hotmail.com _ CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA. http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregador http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregadoroc id=Hotmail:MSN:Messenger:Tagline:1x1:agregador: ocid=Hotmail:MSN:Messenger:Tagline:1x1:agregador:- ___ 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] RES: RES: Melhorando o desempenho do PostGre
Caro Marçal, Sao 3 discos de 73 GB (tecnologia SAS) em RAID 5. Servidor Dell 1950III, com 3 GB de memória RAM. Agradeço muito as respostas e as sugestões enviadas. São de grande ajuda para nossas decisões. Um abraço, Marcio - TI -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de Marcal Hokama Enviada em: quarta-feira, 5 de maio de 2010 00:17 Para: pgbr-geral@listas.postgresql.org.br Assunto: Re: [pgbr-geral] RES: Melhorando o desempenho do PostGre From: mar...@npsistemas.com.br To: pgbr-geral@listas.postgresql.org.br Date: Tue, 4 May 2010 19:01:55 -0300 Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre Utilizamos o Postgres na empresa há dois anos, em um sistema completo (ERP). Acontece que de uns tempo pra cá o sistema se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais que antes era bem rápido, agora se tornou muito lento nas pesquisas e nas inclusões. Eliminamos todos os problemas de redes e infraestrutura, chegando a conclusão que se trata do banco de dados. O DBA comentou que a solução seria a separação dos índices do banco de dados. Assim, teríamos dois discos, um com os índices e outro com o banco de dados. Esse procedimento é complexo, visto que terei que desmontar um RAID 5 e refazê-lo e não tenho certeza que isso dará um desempenho maior no sistema. Gostaria de saber se alguém já utiliza essa solução de índices separados e se realmente vale arriscar todo arranjo já feito para se montar algo assim. Será que com a separação terei mais desempenho?? Marcio - TI Olá Marcio, Não sei com quantos discos físicos você está montando seu RAID 5, mas geralmente essa questão de separação de índices e dados é útil quando você tem os dois no mesmo disco físico, e o hardware não consegue dar conta do grande número de requisições ao dispositivo, gerando conteção e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados são distribuídos entre os discos físicos, minimizando a questão da contenção em um único disco físico (mas depende também de quantos discos físicos formam o seu volume). Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode não ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situações, mas acredito que possa servir também para PostgreSQL: http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c= myl=ens=k12 Outra idéia pode ser verificar qual é a tecnologia dos seus discos físicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situação, pensar num upgrade. Marçal de Lima Hokama -- e-mail: mhok...@hotmail.com _ CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA. http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregadoroci d=Hotmail:MSN:Messenger:Tagline:1x1:agregador:- ___ 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] PROBLEMAS DE PERFORMANCE
Pessoal Bom dia, estou enviando esse email, porquanto estou com sério problemas de performance eu meu banco de dados. Segue meu cenário: servidores fisicos 2 servidores - DLG 160 com 38 GB de ram cada um, trabalhando em cluster.. (hd dos servidres e de 146GB) - cada máquina fisica tem 2 CPU quad..da intel storage com 8 discos de 400 gb, trabalhando em raid. Sistema operacional instalado nos Servidores fisicos: VMWARE ENTERPRISE ESX 4.0 Tenho umas 13 máquinas virtuais criadas entre windows e linux, Entretanto o servidor de banco de dados(maquina virtual) que de fato é o postgresql 8.1.3 com a seguinte configuração: 6 (cpu's) 16GB de ram 150GB na partição /dados onde está montado o cluster do banco de dados de produção. 10 GB onde está instalado a distribuição SUSE Linux Enterprise 11 64bits Problema: Acontece que, pessoal começa usar o sistema pela parte da manhã, e por volta de 10:00hrs da manhão o ERP começa a ficar bastante lento até chegar o ponto de travar, e percebo que quanto mais recurso disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem hardware que de conta disso. as consultas, a CPu e memoria vai para o ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, já segui alguns conselhos para realizar tunnig no sgbd, mas não deu certo.., gostaria da opinião de vocês o que eu tenho que fazer para resolver esse problema. segue o link para vocês verem minhas conf's postgresql.conf http://200.175.138.130/postgresql.conf System V: (configuração defaul que veio, eu nem mexi em nada) kernel.shmmax = 18446744073709551615 kernel.shmall = 1152921504606846720 kernel.shmmni = 4096 estado da maquina agora sem problemas: (porem a qualquer momento ela pode apresenta problemas, principalmente quando os usuarios racam relatorios pesados).. a rede hoje tem cerca de 150 usuarios ativos no sistema. uso de memoria = dberp:/dados/pgsql # cat /proc/meminfo MemTotal: 16307396 kB MemFree: 1711440 kB Buffers: 23724 kB Cached:4221676 kB SwapCached: 80676 kB Active:4742244 kB Inactive: 1533132 kB SwapTotal: 1044216 kB SwapFree: 592144 kB Dirty:1012 kB Writeback: 0 kB AnonPages: 1954908 kB Mapped:1075736 kB Slab:70516 kB SReclaimable:34456 kB SUnreclaim: 36060 kB PageTables: 201260 kB NFS_Unstable:0 kB Bounce: 0 kB WritebackTmp:0 kB CommitLimit: 9197912 kB Committed_AS: 3784748 kB VmallocTotal: 34359738367 kB VmallocUsed:306132 kB VmallocChunk: 34359431799 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M: 16766976 kB dberp:/dados/pgsql # == cpu === top - 11:55:46 up 21:26, 2 users, load average: 0.71, 0.40, 2.34 Tasks: 197 total, 1 running, 194 sleeping, 2 stopped, 0 zombie Cpu0 : 2.2%us, 0.8%sy, 0.0%ni, 95.8%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 14.8%us, 1.7%sy, 0.0%ni, 71.9%id, 11.3%wa, 0.0%hi, 0.1%si, 0.0%st Cpu2 : 1.5%us, 0.8%sy, 0.0%ni, 97.2%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.3%us, 0.7%sy, 0.0%ni, 98.6%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.2%us, 0.7%sy, 0.0%ni, 98.9%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.2%us, 0.6%sy, 0.0%ni, 99.1%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16307396k total, 14723100k used, 1584296k free,24536k buffers Swap: 1044216k total, 451616k used, 592600k free, 4371700k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 11807 postgres 20 0 1108m 303m 296m D5 1.9 1:02.66 postmaster 1 root 20 0 1064 76 32 S0 0.0 0:15.54 init 2 root 15 -5 000 S0 0.0 0:00.02 kthreadd 3 root RT -5 000 S0 0.0 0:00.04 migration/0 4 root 15 -5 000 S0 0.0 0:00.18 ksoftirqd/0 5 root RT -5 000 S0 0.0 0:00.02 migration/1 6 root 15 -5 000 S0 0.0 0:00.06 ksoftirqd/1 7 root RT -5 000 S0 0.0 0:00.00 migration/2 8 root 15 -5 000 S0 0.0 0:00.02 ksoftirqd/2 9 root RT -5 000 S0 0.0 0:00.00 migration/3 10 root 15 -5 000 S0 0.0 0:00.00 ksoftirqd/3 11 root RT -5 000 S0 0.0 0:00.02 migration/4 12 root 15 -5 000 S0 0.0 0:00.00 ksoftirqd/4 13 root RT -5 000 S0 0.0 0:00.00 migration/5 14 root 15 -5 000 S0 0.0 0:00.00 ksoftirqd/5 15 root 15 -5 000 S0 0.0
Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Em 5 de maio de 2010 11:29, Marcio Maestrello mar...@npsistemas.com.brescreveu: Pessoal, Segue as respostas abaixo. Agradeço muito as repostas enviadas e segue as respostas as perguntas efetuadas 1. qual é seu hardware? R: Servidor Dell Power Edge 1950III com processador Intel Quad Core Xeon, 2,33 GHz, 2x6Mb cachê, 3 Gb RAM 3 discos SAS (RAID 5) de 73 Gb cada um deles. Calma. Respire fundo. Conte até 10 lentamente. Expire, inspire. Sim, eu já vi isso antes. RAID 5 com 3 discos. Não vou explicar o porquê aqui, você vai ter que pesquisar um pouco. Só vou dizer o seguinte: Desmonta o RAID 5 e monta um RAID 1 com um disco de spare. Melhor negócio: mais rápido, mais seguro. ISSO é MUITO SÉRIO. 3. versão do Postgresql? R: Versao 8.2 Bom, eu pensaria em migrar para o 8.4. Sim, há bons motivos para isso, particularmente o desempenho. 6. se isto passou a ocorrer de repente ou veio piorando durante o tempo? R.: Vem ocorrendo há algum tempo e piorando durante o tempo Sim, você tem notado aumento no tamanho / número de registros de algum objeto no banco nos últimos meses? Você tem algum tipo de acompanhamento disso? 7. se é feito vacuum analyse e com que regularidade? R. Não é feito Milagre não existe. Leia a documentação. Rode um vacuum analyse no final-de-semana (um backup antes, por favor), veja como se comporta durante a semana. 8. se o autovacuum esta ativo? R.: Não Se o Vacuum Analyse se comportar bem e você subitamente perceber que a performance melhorou 2000%, ative o autovacuum e seja feliz. No 8.4 ele funciona melhor ainda. 9. se já foi feito um backup, drop, create e restore desta base? R.: Neste item, acredito que nada foi feito em relação a isso. Não acredito != Não foi, cuidado. Meus 2 centavos. []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE
Em 5 de maio de 2010 12:01, sebastiao fidencio sfiden...@gmail.comescreveu: Pessoal Bom dia, estou enviando esse email, porquanto estou com sério problemas de performance eu meu banco de dados. Segue meu cenário: servidores fisicos 2 servidores - DLG 160 com 38 GB de ram cada um, trabalhando em cluster.. (hd dos servidres e de 146GB) - cada máquina fisica tem 2 CPU quad..da intel storage com 8 discos de 400 gb, trabalhando em raid. Sistema operacional instalado nos Servidores fisicos: VMWARE ENTERPRISE ESX 4.0 Tenho umas 13 máquinas virtuais criadas entre windows e linux, Entretanto o servidor de banco de dados(maquina virtual) que de fato é o postgresql 8.1.3 com a seguinte configuração: Vamos lá: 1) Eu não utilizaria um SGDB em produção num SO virtualizado. Não é uma boa idéia por definição. Pode ser preconceito meu, os tempos podem estar mudando, mas tem que saber muito bem o que está fazendo para entrar nessa. 2) Os discos no seu SO estão sendo repartidos com mais alguém? Tem certeza. Se você coloca fé no seu VM, tudo bem, mas tem que ter certeza de que os discos do banco de dados não são compartilhados com mais ninguém. Certeza absoluta. 3) O PostgreSQL 8.1.3 está meio velinho, não acha? Tá na hora de atualizar. postgresql.conf http://200.175.138.130/postgresql.conf System V: (configuração defaul que veio, eu nem mexi em nada) kernel.shmmax = 18446744073709551615 kernel.shmall = 1152921504606846720 kernel.shmmni = 4096 Caracoles? O que é isso no seu shmmax? Isso não pode ser bom, certo? Se você tem 16GB, um número razoável seria algo como 16GB/3, ou ~ 5368709120 . NUNCA passe de 2/3 da RAM aqui. Você estará correndo um risco que vai garantir boas horas diversão quando tudo explodir. As informações adicionais que você enviou não ajudam se não forem coletadas num momento de lentidão. Tente o SAR ou outra ferramenta de monitoramento como o Munin, Zabbix, etc. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PROBLEMAS DE PERFORMANCE
Em 5 de maio de 2010 12:01, sebastiao fidencio sfiden...@gmail.com escreveu: Pessoal Bom dia, estou enviando esse email, porquanto estou com sério problemas de performance eu meu banco de dados. Segue meu cenário: servidores fisicos 2 servidores - DLG 160 com 38 GB de ram cada um, trabalhando em cluster.. (hd dos servidres e de 146GB) - cada máquina fisica tem 2 CPU quad..da intel storage com 8 discos de 400 gb, trabalhando em raid. Sistema operacional instalado nos Servidores fisicos: VMWARE ENTERPRISE ESX 4.0 Tenho umas 13 máquinas virtuais criadas entre windows e linux, Entretanto o servidor de banco de dados(maquina virtual) que de fato é o postgresql 8.1.3 com a seguinte configuração: 6 (cpu's) 16GB de ram 150GB na partição /dados onde está montado o cluster do banco de dados de produção. 10 GB onde está instalado a distribuição SUSE Linux Enterprise 11 64bits Problema: Acontece que, pessoal começa usar o sistema pela parte da manhã, e por volta de 10:00hrs da manhão o ERP começa a ficar bastante lento até chegar o ponto de travar, e percebo que quanto mais recurso disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem hardware que de conta disso. as consultas, a CPu e memoria vai para o ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, já segui alguns conselhos para realizar tunnig no sgbd, mas não deu certo.., gostaria da opinião de vocês o que eu tenho que fazer para resolver esse problema. segue o link para vocês verem minhas conf's postgresql.conf http://200.175.138.130/postgresql.conf Se não me engano na versão 8.1.x o default do autovacuum é off. Você não informa se roda ou não um vacuum periodicamente e isso pode acarretar uma perda gradativa de performance. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] NÃO CONSEGUE INICIAR O SERVIÇO
Cenário: PostgreSQL 8.2.11 SO Windows Vista Ultimate 64 ATHLON PHENOM QUAD-COR Servidor caiu por falha de hardware e agora ao retornar o serviço fica iniciando mas não conclui a operação e por consequência não disponibiliza os dados. Fiz nova instalação em outra pasta e o banco entrou normalmente com os dados vazio (nova instalação) então copiei a pasta baseda instalação baleada para dentro da pasta data, liberei as permissões de escrita para todos os administradores e não consegue subir o serviço assim mesmo. Alguém tem uma idéia do que posso tentar ainda?? Mello 41.9957-2007 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NÃO CONSEGUE INICIAR O SERVIÇO
Em 5 de maio de 2010 12:53, José Mello Júnior jose.mello.jun...@gmail.com escreveu: Cenário: PostgreSQL 8.2.11 SO Windows Vista Ultimate 64 ATHLON PHENOM QUAD-COR Servidor caiu por falha de hardware e agora ao retornar o serviço fica iniciando mas não conclui a operação e por consequência não disponibiliza os dados. Fiz nova instalação em outra pasta e o banco entrou normalmente com os dados vazio (nova instalação) então copiei a pasta baseda instalação baleada para dentro da pasta data, liberei as permissões de escrita para todos os administradores e não consegue subir o serviço assim mesmo. Alguém tem uma idéia do que posso tentar ainda?? O que dizem os logs? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Inclusão LATIN1 (ISO 8859-1)
Senhores, Estou com o seguinte problema. Tenho Postgres 8.2 no ambiente Windows de desenvolvimento com LATIN1 (ISO 8859-1). Preciso manter o ENCODING LATIN1 (ISO 8859-1) no ambiente Linux Ubuntu onde a versão do Postgres é 8.3 e como default o ENCODING UTF8. Os projetos gerados ponto WAR para rodar no ambiente Java do Linux precisam dessa configuração anterior LATIN1. Qual a melhor saída? Grato, George ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Inclusão LATIN1 (ISO 8859-1)
Mude o locale do Ubuntu adicionando o suporte ao Latin1. []s Em 5 de maio de 2010 13:22, George M Tabatinga george.tabati...@gmail.comescreveu: Senhores, Estou com o seguinte problema. Tenho Postgres 8.2 no ambiente Windows de desenvolvimento com LATIN1 (ISO 8859-1). Preciso manter o ENCODING LATIN1 (ISO 8859-1) no ambiente Linux Ubuntu onde a versão do Postgres é 8.3 e como default o ENCODING UTF8. Os projetos gerados ponto WAR para rodar no ambiente Java do Linux precisam dessa configuração anterior LATIN1. Qual a melhor saída? Grato, George ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorando o desempenho do PostGre
Olá Fabrízio, From: Fabrízio de Royes Mello fabriziome...@gmail.com Em 4 de maio de 2010 22:01, Mozart Hasse mozart.ha...@usa.net escreveu: Não pude deixar de ver esse comentário sobre entupir as tabelas de índices e gostaria de saber exatamente o porque disso e trocar alguma idéia... É que preferi criar os índices que com quase certamente serão necessários ao invés de esperar o óbvio. Quando faço uma chave estrangeira, quase certamente terei consultas com joins entre a tabela pai e a filha, logo nada mais sensato do que criar um índice para isso. Assim, o otimizador já tem estatísticas e índices eficientes para buscar registros pais com poucos filhos. Buscar dados do pai partindo do filho também é rotina devido à grande quantidade de relacionamentos e pesquisas. Por isso, logo ao criar a base já colocamos, para cada chave estrangeira, dois índices. Exemplo: transportadora de redespacho da nota fiscal ALTER TABLE notavend ADD CONSTRAINT notavend_transporredesp FOREIGN KEY (transpredesp, filtransp, emptransp) REFERENCES transpor (transportadora, filial, empresa) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION; Por conta desse relacionamento crio automaticamente os seguintes índices: -- agiliza a consulta de notas da transportadora, por exemplo CREATE INDEX i1_notavend_transporredesp ON notavend USING btree (transpredesp, filtransp, emptransp, notavenda, serievenda, filial, empresa); -- agiliza a busca de detalhes da nota em consultas maiores CREATE INDEX i2_notavend_transporredesp ON notavend USING btree (notavenda, serievenda, filial, empresa, transpredesp, filtransp, emptransp); Como viu são os mesmos campos em ordem diferente para que pelo menos um deles pareça bom para o otimizador. É difícil enmerar em quantos casos elas são usadas, mas teoricamente o otimizador preciará de um dos dois em praticamente qualquer consulta que faça JOIN entre essas tabelas usando esses campos. Além desses, ainda sobram muitas consultas que têm problemas de desempenho, e para as principais, usadas em processos críticos, criamos índices específicos que acabam sendo usados em 2 ou 3,com sorte 6 consultas cada um. Na tabela de notas, por exemplo, tenho 7 personalizados mais os pares para cada chaves estrangeira. Atualmente trabalho no desenvolvimento e manutenção um ERP para órgãos públicos (prefeituras, camaras, autarquias, fundações, etc) e temos mais de 2mil tabelas sendo que a que mais tenho índices totalizam 12, e isso que não é a minha maior tabela, pois as duas maiores uma tenho 5 indices e outra 8 indices... Crie os pares para chaves estrangeiras que vai acabar no mesmo patamar que eu... Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Inclusão LATIN1 (ISO 8859-1)
Fábio, Como fazer isso? preciso passar as instruções para a pessoa responsável pelo ambiente Linux. Grato, George Em 5 de maio de 2010 13:28, Fábio Telles Rodriguez fabio.tel...@gmail.comescreveu: Mude o locale do Ubuntu adicionando o suporte ao Latin1. []s Em 5 de maio de 2010 13:22, George M Tabatinga george.tabati...@gmail.com escreveu: Senhores, Estou com o seguinte problema. Tenho Postgres 8.2 no ambiente Windows de desenvolvimento com LATIN1 (ISO 8859-1). Preciso manter o ENCODING LATIN1 (ISO 8859-1) no ambiente Linux Ubuntu onde a versão do Postgres é 8.3 e como default o ENCODING UTF8. Os projetos gerados ponto WAR para rodar no ambiente Java do Linux precisam dessa configuração anterior LATIN1. Qual a melhor saída? Grato, George ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- George Machado Tabatinga, Analista de Sistemas - SETUR ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Inclusão LATIN1 (ISO 8859-1)
O Google é seu amigo: http://www.google.com.br/search?hl=pt-BRq=add+locale+latin1+in+ubuntuaq=faqi=aql=oq=gs_rfai= http://www.google.com.br/search?hl=pt-BRq=add+locale+latin1+in+ubuntuaq=faqi=aql=oq=gs_rfai= Atenciosamente, Em 5 de maio de 2010 13:35, George M Tabatinga george.tabati...@gmail.comescreveu: Fábio, Como fazer isso? preciso passar as instruções para a pessoa responsável pelo ambiente Linux. Grato, George Em 5 de maio de 2010 13:28, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Mude o locale do Ubuntu adicionando o suporte ao Latin1. []s Em 5 de maio de 2010 13:22, George M Tabatinga george.tabati...@gmail.com escreveu: Senhores, Estou com o seguinte problema. Tenho Postgres 8.2 no ambiente Windows de desenvolvimento com LATIN1 (ISO 8859-1). Preciso manter o ENCODING LATIN1 (ISO 8859-1) no ambiente Linux Ubuntu onde a versão do Postgres é 8.3 e como default o ENCODING UTF8. Os projetos gerados ponto WAR para rodar no ambiente Java do Linux precisam dessa configuração anterior LATIN1. Qual a melhor saída? Grato, George ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- George Machado Tabatinga, Analista de Sistemas - SETUR ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Inclusão LATIN1 (ISO 8859-1)
Ola George Esse link ajuda http://www.vivaolinux.com.br/dica/Reconfigurar-as-LOCALES-passando-de-UTF8-para-ISO88591 []s Luiz www.xharbour.com.br Fábio, Como fazer isso? preciso passar as instruções para a pessoa responsável pelo ambiente Linux. Grato, George Em 5 de maio de 2010 13:28, Fábio Telles Rodriguez fabio.tel...@gmail.comescreveu: Mude o locale do Ubuntu adicionando o suporte ao Latin1. []s Em 5 de maio de 2010 13:22, George M Tabatinga george.tabati...@gmail.com escreveu: Senhores, Estou com o seguinte problema. Tenho Postgres 8.2 no ambiente Windows de desenvolvimento com LATIN1 (ISO 8859-1). Preciso manter o ENCODING LATIN1 (ISO 8859-1) no ambiente Linux Ubuntu onde a versão do Postgres é 8.3 e como default o ENCODING UTF8. Os projetos gerados ponto WAR para rodar no ambiente Java do Linux precisam dessa configuração anterior LATIN1. Qual a melhor saída? Grato, George ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- George Machado Tabatinga, Analista de Sistemas - SETUR ___ 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] NÃO CONSEGUE INICIAR O SERVIÇO
2010-05-05 09:03:02 LOG: database system was interrupted at 2010-05-05 08:57:40 2010-05-05 09:03:02 LOG: checkpoint record is at 1/1F864BA8 2010-05-05 09:03:02 LOG: redo record is at 1/1F864BA8; undo record is at 0/0; shutdown FALSE 2010-05-05 09:03:02 LOG: next transaction ID: 0/9717008; next OID: 747423 2010-05-05 09:03:02 LOG: next MultiXactId: 1; next MultiXactOffset: 0 2010-05-05 09:03:02 LOG: database system was not properly shut down; automatic recovery in progress 2010-05-05 09:03:02 LOG: redo starts at 1/1F864BF8 2010-05-05 09:03:02 FATAL: the database system is starting up 2010-05-05 09:03:02 LOG: record with zero length at 1/1F88CBE8 2010-05-05 09:03:02 LOG: redo done at 1/1F88CBB8 2010-05-05 09:03:03 FATAL: the database system is starting up 2010-05-05 09:03:03 LOG: database system is ready Em 5 de maio de 2010 12:55, Osvaldo Kussama osvaldo.kuss...@gmail.comescreveu: Em 5 de maio de 2010 12:53, José Mello Júnior jose.mello.jun...@gmail.com escreveu: Cenário: PostgreSQL 8.2.11 SO Windows Vista Ultimate 64 ATHLON PHENOM QUAD-COR Servidor caiu por falha de hardware e agora ao retornar o serviço fica iniciando mas não conclui a operação e por consequência não disponibiliza os dados. Fiz nova instalação em outra pasta e o banco entrou normalmente com os dados vazio (nova instalação) então copiei a pasta baseda instalação baleada para dentro da pasta data, liberei as permissões de escrita para todos os administradores e não consegue subir o serviço assim mesmo. Alguém tem uma idéia do que posso tentar ainda?? O que dizem os logs? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- José de Mello Júnior 41.9957-2007 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorando o desempenho do PostGre
Em 5 de maio de 2010 15:03, Fábio Telles Rodriguez fabio.tel...@gmail.comescreveu: Olha, eu sou obrigado a concordar. Se você tem um sistema com muitos objetos e poucos registros, tomando cuidado com índices compostos você até que consegue se virar razoavelmente bem. Claro que uma verificação simples pode tirar os índices mais inúteis com facilidade. Particularmente aqueles com baixa seletividade e baixa cardinalidade. Mas em tabelas grandes e tabelas relacionadas com tabelas grandes... melhor tomar mais cuidado. Criar índices ainda é algo que exige um tanto de arte, não é algo que se possa automatizar com segurança. Evite as Rules Of Thumbs por aí. Vou contar um segredo... em tabelas grandes tenho alguns indices compostos sim... fruto de alguns ajustes finos na aplicação e banco... mas eu apenas evito o uso demasiado, não que eles não sejam necessários em alguns casos... mas também é como a velha máxima da medicina: cada caso é um caso. Sem contar que a órdem dos tratores faz toda a diferença. Bahhh... e se faz... heheh Abraços, -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Comandos SQL + variável
Boa tarde a todos! Venho novamente recorrer à ajuda da comunidade. O caso é o seguinte: sempre que insiro numa tabela um produto e seu valor, preciso que o campo valor de revenda seja calculado automaticamente com base no ICMS. Ou seja, crio uma trigger do tipo AFTER que dispara uma função para calcular o valor. Porém tenho várias tabelas que se comportam da mesma maneira: chamando essa função de cálculo de revenda. Então na função criei uma variável que recebe TG_TABLE_NAME pra saber qual tabela chamou a função. Só que agora não sei utilizar essa variável junto com códigos SQL. Tentei de várias formas e não deu certo, então comecei a pesquisar sobre EXECUTE, mas não sei se é bem isso que terei que usar. Alguém pode ajudar? Minha versão é 8.4. O código da função segue abaixo: CREATE OR REPLACE FUNCTION revenda() RETURNS trigger AS $$ DECLARE tab varchar;--variável que armazena o nome da tabela que chamou a função icms integer; --icms do fornecedor valor float:=0; --valor de compra pf float:=0; --preço final(de revenda) local int:=17;--variável que recebe o icms de SC BEGIN tab:=TG_TABLE_NAME; raise notice 'A tabela que disparou a trigger foi %', tab; SELECT dist.in_icms INTO icms FROM tab, dist WHERE dist.chis_iddist = tab.chis_iddist; raise notice 'ICMS é %', icms; SELECT tab.fl_valor INTO valor FROM tab, dist WHERE dist.chis_iddist = tab.chis_iddist; raise notice 'Valor é %', valor; IF icms local THEN pf:=valor+(valor*(icms/100)); OLD.fl_icms=pf; ELSIF icms = local THEN OLD.fl_icms = valor; ELSE OLD.fl_icms = valor; END IF; RETURN NULL; END;$$ LANGUAGE 'plpgsql' Grata, -- Aline Renosto Divisão de hardware e soluções integradas ___ 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 DE PERFORMANCE
Boa tarde, Concordo com o Telles, rodar um banco de dados em um ambiente virtualizado no uma boa idia a no ser para fins de testes e olhe l! Recomendo que voc leia atentamente esse artigo [1] e configure melhor o seu postgresql.conf Neste outro link [2] voc pode colocar o valor em GB que ele te d o valor correto em bytes. Para o valor de shmmax voc pode utilizar o valor calculado pelo site, e para o shmall pegue o mesmo valor (ou o que voc quer especificar) e divida por 4096. Por exemplo: 6 GB = 6442450944 bytes 6442450944 / 4096 = 1572864 ento kernel.shmmax = 6442450944 kernel.shmall = 1572864 shared_buffers deve ser igual ou menor que o valor de kernel.shmmax No lembro se na 8.1 os valores j so em MB, mas de qualquer forma atualize a sua verso para a 8.4 Outras coisas que voc pode alterar de cara so esses: work_mem - Cuidado com valores grandes, leia o artigo que voc vai enteder max_stack_depth - utilize o "ulimit - s" e veja o valor retonado, faa testes mas nunca ultrapasse o valor vaccum_cost_delay - habilite porm o valor vai depender bastante da aplicao commit_delay - idem vaccum_cost_delay random_page_cost = 2 [1] - http://www.pgcon.org/2008/schedule/attachments/44_annotated_gucs_draft1.pdf [2] - http://www.easycalculation.com/bandwidth-calculator.php Abrao, Fabiano Machado Dias sebastiao fidencio escreveu: Pessoal Bom dia, estou enviando esse email, porquanto estou com srio problemas de performance eu meu banco de dados. Segue meu cenrio: servidores fisicos 2 servidores- DLG 160 com 38 GB de ram cada um, trabalhando em cluster.. (hd dos servidres e de 146GB) - cada mquina fisica tem 2 CPU quad..da intel storage com 8 discos de 400 gb, trabalhando em raid. Sistema operacional instalado nos Servidores fisicos: VMWARE ENTERPRISE ESX 4.0 Tenho umas 13 mquinas virtuais criadas entre windows e linux, Entretanto o servidor de banco de dados(maquina virtual)que de fato o postgresql 8.1.3 com a seguinte configurao: 6 (cpu's) 16GB de ram 150GB na partio /dados onde est montado o cluster do banco de dados de produo. 10 GB onde est instalado a distribuio SUSE Linux Enterprise 11 64bits Problema: Acontece que, pessoal comea usar o sistema pela parte da manh, e por volta de 10:00hrs da manho o ERP comea a ficar bastante lento at chegar o ponto de travar, e percebo que quanto mais recurso disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem hardware que de conta disso. as consultas, a CPu e memoria vai para o ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, j segui alguns conselhos para realizar tunnig no sgbd, mas no deu certo.., gostaria da opinio de vocs o que eu tenho que fazer para resolver esse problema. segue o link para vocs verem minhas conf's postgresql.conf http://200.175.138.130/postgresql.conf System V: (configurao defaul que veio, eu nem mexi em nada) kernel.shmmax = 18446744073709551615 kernel.shmall = 1152921504606846720 kernel.shmmni = 4096 estado da maquina agora sem problemas: (porem a qualquer momento ela pode apresenta problemas, principalmente quando os usuarios racam relatorios pesados).. a rede hoje tem cerca de 150 usuarios ativos no sistema. uso de memoria = dberp:/dados/pgsql # cat /proc/meminfo MemTotal: 16307396 kB MemFree: 1711440 kB Buffers: 23724 kB Cached: 4221676 kB SwapCached: 80676 kB Active: 4742244 kB Inactive: 1533132 kB SwapTotal: 1044216 kB SwapFree: 592144 kB Dirty: 1012 kB Writeback: 0 kB AnonPages: 1954908 kB Mapped: 1075736 kB Slab: 70516 kB SReclaimable: 34456 kB SUnreclaim: 36060 kB PageTables: 201260 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 9197912 kB Committed_AS: 3784748 kB VmallocTotal: 34359738367 kB VmallocUsed: 306132 kB VmallocChunk: 34359431799 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M: 16766976 kB dberp:/dados/pgsql # == cpu === top - 11:55:46 up 21:26, 2 users, load average: 0.71, 0.40, 2.34 Tasks: 197 total, 1 running, 194 sleeping, 2 stopped, 0 zombie Cpu0 : 2.2%us, 0.8%sy, 0.0%ni, 95.8%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 14.8%us, 1.7%sy, 0.0%ni, 71.9%id, 11.3%wa, 0.0%hi, 0.1%si, 0.0%st Cpu2 : 1.5%us, 0.8%sy, 0.0%ni, 97.2%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.3%us, 0.7%sy, 0.0%ni, 98.6%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.2%us, 0.7%sy, 0.0%ni, 98.9%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.2%us, 0.6%sy, 0.0%ni, 99.1%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16307396k total, 14723100k used, 1584296k free, 24536k buffers Swap: 1044216k total, 451616k used, 592600k free,
[pgbr-geral] Alterar base de dados.
Tenho em minha base de dados registros do tipo decimal que possuem valor Nulo. O correto é que estes possuam valor Zero. É possível corrigir isto com única instrução ou terei que fazer uma para cada tabela? Obrigado. Antonio. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NÃO CONSEGUE INICIAR O SERVIÇO
Pessoal, estou me batendo igual a um louco e não consigo mais levantar o serviço do Banco de Dados. Fiz um caminhão de testes e nada resolveu, estou ficando sem idéias. Claro que o cliente não tem BKP algum da base. Copiei (fiz uma copia) da pasta data original e reinstalei o Banco de Dados, mas se substituo a pasta data pela antiga, o serviço não consegue executar por time-out. Alguma idéia? Em 5 de maio de 2010 14:22, José Mello Júnior jose.mello.jun...@gmail.comescreveu: 2010-05-05 09:03:02 LOG: database system was interrupted at 2010-05-05 08:57:40 2010-05-05 09:03:02 LOG: checkpoint record is at 1/1F864BA8 2010-05-05 09:03:02 LOG: redo record is at 1/1F864BA8; undo record is at 0/0; shutdown FALSE 2010-05-05 09:03:02 LOG: next transaction ID: 0/9717008; next OID: 747423 2010-05-05 09:03:02 LOG: next MultiXactId: 1; next MultiXactOffset: 0 2010-05-05 09:03:02 LOG: database system was not properly shut down; automatic recovery in progress 2010-05-05 09:03:02 LOG: redo starts at 1/1F864BF8 2010-05-05 09:03:02 FATAL: the database system is starting up 2010-05-05 09:03:02 LOG: record with zero length at 1/1F88CBE8 2010-05-05 09:03:02 LOG: redo done at 1/1F88CBB8 2010-05-05 09:03:03 FATAL: the database system is starting up 2010-05-05 09:03:03 LOG: database system is ready Em 5 de maio de 2010 12:55, Osvaldo Kussama osvaldo.kuss...@gmail.comescreveu: Em 5 de maio de 2010 12:53, José Mello Júnior jose.mello.jun...@gmail.com escreveu: Cenário: PostgreSQL 8.2.11 SO Windows Vista Ultimate 64 ATHLON PHENOM QUAD-COR Servidor caiu por falha de hardware e agora ao retornar o serviço fica iniciando mas não conclui a operação e por consequência não disponibiliza os dados. Fiz nova instalação em outra pasta e o banco entrou normalmente com os dados vazio (nova instalação) então copiei a pasta baseda instalação baleada para dentro da pasta data, liberei as permissões de escrita para todos os administradores e não consegue subir o serviço assim mesmo. Alguém tem uma idéia do que posso tentar ainda?? O que dizem os logs? Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- José de Mello Júnior 41.9957-2007 -- José de Mello Júnior 41.9957-2007 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Alterar base de dados.
update esquema.tabela set valor = coalesce( valor, 0) Em 5 de maio de 2010 16:00, Antonio Prado supo...@antonioprado.eti.brescreveu: Tenho em minha base de dados registros do tipo decimal que possuem valor Nulo. O correto é que estes possuam valor Zero. É possível corrigir isto com única instrução ou terei que fazer uma para cada tabela? Obrigado. Antonio. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att. José Adriano Alves Analista de Sistemas - Grupo Gazin. Cel..: +55 44 8802 3994 Fone: + 55 44 3663 8000 - 2319 Mail: alves.jadri...@gazin.com.br MSN: jose.adri...@gazin.com.br WEB-SITE: http://www.gazin.com.br/institucional Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN. Antes de imprimir pense em seu compromisso com o Meio Ambiente ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Pedro Rômulo wants to stay in touch o n LinkedIn
LinkedIn Pedro Rômulo requested to add you as a connection on LinkedIn: -- Mateus, I'd like to add you to my professional network on LinkedIn. - Pedro Rômulo Accept invitation from Pedro Rômulo http://www.linkedin.com/e/hJyn_mKDb3AYKem6pM_q9mB_905WKe_qzCqrQvDjbGRKE3zlm8R7/blk/I2016761160_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnP0Scj4SdPoNc399bSpju31jrCRTbPgVdPwQdPoTcz4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Pedro Rômulo http://www.linkedin.com/e/hJyn_mKDb3AYKem6pM_q9mB_905WKe_qzCqrQvDjbGRKE3zlm8R7/blk/I2016761160_2/39vc3oNcjoTdz4McAALqnpPbOYWrSlI/svi/ -- Why might connecting with Pedro Rômulo be a good idea? People Pedro Rômulo knows can discover your profile: Connecting to Pedro Rômulo will attract the attention of LinkedIn users. See who's been viewing your profile: http://www.linkedin.com/e/wvp/inv18_wvmp/ -- (c) 2010, LinkedIn Corporation___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] NÃO CONSEGUE INICIAR O SERVIÇO
Em 5 de maio de 2010 16:30, José Mello Júnior jose.mello.jun...@gmail.com escreveu: Pessoal, estou me batendo igual a um louco e não consigo mais levantar o serviço do Banco de Dados. Fiz um caminhão de testes e nada resolveu, estou ficando sem idéias. Claro que o cliente não tem BKP algum da base. Copiei (fiz uma copia) da pasta data original e reinstalei o Banco de Dados, mas se substituo a pasta data pela antiga, o serviço não consegue executar por time-out. Alguma idéia? Não estou entendendo. Na listagem do log que você postou a última mensagem é: 2010-05-05 09:03:03 LOG: database system is ready Agora esta forma de restauração (não deixa de ser um back-up no nível de sistema de arquivo, mas com o PostgreSQL rodando) tem uma grande chance de não funcionar [1]. Osvaldo [1] http://www.postgresql.org/docs/current/interactive/backup-file.html ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Bem, essas informaes permitem dar algumas sugestes. Considerando que o tamanho do banco no nada demais, mas que o nmero de usurios significativo e que no especificasses que tipo de acesso esses 80 usurios fazem eu sugiro o seguinte: 1. Se a empresa para durante a noite faa hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se no der para fazer a noite use o final de semana, um feriado, ... 2. Rotineiramente faa um vacuum analyse no perodo de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites. Eu acho que d at para colocar a mo no fogo que isto vai resolver teu problema, exceto se de algum tempo para c o volume de dados tenha crescido muito acima da mdia ou o nmero de usurios, ou pior ainda ambas as coisas. Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1. Abraos, Sergio Medeiros Santi Em 05/05/2010 11:29, Marcio Maestrello escreveu: Pessoal, Segue as respostas abaixo. Agradeo muito as repostas enviadas e segue as respostas as perguntas efetuadas 1. qual seu hardware? R: Servidor Dell Power Edge 1950III com processador Intel Quad Core Xeon, 2,33 GHz, 2x6Mb cach, 3 Gb RAM 3 discos SAS (RAID 5) de 73 Gb cada um deles. 2. SO? LINUX Red Hat 3. verso do Postgresql? R: Versao 8.2 4. Tamanho ocupado pelo banco? R.: 11 GB 5. Nmero de acessos simultneos? R.: So 80 usurios utilizando o sistema e acessando o BD. 6. se isto passou a ocorrer de repente ou veio piorando durante o tempo? R.: Vem ocorrendo h algum tempo e piorando durante o tempo 7. se feito vacuum analyse e com que regularidade? R. No feito 8. se o autovacuum esta ativo? R.: No 9. se j foi feito um backup, drop, create e restore desta base? R.: Neste item, acredito que nada foi feito em relao a isso. Abraos, Sergio Medeiros Santi Em 05/05/2010 00:16, Marcal Hokama escreveu: From: mar...@npsistemas.com.br To: pgbr-geral@listas.postgresql.org.br Date: Tue, 4 May 2010 19:01:55 -0300 Subject: [pgbr-geral] RES: Melhorando o desempenho do PostGre Utilizamos o Postgres na empresa h dois anos, em um sistema completo (ERP). Acontece que de uns tempo pra c o sistema se tornou muito lento. As consultas ficaram lentas. O cadastro de notas fiscais que antes era bem rpido, agora se tornou muito lento nas pesquisas e nas incluses. Eliminamos todos os problemas de redes e infraestrutura, chegando a concluso que se trata do banco de dados. O DBA comentou que a soluo seria a separao dos ndices do banco de dados. Assim, teramos dois discos, um com os ndices e outro com o banco de dados. Esse procedimento complexo, visto que terei que desmontar um RAID 5 e refaz-lo e no tenho certeza que isso dar um desempenho maior no sistema. Gostaria de saber se algum j utiliza essa soluo de ndices separados e se realmente vale arriscar todo arranjo j feito para se montar algo assim. Ser que com a separao terei mais desempenho?? Marcio - TI Ol Marcio, No sei com quantos discos fsicos voc est montando seu RAID 5, mas geralmente essa questo de separao de ndices e dados til quando voc tem os dois no mesmo disco fsico, e o hardware no consegue dar conta do grande nmero de requisies ao dispositivo, gerando conteo e perda de performance. No caso do RAID 5, como pode perceber em http://pt.wikipedia.org/wiki/RAID#RAID_5, os dados so distribudos entre os discos fsicos, minimizando a questo da conteno em um nico disco fsico (mas depende tambm de quantos discos fsicos formam o seu volume). Talvez o problema possa ser justamente no RAID 5, que dependendo do hardware envolvido, pode no ser arranjo mais adequado para bancos de dados. Abaixo segue um documento da Dell comparando o desempenho do RAID 5 X RAID 10 com Oracle em diversas situaes, mas acredito que possa servir tambm para PostgreSQL: http://www.dell.com/downloads/global/solutions/tradeoffs_RAID5_RAID10.pdf?c=myl=ens=k12 Outra idia pode ser verificar qual a tecnologia dos seus discos fsicos (SATA, SAS, Fibre Channel, etc.) e dependendo da situao, pensar num upgrade. Maral de Lima Hokama -- e-mail: mhok...@hotmail.com _ CANSADO DE ENTRAR EM TODAS AS SUAS DIFERENTES CONTAS DE EMAIL? JUNTE TODAS AGORA. http://www.windowslive.com.br/public/product.aspx/view/1?cname=agregadorocid=Hotmail:MSN:Messenger:Tagline:1x1:agregador:- ___ 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
Re: [pgbr-geral] Alterar base de dados.
Em Qua, 2010-05-05 às 16:40 -0300, Jose adriano Alves escreveu: update esquema.tabela set valor = coalesce( valor, 0) Assim terei que fazer uma para cada tabela. A questão é: É possível corrigir isto com única instrução ou terei que fazer uma para cada tabela? Obrigado. Antonio. Em 5 de maio de 2010 16:00, Antonio Prado supo...@antonioprado.eti.br escreveu: Tenho em minha base de dados registros do tipo decimal que possuem valor Nulo. O correto é que estes possuam valor Zero. É possível corrigir isto com única instrução ou terei que fazer uma para cada tabela? Obrigado. Antonio. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Att. José Adriano Alves Analista de Sistemas - Grupo Gazin. Cel..: +55 44 8802 3994 Fone: + 55 44 3663 8000 - 2319 Mail: alves.jadri...@gazin.com.br MSN: jose.adri...@gazin.com.br WEB-SITE: http://www.gazin.com.br/institucional Este e-mail, seu conteúdo e seus anexos estão sujeitos à privilégio de comunicação podendo este documento incluir informação confidencial e de propriedade restrita da GAZIN e apenas pode ser lido por aqueles a qual o mesmo tenha sido endereçado. Se você recebeu essa mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer dados, opiniões ou informações expressadas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com aquelas da GAZIN, são de exclusiva responsabilidade do signatário. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito da GAZIN. Antes de imprimir pense em seu compromisso com o Meio Ambiente ___ 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] Alterar base de dados.
Em 5 de maio de 2010 17:38, Antonio Prado
supo...@antonioprado.eti.br escreveu:
Em Qua, 2010-05-05 às 17:24 -0300, Osvaldo Kussama escreveu:
Em 5 de maio de 2010 16:00, Antonio Prado
supo...@antonioprado.eti.br escreveu:
Tenho em minha base de dados registros do tipo decimal que possuem valor
Nulo. O correto é que estes possuam valor Zero.
É possível corrigir isto com única instrução ou terei que fazer uma para
cada tabela?
Numa única instrução não é possível de acordo com o padrão SQL. Você
terá que fazer um UPDATE para cada tabela.
O que você pode fazer é uma função que consulte o catálogo e monte
dinamicamente este UPDATE para cada tabela de seu banco.
Pode me dar um exemplo de como eu faço isto?
Aproveite e altere suas tabelas especificando NOT NULL sempre que
necessário de acordo com seus requisitos.
Sim.
Algo to tipo:
CREATE FUNCTION sua_funcao() RETURNS void AS $$
DECLARE
_rec_tab RECORD;
_rec_col RECORD;
BEGIN
FOR _rec_tab IN SELECT * FROM information_schema.tables WHERE
table_type = 'BASE TABLE' LOOP
_cmd_upd := 'UPDATE ' || table_schema || '.' || table_name || ' SET ';
_campos := '';
_cond := '';
FOR _rec_col IN SELECT * FROM information_schema.columns WHERE
table_schema = ' || _rec_tab.table_schema || ' AND table_name = ' ||
_rec_tab.table_name || ' AND is_nullable = ''YES'' AND data_type =
''numeric''' LOOP
IF _campos '' THEN
_campos := _campos || ', ';
_cond := _cond || ' OR ';
END IF;
_campos := _campos || _rec_col.column_name || ' = coalesce('
|| _rec_col.column_name || ',0)';
_cond := _cond || _rec_col. column_name || ' IS NULL';
END LOOP;
IF _campos '' THEN
RAISE NOTICE ' Tabela alterada: %.%', _rec_tab.table_schema,
_rec_tab.table_name;
EXECUTE _cmd_upd || campos || ' WHERE ' || _cond || ';';
END IF;
RETURN;
END LOOP;
END;
$$ LANGUAGE plpgsql;
Osvaldo
PS: Não testada.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Alterar base de dados.
ATENÇÃO:
Para evitar qualquer problema é melhor limitar a pesquisa de tabelas
apenas nos seus SCHEMAS.
Osvaldo
Em 5 de maio de 2010 18:49, Osvaldo Kussama
osvaldo.kuss...@gmail.com escreveu:
Em 5 de maio de 2010 17:38, Antonio Prado
supo...@antonioprado.eti.br escreveu:
Em Qua, 2010-05-05 às 17:24 -0300, Osvaldo Kussama escreveu:
Em 5 de maio de 2010 16:00, Antonio Prado
supo...@antonioprado.eti.br escreveu:
Tenho em minha base de dados registros do tipo decimal que possuem valor
Nulo. O correto é que estes possuam valor Zero.
É possível corrigir isto com única instrução ou terei que fazer uma para
cada tabela?
Numa única instrução não é possível de acordo com o padrão SQL. Você
terá que fazer um UPDATE para cada tabela.
O que você pode fazer é uma função que consulte o catálogo e monte
dinamicamente este UPDATE para cada tabela de seu banco.
Pode me dar um exemplo de como eu faço isto?
Aproveite e altere suas tabelas especificando NOT NULL sempre que
necessário de acordo com seus requisitos.
Sim.
Algo to tipo:
CREATE FUNCTION sua_funcao() RETURNS void AS $$
DECLARE
_rec_tab RECORD;
_rec_col RECORD;
BEGIN
FOR _rec_tab IN SELECT * FROM information_schema.tables WHERE
table_type = 'BASE TABLE' LOOP
_cmd_upd := 'UPDATE ' || table_schema || '.' || table_name || ' SET ';
_campos := '';
_cond := '';
FOR _rec_col IN SELECT * FROM information_schema.columns WHERE
table_schema = ' || _rec_tab.table_schema || ' AND table_name = ' ||
_rec_tab.table_name || ' AND is_nullable = ''YES'' AND data_type =
''numeric''' LOOP
IF _campos '' THEN
_campos := _campos || ', ';
_cond := _cond || ' OR ';
END IF;
_campos := _campos || _rec_col.column_name || ' = coalesce('
|| _rec_col.column_name || ',0)';
_cond := _cond || _rec_col. column_name || ' IS NULL';
END LOOP;
IF _campos '' THEN
RAISE NOTICE ' Tabela alterada: %.%', _rec_tab.table_schema,
_rec_tab.table_name;
EXECUTE _cmd_upd || campos || ' WHERE ' || _cond || ';';
END IF;
RETURN;
END LOOP;
END;
$$ LANGUAGE plpgsql;
Osvaldo
PS: Não testada.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Em 5 de maio de 2010 17:11, Sergio Santi sergio.tra...@gmail.com escreveu: Bem, essas informações permitem dar algumas sugestões. Considerando que o tamanho do banco não é nada demais, mas que o número de usuários é significativo e que não especificasses que tipo de acesso esses 80 usuários fazem eu sugiro o seguinte: 1. Se a empresa para durante a noite faça hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se não der para fazer a noite use o final de semana, um feriado, ... 2. Rotineiramente faça um vacuum analyse no período de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites. Eu acho que dá até para colocar a mão no fogo que isto vai resolver teu problema, exceto se de algum tempo para cá o volume de dados tenha crescido muito acima da média ou o número de usuários, ou pior ainda ambas as coisas. Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1. Não. Isso não é um procedimento razoável. Não dá para imaginar que você precisa recriar o banco de dados toda a semana. Melhor mesmo é descobrir onde está o problema e não dar tiro de escopeta em mosquito. Você não precisa fazer isso se souber: - Rodar o vacuum e o analyze; - Rodar um reindex em objetos específicos em certos momentos; - Clusterizar tabelas específicas em certos momentos; São rotinas de manutenção. Todo SGDB precisa de manutenção. Recriar o banco de dados é como formatar o HD toda vez que o SO dá problema. Sei que tem muita gente que se acostuma com esse tipo de coisa, mas não é algo normal em ambiente corporativo, certo? []s Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Utilizando o pgtune
Boa noite a todos! Vi que para a nova versao do postgres foi criado uma ferramenta que ajuda fazer uma melhor configuracao, esta ferramenta e a pgtune.Alguem ja utilizou?E que tentei entender como rodando esta ferramenta para gerar esta conf.Alguem sabe como utilizar, como seria a sintaxe para gerar estas conf personalizada? Desde ja agradeco. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Uma ação importante, é analisar as consultas que representam um uso em maior escala pelos usuário de uma empresa antes de sair criando indices ou mesmo ações desesperadoras. Esta semana, consegui melhor em muito consultas que estavam muito lentas. Em uma delas foi anulado alguns relacionamentos *left join* Marcos André G.A Trabin Softwarre Consulting Em 5 de maio de 2010 20:34, Fábio Telles Rodriguez fabio.tel...@gmail.comescreveu: Em 5 de maio de 2010 17:11, Sergio Santi sergio.tra...@gmail.comescreveu: Bem, essas informações permitem dar algumas sugestões. Considerando que o tamanho do banco não é nada demais, mas que o número de usuários é significativo e que não especificasses que tipo de acesso esses 80 usuários fazem eu sugiro o seguinte: 1. Se a empresa para durante a noite faça hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se não der para fazer a noite use o final de semana, um feriado, ... 2. Rotineiramente faça um vacuum analyse no período de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites. Eu acho que dá até para colocar a mão no fogo que isto vai resolver teu problema, exceto se de algum tempo para cá o volume de dados tenha crescido muito acima da média ou o número de usuários, ou pior ainda ambas as coisas. Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1. Não. Isso não é um procedimento razoável. Não dá para imaginar que você precisa recriar o banco de dados toda a semana. Melhor mesmo é descobrir onde está o problema e não dar tiro de escopeta em mosquito. Você não precisa fazer isso se souber: - Rodar o vacuum e o analyze; - Rodar um reindex em objetos específicos em certos momentos; - Clusterizar tabelas específicas em certos momentos; São rotinas de manutenção. Todo SGDB precisa de manutenção. Recriar o banco de dados é como formatar o HD toda vez que o SO dá problema. Sei que tem muita gente que se acostuma com esse tipo de coisa, mas não é algo normal em ambiente corporativo, certo? []s Fábio Telles -- blog: http://www.midstorm.org/~telles/http://www.midstorm.org/%7Etelles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Melhorando o desempenho do PostGre
Uma ação importante, é analisar as consultas que representam um uso em maior escala pelos usuário de uma empresa antes de sair criando indices ou mesmo ações desesperadoras. Esta semana, consegui melhor em muito consultas que estavam muito lentas. Em uma delas foi anulado alguns relacionamentos *left join *e outras um simples indices que realmente precisava resolveu o problema de lentidão. É como disse um dos parceiros desta discursão, *Cada caso é um caso* * *Marcos André G.A Trabin Softwarre Consulting Em 5 de maio de 2010 23:11, Marcos - GMail lgerardlu...@gmail.comescreveu: Uma ação importante, é analisar as consultas que representam um uso em maior escala pelos usuário de uma empresa antes de sair criando indices ou mesmo ações desesperadoras. Esta semana, consegui melhor em muito consultas que estavam muito lentas. Em uma delas foi anulado alguns relacionamentos *left join* Marcos André G.A Trabin Softwarre Consulting Em 5 de maio de 2010 20:34, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de maio de 2010 17:11, Sergio Santi sergio.tra...@gmail.comescreveu: Bem, essas informações permitem dar algumas sugestões. Considerando que o tamanho do banco não é nada demais, mas que o número de usuários é significativo e que não especificasses que tipo de acesso esses 80 usuários fazem eu sugiro o seguinte: 1. Se a empresa para durante a noite faça hoje ainda um backup, seguido de um drop, um create e finalmente um restore. Se não der para fazer a noite use o final de semana, um feriado, ... 2. Rotineiramente faça um vacuum analyse no período de menor atividade da base. Eu particularmente agendo para que sejam feitas todas as noites. Eu acho que dá até para colocar a mão no fogo que isto vai resolver teu problema, exceto se de algum tempo para cá o volume de dados tenha crescido muito acima da média ou o número de usuários, ou pior ainda ambas as coisas. Um detalhe: Verifique o tamanho da sua base antes e depois do procedimento citado no item 1. Não. Isso não é um procedimento razoável. Não dá para imaginar que você precisa recriar o banco de dados toda a semana. Melhor mesmo é descobrir onde está o problema e não dar tiro de escopeta em mosquito. Você não precisa fazer isso se souber: - Rodar o vacuum e o analyze; - Rodar um reindex em objetos específicos em certos momentos; - Clusterizar tabelas específicas em certos momentos; São rotinas de manutenção. Todo SGDB precisa de manutenção. Recriar o banco de dados é como formatar o HD toda vez que o SO dá problema. Sei que tem muita gente que se acostuma com esse tipo de coisa, mas não é algo normal em ambiente corporativo, certo? []s Fábio Telles -- blog: http://www.midstorm.org/~telles/http://www.midstorm.org/%7Etelles/ e-mail / jabber: fabio.tel...@gmail.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ 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 DE PERFORMANCE
Maquinas virtuais tem degradaçao de performance com mais de 8GB. Vc pode confirmar isso com desenvolvedores do VmWare. VM no maximo com 8GB. Wolak Sistemas - Fabiano Machado Dias wrote: Boa tarde, Concordo com o Telles, rodar um banco de dados em um ambiente virtualizado natilde;o eacute; uma boa ideacute;ia a natilde;o ser para fins de testes e olhe laacute;! Recomendo que vocecirc; leia atentamente esse artigo [1] e configure melhor o seu postgresql.conf Neste outro link [2] vocecirc; pode colocar o valor em GB que ele te daacute; o valor correto em bytes. Para o valor de shmmax vocecirc; pode utilizar o valor calculado pelo site, e para o shmall pegue o mesmo valor (ou o que vocecirc; quer especificar) e divida por 4096. Por exemplo: 6 GB = 6442450944 bytes 6442450944 / 4096 = 1572864 entatilde;o kernel.shmmax = 6442450944 kernel.shmall = 1572864 shared_buffers deve ser igual ou menor que o valor de kernel.shmmax Natilde;o lembro se na 8.1 os valores jaacute; satilde;o em MB, mas de qualquer forma atualize a sua versatilde;o para a 8.4 Outras coisas que vocecirc; pode alterar de cara satilde;o esses: work_mem - Cuidado com valores grandes, leia o artigo que vocecirc; vai enteder max_stack_depth - utilize o ulimit - s e veja o valor retonado, faccedil;a testes mas nunca ultrapasse o valor vaccum_cost_delay - habilite poreacute;m o valor vai depender bastante da aplicaccedil;atilde;o commit_delay - idemnbsp; vaccum_cost_delay random_page_cost = 2 [1] - http://www.pgcon.org/2008/schedule/attachments/44_annotated_gucs_draft1.pdf [2] - http://www.easycalculation.com/bandwidth-calculator.php Abraccedil;atilde;o, Fabiano Machado Dias sebastiao fidencio escreveu: Pessoal Bom dia, estou enviando esse email, porquanto estou com seacute;rio problemas de performance eu meu banco de dados. Segue meu cenaacute;rio: nbsp; servidores fisicos nbsp; 2 servidoresnbsp;- DLG 160nbsp; com 38 GB de ram cada um, trabalhando em cluster.. (hd dos servidres e de 146GB)nbsp; - cada maacute;quina fisica tem 2 CPU quad..da intel storage com 8 discos de 400 gb, trabalhando em raid.nbsp; nbsp; nbsp; Sistema operacional instalado nos Servidores fisicos: VMWARE ENTERPRISE ESXnbsp; 4.0 nbsp; nbsp; Tenho umas 13 maacute;quinas virtuais criadas entre windows e linux, Entretanto o servidor de banco de dados(maquina virtual)nbsp;que de fato eacute; o postgresql 8.1.3 com a seguinte configuraccedil;atilde;o: nbsp; 6nbsp; (cpu's) 16GB de ram 150GB na particcedil;atilde;o /dados onde estaacute; montado o cluster do banco de dados de produccedil;atilde;o. 10 GBnbsp; onde estaacute; instalado a distribuiccedil;atilde;o SUSE Linux Enterprise 11 64bits nbsp; nbsp; nbsp; Problema: nbsp; nbsp; Acontece que, pessoal comeccedil;a usar o sistema pela parte da manhatilde;, e por volta de 10:00hrs da manhatilde;o o ERP comeccedil;a a ficar bastante lento ateacute; chegar o ponto de travar, e percebo que quanto mais recurso disponibilizo para o servidor de sgbd, mais ele consome, poxa..na tem hardware que de conta disso. as consultas, a CPu e memoria vai para o ultimo estagio, e toda vez tem q ficar reiniciando o sgbd, jaacute; segui alguns conselhos para realizar tunnig no sgbd, mas natilde;o deu certo.., gostaria da opiniatilde;o de vocecirc;s o que eu tenho que fazer para resolver esse problema. nbsp; segue o link para vocecirc;s verem minhas conf's nbsp; postgresql.conf http://200.175.138.130/postgresql.conf nbsp; nbsp; System V: (configuraccedil;atilde;o defaul que veio, eu nem mexi em nada) nbsp; kernel.shmmax = 18446744073709551615 kernel.shmall = 1152921504606846720 kernel.shmmni = 4096 nbsp; nbsp; nbsp; nbsp; estado da maquina agora sem problemas: (porem a qualquer momento ela pode apresenta problemas, principalmente quando os usuarios racam relatorios pesados).. nbsp; a rede hoje tem cerca de 150 usuarios ativos no sistema. nbsp; nbsp; nbsp; uso de memoria = dberp:/dados/pgsql # cat /proc/meminfo MemTotal:nbsp;nbsp;nbsp;nbsp; 16307396 kB MemFree:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 1711440 kB Buffers:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 23724 kB Cached:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 4221676 kB SwapCached:nbsp;nbsp;nbsp;nbsp;nbsp; 80676 kB Active:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 4742244 kB Inactive:nbsp;nbsp;nbsp;nbsp;nbsp; 1533132 kB SwapTotal:nbsp;nbsp;nbsp;nbsp; 1044216 kB SwapFree:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 592144 kB Dirty:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 1012 kB Writeback:nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 0 kB AnonPages:nbsp;nbsp;nbsp;nbsp; 1954908
[pgbr-geral] Convite para se conectar no LinkedIn
LinkedIn Claudio Costa requested to add you as a connection on LinkedIn: -- Mateus, Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn. -Claudio Accept invitation from Claudio Costa http://www.linkedin.com/e/hJyn_mKDb3AYKem6pM_q9mB_905WKe_qzCqrQvDjbGRKE3zlm8R7/blk/I2017979622_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnP8OdzATejsNc399bQcQrAoNc4JqbPwVcPwRe3sTcz4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Claudio Costa http://www.linkedin.com/e/hJyn_mKDb3AYKem6pM_q9mB_905WKe_qzCqrQvDjbGRKE3zlm8R7/blk/I2017979622_2/39vcz8SejsVdP4McAALqnpPbOYWrSlI/svi/ -- (c) 2010, LinkedIn Corporation___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
