[pgbr-geral] Alta disponibilidade
Caros colegas, estou utilizando o Heartbeat e gostaria de saber como deixar um processo ativo nas duas máquinas. Situação: Vou utilizar a replicação nativa e preciso que o postgres esteja ativo. Porem ao start o Heart no servidor principal ele está derrubando o postgres no secundário. Como evitar isto? No momento preciso de uma ajuda neste tópico. Já começei a estudar outras soluções recomendadas por outros colegas. Antecipadamente agradeço a ajuda. Att Paulo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Melhor servidor para Banco de dados
Bom dia, senhores. Estou fazendo uns testes com um servidor de banco de dados utilizando PostgreSQL 9.2 com FreeBSD. Sempre utilizei o Fedora (atualmente a versão 19) em servidores aqui da empresa. Li alguns artigos que mencionam o FreeBSD com um algorítmo diferenciado para sistemas multiprocessados, que trazem uma performance de 35% a 45% acima de outros servidores e de até 15% acima das distribuições Linux quando utilizado o PostgreSQL. Gostaria de saber a opinão de vocês a respeito e se há alguma distribuição Linux que seja mais indicada para Servidores de Banco de Dados PostgreSQL. Att Carlos ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhor servidor para Banco de dados
2013/7/23 Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br: Bom dia, senhores. Estou fazendo uns testes com um servidor de banco de dados utilizando PostgreSQL 9.2 com FreeBSD. Sempre utilizei o Fedora (atualmente a versão 19) em servidores aqui da empresa. Li alguns artigos que mencionam o FreeBSD com um algorítmo diferenciado para sistemas multiprocessados, que trazem uma performance de 35% a 45% acima de outros servidores e de até 15% acima das distribuições Linux quando utilizado o PostgreSQL. Gostaria de saber a opinão de vocês a respeito e se há alguma distribuição Linux que seja mais indicada para Servidores de Banco de Dados PostgreSQL. Att Carlos o que tenho a dizer é que é o proprio Tom Lane quem compila os pacotes do postgresql para o fedora. Itamar Reis Peixoto ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhor servidor para Banco de dados
Debian ! Em 23 de julho de 2013 11:26, Itamar Reis Peixoto ita...@ispbrasil.com.brescreveu: 2013/7/23 Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br: Bom dia, senhores. Estou fazendo uns testes com um servidor de banco de dados utilizando PostgreSQL 9.2 com FreeBSD. Sempre utilizei o Fedora (atualmente a versão 19) em servidores aqui da empresa. Li alguns artigos que mencionam o FreeBSD com um algorítmo diferenciado para sistemas multiprocessados, que trazem uma performance de 35% a 45% acima de outros servidores e de até 15% acima das distribuições Linux quando utilizado o PostgreSQL. Gostaria de saber a opinão de vocês a respeito e se há alguma distribuição Linux que seja mais indicada para Servidores de Banco de Dados PostgreSQL. Att Carlos o que tenho a dizer é que é o proprio Tom Lane quem compila os pacotes do postgresql para o fedora. Itamar Reis Peixoto ___ 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] Melhor servidor para Banco de dados
Em 23 de julho de 2013 11:23, Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br escreveu: Bom dia, senhores. Estou fazendo uns testes com um servidor de banco de dados utilizando PostgreSQL 9.2 com FreeBSD. Sempre utilizei o Fedora (atualmente a versão 19) em servidores aqui da empresa. Li alguns artigos que mencionam o FreeBSD com um algorítmo diferenciado para sistemas multiprocessados, que trazem uma performance de 35% a 45% acima de outros servidores e de até 15% acima das distribuições Linux quando utilizado o PostgreSQL. Particularmente tbm gosto muito do FreeBSD, mas ainda não o domino o suficiente para poder te falar com propriedade. Acredito que vc poderá obter realmente um desempenho melhor se utilizar o recurso de SoftUpdates [1] com partição UFS2, além de outras dicas sobre discos em [2]. E creio que seria na lista brasileira do FreeBSD [3] vc teria uma idéia melhor sobre o assunto. Recomendo fortemente que assine essa lista. []s [1] http://en.wikipedia.org/wiki/Soft_updates [2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html [3] https://www.fug.com.br/mailman/listinfo/freebsd Gostaria de saber a opinão de vocês a respeito e se há alguma distribuição Linux que seja mais indicada para Servidores de Banco de Dados PostgreSQL. Att Carlos ___ 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] Alta disponibilidade
On 23-07-2013 09:40, Paulo Bastos wrote: Paulo, para que repetir a mesma pergunta feita no dia anterior? Todos aqui receberam o seu email. Se você quer se certificar disso, consulte o histórico [1]. É rude ficar insistindo em um assunto (vide as regras da lista [2]). estou utilizando o Heartbeat e gostaria de saber como deixar um processo ativo nas duas máquinas. Situação: Vou utilizar a replicação nativa e preciso que o postgres esteja ativo. Porem ao start o Heart no servidor principal ele está derrubando o postgres no secundário. Como evitar isto? Você está confundindo conceitos. Replicação é uma coisa e alta disponibilidade é outra. Aconselho que você leia sobre o assunto [3] para entender onde o conceito HA se encaixa. Você não informou qual é a arquitetura utilizada, mas as mais comuns são: (i) shared storage: *não* pode haver dois serviços postgres ativos. É o caso da solução Red Hat Cluster Suite; (ii) shared nothing: você terá que montar o failover fazendo com que o heartbeat crie o trigger_file. Nessa solução o failback é muito complicado pois você terá que refazer o servidor principal a partir do servidor que assumiu o serviço (se sua base é algumas centenas de gigabytes ou a sua rede é instável isso fica bastante complicado pois o processo pode levar algumas dezenas de minutos). PS Não poste mais perguntas sobre heartbeat nesta lista. Ao invés disso, procure uma lista de HA. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2013-July/thread.html [2] http://www.postgresql.org.br/RegrasLista [3] http://www.postgresql.org/docs/9.2/static/high-availability.html -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhor servidor para Banco de dados
Em 23 de julho de 2013 11:23, Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br escreveu: Bom dia, senhores. Estou fazendo uns testes com um servidor de banco de dados utilizando PostgreSQL 9.2 com FreeBSD. Sempre utilizei o Fedora (atualmente a versão 19) em servidores aqui da empresa. Li alguns artigos que mencionam o FreeBSD com um algorítmo diferenciado para sistemas multiprocessados, que trazem uma performance de 35% a 45% acima de outros servidores e de até 15% acima das distribuições Linux quando utilizado o PostgreSQL. Gostaria de saber a opinão de vocês a respeito e se há alguma distribuição Linux que seja mais indicada para Servidores de Banco de Dados PostgreSQL. Cara a diferença de desempenho de FreeBSD para Linux é pequena. Não importa o que digam. Não conheço nenhum teste SÉRIO comparando os 2. Eu particularmente acredito que a sua escolha deva se basear em outros princípios como: 1) Escolher algo estável que não esteja no limite da curva de desenvolvimento. Neste quesito, eu prefiro o Red Hat ou CentoOS e Debian no lugar do Fedora e Ubuntu. 2) Prefira a plataforma com a qual você e a equipe da empresa tem maior facilidade. Em alguns casos eu até mesmo acho que é melhor rodar em Windows. Não adianta nada ter desempenho não ter ninguém para dar suporte na plataforma. Discussões em torno de desempenho são intermináveis. A maior diferença está na mão do desenvolvedor, DBA e sysadmin, nesta ordem de importância. Quanto ao SO, o que vale é saber ajustar bem o seu sistema de arquivos, fazer um bom particionamento, saber se recuperar bem em caso de desastre, isso sim é o importa. -- Atenciosamente, Fábio Telles Rodriguez blog: http://savepoint.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
Re: [pgbr-geral] Melhorar desempenho de uma função
Em 19-07-2013 11:12, Danilo Silva escreveu:
Segue os explains
CREATE OR REPLACE VIEW vcons_pend_documento AS
SELECT ht011.codtb011, ht011.codtb001 AS codempresa, ht011.codtb002 AS
codcto, tb002.dscr AS ctonome, ht011.codtb004 AS codcli, ht011.codtb012
AS codprod, count(*) AS total
FROM historico_tb011 ht011
JOIN tb002ctrodtrb tb002 ON tb002.codtb001 = ht011.codtb001 AND
tb002.codtb002 = ht011.codtb002
JOIN tb005unnegsrv tb005 ON tb005.codtb001 = ht011.codtb001 AND
tb005.codtb004 = ht011.codtb004 AND tb005.codtb005 = ht011.coddest_uni
JOIN tb012tpmltcxa tb012 ON tb012.codtb001 = ht011.codtb001 AND
tb012.codtb004 = ht011.codtb004 AND tb012.codtb012 = ht011.codtb012
WHERE ht011.baixado = false AND ht011.saida = false AND ht011.datahist
'2012-11-05'::date
AND f_soma_diautil(ht011.datahist, ht011.horahist, 'now'::text::date,
'now'::text::time(0) without time zone, ht011.codtb001, tb005.uf::text,
tb005.cdde::text) = 86400::double precision
AND (ht011.idhistorico_tb011 IN ( SELECT h11.idhistorico_tb011 FROM
historico_tb011 h11 WHERE h11.codtb011 = ht011.codtb011 ORDER BY
h11.datahist DESC, h11.horahist DESC LIMIT 1))
GROUP BY ht011.codtb011, ht011.codtb001, ht011.codtb002, tb002.dscr,
ht011.codtb004, ht011.codtb012;
EXPLAIN ANALYSE SELECT ctonome, SUM(total) AS total,codcto FROM
vcons_pend_documento
WHERE ((SELECT 1::text = ANY(string_to_array((SELECT confsis_valor FROM
configuracao_sistema WHERE (confsis_variavel = 'MOSTRAPEND24HPERFIL')),
','))) IS TRUE)
GROUP BY codempresa, codcto, ctonome, codcli ORDER BY total DESC LIMIT
15 OFFSET 0;
Limit (cost=3111275.63..3111275.66 rows=15 width=38) (actual
time=66561.745..66561.746 rows=5 loops=1)
InitPlan 2 (returns $1)
- Result (cost=1.18..1.20 rows=1 width=0) (actual
time=0.032..0.032 rows=1 loops=1)
InitPlan 1 (returns $0)
- Seq Scan on configuracao_sistema (cost=0.00..1.18
rows=1 width=9) (actual time=0.012..0.012 rows=1 loops=1)
Filter: (confsis_variavel = 'MOSTRAPEND24HPERFIL'::text)
- Sort (cost=3111274.43..3111328.53 rows=21643 width=38) (actual
time=66561.744..66561.744 rows=5 loops=1)
Sort Key: (sum((count(*
Sort Method: quicksort Memory: 25kB
- HashAggregate (cost=3110527.00..3110743.43 rows=21643
width=38) (actual time=66561.669..66561.701 rows=5 loops=1)
Este HashAggregate aqui foi caro.
- Result (cost=3103493.25..3107821.71 rows=216423
width=38) (actual time=66561.225..66561.537 rows=237 loops=1)
One-Time Filter: ($1 IS TRUE)
- HashAggregate (cost=3103493.25..3105657.48
rows=216423 width=38) (actual time=66561.191..66561.483 rows=237 loops=1)
- Hash Join (cost=7429.24..3099705.85
rows=216423 width=38) (actual time=38486.447..66560.231 rows=237 loops=1)
Hash Cond: ((ht011.codtb001 =
tb012.codtb001) AND (ht011.codtb004 = tb012.codtb004) AND
(ht011.codtb012 = tb012.codtb012))
- Hash Join
(cost=7423.74..3095101.36 rows=216423 width=50) (actual
time=390.452..66559.164 rows=401 loops=1)
Por causa dos demais HashAggregates acima.
Hash Cond: ((ht011.codtb001 =
tb002.codtb001) AND (ht011.codtb002 = tb002.codtb002))
- Hash Join
(cost=7422.36..3091312.58 rows=216423 width=28) (actual
time=390.427..66557.919 rows=401 loops=1)
Hash Cond: ((ht011.codtb001
= tb005.codtb001) AND (ht011.codtb004 = tb005.codtb004) AND
(ht011.coddest_uni = tb005.codtb005))
Join Filter:
(f_soma_diautil(ht011.datahist, ht011.horahist, ('now'::text)::date,
('now'::text)::time(0) without time zone, ht011.codtb001,
(tb005.uf)::text, (tb005.cdde)::text) = 86400::double precision)
- Bitmap Heap Scan on
historico_tb011 ht011 (cost=7128.99..239.91 rows=652072 width=36)
(actual time=10.110..174.309 rows=13844 loops=1)
Recheck Cond:
(datahist '2012-11-05'::date)
Filter: ((NOT
baixado) AND (NOT saida) AND (SubPlan 3))
- Bitmap Index Scan
on historico_tb011_saida_idx (cost=0.00..6965.98 rows=184375 width=0)
(actual time=9.871..9.871 rows=22293 loops=1)
Index Cond:
((baixado = false) AND (saida = false) AND (datahist '2012-11-05'::date))
SubPlan 3
- Limit
(cost=14.23..14.23 rows=1 width=16) (actual time=0.009..0.009 rows=1
loops=13847)
- Sort
(cost=14.23..14.25 rows=9 width=16) (actual time=0.008..0.008 rows=1
loops=13847)
Re: [pgbr-geral] Melhorar desempenho de uma função
Quando você coloca a função na visão e ainda filtra por essa coluna na sua consulta, o planejador não consegue otimizar. Prefira manter a visão sem a função na coluna que você vai filtrar e faça: 1) a função na cláusula WHERE final; 2) talvez, um índice por função (functional index). A última linha da função estava como *LANGUAGE plpgsql VOLATILE, alterei de VOLATILE para IMMUTABLE para criar o index: CREATE INDEX historico_tb011_function_idx ON historico_tb011 (f_soma_diautil(datahist,horahist,CURRENT_DATE,LOCALTIME(0),codtb001,'','')); Mas ocorre o erro ERROR: functions in index expression must be marked IMMUTABLE. Estou errando em algum lugar? []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] Melhorar desempenho de uma função
Em 23-07-2013 16:53, Danilo Silva escreveu: Quando você coloca a função na visão e ainda filtra por essa coluna na sua consulta, o planejador não consegue otimizar. Prefira manter a visão sem a função na coluna que você vai filtrar e faça: 1) a função na cláusula WHERE final; 2) talvez, um índice por função (functional index). A última linha da função estava como *LANGUAGE plpgsql VOLATILE, alterei de VOLATILE para IMMUTABLE para criar o index: CREATE INDEX historico_tb011_function_idx ON historico_tb011 (f_soma_diautil(datahist,horahist,CURRENT_DATE,LOCALTIME(0),codtb001,'','')); Mas ocorre o erro ERROR: functions in index expression must be marked IMMUTABLE. Estou errando em algum lugar? Sim. Você não pode criar um índice funcional com uma expressão variável (como LOCALTIME) pois isso depende... do momento atual :) []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] Ultimo Vacuum Full Executado
Boa Noite, Preciso saber quando foi o ultimo vacuum full executado em uma tabela, para o vacuum já consegui. Mais observei que não funciona para o vacuum full. Minha versão do PostgreSQL 9.1.9. Segue select que usei para ver o ultimo vacuum executado. select relname, last_vacuum, last_autovacuum from pg_stat_all_tables where schemaname = 'sis'; Alguma dica? Agradeço desde já! Att Glauco Torres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ultimo Vacuum Full Executado
Boa Noite, Preciso saber quando foi o ultimo vacuum full executado em uma tabela, para o vacuum já consegui. Mais observei que não funciona para o vacuum full. Minha versão do PostgreSQL 9.1.9. Segue select que usei para ver o ultimo vacuum executado. select relname, last_vacuum, last_autovacuum from pg_stat_all_tables where schemaname = 'sis'; Alguma dica? Infelizmente esta informação não é armazenada nos catálogos do PostgreSQL. O VACUUM FULL é uma operação extrema, que deve ser raramente executada. O motivo dela não ser armazenada é que, como a tabela é 100% limpa de todo espaço livre (na versão que você está os índices também são limpos) então todas as estatísticas de espaço livre deixam de ser importantes, o FSM - Free Space Map da tabela é zerado, logo, não é armazenada em lugar nenhum esta informação porque ela não é relevante para as operações de banco de dados. Considere um bom ajuste do autovacuum e esqueça que existe o VACUUM FULL rotineiramente. Faça seus planejamentos a partir do inchaço das tabelas (veja consulta de bloat que postei semana passada aqui) e considere logar as execuções de vacuum no log, onde um analisador como o PgBadger pode te dar boas notícias sobre como vai a manutenção automática de seu banco de dados. []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] Trim X Chr(13) X Espaco
Uma sugestão de solução para remover caracteres especiais seria criar uma
store function para remover esse caracteres especiais.
http://emersonhermann.blogspot.com.br/2013/07/remover-caracteres-especiais-em-campos.html
Em 22 de julho de 2013 20:50, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
2013/7/22 Marcelo da Silva marc...@ig.com.br
Pessoal, tenho o seguinte, sabe como é o usuário no copia e cola, as
vezes vem caracteres invisiveis, mas que nos dão uma dor de cabeça.
Veja os exemplos dos select abaixo:
SELECT 'TESTE' = TESTE
SELECT TRIM('TESTE ') = TESTE
SELECT TRIM('TESTE
') = TESTE
Vejam que o ultimo select tem um Chr(13) no final da string, o que deixa
o Trim menos eficiente pois ele tira o chr(13) mas deixa um espaço.
Me parece que o Trim entende que logo depois do tem um novo caracter,
então ele passa a considerar o como um intervalo de palavras... isso
acaba causando problemas numa verificação no Delphi, que que o Trim do
Delphi limpa mesmo caracteres como chr(13) quando percebe que não há mais
caracteres visiveis.
Pergunta: Isso é um bug do trim Postgres ou esse funcionamento está
correto?
É o comportamento padrão. O PostgreSQL vai remover apenas espaços do
início e fim quando usada função trim com apenas uma string como parâmetro
[1].
Mas... Você pode passar como segundo parâmetro quais serão os caracteres
que devem ser removidos do início e fim, bastando passar uma string com os
mesmos. Exemplo, para ignorar espaço, tab, line feed e carriage return:
SELECT trim(coluna, E' \n\r\t') ...;
^ obs: tem um espaço no início da string.
[1]
http://www.postgresql.org/docs/current/static/functions-string.html#FUNCTIONS-STRING-OTHER
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
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
