Re: [pgbr-geral] [OFF] PgBr 2013 - Porto Velho - RO
Meus comentários sobre o PGBR2013: http://savepoint.blog.br/e-mais-um-pgbr-se-vai/ Em 19 de agosto de 2013 12:32, Roberto Mello roberto.me...@gmail.comescreveu: 2013/8/19 Juliano Atanazio juliano.l...@gmail.com: Bom dia, pessoal! Gostaria aqui, brevemente agradecer a todos que participaram ou se envolveram de alguma forma, tornando possível o evento. Faço minhas as palavras do Juliano. Obrigado a todos que se esforçaram e trabalharam no evento, e até o próximo PgBR! Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Travamento
Bom dia. Ontem a noite o banco travou aqui para mim, em um situação estranha. Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS 6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit). Já tive um problema sério com essa maquina, que no qual existia um problema com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica solução para ela voltar a funcionar era utilizando o botão power. Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não respondia, simplismente não o conseguia nem mesmo parar ele. Só para constar, não apareceu nada em log algum (dmesg, messages, do postgres, etc..), nada mesmo. Como não tinha como matar os processos do banco foi obrigado a dar um reboot, que no qual também não foi bem sucedido, que no qual ficou travado no ponto de montagem para com a storage (o OS não conseguia desmontar a unidade, nem a pau). A solução foi no botão power mesmo. Gostaria de uma opinião de vocês, já que conhecem melhor o banco. Eu acredito que seja problema com o servidor e não com o postgres, mas em todos os casos não custa perguntar, talvez alguem já tenha passado por isso ou seja um bug e tal. Agradeço desde já. Jean Pereira. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
2013/8/20 Jean Pereira ad...@olostech.com: Já tive um problema sério com essa maquina, que no qual existia um problema com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica solução para ela voltar a funcionar era utilizando o botão power. Problema já resolvido? Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não respondia, simplismente não o conseguia nem mesmo parar ele. Só para constar, não apareceu nada em log algum (dmesg, messages, do postgres, etc..), nada mesmo. Isso não quer dizer muita coisa… Como não tinha como matar os processos do banco foi obrigado a dar um reboot, que no qual também não foi bem sucedido, que no qual ficou travado no ponto de montagem para com a storage (o OS não conseguia desmontar a unidade, nem a pau). A solução foi no botão power mesmo. Problema de E/S, mas sem testes fica difícil falar qualquer coisa. Ao reiniciar sem diagnóstico, você perdeu a oportunidade de ver algo sem esperar pelo próximo problema. Eu não lembro mais do ferramental todo, mas a primeira coisa que eu olharia, tentando prevenir algum problema futuro, seriam as ferramentas de monitoramento Smart (das unidades de armazenamento) e de diagnóstico do sistemas de arquivos, lembrando também de olhar se algum dos sistemas de arquivos foi verificado e gerou algum alerta na reinicialização. Creio que os gurus de plantão acrescentarão detalhes mais úteis que minhas idéias genéricas… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] PgBr 2013 - Porto Velho - RO
2013/8/20 Fábio Telles Rodriguez fabio.tel...@gmail.com: Meus comentários sobre o PGBR2013: http://savepoint.blog.br/e-mais-um-pgbr-se-vai/ Muito obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
Em 20-08-2013 10:03, Jean Pereira escreveu: Bom dia. Ontem a noite o banco travou aqui para mim, em um situação estranha. Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS 6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit). Gostei disso aqui. Bastante informação útil. Já tive um problema sério com essa maquina, que no qual existia um problema com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica solução para ela voltar a funcionar era utilizando o botão power. Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não respondia, simplismente não o conseguia nem mesmo parar ele. Só para constar, não apareceu nada em log algum (dmesg, messages, do postgres, etc..), nada mesmo. Como não tinha como matar os processos do banco foi obrigado a dar um reboot, que no qual também não foi bem sucedido, que no qual ficou travado no ponto de montagem para com a storage (o OS não conseguia desmontar a unidade, nem a pau). A solução foi no botão power mesmo. Duas coisas devem ter acontecido: 1) o S.O. não quis desmontar a unidade porque tinha escrita pendente e ele estava inacessível; 2) o PostgreSQL não pode ser parado tão facilmente quando tem conexões ainda e, talvez, transações em andamento. Gostaria de uma opinião de vocês, já que conhecem melhor o banco. Eu acredito que seja problema com o servidor e não com o postgres, mas em todos os casos não custa perguntar, talvez alguem já tenha passado por isso ou seja um bug e tal. Olhe novamente no messages. Procure por indisponibilidade um (ou mais) canais de fibra pro Storage. Já aconteceu comigo de fibra cair e voltar, mesmo que rapidamente, é o suficiente pra bagunçar as coisas de uma forma bem bacana. Pergunta: qual sistema de arquivos está usando, e quantos pontos de montagem estão disponíveis para o banco? []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro ao restaurar base
Pessoal, bom dia, surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. Utilizamos CentOS versao 6 64bits. Estou usando o PGAdmin versao 1.12, que usei a um tempo atras para fazer o dump; agora quando tento fazer o restore aparecem os erros abaixo: ERROR: parameter standard_conforming_strings cannot be changed ERROR: syntax error at or near PROCEDURAL at character 19 ERROR: relation dblink_pkey_results already exists ERROR: could not find function dblink_cancel_query in file /usr/lib64/pgsql/dblink.so tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: ERROR: could not load library /usr/lib64/pgsql/dblink.so: /usr/lib64/pgsql/dblink.so: undefined symbol: SnapshotNowData Alguem tem ideia do por que acontecem os erros? desde ja agradeço, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
Em 20-08-2013 11:17, Wellington escreveu: Pessoal, bom dia, surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. Utilizamos CentOS versao 6 64bits. Estou usando o PGAdmin versao 1.12, que usei a um tempo atras para fazer o dump; agora quando tento fazer o restore aparecem os erros abaixo: Use a versão mais nova do PgAdmin, 1.16 ERROR: parameter standard_conforming_strings cannot be changed Você está tentando essa restauração na versão 8.1 (você não disse, estou chutando), então, essa configuração não está disponível via SQL. Ignore este erro. ERROR: syntax error at or near PROCEDURAL at character 19 Passe a linha inteira dentro desse dump, onde deu esse erro. Quem gerou esse dump colocou uma palavra que não existina na versão 8.1 ERROR: relation dblink_pkey_results already exists Estranho. O dump foi gerado errado. ERROR: could not find function dblink_cancel_query in file /usr/lib64/pgsql/dblink.so Foi usada uma biblioteca dblink no banco antigo diferente da atual. tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: Ah, bem melhor fazer assim. Vá logo pra 9.2, não se arrependerá. ERROR: could not load library /usr/lib64/pgsql/dblink.so: /usr/lib64/pgsql/dblink.so: undefined symbol: SnapshotNowData Instale o dblink. Tá faltando. Não sei como você instalou o PostgreSQL, então, fica difícil dar a dica de como instalar. Alguem tem ideia do por que acontecem os erros? Bom, taí. Passe mais informações conforme pedido pra continuarmos. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
2013/8/20 Flavio Henrique Araque Gurgel fla...@4linux.com.br: Em 20-08-2013 11:17, Wellington escreveu: surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. […] tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: Ah, bem melhor fazer assim. Vá logo pra 9.2, não se arrependerá. Tanto na 8.4 quanto na 9.2, mas principalmente nesta última, serão necessários testes e, provavelmente, ajustes no aplicativo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
Em 20-08-2013 11:32, Guimarães Faria Corcete DUTRA, Leandro escreveu: Tanto na 8.4 quanto na 9.2, mas principalmente nesta última, serão necessários testes e, provavelmente, ajustes no aplicativo. É fato Dutra, obrigado. Só fiz a recomendação porque, pelo que entendi no e-mail do colega, ele precisa meio que ver os dados não conectar algum aplicativo. Inclusive, neste caso de só ver os dados antigos, os erros de dblink podem ser ignorados. Até porque, provavelmente o banco ao qual ele se conectava nem deve mais existir e tal. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
2013/8/20 Flavio Henrique Araque Gurgel fla...@4linux.com.br: Só fiz a recomendação porque, pelo que entendi no e-mail do colega, ele precisa meio que ver os dados não conectar algum aplicativo. É que ele falou que precisava reinstalar o aplicativo… então imagino que seja rodar o programa, mesmo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
- Original Message - From: Flavio Henrique Araque Gurgel fla...@4linux.com.br To: pgbr-geral@listas.postgresql.org.br Sent: Tuesday, August 20, 2013 11:30 AM Subject: Re: [pgbr-geral] Erro ao restaurar base Em 20-08-2013 11:17, Wellington escreveu: Pessoal, bom dia, surgiu a necessidade de reinstalarmos uma versao de um aplicativo legado, que funcionava na versao 8.1. Utilizamos CentOS versao 6 64bits. Estou usando o PGAdmin versao 1.12, que usei a um tempo atras para fazer o dump; agora quando tento fazer o restore aparecem os erros abaixo: Use a versão mais nova do PgAdmin, 1.16 ERROR: parameter standard_conforming_strings cannot be changed Você está tentando essa restauração na versão 8.1 (você não disse, estou chutando), então, essa configuração não está disponível via SQL. Ignore este erro. ERROR: syntax error at or near PROCEDURAL at character 19 Passe a linha inteira dentro desse dump, onde deu esse erro. Quem gerou esse dump colocou uma palavra que não existina na versão 8.1 ERROR: relation dblink_pkey_results already exists Estranho. O dump foi gerado errado. ERROR: could not find function dblink_cancel_query in file /usr/lib64/pgsql/dblink.so Foi usada uma biblioteca dblink no banco antigo diferente da atual. tentei tambem restaurar na versao 8.4, mas aparece o erro abaixo: Ah, bem melhor fazer assim. Vá logo pra 9.2, não se arrependerá. ERROR: could not load library /usr/lib64/pgsql/dblink.so: /usr/lib64/pgsql/dblink.so: undefined symbol: SnapshotNowData Instale o dblink. Tá faltando. Não sei como você instalou o PostgreSQL, então, fica difícil dar a dica de como instalar. Alguem tem ideia do por que acontecem os erros? Bom, taí. Passe mais informações conforme pedido pra continuarmos. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS Flavio, realmente faltou uma linha do erro: ERROR: syntax error at or near PROCEDURAL at character 19 language plpgsql does not exist O aplicativo é de terceiros e foi descontinuado. Antes eu instalava a versao 8.1 pelo yum e o aplicativo carregava normalmente, mas agora os repositorios dessa versao nao estao mais ativos, entao eu instalei pelos pacotes rpm; devo ter feito algo errado; eu instalei os pacotes postgresql81, postgresql81-libs, postgresql81-server e postgresql81-contrib. Com esses erros do restore, o aplicativo nao inicializa. Estou tentando restaurar na base da versao 8.1. Att, Wellington ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro ao restaurar base
Em 20-08-2013 14:45, Wellington escreveu: O aplicativo é de terceiros e foi descontinuado. Antes eu instalava a versao 8.1 pelo yum e o aplicativo carregava normalmente, mas agora os repositorios dessa versao nao estao mais ativos, entao eu instalei pelos pacotes rpm; devo ter feito algo errado; eu instalei os pacotes postgresql81, postgresql81-libs, postgresql81-server e postgresql81-contrib. Com esses erros do restore, o aplicativo nao inicializa. Estou tentando restaurar na base da versao 8.1. Se você tem de restaurar na versão 8.1 você precisa só instalar o dblink correspondente daquela versão também. Se não conseguir com yum, talvez você tenha que compilar o PostgreSQL e o módulo contrib dblink. Procure subir esse dump com psql. Sobre o erro da linguagem procedural, é típico de versões mais recentes do PostgreSQL, pois a linguagem já vem pré-instalada. Se você não tem outro jeito e tem que conviver com esse legado imenso, você precisa ter *certeza* de que instalou a versão 8.1, o módulo contrib dblink dela e usar as ferramentas de linha de comando dela. Tenha certeza disso e tudo deve funcionar. Em tempo, talvez você tenha de compilar em S.O. recente. Mas o código fonte está disponível, logo, não deve ser um problema grande. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
On 08/20/2013 10:26, Guimarães Faria Corcete DUTRA, Leandro wrote: 2013/8/20 Jean Pereira ad...@olostech.com: Já tive um problema sério com essa maquina, que no qual existia um problema com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica solução para ela voltar a funcionar era utilizando o botão power. Problema já resolvido? Esse já, o suporte contratado demorou mais resolveu. Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não respondia, simplismente não o conseguia nem mesmo parar ele. Só para constar, não apareceu nada em log algum (dmesg, messages, do postgres, etc..), nada mesmo. Isso não quer dizer muita coisa… Como não tinha como matar os processos do banco foi obrigado a dar um reboot, que no qual também não foi bem sucedido, que no qual ficou travado no ponto de montagem para com a storage (o OS não conseguia desmontar a unidade, nem a pau). A solução foi no botão power mesmo. Problema de E/S, mas sem testes fica difícil falar qualquer coisa. Ao reiniciar sem diagnóstico, você perdeu a oportunidade de ver algo sem esperar pelo próximo problema. Eu não lembro mais do ferramental todo, mas a primeira coisa que eu olharia, tentando prevenir algum problema futuro, seriam as ferramentas de monitoramento Smart (das unidades de armazenamento) e de diagnóstico do sistemas de arquivos, lembrando também de olhar se algum dos sistemas de arquivos foi verificado e gerou algum alerta na reinicialização. Sim, entendo. Mais 1 minuto para mim parado é muito, sei dos problemas que possivelmente podem acontecer quanto a isso. Mas tenho servidor reserva, e devo efetuar a troca o mais rápido possível. Quanto ao tempo de parada... o banco faz parte de um sistema de saúde, que no qual tem alguns PA e PS 24h. Creio que os gurus de plantão acrescentarão detalhes mais úteis que minhas idéias genéricas… ___ 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] Travamento
On 08/20/2013 10:47, Flavio Henrique Araque Gurgel wrote: Em 20-08-2013 10:03, Jean Pereira escreveu: Bom dia. Ontem a noite o banco travou aqui para mim, em um situação estranha. Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS 6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit). Gostei disso aqui. Bastante informação útil. Já tive um problema sério com essa maquina, que no qual existia um problema com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica solução para ela voltar a funcionar era utilizando o botão power. Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não respondia, simplismente não o conseguia nem mesmo parar ele. Só para constar, não apareceu nada em log algum (dmesg, messages, do postgres, etc..), nada mesmo. Como não tinha como matar os processos do banco foi obrigado a dar um reboot, que no qual também não foi bem sucedido, que no qual ficou travado no ponto de montagem para com a storage (o OS não conseguia desmontar a unidade, nem a pau). A solução foi no botão power mesmo. Duas coisas devem ter acontecido: 1) o S.O. não quis desmontar a unidade porque tinha escrita pendente e ele estava inacessível; 2) o PostgreSQL não pode ser parado tão facilmente quando tem conexões ainda e, talvez, transações em andamento. Gostaria de uma opinião de vocês, já que conhecem melhor o banco. Eu acredito que seja problema com o servidor e não com o postgres, mas em todos os casos não custa perguntar, talvez alguem já tenha passado por isso ou seja um bug e tal. Olhe novamente no messages. Procure por indisponibilidade um (ou mais) canais de fibra pro Storage. Já aconteceu comigo de fibra cair e voltar, mesmo que rapidamente, é o suficiente pra bagunçar as coisas de uma forma bem bacana. Flavio, pior que não tem nada no messages mesmo, isso que está me deixando com a pulga atrás da orelha. Sobre os cabos, conferi eles no ato, mesmo assim, pela lógica, tenho redundancia de HBA e de Modulo controlador, na teoria 1 cabo não deveria dar isso, eu não tenho muita experiencia em hardware, mais acho eu que não deveria. Pergunta: qual sistema de arquivos está usando, e quantos pontos de montagem estão disponíveis para o banco? ext4 Segue mais informações: [root@olosdb01 ~]# df -h FilesystemSize Used Avail Use% Mounted on /dev/sda1 49G 3.0G 43G 7% / tmpfs 32G 0 32G 0% /dev/shm /dev/mapper/mpathcp1 1.4T 94G 1.2T 8% /opt/md3200/pgdata /dev/mapper/mpathbp1 275G 1.3G 260G 1% /opt/md3200/pgxlog /dev/sda5 283G 37G 232G 14% /usr/local/pgsql /dev/sda2 97G 279M 91G 1% /var/log [root@olosdb01 ~]# multipath -ll mpathc (36d4ae52000996c41085151dbf626) dm-1 DELL,MD32xx size=1.4T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw |-+- policy='round-robin 0' prio=6 status=active | |- 1:0:0:1 sdc 8:32 active ready running | `- 2:0:1:1 sdi 8:128 active ready running `-+- policy='round-robin 0' prio=1 status=enabled |- 1:0:1:1 sde 8:64 active ghost running `- 2:0:0:1 sdg 8:96 active ghost running mpathb (36d4ae5200099721d081d51dbf5b8) dm-0 DELL,MD32xx size=279G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw |-+- policy='round-robin 0' prio=6 status=active | |- 1:0:1:0 sdd 8:48 active ready running | `- 2:0:0:0 sdf 8:80 active ready running `-+- policy='round-robin 0' prio=1 status=enabled |- 1:0:0:0 sdb 8:16 active ghost running `- 2:0:1:0 sdh 8:112 active ghost running []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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] Travamento
2013/8/20 Jean Pereira ad...@olostech.com: On 08/20/2013 10:26, Guimarães Faria Corcete DUTRA, Leandro wrote: 2013/8/20 Jean Pereira ad...@olostech.com: Eu não lembro mais do ferramental todo, mas a primeira coisa que eu olharia, tentando prevenir algum problema futuro, seriam as ferramentas de monitoramento Smart (das unidades de armazenamento) e de diagnóstico do sistemas de arquivos, lembrando também de olhar se algum dos sistemas de arquivos foi verificado e gerou algum alerta na reinicialização. Sim, entendo. Mais 1 minuto para mim parado é muito, sei dos problemas que possivelmente podem acontecer quanto a isso. Mas tenho servidor reserva, e devo efetuar a troca o mais rápido possível. A vida não é mole, não… mas verifique o Smart, as ferramentas de sistemas de arquivos, os logs de reinicialização… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
Em 20-08-2013 16:23, Jean Pereira escreveu: Flavio, pior que não tem nada no messages mesmo, isso que está me deixando com a pulga atrás da orelha. Ora pois... O messages (caso do CentOS) tem que ter todas as mensagens do kernel desde o momento do boot. Como assim, não tem *nada*? []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
On 08/20/2013 16:24, Flavio Henrique Araque Gurgel wrote: Em 20-08-2013 16:23, Jean Pereira escreveu: Flavio, pior que não tem nada no messages mesmo, isso que está me deixando com a pulga atrás da orelha. Ora pois... O messages (caso do CentOS) tem que ter todas as mensagens do kernel desde o momento do boot. Como assim, não tem *nada*? Bom, melhor explicar. Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando coloquei novamente esta maquina em produção. Algo parecido, acontecia com o problema que essa maquina apresentou, e que aparentemente foi resolvido. Nada nos logs de informação de problemas. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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] Travamento
Em 20-08-2013 16:28, Jean Pereira escreveu: Bom, melhor explicar. Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando coloquei novamente esta maquina em produção. Algo parecido, acontecia com o problema que essa maquina apresentou, e que aparentemente foi resolvido. Nada nos logs de informação de problemas. Olha amigo, então o negócio me parece hardware. Você disse que não conseguiu matar o processo do PostgreSQL. Como tentou esse tiro? Você ainda tinha acesso ao console, usou ssh, usou pg_ctl, usou kill? []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PGDay Campinas - inscrição com desconto
Olá pessoal, Hoje é o último dia de inscrições [1] com desconto de primeiro lote para o PGDay Campinas 2013 [2]. O evento vai ser bem bacana, recomendo a todos. Também é o último dia para submissão de trabalhos [3]. Corram que ainda dá tempo. [1] http://pgdaycampinas.com.br/2013/ [2] http://pgdaycampinas.com.br/2013/inscricao/ [3] http://pgdaycampinas.com.br/2013/submissao-de-trabalhos/ Abraços, Matheus de Oliveira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
On 08/20/2013 16:37, Flavio Henrique Araque Gurgel wrote: Em 20-08-2013 16:28, Jean Pereira escreveu: Bom, melhor explicar. Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando coloquei novamente esta maquina em produção. Algo parecido, acontecia com o problema que essa maquina apresentou, e que aparentemente foi resolvido. Nada nos logs de informação de problemas. Olha amigo, então o negócio me parece hardware. Você disse que não conseguiu matar o processo do PostgreSQL. Como tentou esse tiro? Você ainda tinha acesso ao console, usou ssh, usou pg_ctl, usou kill? Bom, primeiro eu tentei via ssh com o '/etc/init.d/postgresql stop' (o arquivo do contrib/), esperei alguns minutos, alguns mesmo, depois vi que não tinha geito por ele, e então por via das duvidas fiz o acesso e a tentativa direto no terminal do servidor, ai tentei no 'pg_ctl -m immediate', aonde também não tive sucesso, por fim fiz um 'kill -9' do processo do banco, que no qual também não foi. Não consegui de maneira alguma matar o postgres. Digamos que é o que nós aqui já imaginavamos, mas não custa trocar ideias sobre o assunto, a gente cresce com isso. Obrigado, Se tiver alguma dica ou sugestão, fica a vontade Flavio. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@4linux.com.br __ FREE SOFTWARE SOLUTIONS ___ 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] Solução para backup
Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. É muito difícil saber se isto é suficiente. Uma vez que há o apache no mesmo servidor. Você também não disse ainda onde está o gargalo. Quando as consultas ficam lentas, qual recurso está no talo? Vamos ser mais práticos. No momento do pico, o processador fica como no top? A máquina faz swap? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Dump 4x ao dia é algo muito ruim. Muito mesmo. Leia o post que recomendei antes Dump não é Backup. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Ainda não. Você tem um longo caminho pela frente. 1) Rever completamente as rotinas de backup 2) Encontrar quais são os recursos que estão engargalando. 3) Encontrar quais consultas ficam lentas e se é possível otimiza-las. Se você não tem verba para ter um servidor separado para a aplicação e a base... então certamente não terá verba para contratar uma consultoria. Reserve uns trocados para estudar melhor o assunto. Para começar, bons livros sobre o assunto: http://www.packtpub.com/postgresql-90-high-performance/book http://www.packtpub.com/how-to-postgresql-backup-and-restore/book É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. Antes que alguém te responda a pergunta que fizeste, farei a minha: por que é que você acha que particionamento te ajudará? Lembra que particionamento, se não for indicado, é contraindicado… em outros termos, se não ajudar, atrapalha, porque também consome recursos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com Em 5 de agosto de 2013 14:33, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 14:46, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Em 5 de agosto de 2013 12:10, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 5 de agosto de 2013 02:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Pessoal, O banco cresceu!!! Cresceu para quanto? Nos dê uma ideia de valores. Atualmente está com 30 GiB. É muito pouco para medidas drásticas como particionamento. Por falta de recursos de hardware, Quais recursos de hardware estão faltando hoje? Espaço em disco? Desempenho em disco? Memória, CPU? Server com 12 GiB de Ram e HD de 1TB. É muito difícil saber se isto é suficiente. Uma vez que há o apache no mesmo servidor. Você também não disse ainda onde está o gargalo. Quando as consultas ficam lentas, qual recurso está no talo? Vamos ser mais práticos. No momento do pico, o processador fica como no top? A máquina faz swap? e a lentidão que está atrapalhando algumas rotinas, Quais rotinas? Como você faz o backup hoje? Único servidor que roda, além do postgres, replicação nativa, apache, php. O banco sofre muitos selects e inserts simultâneos. Além da replicação, é feito dump 4x aos dia, todos os dias. Dump 4x ao dia é algo muito ruim. Muito mesmo. Leia o post que recomendei antes Dump não é Backup. Ver artigo Dump não é backup: http://savepoint.blog.br/dump-nao-e-backup/ E também a palestra do Flávio no PGBR2011: Meu ambiente cresceu e eu não planejei. E agora? http://pgbr.postgresql.org.br/2011/palestras.php?id=53 foi decidido efetuar uma *limpeza*, removendo os registros antigos, deixando somente os últimos 3 meses, sendo que o que for removido, deverá ficar, de alguma forma, disponível para consulta. Você pensa em criar uma base histórica no mesmo servidor ou montar um novo servidor com a base histórica? Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Existem várias alternativas para isso, como alguns comentaram uma delas é o particionamento. Mas particionamento está longe de ser algo simples. * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-quando/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-como/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-detalhes/ * http://savepoint.blog.br/particionamento-de-tabelas-no-postgres-automatizando/ O que é indicado/recomendado para este cenário? Você precisa dar mais detalhes sobre o seu cenário para podermos avaliar. Em todo caso, deixei aí algumas dicas que já podem lhe ajudar a pensar no assunto. Respondido? Ainda não. Você tem um longo caminho pela frente. 1) Rever completamente as rotinas de backup 2) Encontrar quais são os recursos que estão engargalando. 3) Encontrar quais consultas ficam lentas e se é possível otimiza-las. Se você não tem verba para ter um servidor separado para a aplicação e a base... então certamente não terá verba para contratar uma consultoria. Reserve uns trocados para estudar melhor o assunto. Para começar, bons livros sobre o assunto: http://www.packtpub.com/postgresql-90-high-performance/book http://www.packtpub.com/how-to-postgresql-backup-and-restore/book É possível efetuar o particionamento em tabelas já *populadas*? Pois tudo que li até agora somente falam sobre o particionamento começado do zero. Sim, é possível. Basta você montar o particionamento (adicionar as tabelas filhas - com constraints, índices, etc. - e as triggers) e, em seguida, mover os dados da pai para as filhas. Por exemplo, imagine um particionamento por mês/ano onde a pai chama foo e cada filha chama foo_anomes, para mover os dados já presentes: BEGIN; ... INSERT INTO foo_201306 SELECT * FROM foo WHERE bar BETWEEEN '2013-06-01' AND '2013-06-30'; INSERT INTO foo_201307 SELECT * FROM foo WHERE bar BETWEEEN '2013-07-01' AND '2013-07-31'; INSERT INTO foo_201308 SELECT * FROM foo WHERE bar BETWEEEN '2013-08-01' AND '2013-08-31'; ... TRUNCATE ONLY foo; COMMIT; Veja que isso foi feito em uma transação para evitar a visão de dados duplicados. Também recomendo fazer algumas consultas antes do truncate (um count(*) em cada tabela já é uma boa ideia) para verificar que não foi esquecida nenhuma partição. Outra forma que já vi pessoas usando é reinserir tudo na própria tabela, já que a trigger de particionamento cuidará de mover os dados para a partição correta: BEGIN; INSERT INTO foo SELECT * FROM foo; TRUNCATE ONLY foo; COMMIT; Apesar de funcionar bem, e talvez mais fácil, vai ser menos performático, mas isso vai depender da quantidade de dados. Por fim, lembre-se que não necessariamente a tabela pai deve ficar vazia, é possível manter dados na mesma,
Re: [pgbr-geral] Solução para backup
Como disse anteriormente, não será fornecido um novo servidor para tal finalidade, portanto, deveremos efetuar no mesmo servidor. Considere a possibilidade de convencer seus superiores em novas aquisições. Não se pode fazer milagres. A maioria dos SGBD exigem servidores dedicados. Além disso, você menciona anteriormente que está tirando dados do banco mas tem que deixá-los disponíveis para consultas. Vai colocar onde? Em uma nova instância no mesmo servidor? Acho que isso não vai resolver muito... Para lhe ajudar: Recentemente, após muitas tentativas de convencer os gestores de fazer uma nova aquisição (sem sucesso), tivemos uma parada de 2 horas em um dos equipamentos. Onde rodamos um sistema 24X7, onde as pessoas precisam do serviço para se manter vivos, 2 horas de parada podem representar muitos problemas, além de perdas humanas irreparáveis. Sorte a minha ter documentado todas as minhas solicitações, porque dessa forma, tive argumentos para justificar e conseguir o que precisava. Na pior das hipóteses você perde seu emprego mas não perde sua reputação. Att Carlos Antônio Pereira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 carlosanto...@utivida.com.br: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Não se pode fazer milagres. A maioria dos SGBD exigem servidores dedicados. Não necessariamente. Além disso, você menciona anteriormente que está tirando dados do banco mas tem que deixá-los disponíveis para consultas. Vai colocar onde? Em uma nova instância no mesmo servidor? Acho que isso não vai resolver muito... Uma instância separada consumirá ainda mais recursos, de fato. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20/08/2013 21:25, Guimarães Faria Corcete DUTRA escreveu: 2013/8/20 carlosanto...@utivida.com.br: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Tá certo. Deve ser melhor investigado. Acho que senti na pele o problema de verba... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Lentidão no PgDAC
Senhores, há algum tempo postei na lista a respeito de lentidão no componente PgDAC da devart. Depois de algumas tentativas de ajuda dos membros desta e de outra lista, e muitos testes, descobri que (pelo menos em meus testes) o problema está relacionado com as conexões wireless do Windows 8. Não consegui resolver mas, para efeitos de histórico e de uma possível luz futura, fica meu comentário relacionado. No momento estou usando Zeoslib que são bem espertinhos. Carlos Antônio Pereira ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Travamento
Jean, Estranho realmente não aparecer nada los logs, como mencionado por você. Eu já tive problemas com disco, mais normalmente eles apareciam no messages. O que recomendo é que caso ocorra o problema novamente, tente verificar na hora a estrutura dos discos (multipath -l, pvscan). Pois, assim pode vê se nesses momentos ele está se perdendo. Seria bom também ver como está a utilização dos discos com o 'sar -d' e a fila de processamento com o 'vmstat 2' (a cada 2 segundos). Se tiver com grande utilização dos discos e a fila estiver muito grande, aí é indicativo de que não está funcionando bem sua estrutura. Atenciosamente, Aldrey Galindo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20 de agosto de 2013 20:40, carlosanto...@utivida.com.br escreveu: Em 20/08/2013 21:25, Guimarães Faria Corcete DUTRA escreveu: 2013/8/20 carlosanto...@utivida.com.br**: Considere a possibilidade de convencer seus superiores em novas aquisições. Mas sem diagnóstico da lentidão? Isso pode queimar filme… amiúde o problema é aplicação, e o servidor dedicado pode até aumentar a latência. Tá certo. Deve ser melhor investigado. Acho que senti na pele o problema de verba... Mais uma pulga atrás da orelha... Sobre a lentidão que comentei, também estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o principal seja a base direto numa máquina física. Virtualização em PC costuma ter E/S sofrível. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? Correto. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução para backup
Em 20 de agosto de 2013 22:40, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2013/8/20 Danilo Silva danilo.dsg.go...@gmail.com: estava tendo em meu ambiente de desenvolvimento, que é o meu notebook, somente problema de lentidão, considerando que o ambiente estava em uma VM com 4 GiB de RAM, S.O linux, mais o apache e o banco tinha em torno de 7 GiB de tamanho, ou seja, não ocorria outros problemas. Recentemente formatei meu notebook e deixei o linux como S.O principal, agora continuo com o mesmo ambiente (banco, apache), porém, o notebook agora tem 6 GiB de RAM, e para minha surpresa, a lentidão não existe. 2 GiB de memória viva podem fazer muita diferença, mas suspeito que o principal seja a base direto numa máquina física. Virtualização em PC costuma ter E/S sofrível. Eu sei que se a gente efetuar um dump e subir novamente, vai subir um banco totalmente limpo (sem tuplas mortas) e etc, diminuindo até o tamanho do banco. Agora a dúvida: isso não seria facilmente resolvido executando vacuum full e até mesmo um reindex? ou estou enganado? Correto. Pois é, no servidor produção, que não está em VM e possui 12 GiB de ram, mesmo executando vacuum full, reindexdb, continuo tendo a lentidão. Acho até que estou com a minha memória (a da cabeça mesmo) corrompida, pois lembrei de alguns detalhes importantes: No servidor de produção, apesar do max_connections estar em 70, eu ainda não vi (a olho nú por assim dizer) esse número em conexões simultânea, mas a replicação nativa está ativa. Posso até ativar uma replicação no meu ambiente de desenvolvimento, mas como poderia simular as conexões simultâneas, não só as conexões mas as transações também? []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] ROTINA DE BACKUP COM VACUUM
Tudo bem pessoal.Criei uma rotina de backup do meu banco que esta na versão 9.2, é gostaria de implementar a mesma com compactação e vacuum full, baiaxo segue a rotina que criei, detalhe que criei um rolin no banco para mais um usuário. @echo off for /f tokens=1-4 delims=/ %%i in (%date%) do ( set dow=%%i set month=%%j set day=%%k set year=%%l ) for /f tokens=1-4 delims=: %%a in (%time%) do ( set hora=%%a set minu=%%b )set datestr=%hora%-%minu%-%dow%%year%-%month%-%day% echo datestr is %datestr% set BACKUP_FILE=Retaguarda-%datestr%.backup echo backup file name is %BACKUP_FILE% SET PGPASSWORD=postgres echo on pg_dump -i -h localhost -p 5432 -U retaguarda_dba -F c -b -v -f %BACKUP_FILE% retaguarda_db Esta funcionando beleza, pois coloquei a .bat dentro da pasta C:\Program Files\PostgreSQL\9.2\bin do 2008 server, como faço para implementar ela com o comando vacuum full antes de fazer o backup e depois compactar o banco? Waister Marques de Oliveira Telefone: (64) 9695-1884 Skype: waiste...@hotmail.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] [OFF] PgBr 2013 - Porto Velho - RO
Fantástico!!! Fico muitíssimo feliz e orgulhoso pelo formato e sucesso do evento. Aproveito para pedir desculpas pela minha ausência e por avisar de última hora que não conseguiria ir (de fato tentei negociar com a empresa até o último instante, mas no governo tá !@#$..), falhando com o compromisso assumido como palestrante. Segue o link de minha palestra[1] – Sim, é a mesma do FISL, mas com alguns ajustes técnicos para o público alvo do PGBR q é mais avançado. Também aproveito para parabenizar o Bueno e todos os colaboradores que contribuíram para o sucesso do evento. [1] http://www.slideshare.net/LeonardoCezar1/alta-disponibilidade-com-postgresql Um forte abraço! -Leo 2013/8/20 Fábio Telles Rodriguez fabio.tel...@gmail.com Meus comentários sobre o PGBR2013: http://savepoint.blog.br/e-mais-um-pgbr-se-vai/ Em 19 de agosto de 2013 12:32, Roberto Mello roberto.me...@gmail.comescreveu: 2013/8/19 Juliano Atanazio juliano.l...@gmail.com: Bom dia, pessoal! Gostaria aqui, brevemente agradecer a todos que participaram ou se envolveram de alguma forma, tornando possível o evento. Faço minhas as palavras do Juliano. Obrigado a todos que se esforçaram e trabalharam no evento, e até o próximo PgBR! Roberto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Leonardo Cezar http://www.postgreslogia.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
