Planeta PostgreSQL-BR

08/03/2010

Claudio Bezerra Leopoldino

PostgreSQL 9.0: Quais são as novidades? A visão das "funcionalidades da semana"!

O PostgreSQL está em sua quarta versão alfa, e começam a aparecer indicações das novas funcionalidades e alterações que foram introduzidas. O informe semanal "PostgreSQL Weekly News", organizado por David Fetter apresenta uma seção chamada "Feature of the Week", ou funcionalidade da semana, descrevendo uma alteração em desenvolvimento. Os informes originais podem ser consultados aqui.

Abaixo listo as últimas funcionalidades citadas, agregando algum comentário quando pertinente:

07/03/2010 - A saída do EXPLAIN pode ser formatada como XML, JSON, YAML e o mecanismo de análise está muito mais simples. O formato tradicional de texto ainda é o formato padrão.

Obs: Os novos formatos permitem a definição de relatórios e ferramentas de análise dos resultados do comando Explain, facilitando a otimização de consultas.

28/02/2010 - A suíte pgbench agora é multi-threaded, o que lhe permite tirar partido de múltiplos núcleos de CPU.

Obs: O pgbench é um utilitário que faz o benchmark de desempenho do servidor. Pode ser utilizada para testes de estresse, carga e performance. O uso de múltiplas threads faz com que os resultados sejam mais confiáveis e obtidos em menor tempo.

21/02/2010 - Agora você pode controlar o comportamento de valores distintos para cada coluna com ALTER TABLE ALTER COLUMN ... ... SET (parâmetro = valor ,...) onde parâmetro pode ser uma das n_distinct e n_distinct_inherited. Valores positivos são assumidos como sendo o número de valores distintos aceitos, 0 diz que o planejador da consulta deve utilizar os resultados do comando ANALYZE, e os números negativos (que devem estar entre -1 e 0) fazem com que o planejador estime o número de valores distintos como o número de linhas multiplicado pelo valor absoluto do número.

Obs: Funcionalidade de performance, para consultas específicas.

14/02/2010 - Violações de restrição de unicidade de valor agora geram mensagens de erro mais detalhadas.

Obs: Agora fica mais fácil encontrar a causa de exceções de valores repetidos e como resolvê-las.

31/01/2010 - A checagem de constraints de não repetição de valores pode agora ser adiada até a hora do commit.

Obs: Funcionalidade de performance, para consultas específicas.

24/01/2010 - A sintaxe DROP IF EXISTS agora trabalha em colunas e restrições.

Obs: Sintaxe interessante para os desenvolvedores de ferramentas de banco de dados.

17/01/2010 - O Vacuum full foi alterado para gerar novos arquivos para tabelas e índices por padrão. Esta implementação é baseada no antigo comando CLUSTER e mais eficiente e efetiva. A funcionalidade antiga do VACUUM FULL ainda pode ser acessada através do comando VACUUM FULL INPLACE, mas será incompatível com o Hot Standby.

Obs: O Vacuum Full Implace só parece ser vantajoso para sistemas com pouco espaço em disco. A nova Implementação promete ganho de tempo nas manutenções de banco.

10/01/2010 - Agora você pode armazenar em log o estado de consultas SQL, erros, etc, usando "%e" na sua log_line_prefix.

03/01/2010 - No psql o uso de "\d" agora mostra quantas tabelas herdadas uma tabela-mãe tem, e "\d+" lista os nomes das tabelas herdadas.

Obs: Alteração de pouco impacto para quem não utiliza recursos objeto-relacionais.

27/12/2009 - Hot Standby. Após 1,5 anos de desenvolvimento, você pode finalmente executar consultas somente leitura PITR contra os escravos. Graças ao Simon Riggs, Heikki Linnakangas, qualquer muitos outros esforços incessantes.

Obs: O melhor uso de hardware promete ganho de desempenho e redução de custos para grandes sistemas escaláveis e resistentes a falhas. Esta é uma das funcionalidaes que merecerá bastante atenção dos DBAs.

20/12/2009 - Cláusulas WHEN sobre Triggers. Na versão 8.5 Alpha3 você será capaz de criar triggers com uma cláusula WHEN para que as mesmas executem apenas se os valores ou condições específicas ocorrerem. Graças Itagaki Takahiro e a equipe da NTT.

Obs: Esta alteração permite triggers mais específicas com menos validações internas, possivelmente impactando positivamente seu desempenho.

13/12/2009 - Constraints de exclusão (por Jeff Davis) permitem que você especifique como únicos "dados" que abranjam um intervalo, como uma área geométrica, um período de tempo, ou um array.

Obs: Função importante para quem trabalha com lógicas de negócios no banco de dados.

Abaixo, a redação oficial da coluna:

07/03/2010 - EXPLAIN output can be formatted as XML, JSON, and YAML, making machine parsing much simpler. The traditional text format is still the default format.

28/02/2010 - The pgbench suite is now multi-threaded, allowing you to take advantage of multiple CPU cores.

21/02/2010 - You can now control the behavior of distinct values per column using ALTER TABLE...ALTER COLUMN...SET (parameter=value,...) where parameter can be one of n_distinct and n_distinct_inherited. Positive numbers are assumed to be the number of distinct values, 0 tells the planner to use the results from ANALYZE, and negative numbers (which should be between -1 and 0, cause the planner to estimate the number of distinct values as the estimated number of rows multiplied by the absolute value of the number.

14/02/2010 - Uniqueness violations now raise more detailed error messages.

31/01/2010 - Uniqueness constraints can now be deferred until commit time.

24/01/2010 - The DROP IF EXISTS syntax now works on columns and constraints.

17/01/2010 - VACUUM FULL has been changed to now generate all-new files for the vacuumed table and indexes. This is based on the old CLUSTER command, and is both more efficient and more effective. The old functionality of VACUUM FULL can still be accessed via VACUUM FULL INPLACE, but will be incompatible with Hot Standby.

10/01/2010 - You can now log SQL state for queries, errors, etc., using %e in your log_line_prefix.

03/01/2010 - In psql, \d now shows how many inherited tables a parent has, and \d+ lists them.

27/12/2009 - Hot Standby. After 1.5 years of development, you can at last run read-only queries against PITR slaves. Thanks to Simon Riggs, Heikki Linnakangas, any many others for unceasing efforts.

20/12/2009 - WHEN clauses on Triggers. In 8.5Alpha3, you will be able to create triggers with a WHEN clause so that they will only execute if specific values or conditions occur. Thanks Itagaki Takahiro and the NTT team.

13/12/2009 - Exclusion Constraints (by Jeff Davis) allow you to specify as "unique" data which covers a range, such as a geometric area, a period of time, or an array.

O que acharam destas novas funcionalidades? Elas impactarão o seu trabalho atual?

by cbleopoldino (claudio.leopoldino@gmail.com) at 08/03/2010 11:36

01/03/2010

Claudio Bezerra Leopoldino

Versão Alfa do PostgreSQL 9.0 Lançada!

A versão de desenvolvimento ALFA do PostgreSQL 9.0 está disponível para downloads e testes.

Na verdade, é a quarta versão alfa, uma vez que três versões anteriores haviam sido lançadas como sendo para o PostgreSQL 8.5.

Faça o download aqui!

Veja as notas de lançamento com os avanços desta versão aqui!

by cbleopoldino (claudio.leopoldino@gmail.com) at 01/03/2010 01:57

19/02/2010

Claudio Bezerra Leopoldino

Select - Cláusulas FOR UPDATE, FOR SHARE e NOWAIT

Influenciar nos mecanismos de lock do banco de dados nem sempre é um processo intuitivo. No entanto pode ser bastante útil para garantia da confiabilidade de resultados e para ajustes de desempenho.

O PostgreSQL oferece algumas cláusulas relativamente simples que permitem este tipo de controle no caso de consultas no banco de dados: FOR UPDATE, FOR SHARE e NOWAIT.

O uso de consultas com a cláusula FOR UPDATE obriga o servidor a bloquear os registros consultados para leitura e escrita durante otranscorrer da transação. Desta forma se garante que o que está sendo visualizado corresponde ao que está armazenado no banco de dados. A cláusula FOR SHARE efetua bloqueio de escrita, mas permite que leituras sejam feitas aos dados consultados.

Ambas as cláusulas bloqueiam apenas os dados que são recuperados na consulta.

A cláusula NOWAIT pode ser utilizada tanto com FOR UPDATE quanto com FOR SHARE, e força a ocorrência de erro caso o servidor tenha de esperar par a a obtenção de bloqueios nos dados consultados. Desta forma, sacrifica-se a transação para que não se perca tempo na fila de espera por bloqueios.

As cláusulas UNION, INTERSECT e EXCEPT até o momento não são compatíveis com FOR UPDATE e FOR SHARE.

Para os próximos exemplo, serão utilizadas as seguintes tabelas:

CREATE TABLE pai (codpai integer,nomepai varchar(50));
CREATE TABLE filho (codpai integer,codfilho integer,nomefilho varchar(50));

Exemplos:

1 - Sintaxe simples com FOR UPDATE.

SELECT * FROM pai FOR UPDATE;

2 - Sintaxe simples com FOR SHARE.

EXPLAIN SELECT * FROM pai FOR SHARE;

3 - Uso de FOR SHARE em consulta com junção.

SELECT *
FROM pai p, filho f
WHERE p.codpai = f.codpai
FOR SHARE;

4 - Uso de NOWAIT.

SELECT * FROM pai FOR UPDATE NOWAIT;

5 - Uso de FOR UPDATE em transação de atualização.

BEGIN;
SELECT * FROM pai FOR UPDATE;
UPDATE pai SET nomepai = nomepai ' Father';
COMMIT;

by cbleopoldino (claudio.leopoldino@gmail.com) at 19/02/2010 10:10

27/01/2010

Claudio Bezerra Leopoldino

Algoritmos: Caixa de Banco Simulado no PostgreSQL

Ao retirar dinheiro de um caixa eletrônico, solicitamos uma quantia e o caixa decide quantas notas de cada tipo disponível nós receberemos. O algoritmo que faz esta decisão é relativamente simples.

Abaixo coloco uma função que recebe uma solicitação de dinheiro e calcula quantas notas de 100, 50, 10, 5 e 1 serão retornadas ao solicitante:

--Retornando notas do caixa eletrônico
--Notas de 1, 5, 10, 50 e 100
CREATE OR REPLACE FUNCTION caixa_elet (pvalor integer) RETURNS text AS $$
DECLARE
sretorno text;
qnota1 integer;
qnota5 integer;
qnota10 integer;
qnota50 integer;
qnota100 integer;
BEGIN
sretorno := '';
qnota100 := (pvalor - (pvalor % 100))/100;
qnota50 := ((pvalor % 100) - (pvalor % 50)) /50;
qnota10 := ((pvalor % 50) - (pvalor % 10)) /10;
qnota5 := ((pvalor % 10) - (pvalor % 5)) /5;
qnota1 := ((pvalor % 5) - (pvalor % 1)) /1;
sretorno := 'Total: ' || pvalor || chr(10) || 'Notas de 100:' || qnota100 || chr(10) || 'Notas de 50:' || qnota50 || chr(10) || 'Notas de 10:' || qnota10 || chr(10) || 'Notas de 5:' || qnota5 || chr(10) || 'Notas de 1:' || qnota1;
RETURN sretorno; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;

Chamada da função e resultado apresentado:

SELECT caixa_elet(1078);

"Total: 1078
Notas de 100:10
Notas de 50:1
Notas de 10:2
Notas de 5:1
Notas de 1:3"

SELECT caixa_elet(2189);

"Total: 2189
Notas de 100:21
Notas de 50:1
Notas de 10:3
Notas de 5:1
Notas de 1:4"

Agora, gostaria de fazer algumas perguntas para os programadores de plantão:
- O código da função caixa_elet está correto?
- O código da função caixa_elet pode ser melhorado de que formas?
- Que alterações seriam necessárias para acrescentar notas de 20?

Aguardo suas contribuições nos comentários!

by cbleopoldino (claudio.leopoldino@gmail.com) at 27/01/2010 04:51

21/01/2010

Claudio Bezerra Leopoldino

8.5 sai de cena antes de ser lançado: nova versão do Postgres será a 9.0!

O anúncio não é oficial, mas a versão 8.5 terá sua numeração alterada para 9.0. Os testes e o desenvolvimento continuam normalmente.

As razões envolvendo a mudança compreendem o aumento das funcionalidades da nova versão e da abrangência das alterações no código, o grande tempo desde a primeira versão 8.* e um benefício em termos de marketing, pela insinuação de uma mudança mais substancial refletida na alteração de 8.4 para 9.0.

Você concorda com essa atitude?

by cbleopoldino (claudio.leopoldino@gmail.com) at 21/01/2010 02:43

18/12/2009

Claudio Bezerra Leopoldino

Onde esse elefante está? O que nos diz o google insights sobre o ano de 2009?

As pesquisas na internet dizem muito sobre a aceitação de produtos, serviços, candidatos a cargos eletivos e sobre o uso de programas e sistemas. Com o PostgreSQL não é diferente. Fiz uma breve pesquisa sobre o ano de 2009 no google insights e os resultados compartilho neste post. O levantamento do ano passado está aqui.

As imagens capturadas e os dados foram todos coletados dia 18/12/2009.

- O ano de 2009 foi relativamente estável. Houve uma queda nas buscas com a festas de fim de ano e um aumento nas pesquisas durante o lançamento da nova versão 8.4, em meados de abril. A figura 1 mostra a evolução destas buscas no ano.


Considerando os últimos 4 anos, houve uma diminuição nas buscas. No entanto isto não significa necessariamente perda de espaço, podendo indicar também uma maior disseminação do conhecimento sobre o banco, que reduz a necessidade de pesquisas na rede.


- No mundo, Japão e Rússia crescem no ranking relativo de buscas e recuperam as primeiras posições perdidas em 2008 para Cuba e China.


- No mundo ganha destaque a busca "PostgreSQL MySQL", indício de que o PostgreSQL não é considerado uma alternativa tão natural ao Oracle ou ao Sql Server, mas uma boa opção em relação ao MySQL (Esta é apenas uma suposição que carece de mais comprovação!).

- No Brasil destaco as buscas "PostgreSQL Windows" e "PostgreSQL Linux". A pontuação destas buscas mostra que a compatibilidae com vários sistemas operacionais é um importante fator para os projetos de software nacionais.

- O Brasil continua em uma posição intermediária. Na América do Sul o destaque fica para a Bolívia, que ocupa a quarta posição entre os 10 maiores índices de busca pelo PostgreSQL no Google.

- Dentre os estados brasileiros, Distrito Federal e Ceará ocupam as duas primeiras posições. Santa Catarina, Paraná e Rio Grande do Sul estão nas três posições subsequentes, o que mostra a força do PostgreSQL na Região Sul.


Não recomendo que estes dados sejam utilizados para a tomada de decisões. São informações retrospectivas sujeitas a erros estatísticos! 2009 está consumado. Agora é trabalhar pelo 2010!

by cbleopoldino (claudio.leopoldino@gmail.com) at 18/12/2009 05:27

17/12/2009

Claudio Bezerra Leopoldino

GreenSQL: O Rinoceronte Amigo do Elefante!

Segurança nunca é demais e cautela e caldo de galinha não fazem mal a ninguém! No caso do PostgreSQL não é diferente, e qualquer atualização de segurança é sempre recomendada.

O GreenSQL é um firewall de código aberto que visa proteger bases de dados de ataques tipo "SQL Injection", verificando os comandos submetidos ao banco, restringindo comandos de administrador para criação e destruição de tabelas e outros objetos e impedindo a submissão de códigos maliciosos. Seu símbolo é o do Rinoceronte.



A versão mais recente agregou o suporte ao PostgreSQL ao do MySQL já existente. Espera-se que o Rinoceronte possa agir como guarda costas do elefante a partir deste lançamento! Abaixo, uma imagem da arquitetura do GreenSQL.

A licença é GPL. Teste e me diga o que achou!

by cbleopoldino (claudio.leopoldino@gmail.com) at 17/12/2009 04:11

10/12/2009

Claudio Bezerra Leopoldino

Enquete aponta que PostgreSQL Crescerá com a Compra do MySQL

A compra recente da Sun pela Oracle, incluindo o banco MySQL começa a trazer mudanças no mercado. Segundo enquete realizada pelo "The 451 Group", há uma tendência de redução do market share do MySQL em detrimento do PostgreSQL e do novo banco de dados MariaDB, que seria um fork livre do MySQL com um processamento de consultas novo e bastante promissor.

Este autor acha que há espaço para todos, e acredita no crescimento do PostgreSQL independentemente do apresentado pelas demais alternativas. Aproveita para lembrar que enquetes revelam apenas intenções, e que o mercado pode tomar outra direção.

O que você acha? O que tem acontecido na sua empresa?

O artigo original pode ser obtido aqui.

by cbleopoldino (claudio.leopoldino@gmail.com) at 10/12/2009 10:50

08/12/2009

Rodrigo Hjort

PostgreSQL monitoring on ZABBIX



I've recently started to get to know ZABBIX [1] a little deeper, especially regarding PostgreSQL database servers monitoring. At first sight I thought it an incredible monitoring and notification system as it fulfills most of the requirements I wondered to have in Cedrus [2].

After setting up some basic OS-related items to be monitored, I was searching for PostgreSQL specific configurations and then I found a wiki [3] on ZABBIX UserParameters. It is indeed very simple! You just need to create SQL statements and then invoke them with psql. If successful, you could append the corresponding lines into ZABBIX agent configuration file and restart it. Then, in the front-end application, what is left to do is to properly set these PostgreSQL parameters to a given host.

I've created some additional parameters I always use in PostgreSQL instances in order to monitor the server health. In this case, I previously created a user called "zabbix" and a database with same name on PostgreSQL.

Here are the included lines on /etc/zabbix/zabbix_agentd.conf:


# PostgreSQL custom parameters

# instance version
UserParameter=pgsql.version,psql -U zabbix zabbix -Atc 'select version()'

# instance databases summary
UserParameter=pgsql.db.summary,psql -c "select a.datname, pg_size_pretty(pg_database_size(a.datid)) as size, cast(blks_hit/(blks_read+blks_hit+0.000001)*100.0 as numeric(5,2)) as cache, cast(xact_commit/(xact_rollback+xact_commit+0.000001)*100.0 as numeric(5,2)) as success from pg_stat_database a order by a.datname"

# total databases size
UserParameter=pgsql.db.totalsize,psql -Atc "select sum(pg_database_size(datid)) as total_size from pg_stat_database"

# specific database size (in bytes)
UserParameter=pgsql.db.size[*],psql -Atc "select pg_database_size('$1') as size"

# database cache hit ratio (percentage)
UserParameter=pgsql.db.cache[*],psql -Atc "select cast(blks_hit/(blks_read+blks_hit+0.000001)*100.0 as numeric(5,2)) as cache from pg_stat_database where datname = '$1'"

# database success rate (percentage)
UserParameter=pgsql.db.success[*],psql -Atc "select cast(xact_commit/(xact_rollback+xact_commit+0.000001)*100.0 as numeric(5,2)) as success from pg_stat_database where datname = '$1'"


After restarting ZABBIX Agent, you can check whether the added parameters are valid by issuing zabbix_get command in a shell. For instance, to query PostgreSQL instance version, type this:


$ zabbix_get -s localhost -k pgsql.version
PostgreSQL 8.3.3 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

This other script returns an overview of existing databases in the instance, highlighting their names, size in disk, cache hit ratio and percentage of successful transactions:


$ zabbix_get -s localhost -k pgsql.db.summary
datname | size | cache | success
-------------+---------+-------+---------
auction5 | 4400 kB | 0.00 | 0.00
auditing | 4512 kB | 0.00 | 0.00
escola | 4656 kB | 0.00 | 0.00
postgres | 4223 kB | 99.81 | 100.00
rodrigo | 4144 kB | 0.00 | 0.00
template0 | 4144 kB | 0.00 | 0.00
template1 | 4144 kB | 0.00 | 0.00
zabbix | 10 MB | 99.99 | 100.00
zahle | 86 MB | 0.00 | 0.00
(9 registros)

In order to measure total space in disk occupied by the entire instance, this script should be used:


$ zabbix_get -s localhost -k pgsql.db.totalsize
1507326452

On the other hand, to retrieve the space (in bytes) occupied by a single database, you just need to specify its name in the parameter key, as exemplified below:


$ zabbix_get -s localhost -k pgsql.db.size[auction5]
4505604

Likewise, to recover cache hit ratio (in percentage) of a single database, use this key:


$ zabbix_get -s localhost -k pgsql.db.cache[zabbix]
99.99

The percentage of successful transactions in relation to all attempts is given by this parameter:


$ zabbix_get -s localhost -k pgsql.db.success[postgres]
100.00


After testing these parameters, it is time to set them up onto ZABBIX Frontend as illustrated below:



It is very interesting to further add some traps and actions based on the configured items. For example, to send an email to the DBA every time a given database grows up faster than expected or whether its cache ratio starts to lower significantly.

At Joe Uhl's blog there is a post [4] concerning using ZABBIX to monitor PostgreSQL TPS (Transactions per Second). It is an interesting source as it explains how to configure deltas and graphs in ZABBIX.

References:


[1] ZABBIX Monitoring Solution
[2] Cedrus: PostgreSQL Manager
[3] ZABBIX Wiki - PostgreSQL UserParameters
[4] Monitoring PostgreSQL TPS with Zabbix

by Rodrigo HJORT (noreply@blogger.com) at 08/12/2009 06:12

07/12/2009

PostgreSQL Brasil

Agenda Livre

A agenda livre é um lugar para compartilhar com todos os eventos de tecnologia e software livre que acontecem no país. Se você quiser participar ou compartilhar esta agenda, basta colocar o código abaixo no seu portal.
<iframe src='//www.google.com/calendar/embed?height=600&wkst=1&bgcolor=%23ffffff&src=c1lp1q1iv9s2p6of0pi5g38gqg%40group.calendar.google.com&color=%2328754E&ctz=America%2FSao_Paulo' style=' border-width:0 ' width='100%' height='600' frameborder='0' scrolling='no'></iframe>

leia mais

by filhocf at 07/12/2009 11:19

27/11/2009

Claudio Bezerra Leopoldino

O Comando Table

O comando TABLE é muito pouco conhecido entre os usuário do Postgres, no entanto isto não chega a ser um problema. É um comando que funciona mais como uma curiosidade do que como uma funcionalidade real. Sua função principal é economizar digitação de consultas relativas a todos os dados de uma tabela.

Consultas com a sintaxe abaixo, por exemplo:

SELECT * FROM tabela;

Poderiam ser simplificadas para:

TABLE tabela;

O ganho é apenas de tempo de digitação ou de simplificação. O plano de execução é o mesmo.

O comando TABLE pode ser utilizado no lugar de "SELECT * FROM" de diversas maneiras diferentes:

Exemplo 1:

TABLE ADDRESS; --Recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 2:

TABLE ADDRESS ORDER BY postal_code; --Classifica e recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 3:

TABLE ADDRESS ORDER BY postal_code DESC; --Classifica de modo decrescente e recupera todas as colunas e linhas da tabela ADDRESS

Exemplo 4:

SELECT * FROM ADDRESS
UNION ALL
TABLE ADDRESS; --Uso de TABLE com UNION

by cbleopoldino (claudio.leopoldino@gmail.com) at 27/11/2009 09:52

07/11/2009

Rodrigo Hjort

Auction5 sample web application released



I'm very proud to announce that Auction5, a sample web application built under Demoiselle Framework [1] has just been released to the public. Its complete documentation including source codes retrieval and deployment instructions can be found here: [2].

Auction5 is a MVC-structured application that exemplifies an online auction system using Demoiselle Framework and related technologies. Its main goal is to provide a complete transactional application based on JavaServer Faces (JSF 1.2 [3]) and Java Persistence API (JPA 1.0 [4]) specifications.


Moreover, the sample assembles several top computing technologies such as Java EE, Maven, JBoss Application Server, Apache Tomcat, and PostgreSQL DBMS.

Please send me your comments and or suggestions.

References:
[1] Demoiselle Framework
[2] Auction5 Application Sample
[3] JavaServer Faces 1.2
[4] Java Persistence API 1.0

by Rodrigo HJORT (noreply@blogger.com) at 07/11/2009 06:52

04/11/2009

PostgreSQL Brasil

Replicação de dados com java

Alessandro Silva nos enviou um link interessante que pode ser útil para quem quer ter exemplos de replicação de dados.

O link aponta para um vídeo demonstrando como realizar uma replicação bem simples de dados entre duas bases:

http://www.youtube.com/watch?v=Z7_WCDLVh_o

Outros links sobre replicação:

leia mais

by guedes at 04/11/2009 12:06

31/10/2009

Leandro Guimarães Faria Corcete DUTRA

Convite Google Wave

Tenho doze convites do Google Wave para diſtribuir — o que é engraçado, porque até hoje não o uſei de fato.

Prioridade para comunidades de que participo, como PoſtgreSQL, Debian, Projeto GNU, Gutenberg, Sociedade Bíblica Croßwire, fotografia Quatro Terços e Olympus Zuiko, OpenRAW &c.

by DUTRA, Leandro Guimarães Faria Corcete (leandro.gfc.dutra@gmail.com) at 31/10/2009 10:50

PostgreSQL Brasil

30/10/2009

João Cosme

HA em Postgresql = Warm Stand By + HeartBeat + HAPM


Prefácio hehehe

Ja faz um bom tempo que eu gostaria de postar novamente, ando muito ocupado não sei se vocês sabem, mas estou no SERPRO em Porto Alegre agora envolvido não mais com o desenvolvimento em si do EXPRESSO  mas com a  a PRODUÇÃO!! Maravilha tudo o que eu queria….

AAAAA como é bom o cheiro dos servidores, aquele lindo terminal e finalmente Postgresql novamente …. O bom filho a casa retorna! Finalmente retornei com postgresql , não com a mesma exclusividade mas já é uma ótima!!

Mandando o SALVE!!

Galera gostaria de mandar um salve pros amigos que reencontrei no PGCON2009 e para os novas amizades que foram conquistadas , depois posto sobre o PGCON!!

Um salve pro meu brother Euler… esse já é irmão!!!

Um salve pro Minerin “Cara de coveiro”…

Um salve pro Léo Lindo e para a Cris….

Um salve pro Jovem “J”

Um salve pro Telles

Um salve pro Zé do Cleyssom de BSB (Agora convertido em Postgresql :P )

Um salve pro Diogo Biazus

Um salve pro pequeno inseto (Ele sabe quem é)

Um salve pro Roberto Mello (Cara 10 ….. PRAZER do Ca!@#$$# conhecer esse cabra)

Um salve pro Francisco , (Outro cara 10 …. que conheci tb em mais um evento)

Um salve pro GUTO de BSB….

Um salve pro “Rolon Boy” (Esse tb sabe quem é hehhe)

Um salve pro DUTRA.

Um salve pra Marisa (Valeu Marisaaaaaaaa……….. )

Um salve pro …. pra……

Um salve pro  Galera do MEC ( O Rodrigão e o Marcelo)

Um salve pros brothers da CELEPAR( esqueci o nome foi mal)

Um salve pro Emanuel “EL Aprendiz” da Argentina !

Um salve pra geral que prestigiou o evento e a minha palestra!!

2009-09-14-153739

Voltando ao Post….

Vejo muita gente comentando sobre Replicação , alta disponibilidade, balanceamento de carga. Em vários eventos de SL são debatidos esses temas e como está na semana do PGCON 3 edição , acho que seria uma boa soltar um post de interesse de muita gente, pois é galera ai vai …. Vamos ganhar um dinheirinho com consultoria ai….

Cenário

Não irei entrar em conceitos como PITR, WAL , pá e bola…. Então são pré-requisitos para um bom entendimento!! Não que não consiga implementar sem esses conceitos mas véio de boa…. Estuda!! :P

Um servidor primário e um servidor secundário.

O  servidor  primário recebe as requisições  feliz da vida  e tranquilo , o servidor secundário fica em Stand-By em modo seca pimenteiro = on hehehe , pois ele não pode ser não pode ser acessado. Em um determinado momento meu servidor primário deixa de prover o serviço e…..

Meu servidor em Stand-by cheio de moral e doido para mostrar serviço, assume a posição  do servidor primário de maneira  “transparente” ao usuário… pois é … nem tudo é perfeito e o afobado jovem em stand by pode deixar um dado ou outro de lado :P

Nessa brincadeira ai  já traçamos alguns conceitos importantes : Alta-disponibilidade , Replicação Síncrona e uma característica importante na implementação do stand-by (Não pode ser acessado nem para consulta)

HA-PG

Para alcançar o objetivo iremos utilizar  como coadjuvantes os softwares HAPM e o HeartBeat que nos possibilitaram a Alta-disponibilidade do serviço.

Configurando o Ambiente!

Anota ai jovem…

Postgresql-8.3
postgresql-contrib-8.3
heartbeat-2
nfs-kernel-server
hapm

Vamos utilizar o Debian Lenny como exemplo e instalar os pacotes acima nas duas máquinas:

apt-get install postgresql-8.3 heartbeat-2 nfs-kernel-server hapm  postgresql-8.3-contrib

Uma vez instalados os pacotes nos dois servidores criaremos um local para arquivar os segmentos WAL. É altamente recomentados gravar os segmentos WAL remotamente do servidor primário, pois se o servidor primário cair , não teremos acesso aos segmentos WAL, o que comprometeria a replicação e consequentemente a disponibilidade do sistema.

Os arquivos devem ter permissões de escrita e leitura para ambos os servidores. No exemplo que estamos demonstrando a técnica, criaremos um compartilhamento NFS no servidor Stand By e o servidor primário exportará os arquivos WAL(cansei de colocar o Wal em negrito) para este determinado local. Tenha a certeza que o diretório pertença ao usuário postgres. Entendeu??

Criação do diretório na máquina slave  para arquivamento  no qual o usuário PostgreSQL pode escrever e ler:

Como usuário root:

mkdir /psql-archive

chown postgres.postgres /pgsql-archive

echo “/psql-archive IP_MASTER (rw,sync,no_subtree_check)” >> /etc/exports

exportfs -a

su postgres -c “touch /psql-archive/mounted”


O que os comandos acima fazem??

Criamos um diretório chamado /psql-archive cujo o dono é o safadinho do usuário postgres e permitimos que a máquina PRIMÁRIA possa montar o diretório remotamente podendo escrever e ler nele… já ia esquecer ,também criamos de ante-mão um arquivo lá no diretório chamado mounted… (aí está a mágica!!)

Agora na máquina primária

mkdir /psql-archive

chown postgres.postgres /psql-archive

mount IP_SLAVE:/psql-archive /psql-archive


O que os comandos acima fazem??

Agora na máquina primária criamos um diretório chamado /psql-archive cujo o dono  é o postgres montamos remotamente o diretório da máquina slave psql-archive no /psql-archive do primário.


Ainda na máquina primária iremos ativar o recurso de WALs :

no arquivo /etc/postgresql/8.3/main/postgresql.conf alterar as seguintes linhas:

archive_mode = on

archive_command = “test -f /psql_archive/mounted && test ! -f /psql_archive/%f && rsync -a %p /psql_archive/%f”

Que lindo o archive_command!!! Fandásdigo como diria tiririca, confesso esse eu copiei  hehehhe mas eu sei o que ele faz :)

Vamos por partes!!!

arvhice command = (condicao 1) && (condicao 2)

Condição 1 = teste -f /psql/mounted

Lembra do comando touch /psql/mounted no servidor seca pimenteiro, ops .. escravo?? O que ele faz é verificar se o arquivo mounted existe, se ele existir significa que a partição remota está montada  :)

Condição 2 = test ! -f /psql_archive/%f && rsync -a %p /psql_archive/%f

Verifica se já existe o arquivo Wall no secundário , se não existir ele copia o Wal file para lá :)

o “&&”,  elementar meu caro as duas condições tem que serem válidas ou seja

(particao tem que estar montada ) e (nao deve existir o arquivo no diretorio la no escravo)

Reiniciar o serviço do PostgreSQL

/etc/init.d/Postgresql-8.3 restart

A Partir deste momento meu caro parabéns, já está gerando arquivos Wals e o mais legal, lá no diretório do escravo… nossa imagina o cabra ter que suportar ter que ser secundário e neguin escrevendo no diretório dele hehehh.

Prova dos 9!

Vamos lá…

Agora devemos fazer o backup básico do diretório $PGDATA, sem a necessidade de parar o banco de dados , isso no servidor primário logicamente.

psql -U postgres

Bem vindo ao psql 8.3.3, o terminal iterativo do PostgreSQL.

Digite: \copyright para mostrar termos de distribuição

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

\g ou terminar com ponto-e-vírgula para executar a consulta

\q para sair


postgres=# select pg_start_backup(‘meu_backup’);

pg_start_backup

2/CE005F40

(1 registro)

postgres=# \q

# su – postgres

# cd /var/lib/Postgresql/8.3/

$ tar -czf /psql-archive/base_backup.tar.gz *

tar: Removendo `/’ inicial dos nomes dos membros

tar: main/pg_xlog/0000000100000002000000CF: arquivo alterado enquanto estava sendo lido

…..

…..

…..

Estamos gerando um backup a fisico do diretório de dados e colocando no diretório compartilhado /psql-archive . Uma vez terminado o backup, conectar no banco de dados e efetuar o seguinte comando:

psql -U postgres -h localhost

Bem vindo ao psql 8.3.3, o terminal iterativo do Postgresql.


Digite: \copyright para mostrar termos de distribuição

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

\g ou terminar com ponto-e-vírgula para executar a consulta

\q para sair


conexão SSL (cifra: DHE-RSA-AES256-SHA, bits: 256)

postgres=# select pg_stop_backup();

pg_stop_backup

—————-

2/D000BC0C

(1 registro)


postgres=# \q


Na máquina secundária novamente

mv /var/lib/Postgresql/8.3/main /var/lib/Postgresql/8.3/main.old

Estamos renomeando o $PGDATA da máquina secundária para $PGDATA.old

mv /psql-archive/base_backup.tar.gz /var/lib/Postgresql/8.3

Copiando o backup do servidor primário para o diretório /var/lib/Postgresql;8.3

tar -xzvf /var/lib/Postgresql/8.3

Mandando bala descompactando o danado…

cd /var/lib/Postgresql/8.3/main/

Entrando no diretório $PGDATA novo do secundário…

rm -Rf ./pg_xlog/*

Removendo os arquivos do pg_xlog do primário…. Cansei…

Vamos vamos…. Vamos !!!!!

Criação do arquivo recovery.conf na máquina para o modo contínuo de recovery dentro do $PGDATA ( /var/lib/Postgresql/8.3/main/) com a seguinte linha:

restore_command = ‘/usr/lib/postgresql/8.3/bin/pg_standby -d -l -r 3 -s 60 -t /psql_archive/trigger.done /psql_archive %f %p %r 2>>/tmp/pg_standby.log’

Essa linha basicamente indica o Postgresql para continuar o recovery até encontrar um arquivo chamado /psql-archive/trigger.done, ou seja , quando o servidor primário cair, um arquivo trigger.done será criado e o procedimento da subida do servidor slave é iniciado.


Iniciando o servidor Stand by

#  /etc/init.d/Postgresql-8.3 start

* Starting Postgresql 8.3 database server

[ OK ]

# tail -f /tmp/pg_standby.log

Keep archive history : 000000000000000000000000 and later

running restore : OK

Trigger file : /psql-archive/trigger.done

Waiting for WAL file : 000000020000000200000088

WAL file path : /psql-archive/000000020000000200000088

Restoring to… : pg_xlog/RECOVERYXLOG

Sleep interval : 60 seconds

Max wait interval : 0 forever

Command for restore : ln -s -f “/psql-archive/000000020000000200000088″ “pg_xlog/RECOVERYXLOG”

Keep archive history : 000000000000000000000000 and later

Que lindo Que lindo …. Vamos Vamos…

Criação do arquivo recovery.conf na máquina para o modo contínuo de recovery dentro do $PGDATA ( /var/lib/Postgresql/8.3/main/) com a seguinte linha:

restore_command = ‘pg_standby -d -l -r 3 -s 60 -t /psql_archive/trigger.done /psql_archive %f %p %r 2>>/tmp/pg_standby.log’

Essa linha basicamente indica o Postgresql para continuar o recovery até encontrar um arquivo chamado /psql-archive/trigger.done, ou seja , quando o servidor primário cair, um arquivo trigger.done será criado e o procedimento da subida do servidor slave é iniciado.


#psql -U postgres -h localhost

psql: FATAL: o sistema de banco de dados está iniciando ou seja esta em restore continuo.

????? Num intindi nada!!!???

O servidor está em restore constante!!!! Não temos como acessar o servidor (WARM Stand by Falei isso lá em cimaaa nocomeço do Post)

Gerando arquivos Wals para serem replicados a partir do host primário

Começaremos a gerar alguns arquivos Wals .

# psql -U postgres

Bem vindo ao psql 8.3.3, o terminal iterativo do Postgresql.


Digite: \copyright para mostrar termos de distribuição

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

\g ou terminar com ponto-e-vírgula para executar a consulta

\q para sair


postgres=# create table teste as select * from pg_class, pg_attribute;

SELECT

postgres=# create table teste1 as select * from pg_class, pg_attribute;

SELECT


postgres=#\q

Vários arquivos Wals foram gerados e gravados no diretório especificado no archive_command, configuração do servidor que no caso, mais uma vez pra não se perder  o tal /psql-archive que está montado na máquina primária .

# ls -l /psql-archive

total 738184

-rw——- 1 postgres postgres 16777216 2009-10-06 16:31 0000000100000002000000CE

-rw——- 1 postgres postgres 246 2009-10-06 16:35 0000000100000002000000CE.00005F40.backup

-rw——- 1 postgres postgres 16777216 2009-10-06 16:33 0000000100000002000000CF

-rw——- 1 postgres postgres 16777216 2009-10-06 16:35 0000000100000002000000D0

-rw——- 1 postgres postgres 16777216 2009-10-06 16:37 0000000100000002000000D1

-rw——- 1 postgres postgres 16777216 2009-10-06 16:39 0000000100000002000000D2

-rw——- 1 postgres postgres 16777216 2009-10-06 16:41 0000000100000002000000D3

-rw——- 1 postgres postgres 16777216 2009-10-06 16:43 0000000100000002000000D4

-rw——- 1 postgres postgres 16777216 2009-10-06 16:45 0000000100000002000000D5

-rw——- 1 postgres postgres 16777216 2009-10-06 16:47 0000000100000002000000D6

-rw——- 1 postgres postgres 16777216 2009-10-06 16:49 0000000100000002000000D7

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000D8

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000D9

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DA

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DB

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DC

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DD

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DE

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000DF

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000E0

-rw——- 1 postgres postgres 16777216 2009-10-06 16:51 0000000100000002000000E1


Testando a replicação para a máquina em Stand By

Agora criaremos o arquivo /tmp/trigger.done.

touch /psql-archive/trigger.done

Neste momento, o servidor Stand By detectará que deve sair do modo recovery e levantar o serviço. Ou seja, quando o arquivo /psql-archive/trigger.done existir, o servidor em Stand By sai do modo recovery e passa a operar normalmente. Você pode logar no servidor Stand By e verificar as tabelas criadas.

To be continued…

Até agora implementamos o Warm Stand by… Sem alta disponibilidade…..  o próximo post mostro como garantir a disponibilidade de forma que o servidor escravo assuma o ip do outro servidor mantendo a disponibilidade do serviço…



by joaocosme at 30/10/2009 05:49

26/10/2009

PostgreSQL Brasil

Dica: ZEOS Lib - Componente para acesso nativo ao PostgreSQL.

Bruno da Silva Reis nos enviou uma dica de uso da ZEOS Lib, que é um componente muito utilizado por desenvolvedores Delphi para acesso nativo ao PostgreSQL, sem que seja necessário o uso de drivers externos como ODBC, JDBC, BDE e outros artifícios.

Você pode fazer o download do componente aqui ou participar dos fóruns aqui

by guedes at 26/10/2009 06:26

25/10/2009

Fabio Telles

COMMIT

O sol nascendo aqui na Unicamp é um espetáculo que vale a pena ser visto. Aqui da piscina do hotel eu acordei cedo para colocar as idéias no lugar. Ainde temos muito trabalho pela frente. Colocar as palestras no site, acertar toda a parte burocrática e acertar um problema ou outro.

Mas ontem terminamos o evento. Como sempre, muitos problemas, muito mais do que os participantes do evento possam imaginar. Muitos erros, mas também muito aprendizado com os erros das edições anteriores.

Novos patrocinadores, novos palestrantes, novos temas, novos organizadores, novos participantes, novos clientes, novas idéias. Sim. Muita coisa nova. Sobre tudo, novos amigos, novas perspectivas, novos horizontes.

Se o primeiro PGCon Brasil, em 2007, foi um marco em termos de organização da comunidade, hoje, em 2009 temos um novo marco. As pessoas bateram à  nossa porta, entraram no evento, subiram no palco e disseram: “Hey, nós estamos utilizando o PostgreSQL em missão crítica aqui, precisamos da ajuda de vocês”. Sim, o PostgreSQL está crescendo e tomando de assalto grandes CPDs. Não é mais algo que entra pela porta dos fundos. Muita gente já testou, já sabe que funciona e também conhece suas peculiaridades. Já temos casos de implantações grandes rodando há alguns anos. Não é mais uma aventura, é uma realidade.

Sim, muita gente não sabe disso. Temos muito o que caminhar. Mas quem acompanha as listas de discussão (você AINDA não acompanha?), o planeta e principalmente acompanha os nossos eventos sabe que as coisas estão mudando. Pare para pensar como eram as coisas há 5 anos atrás?

Bom, ontem eu vi porquê valeu a pena esperar 3 anos para trazer o Bruce Momjian para o Brasil: em um dado momento ele contou um pouco da história do PostgreSQL e da sua história no PostgreSQL. De como ele começou a se dedicar ao projeto e de como aquilo inicialmente afetou a sua família e as suas finanças pessoais. Mas de repente, algo estranho começa a acontecer…. as pessoas começaram a utilizar o Postgres no Japão! Sim, em ambientes de produção. Estas pessoas criaram uma comunidade, com artigos, documentação, livros, profissionais qualificados e se tornaram o primeiro mercado a efetivamente utilizar o PostgreSQL para valer. A dedicação por anos de trabalho parece ter valido a pena.

Para mim isto tem um significado muito especial. Todos que me conhecem sabem que eu ainda não me sustento trabalhando com PostgreSQL. Mas já fazem alguns anos que eu tenho mantido algum tipo de contribuição para a comunidade brasileira. Sim, tem muita gente que começou muito antes e fez muito mais do que eu. Mas para mim e para muitos outros a questão é acreditar no projeto, acreditar nas pessoas. Cada vez que conheço um novo desenvolvedor do time central do Postgres eu fico mais empolgado. Pois são pessoas facinantes que estão desenvolvendo o Postgres. São pessoas que não são apenas desenvolvedores extraordinários. São pessoas com uma cultura e uma visão de mundo fantástica. É fantástico poder conversar com estas pessoas e saber que existem mais loucos pelo mundo. Que estes loucos fazem a diferença no mundo e que talvez você possa até fazer parte disso tudo, de dar a sua parte para construir um mundo mais próximo daquilo que você acredita que ele deveria ser.

YES, WE CAN!!!

IS DONE

IS JUST THE BEGINING…

Ok, devo postar mais sobre o evento, as fotos, as palestras, as pessoas, e outras coisas que rolaram no PGCon Brasil 2009, mas o dia já está claro e a água da piscina parece estar ótima… :-)

by Telles at 25/10/2009 10:37

18/10/2009

Rodrigo Hjort

Echoing hidden psql statements



One of the greatest advantages of a Database Management System is its embedded data dictionary, also called metadata or system catalog [1]. On PostgreSQL DBMS it is not different, and its metadata are widely used by database handling tools.

A great and yet simple tool available to this relational database is psql [2], a command-line, bash-enabled application that permits issuing SQL instructions to PostgreSQL server instances.

Even when sending a simple command such as "\d" on psql, there might be one or several SQL instructions sent internally to that given instance. Knowing exactly what is being sent could help a database administrator or even a simple developer on common and ordinary daily tasks.

So, how could we know those SQL instructions? Simpler than expected!

There is an environment variable on psql called ECHO_HIDDEN, which once set echoes all hidden instructions, as its own name says. In order to enable that, simply execute the following command:


# \set ECHO_HIDDEN

Then, try to issue some internal commands like "\l" (typing "\?" shows the entire list of options). Here is the output after enabling ECHO_HIDDEN:


# \l
********* QUERY **********
SELECT d.datname as "Name",
r.rolname as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding"
FROM pg_catalog.pg_database d
JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
ORDER BY 1;
**************************

List of databases
Name | Owner | Encoding
-------------+----------------+----------
auction5 | sa_auction5 | UTF8
postgres | postgres | UTF8
rodrigo | rodrigo | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
(5 rows)

Note the contents enclosed by "QUERY" and "***". Here are the internal SQL instructions respectively performed.

When you're done, you could deactivate this variable by executing the command below:


# \unset ECHO_HIDDEN

That's it! :D

References:
[1] PostgreSQL 8.3.8 Documentation - System Catalogs
[2] psql - PostgreSQL interactive terminal

by Rodrigo HJORT (noreply@blogger.com) at 18/10/2009 08:40

14/10/2009

PostgreSQL Brasil

Inscrições on-line para o PGCon Brasil 2009 terminam em 19/10

As inscrições on-line para o PGCon Brasil 2009 terminam neste dia 19/10. Todos que efetivarem sua inscrição terão desconto especial.

Faça já sua inscrição!

 Acompanhe também os destaques do evento no site oficial do PGCon Brasil 2009.

by telles at 14/10/2009 09:16

08/10/2009

Ribamar FS

Dicas e Truque do SQL no PostgreSQL


Trabalhando com SQL

Quase todas estas dicas abaixo recebi na lista de PostgreSQL do http://postgresql.org.br. Sempre que lembrei concedi os devidos créditos.
1) Criar Tabela tendo outra outra como base e já importando todos os registros dessa outra:
CREATE TABLE tabelanova AS SELECT * FROM tabealexistente;
2) Inserindo com SELECT
Inserir todos os registros de uma tabela em outra:
INSERT INTO tabelaqueimporta SELECT * from tabelaqueexporta;

insert into engenharia.insumos (grupo,insumo,descricao,unidade) select grupo,insumo,descricao, CAST(unidade AS int2) AS “unidade” from engenharia.apagar

insert into engenharia.insumos (grupo,insumo,descricao,unidade) select grupo,insumo,descricao, cast(unidade AS INT2) AS unidade from engenharia.apagar

$conn = pg_connect(”host=10.40.100.186 dbname=apoena user=_postgresql”);
for($x=10;$x<=87;$x++){
$sql=”update engenharia.precos set custo_produtivo = (select custo_produtivo from engenharia.apagar where insumo=’$x’) where insumo=’00′ || ‘$x’”;
$ret=pg_query($conn,$sql);
}


3) Atualizar um campo em todos os registros de uma tabela recebendo de outra tabela:

UPDATE servicos s SET custo = total FROM composicoes c
WHERE s.tabela = c.tabela AND s.servico = c.servico

Uso do Like e de Expressões Regulares

Registros:
Ribamar Ferreira de Sousa
João Pereira Brito

Usando LIKE e ILIKE

SELECT * FROM clientes WHERE nome LIKE ‘Riba%’; // Retorna Ribamar Ferreira de Sousa
SELECT * FROM clientes WHERE nome LIKE ‘riba%’; // Nada retorna
SELECT * FROM clientes WHERE nome ILIKE ‘riba%’; // Retorna Ribamar Ferreira de Sousa
SELECT * FROM clientes WHERE nome NOT LIKE ‘pedro’; // Retorna ambos os registros

Usando Expressões Regulares

SELECT * FROM clientes WHERE nome ~~ ‘Riba%’; // Retorna Ribamar Ferreira de Sousa
SELECT * FROM clientes WHERE nome ~~ ‘riba%’; // Nada retorna
SELECT * FROM clientes WHERE nome ~~* ‘riba%’; // Retorna Ribamar Ferreira de Sousa
SELECT * FROM clientes WHERE nome !~~ ‘pedro’; // Retorna ambos os registros
SELECT nome FROM clientes WHERE nome ~ ‘Ribamar Ferreira de Sousa’; // Retorna Ribamar Ferreira de Sousa
SELECT * FROM clientes WHERE nome !~ ‘jorge’; // Retorna ambos

4) Buscar nas tabelas de sistema do postgresql, todos as tabelas de um determinado schema, os campos que sejam do tipo boolean..

SELECT n.nspname AS Schema, c.relname AS Tabela, t.typname AS Tipo
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
LEFT JOIN pg_type t ON t.oid = c.reltype
WHERE c.relkind = ‘r’::”char”
AND t.typname = ‘boolean’;


5) Exemplos de Joins

Join com 4 tabelas

$w_sql = ” TRUE “;

if ( $p_tabela != “”) { $w_sql = $w_sql . ” AND tabela ~~*’” . $p_tabela . “‘”; }
if ( $p_insumo_grupo != “”) { $w_sql = $w_sql . ” AND insumo_grupo ~~*’” .$p_insumo_grupo.”‘”; }
if ( $p_insumo != “”) { $w_sql = $w_sql . ” AND insumo ~~*’” . $p_insumo . “‘”; }
if ( $p_fornecedor != “”) { $w_sql = $w_sql . ” AND fornecedor ~~*’” .$p_fornecedor.”‘”; }

$w_sql=”SELECT distinct on (p.tabela, p.insumo_grupo, p.insumo, p.fornecedor) p.custo_produtivo, p.data_inclusao,
t.tabela, t.descricao as tabelad,
ig.grupo, ig.descricao as insumogd,
i.grupo, i.insumo, i.descricao as insumod,
f.codigo_fornecedor, f.razao_social as fornecedord
FROM $m_table as p, $m_table_tab as t, $m_table_ing as ig, $m_table_ins as i, $m_table_for as f
WHERE p.tabela=t.tabela AND p.insumo_grupo=ig.grupo AND p.insumo=i.insumo AND p.fornecedor=f.codigo_fornecedor
AND p.insumo_grupo = i.grupo ORDER BY p.tabela DESC, p.insumo_grupo;”;

/*
p – $m_table (engenharia.precos)
i – $m_table_ins (engenharia.insumos)
ig – $m_table_ing (engenharia.insumos_grupos)
t – $m_table_tab (engenharia.tabela)
*/


6) Mudar Tipo de Dados de Campo – CAST (Só >=8.0):

ALTER TABLE tabela ALTER COLUMN campo TYPE tipo;
ALTER TABLE produtos ALTER COLUMN preco TYPE numeric(10,2);
ALTER TABLE produtos ALTER COLUMN data TYPE DATE USING CAST (data AS DATE);


7) Renomear Tabela

ALTER TABLE tabela RENAME TO nomenovo;
ALTER TABLE produtos RENAME TO equipamentos;


8) Tamanho de Tabela, Banco ou Todos os Bancos do SGBD:

Tamanho de Banco de Dados (postgresql 8.1 ou superior):
select pg_database_size(’nomebanco’);

Tamanho de Tabela
select pg_tablespace_size(’nometabela’);

Tamanho de todos os bancos de dados do SGBD:
select (sum(relpages) * 8) / 1024 || ‘ MB’ as tamanho from pg_class where relowner > 1;

Ou

select (sum(relpages) / 2^7) :: int || ‘ MB’ as tamanho from pg_class where relowner > 1;


9) Validação de e-mails

1 – select distinct(campo_email),campo_nome, campos_n from tabela where campo_email like ‘%@%.%’
2 – SELECT POSITION(’@', ‘ribafs@gmail.com’) > 0
3 – select ‘coutinho.php@gmail.com’ ~ ‘@’
4 – select ‘coutinho.php@gmail.com’ like ‘%@%’
5 – select if (’campo_email’ like “%@%.%”,”TRUE”,”FALSE”) as flag, campo_adcional from tabela
6 – select ‘coutinho@gmail.com’ similar to ‘%@%.%’;


10) Temos um campo (insumo) com valores = 1, 2, 3, … 87

Queremos atualizar para 0001, 0002, 0003, … 0087

UPDATE equipamentos SET insumo = ‘000′ || insumo WHERE LENGTH(insumo) = 1;
UPDATE equipamentos SET insumo = ‘00′ || insumo WHERE LENGTH(insumo) = 2;

Outra saída mais elegante ainda:

UPDATE equipamentos SET insumo = REPEAT(’0′, 4-LENGTH(insumo)) || insumo;


11) Retornar o número de usuários conectados

select count(*) from pg_stat_activity

pg_stat_database que apresenta para cada banco de dados o número de conexões.
Eu particularmente acho que fica mais fácil de visualizar do que o pg_stat_activity quando se tem muitas conexões.

Mostrar uso dos índices dos bancos de dados:
select * from pg_statio_user_indexes;

select * from pg_stat_user_indexes;

Mostra estatística de uso das tabelas e manutenção:
select * from pg_stat_all_tables;

Mostra todas as tabelas do atual esquema do atual banco:
select * from pg_stat_user_tables;

pg_stat_get_tuples_returned(oid) bigint Number of rows read by sequential scans when argument is a table, or number of index entries returned when argument is an index
pg_stat_get_tuples_fetched(oid) bigint Number of table rows fetched by bitmap scans when argument is a table, or table rows fetched by simple index scans using the index when argument is an index
pg_stat_get_tuples_inserted(oid) bigint Number of rows inserted into table
pg_stat_get_tuples_updated(oid) bigint Number of rows updated in table
pg_stat_get_tuples_deleted(oid) bigint Number of rows deleted from table
pg_stat_get_blocks_fetched(oid) bigint Number of disk block fetch requests for table or index
pg_stat_get_blocks_hit(oid) bigint Number of disk block requests found in cache for table or index
pg_stat_get_last_vacuum_time(oid) timestamptz Time of the last vacuum initiated by the user on this table
pg_stat_get_last_autovacuum_time(oid) timestamptz Time of the last vacuum initiated by the autovacuum daemon on this table
pg_stat_get_last_analyze_time(oid) timestamptz Time of the last analyze initiated by the user on this table
pg_stat_get_last_autoanalyze_time(oid) timestamptz Time of the last analyze initiated by the autovacuum daemon on this table

This is controlled by configuration parameters that are normally set in postgresql.conf

The function pg_stat_get_backend_idset provides a convenient way to generate one row for each active server process. For example, to show the PIDs and current queries of all server processes:

SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_activity(s.backendid) AS current_query
FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;

Visualizar os processos do portgresql num UNIX:

ps auxww | grep ^postgres

Formato de retorno:
postgres: user database host activity

12) Corrigindo Estouro do Máximo de transações (2 bilhões)
Constatando:

SELECT datname, age(datfrozenxid) FROM pg_database;

age acusa mais de 2 bilhões

Tarcizio Meurer

- Execute um dumpall na base
- drop a base e o agrupamento de dados
- recrie o agrupamento
- recrie a base
- carrege os dados novemente.
13) Total de Registros de Todos os Bancos do SGBD (PHP):

<?php

$conexao=pg_connect(”host=127.0.0.1 user=postgres password=postabir”);

$sql=”SELECT datname AS banco FROM pg_database ORDER BY datname”;
$consulta=pg_query($conexao,$sql);

$banco = array();
$c=0;
while ($data = @pg_fetch_object($consulta,$c)) {
$cons=$data->banco;

$banco[] .= $cons;
$c++;
}

$sql2=”SELECT n.nspname as esquema,c.relname as tabela FROM pg_namespace n, pg_class c
WHERE n.oid = c.relnamespace
and c.relkind = ‘r’ — no indices
and n.nspname not like ‘pg\\_%’ — no catalogs
and n.nspname != ‘information_schema’ — no information_schema
ORDER BY nspname, relname”;

for ($x=0; $x < count($banco);$x++){
if ($banco[$x] !=”template0″ && $banco[$x] != “template1″ && $banco[$x] !=”postgres”){
$conexao2=pg_connect(”host=127.0.0.1 dbname=$banco[$x] user=postgres password=postabir”);
$consulta2=pg_query( $conexao2, $sql2 );

while ($data = pg_fetch_object($consulta2)) {
$esquematab=$data->esquema.’.’.$data->tabela;
$sql3=”SELECT count(*) FROM $esquematab”;
$consulta3=pg_query($conexao2,$sql3);
$res=@pg_fetch_array($consulta3);

print ‘Banco.Esquema.Tabela -> ‘.$banco[$x].’.’.$data->esquema.’.’.$data->tabela.’ – Registro(s) – ‘.$res[0].”;
$total += $res[0];
}

}
}
print “Total de Registro de todas as tabelas de todos os bancos “. $total;

?>
14) Uso da Constraint check

CREATE TABLE testes(
codigo serial primary key,
idade integer,
check (idade > 18 AND idade < 70)
)

Alternativas:

check (preco > desconto)

check (desconto > 0 AND preco > desconto)

————-
Somente aceitar c ou e (simulando campo tipo enum do MySQL):
tipo char(1) check (tipo =’c’ OR tipo=’e')

Para este cria-se uma combo com values ‘c’ e ‘e’.
15) Manutenção do PostgreSQL:
No CRON:

/home/pgsql/bin/psql -c “vacuum full analyse” -d dadosadv -U postgres

Consultas no Pronpt do SO:
psql -U postgres -d banco -c “SELECT * FROM clientes”

Manutenção em Tabela
vacuum analize tabela;

Reindexar Banco, tabela ou índice
reindex database banco;

Exibir plano de consulta
explain select * from tabela;

Exibir todos os parâmetros de runtime
show all;
16) Consulta com Dias Úteis

Só para constar aqui vai uma expressão SQL que fornece os
dias úteis de um período. Considerei que existe uma tabela
com o registro dos feriados e outros dias que não devem ser
considerados (emendas, pontos facultativos, etc):

SELECT dia FROM
(SELECT (’2007-10-01′::date+s.a*’1 day’::interval) AS dia
FROM generate_series(0, ‘2007-10-31′::date -
‘2007-10-01′::date, 1) AS s(a)) foo
WHERE EXTRACT(DOW FROM dia) BETWEEN 1 AND 5
EXCEPT
SELECT dia FROM tab_feriado;

Osvaldo (na lista postgresql-br)
17) Update em uma chave primária sem causar duplicação de chave

UPDATE teste SET coluna1 = t_aux.coluna1+1
FROM (
SELECT coluna1
FROM teste
ORDER BY coluna1 DESC
) t_aux
WHERE teste.coluna1 = t_aux.coluna1;

Osvaldo (na lista postgresql-br)
18) Como saber se existe uma transação ativa

select pg_stat_activity;

Dica do João Paulo.
19)Inserir data como valor default:

Pode usar também o current_date ou o localtimestamp.

insert into tabela(data) values ((select current_date));

ou

insert into tabela(data) values ((select localtimestampo));
20) Ler último saldo de tabela

Tenho o seguinte conteudo numa tabela de contas:

Lancto–CCorrente–Banco–OP–DataLan——-Valor———Saldo–
1 12345-6 002 C 19/11/2007 1000.00 1000.00
2 12345-6 002 C 19/11/2007 2000.00 3000.00
3 12345-6 002 D 19/11/2007 100.00 2900.00
4 23450-6 001 C 19/11/2007 2000.00 3000.00
5 23450-6 001 D 19/11/2007 100.00 2900.00

Preciso retornar sempre o último SALDO registrado.
Como nunca vou saber a data exata da periodo de consulta.

Estou executando:

SELECT saldoatual FROM lanban WHERE contacorrente = ‘12345-6′ and datalan <= ‘2007/12/01′ ORDER BY datalan DESC LIMIT 1

Retona o Saldo: 1000.00, preciso pegar o ultimo saldo da conta 12345-6: que é 2900.00.

Isso porque tabelas são conjuntos de dados. O padrão SQL *não* garante a
ordem dos dados. Mesmo se ele garantisse, um simples UPDATE podia mudar
o ordem dos dados e o seu SELECT não retornaria o valor desejado.

> Alguem tem alguma dica?
>
O campo ‘Lancto’ é do tipo serial? Se for poderias utilizar:
SELECT saldoatual FROM lanban WHERE contacorrente = ‘12345-6′ ORDER BY
“Lancto” DESC LIMIT 1.

Dica do Euler Taveira de Oliveira
21) Formato de moeda

O correto seria:
to_char(1030.52,’9G999D99′)
mas o resultado é: 1,030,52
como você pode observar existe um problema no
separador de milhar (indicado pelo G) que é
considerado como , e não como . que seria o esperado.

Uma maneira de contornar (não muito elegante) é:
to_char(1030.52,’9″.”999D99′)

Corrigido na versão 8.3
22) Saber o Tamanho de Tabela e de Índices

pg_relation_size()
pg_total_relation_size()

-Leo

Leonardo Cezar
23) Último Saldo
Fernando Brombatti

A situação é a seguinte. Não se sabe se o serial citado (por N razões) vai ser o último valor existente. Nada me garante que estes dados não sofreram algum UPDATE. Sendo assim, recomendo:
1) alterar o campo DATE para TIMESTAMP
2) alterar o query:
SELECT lan.saldoatual
FROM lanban lan
WHERE lan.contacorrente = ‘12345-6′ AND lan.datalan = (SELECT MAX(maxlan.datalan)
FROM lanban maxlan
WHERE maxlan.contacorrente = lan.contacorrente)
Isso faz com que no primeiro SQL eu traga os lancamentos da conta e no segundo eu trago a máxima data de lançamento para a mesma conta. Como as contas são iguais, trago a máxima data da conta atual, logo tenho o saldo atual.
É confuso, mas é o mais seguro (podem haver UPDATES neste caso também, mas aí não se depende de um serial).
Para este query funcionar bem necessita mais um índice em datalan ao menos.
Nos nossos sistemas da prefeitura nunca usamos saldos desta forma, pois aí se é removido algum registro a informação não fica correta.

Espero não ter confundido tanto.
24) Encontrando tanela de sistema

Para localizar informações desse tipo existe o information_schema
(conforme citado pelo Leandro). Utilizando o catalogo poupa voce de
futuras dores de cabeça quando por exemplo houver alguma alteração
estrutural em tabelas do sistema em versõs futuras. As views do
catalogo deverão permanecer com o máximo de compatibilidade entre
versões (segundo padrão SQL).

Além de ser mais simples:

SELECT *
FROM information_schema.tables
WHERE table_name = ‘foobar’;

Infelizmente não possuimos referencias a outros banco de dados
(banco.schema.tabela), portanto o comando deverá ser executado em
todos seus bancos para localizar a tabela ou um programeta bash
parecido com isso:

$ ARG=$1 || “foo” && for DATABASE in `psql -U postgres -c “\l” \
| cut -d”|” -f1 | egrep ‘^(\ [a-z])’`
do
psql -U postgres -d $DATABASE -Atc \
“SELECT ‘O banco de dados $DATABASE possui a tabela: $RG’
FROM information_schema.tables
WHERE table_name = ‘$ARG’”;
done;

Abraço!

-Leo
25) Como Localizar e Deletar registros duplicados

1.Select para localizar duplicados
select campo,campo1,count(*)
from tabela group by campo,campo1 having count(*) > 1

2.Deletar duplicados:
delete from tab p1
where rowid < (select max(rowid)
from tab1 p2
where p1.primary_key = p2.primary_key);
26) Inserir registros em uma específica posição
> Hi, how are you? maybe you know how SQL insert data
> bellow or above in database tabe? example insert
> data from position table 5 thanks
>

No, I don’t known.
But if you make a copy from table,
create a new table with same structure,
insert a new register,
import register from old table, then first register
are this last register inserted.
27) Timezones do PostgreSQL (lista pgbr-geral)

No POSTGRESQL.CONF tem o timezone onde você pode colocar algo do tipo:

TIMEZONE=BRAZIL/EAST esta é minha configuração, ou seja, de minha região.

Analise.
Wandrey

Outra ———–
Na maioria dos casos é criado um link do diretório de timezones do
S.O. (/usr/share/zoneinfo//usr/share/zoneinfo/) para o diretório de
Timezones do Postgres ($PGDIR/share/timezone )Que possui seu próprio
sistema de controle de timezone, se não me engano a partir d versão 8)


Att:
Thiago Risso
28) Inserir Número Aleatório em Tabela

CREATE TABLE page (
id SERIAL PRIMARY KEY,
about TEXT NULL,
);

ALTER TABLE page ADD myrand NUMERIC NOT NULL DEFAULT RANDOM();

UPDATE page SET myrand = DEFAULT;

SELECT id FROM page WHERE myrand >= RANDOM() ORDER BY myrand LIMIT 1;

This approach has some problems:

* If the number you pick is greater than the largest number in the myrand column, you will not find any matching rows.
* The gaps between the random values in the myrand column are not uniform, and thus the rows selected are not random. Imagine a table with two rows and myrand values of 0.8 and 0.9. If the random number compared to myrand is .8 or less, the first row is chosen. But the second row is only chosen if the value picked is between .8 and .9
* If more than one row has the exact same number, it is likely that one of them will never get picked.

Mais detalhes em: http://people.planetpostgresql.org/greg/index.php?/archives/118-guid.htm…
29) Desabilitar Triggers
Vinicius Santos – MSI escreveu:
Thiago Boufleuhr escreveu:

Como faço para desabilitar as triggers em uma sessão no PLSQL ?

Thiago Boufleuhr

ALTER TABLE [NOME DA TABELA]
DISABLE TRIGGER [NOME DA TRIGGER]
Ou
ALTER TABLE [NOME DA TABELA]
DISABLE TRIGGER ALL

ALERTA:
William Leite Araújo: MUITO CUIDADO AO USAR “DISABLE TRIGGER ALL”

As constraints de chave estrangeira são controladas via TRIGGER. Caso desabilite todos os gatilhos, a checagem da integridade referencial (chaves estrangeiras) serão desabilitadas!
30) Codificação de Caracteres
Euler Taveira de Oliveira
>Evandro Ricardo Silvestre wrote: Codificação de caracteres do cliente e
do servidor podem ser diferentes. Se a codificação do cliente é diferente da codificação do servidor, o servidor PostgreSQL tenta fazer uma conversão antes de armazenar/retornar os dados. Um problema que existia é que a aplicação cliente (no caso abaixo o psql) não avisava se a codificação informada ao servidor (client_encoding) era a mesma do ambiente (terminal).
Bem vindo ao psql 8.3.0, o terminal iterativo do PostgreSQL.
Digite: \copyright para mostrar termos de distribuição
\h para ajuda com comandos SQL
\? para ajuda com comandos do psql
\g ou terminar com ponto-e-vírgula para executar a consulta
\q para sair
template1=# show client_encoding;
client_encoding
—————–
LATIN1
(1 registro)
template1=# show server_encoding;
server_encoding
—————–
LATIN1
(1 registro)
template1=# select upper(’áéíóú’);
upper
——-
ÁÉÍÓÚ
(1 registro)
template1=# set client_encoding to ‘utf-8′;
SET

template1=# show client_encoding;
client_encoding
—————–
utf-8
(1 registro)
template1=# select upper(’áéíóú’);
ERRO: sequência de bytes é inválida para codificação “UTF8″: 0xe1e9ed
DICA: Este erro pode acontecer também se a sequência de bytes nãocorresponde a codificação esperado pelo servidor, que é controlada por “client_encoding”.
ERRO: sequência de bytes é inválida para codificação “UTF8″: 0xe1e9ed
DICA: Este erro pode acontecer também se a sequência de bytes não corresponde a codificação esperado pelo servidor, que é controlada por “client_encoding”.
[trocando a codificação de caracteres do terminal e digitando novamente]
template1=# select upper(’áéí’);
upper
——-
ÁÉÍ
(1 registro)
31) Como visualizar as consultas correntes no Postgres

Colaboração: Frederico Palma

Data de Publicação: 16 de fevereiro de 2008

É necessário habilitar o stats_command_string no postgresql.conf:

stats_command_string = true

Essa configuração pode ser alterada em um banco que está ativo sem a necessidade de reiniciá-lo e sem afetar as conexões abertas para recarregar as configurações. Envie um SIGHUP ou use o comando:

pg_ctl reload

Quando stats_command_string está ativo a tabela pg_stat_activity armazena todas consultas correntes.

Realizando a consulta:

SELECT datname,procpid,current_query FROM pg_stat_activity

Teremos a lista dos bancos de dados utilizados com seus respectivos processos (PID) referente às consultas.

SELECT datname,procpid,current_query FROM pg_stat_activity ORDER BY procpid;

datname | procpid | current_query
————+———+—————–
mydatabase1 | 2587 | < IDLE>
mydatabase2 | 15726 | SELECT * FROM users WHERE id=123 ;
mydatabase3 | 15851 | < IDLE>

Publicado originalmente na Dicas-L – http://www.dicas-l.com.br/dicas-l/20080216.php

32)

by ribafs at 08/10/2009 03:31

07/10/2009

Rodrigo Hjort

PGCon Brasil 2009


Pessoal, faltam só alguns dias para o PGCon Brasil 2009, o maior evento de PostgreSQL da América Latina!


Confira maiores informações no site do evento:

[1] http://pgcon.postgresql.org.br/2009/

by Rodrigo HJORT (noreply@blogger.com) at 07/10/2009 11:26

26/09/2009

Fernando Ike

PGCon Brasil 2009 tá logo aí!!!

    É isso, agora em outubro vai ter a terceira edição da PGCon Brasil. Além de alguns palestrantes brasileiros já consagrados, finalmente terá o líder do time de desenvolvimento PostgreSQL: Bruce Momjian. (torcendo par nenhum imprevisto).

   Com mais palestrantes, na Unicamp, esperamos ter muitas pessoas por lá. :)

  
PGCon Brasil 2008

by Fernando Ike at 26/09/2009 11:43

João Paulo (Jota)

PGCon 2009 – Inscrições abertas


Estão abertas as inscrições para o PGCon 2009.

Não perca tempo e faça já sua inscrição e aproveite o maior de todos os eventos sobre PostgreSQL. Clique aqui e confira:

by jotacomm at 26/09/2009 02:43

24/09/2009

Claudio Bezerra Leopoldino

Monitoração de Comandos com PG_STAT_STATEMENTS

Na versão 8.4, foram acrescentados novos recursos de monitoramento de banco que podem ser bastante úteis para se identificar que consultas têm consumido mais tempo, retornam mais dados e quais são executadas com maior freqüência. A pg_stat_statements é uma biblioteca que monitora e coleta estas informações para o usuário.

Para monitorar o que acontece no sgbd, é necessário manter em memória uma rotina que realize essa atividade. Para colocar esta rotina em execução, deve ser alterado o arquivo de configuração, mais precisamente a variável “shared_preload_libraries”, e reiniciado o servidor. Acrescente no arquivo de configuração postgresql.conf a linha abaixo e reinicie o serviço do banco:

shared_preload_libraries = '$libdir/pg_stat_statements'

Para visualizar se a biblioteca realmente foi colocada na memória pode ser usado o comando show:

Show shared_preload_libraries

Execute algumas consultas para que o sgbd armazene valores monitorados. Serão guardados os códigos dos comandos, o número de vezes em que os mesmos foram executados e os tempos de execução.

O próximo passo é executar o script do arquivo “contrib/pg_stat_statements/pg_stat_statements.sql” que se encontra na pasta de contribs para criar uma visão que mostrará os dados monitorados chamada pg_stat_statements. Abaixo, coloco a consulta padrão aos dados de monitoramento e alguns exemplos adicionais de consultas por número de chamadas ao comando, pelo tempo total e pelo número de linhas retornado.

1 - Consulta padrão

select * from pg_stat_statements;

2 - Consultas ordenadas pelo número de chamadas

select * from pg_stat_statements order by calls desc;

3 - Consultas ordenadas pelo tempo total utilizado

select * from pg_stat_statements order by total_time desc;

4 - Consultas ordenadas pelo número de linhas retornado

select * from pg_stat_statements order by rows desc;

Caso a quantidade de dados retornados seja muito grande, utilize a função pg_stat_statements_reset para limpar os dados coletados:

1 – Limpando dados coletados

select pg_stat_statements_reset();

by cbleopoldino (claudio.leopoldino@gmail.com) at 24/09/2009 02:22

15/09/2009

Fabio Telles

Inscrições para o PGCon Brasil 2009 abrem em 16/09

As inscrições para o PGCon Brasil 2009 estarão abertas a partir de 16/09.

Garanta já sua inscrição!!!

Aproveite e baixe também o cartaz do evento aqui.

by Telles at 15/09/2009 10:51

08/09/2009

Rodrigo Hjort

Cedrus PostgreSQL Management versão 2.0




Pessoal, estou organizando esforços para o desenvolvimento da segunda geração do Cedrus [1], um gerenciador para o SGBD PostgreSQL criado em 2006 na CELEPAR e apresentado ao público no CONISLI [4] naquele mesmo ano em São Paulo.


Dessa vez será adotada a plataforma Launchpad para o gerenciamento do projeto. Se você tiver interesse em participar de qualquer das seguintes etapas (requisitos, projeto, desenvolvimento ou testes) ou se desejar somente dar sugestões, mesmo se você só tiver experiência com administração de outros SGBDs, sinta-se livre em conhecer o projeto [2] ou em fazer parte da equipe [3]!


Referências:


[1] Cedrus 1.0 no SourceForge
[2] Cedrus 2.0 no Launchpad
[3] Equipe do Cedrus no Launchpad
[4] CONISLI - Congresso Internacional de Software Livre

by Rodrigo HJORT (noreply@blogger.com) at 08/09/2009 07:47

04/09/2009

PostgreSQL Brasil

Replicação de dados com java

Alessandro Silva nos enviou um link interessante que pode ser útil para quem quer ter exemplos de replicação de dados.

O link aponta para um vídeo demonstrando como realizar uma replicação bem simples de dados entre duas bases:

http://www.youtube.com/watch?v=Z7_WCDLVh_o

Outros links sobre replicação:

leia mais

by guedes at 04/09/2009 12:06

24/08/2009

Claudio Bezerra Leopoldino

Participe de Concurso "O Elefante está entre nós" e Concorra a 50 Prêmios!!!

A imaginação é mais importante que o conhecimento. E uma iniciativa brasileira promete estimular e recompensar a criativivade da comunidade PostgreSQL, distribuindo 50 prêmios. Apenas a participação de todos pode fazer desta boa idéia um grande sucesso! Se inscreva na PGCON e mostre seu conhecimento!

O concurso apresenta várias categorias:
  • Consulta ou script;
  • Artigo;
  • Artigo traduzido;
  • História em quadrinhos; (!!!)
  • Estudo de caso;

O pai da idéia é o Telles, do blog Savepoint: http://www.midstorm.org/~telles/2009/08/22/concurso-o-elefante-esta-entre-nos/

As regras de cada categoria estão disponíveis aqui!

Se esta iniciativa for bem sucedida, certamente será reproduzida mundo afora. Depende da participação de todos! Este blogueiro parabeniza a iniciativa e tentará participar de pelo menos duas categorias, dentro do espírito olímpico: o "importante é competir". Link

by cbleopoldino (claudio.leopoldino@gmail.com) at 24/08/2009 09:24

22/08/2009

Fabio Telles

Concurso “O elefante está entre nós”

Não, não é uma piada sem graça para me incentivar a perder peso. A história começou mais ou menos assim: Eu estava conversando por e-mail com o Sr. Bruce Momjian (um daqueles desenvolvedores do PostgreSQL que por algum motivo todo mundo já ouviu falar na comunidade…) sobre a possibilidade dele trazer alguns brindes dos EUA para o PGCon Brasil 2009.  Ele me disse que era melhor ver com o Sr. Josh Berkus, e eis que encontrei ele no mesmo dia no IRC, lá no #postgresql.

Eu estava interessado em conseguir uns 100 pendrives personalizados com o nome do PostgreSQL. Ano passado o David Fetter trouxe uns e eles evaporaram instantaneamente quando o pessoal ficou sabendo. Sim, eu tenho um.  Bom, o Josh disse que cada pendrive custava USD 8,00. Seria um pouco mais barato do que o preço aqui no Brasil, mas o Josh já me adiantou que só tem uns 50. Aí ele me disse algo interessante: “Me arranje algo melhor que simplesmente distribuir os pendrives para todo mundo que eu posso lhe conseguir eles de graça para você. E outra pessoa no canal deu a ideia: “Me mostre a sua melhor consulta SQL e ganhe um pendrive”.

O Josh parece que gostou da idéia e eu mais ainda. Aí comecei a rascunhar e pensar em como organizar isso. Pensei logo em algumas categorias para participar:

  • Consulta ou script;
  • Artigo;
  • Artigo traduzido;
  • História em quadrinhos;
  • Estudo de caso;

A ideia é mais ou menos assim: sabe aquela consulta que você criou para verificar o desempenho do banco? Aquele script de backup que ficou bacana? Ou aqueles testes que você ficou de publicar em algum lugar o resultado? Ah… tem também aquele artigo em inglês que um monte de gente adoraria ler em português. Bom, acho que deu para pegar o espírito da idéia. Você manda para nós o seu material, tem grandes chances de ganhar o seu pendrive e a comunidade ganha material novo para colocar na Internet. Todo mundo acaba ganhando.

Vá na página do concurso “O elefante está entre nós” no site do PGCon Brasil 2009 e participe!

by Telles at 22/08/2009 10:54

16/08/2009

João Paulo (Jota)

Usando o DBLink para interligar dois bancos PostgreSQL


Pessoal,

Hoje vou apresentar como é possível trocar informações entre bancos de dados PostgreSQL. Apresentarei como isso é possível através do uso do DBLink.

O primeiro passo é instalar o DBLink no banco. Aqui vou considerar que a instalação do PostgreSQL foi realizada de forma compilada e para isso será necessário fazer uso dos arquivos da instalação. Dentro do diretório existe um diretório denominado contrib e dentro deste diretório existe um subdiretório chamado dblink. Para instalar o dblink é necessário realizar a compilação e posteriormente adiciona-lo ao banco desejado.

Para compilar é necessário executar o seguinte comando:

make

make install

Após a execução dos comandos acima será gerado um arquivo chamado dblink.sql. Este arquivo deve ser carregado (importado) no banco desejado. Para demonstrar o seu uso trabalharei com os bancos: banco01 e banco02.

O banco banco01 possui um tabela chamada tabela01 e o banco02 possui uma tabela chamada tabela02. Cada tabela possui um atributo código do tipo inteiro e ambas as tabelas contém 10 registros.

Carregando o arquivo dblink.sql no banco01.

psql banco01 -f dblink.sql

Com o dblink carregado no banco01, o próximo passo é realizar a conexão entre o banco01 e o banco02.

No exemplo, será considerado que estando conectado no banco01 será requisitada uma conexão com o banco02 para ai sim possibilitar a troca de informações entre os dois bancos de dados.

Então vamos a prática:

banco01=# SELECT dblink_connect(’conexao’,'host=localhost port=9999 user=postgres dbname=banco02′);
dblink_connect
—————-
OK
(1 row)

Alguns parâmetros são informados. O primeiro é um nome para a conexão, e o restante parâmetros normais de uma conexão: hostname, porta, usuário, senha (opcional) e o nome do banco. Como para este exemplo a autenticação esta usando o método trust, o parâmetro password foi omitido.

Com a conexão OK agora é só realizar uma operação qualquer.

Por exemplo, um join entre a tabela01 que pertence ao banco01 e a tabela02 que pertence ao banco02.

banco01=# SELECT tab01.codigo,tab02.codigo FROM tabela01 tab01 INNER JOIN (SELECT * FROM dblink(’conexao’,'SELECT codigo FROM tabela02′) AS resultado(codigo integer)) tab02 ON tab01.codigo=tab02.codigo;

Um outro exemplo pode ser feito com uma operação de escrita (INSERT, UPDATE OU DELETE).

A partir do banco01 fazendo uma chamada de inserção na tabela02 que está no banco02.

banco01=# SELECT dblink_exec(’conexao’,'INSERT INTO tabela02 VALUES (generate_series(11,20))’);
dblink_exec
————-
INSERT 0 10
(1 row)

Conferindo:

banco01=# SELECT * FROM dblink(’conexao’,'SELECT codigo FROM tabela02′) AS resultado(codigo integer);
codigo
——–
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
(20 rows)

Para operações de UPDATE e DELETE o procedimento transcorre da mesma maneira do que do comando INSERT.

Por fim, para encerrar a conexão é necessário executar a seguinte função:

banco01=# SELECT dblink_disconnect(’conexao’);
dblink_disconnect
——————-
OK
(1 row)

Espero que a dica seja útil. Até uma próxima oportunidade :)

Abraços

by jotacomm at 16/08/2009 06:56

15/08/2009

João Paulo (Jota)

PostgreSQL 8.4 – Agora com GRANT/REVOKE por coluna


Olá, pessoal

Após um período de inatividade estou voltando com força total e neste retorno aproveito para falar de uma das funcionalidades que entraram no core do PostgreSQL na versão 8.4.

Alguns bancos de dados como o Oracle já possuiam esta característica e o PostgreSQL ainda não, porém a partir da versão 8.4 é possível conceder e retirar privilégios a colunas específicas de uma tabela.

Segue um exemplo bem simples:

Criação de um banco de dados para o exemplo.

postgres=# CREATE DATABASE exemplo_grant_revoke;

Após criado o banco é realizada uma conexão a ele.

postgres=# \c exemplo_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke”.

Criação de uma tabela para exemplificar a funcionalidade.

exemplo_grant_revoke=# CREATE TABLE tabela01(codigo int PRIMARY KEY,nome varchar(30));
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index “tabela01_pkey” for table “tabela01″
CREATE TABLE

Inserção de dois registros na tabela.

exemplo_grant_revoke=# INSERT INTO tabela01 VALUES (1,’Jota.Comm’),(2,’PostgreSQL’);
INSERT 0 2
exemplo_grant_revoke=# SELECT * FROM tabela01;
codigo |    nome
——–+————
1 | Jota.Comm
2 | PostgreSQL
(2 rows)

Criação de um usuário para conceder e revocar privilégios.

exemplo_grant_revoke=# CREATE ROLE usuario_grant_revoke LOGIN;
CREATE ROLE

Conexão ao banco de dados com o usuário criado.

exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.

Realização uma operação de SELECT na tabela criada.

Neste caso ocorrerá um erro pois o usuário usuario_grant_revoke não tem permissão de acesso ao objeto.

exemplo_grant_revoke=> SELECT * FROM tabela01;
ERROR:  permission denied for relation tabela01

Verificando as permissões de acesso. Observa-se que o usuário usuario_grant_revoke não possui nenhuma permissão no objeto tabela01.

exemplo_grant_revoke=> \z tabela01
Access privileges
Schema |   Name   | Type  | Access privileges | Column access privileges
——–+———-+——-+——————-+————————–
public | tabela01 | table |                   |
(1 row)

Conexão com o superuser (postgres).

exemplo_grant_revoke=> \c exemplo_grant_revoke postgres
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “postgres”.

Concessão do privilégio de SELECT em todas as colunas da tabela.

exemplo_grant_revoke=# GRANT SELECT ON tabela01 TO usuario_grant_revoke;
GRANT

Concessão do privilégio de UPDATE na coluna nome da tabela tabela01.

exemplo_grant_revoke=# GRANT UPDATE(nome) ON tabela01 TO usuario_grant_revoke;
GRANT

Conexão ao banco com o usuário usuario_grant_revoke.

exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.

Tentativa da operação de UPDATE sobre a coluna código da tabela tabela01. Um erro será exibido visto que o usuário não tem permissão de UPDATE na coluna código. O privilégio foi concedido apenas para a coluna nome.

exemplo_grant_revoke=> UPDATE tabela01 SET codigo=10 WHERE codigo=1;
ERROR:  permission denied for relation tabela01

Operação de UPDATE na coluna nome da tabela tabela01.

exemplo_grant_revoke=> UPDATE tabela01 SET nome=’Jota’ WHERE codigo=1;
UPDATE 1

Operação de SELECT em toda a tabela tabela01.

exemplo_grant_revoke=> SELECT * FROM tabela01;
codigo |    nome
——–+————
2 | PostgreSQL
1 | Jota
(2 rows)

Vefiricando as permissões do usuário usuario_grant_revoke na tabela tabela01.

exemplo_grant_revoke=> \x
Expanded display is on.
exemplo_grant_revoke=> \z tabela01
Access privileges
-[ RECORD 1 ]————+———————————-
Schema                   | public
Name                     | tabela01
Type                     | table
Access privileges        | postgres=arwdDxt/postgres
: usuario_grant_revoke=r/postgres
Column access privileges | nome:
:   usuario_grant_revoke=w/postgres

O usuário usuario_grant_revoke possui privilégio de SELECT na tabela (usuario_grant_revoke=r/postgres) e possui privilégio de UPDATE na coluna nome (usuario_grant_revoke=w/postgres).

Conexão ao banco.

exemplo_grant_revoke=> \c exemplo_grant_revoke postgres
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “postgres”.

Remoção dos privilégios concedidos.

exemplo_grant_revoke=# REVOKE SELECT ON tabela01 FROM usuario_grant_revoke;
REVOKE
exemplo_grant_revoke=# REVOKE UPDATE(nome) ON tabela01 FROM usuario_grant_revoke;
REVOKE

Conexão ao banco com o usuário usuario_grant_revoke.

exemplo_grant_revoke=# \c exemplo_grant_revoke usuario_grant_revoke
psql (8.4.0)
You are now connected to database “exemplo_grant_revoke” as user “usuario_grant_revoke”.

A partir de agora o usuario usuario_grant_revoke não possui mais nenhum privilégio na tabela tabela01.

exemplo_grant_revoke=> SELECT * FROM tabela01;
ERROR:  permission denied for relation tabela01

exemplo_grant_revoke=> UPDATE tabela01 SET nome=’Jota.Comm’ WHERE codigo=1;
ERROR:  permission denied for relation tabela01

Verificando os privilégios.

exemplo_grant_revoke=> \z tabela01
Access privileges
Schema |   Name   | Type  |     Access privileges     | Column access privileges
——–+———-+——-+—————————+————————–
public | tabela01 | table | postgres=arwdDxt/postgres |
(1 row)

Espero que tenha sido claro e didático no exemplo. Até a próxima.

Abraços

by jotacomm at 15/08/2009 07:02

13/08/2009

Claudio Bezerra Leopoldino

PostgreSQL 8.4: Falta um bom instalador para Windows!

Dentre as mais de 290 mudanças da versão 8.3.x para a 8.4.0, uma importante lacuna que surgiu foi a do instalador para windows. O projeto pgInstaller, mantido por Dave Page e Magnus Hagander gerou instaladores intuitivos e poderosos, com recursos de configuração mais avançados que facilitavam a adição de contribs e a atualização de versão do SGBD em ambiente Windows. No entanto, o projeto só continuará a ser mantido nas versões 8.2.x e 8.3.x.

Para Linux, além do one-click installer e de live cds, customizações de instaladores para Fedora, SUZE, Ubuntu e Debian estão disponíveis para o PostgreSQL 8.4.

Mais informações aqui!

Espera-se que sujam mais opções de instaladores além do limitado "One-Click Installer" da página oficial do PostgreSQL. Quem se habilita a fazer um?

Creio que o impacto para a difusão do PostgreSQL 8.4 pode ser significativo na plataforma Windows. Não podemos subestimar o impacto da facilidade de instalação para a adoção e atualização de qualquer ferramenta. O que vocês acham?

Complemento 13/08/2009:

- Depois de instalar em algumas máquinas, posso afirmar que o one-click installer é bastante funcional e estável. No entanto, continuo a me sentir incomodado por ter menos uma opção de instalação. E o desafio continua a quem se dispor a fazer um instalador alternativo!!!

by cbleopoldino (claudio.leopoldino@gmail.com) at 13/08/2009 09:46

11/08/2009

João Paulo (Jota)

PGCon 2009 – Grade oficial do evento


Maior evento sobre PostgreSQL da América Latina acontece em Campinas.

A Unicamp já se prepara para receber a “3ª Conferência Brasileira de PostgreSQL” ou simplesmente PGCon Brasil 2009.

Nos dias 23 e 24 de outubro, centenas de estudantes e profissionais de TI participarão do maior evento latino-americano sobre o mais poderoso sistema gerenciador de banco de dados de código livre do mundo, o PostgreSQL.

A programação completa da Conferência já foi confirmada. O evento contará com palestras, tutoriais e os já consagrados Hacker Talks e Lightning Talks. Estarão presentes desenvolvedores nacionais do PostgreSQL como Euler Taveira e Francisco Figueiredo Jr, internacionais como Bruce Momjian, Magnus Hagander além de profissionais reconhecidos no Brasil como Fernando Ike, Roberto Mello, Leandro Dutra entre outros.

Na programação, estarão temas como as últimas novidades da versão 8.4 do PostgreSQL, técnicas de monitoramento, segurança, ajustes de desempenho e muito mais.

Mais informações sobre o evento, podem ser obtidas no site oficial em: http://pgcon.postgresql.org.br/2009/index.php

Abraços

by jotacomm at 11/08/2009 09:31

10/08/2009

Fabio Telles

Saiu a grade do PGCon Brasil 2009!!!

Sim, sim, é verdade! A grade oficial está no ar!!!

Vá lá dar uma olhada e me diga o que você acha…

Vou contar um pouco dos bastidores do evento:

  • Foram ao todo 40 propostas na chamada de trabalhos;
  • 2 Palestrantes internacionais convidados;
  • 65 pessoas votaram nas propostas e disseram quais eram as suas prediletas;
  • 3 pessoas na banca avaliadora fizeram a seleção final das palestras;
  • 4 tutoriais aprovados;
  • 3 palestras avançadas;
  • 4 Hacker Talks (palestras para quem deseja conhecer e  contribuir com o código do PostgreSQL);
  • 11 palestras normais;
  • 12 Lithning Talks  (palestras curtas de até 5 minutos cada);
  • 3 salas simultâneas.

Bom, outras novidades estão por vir, inscrições, concurso, patrocínios, divulgação, tudo a caminho. Até o final do mês o evento deverá estar com quase todos os detalhes fechados.  Em breve traremos mais detalhes… em breve!

by Telles at 10/08/2009 07:13

05/08/2009

Fabio Telles

Pesquisa sobre lembranças para o PGCon Brasil 2009

Andei fazendo algumas pesquisas de lembranças que poderíamos mandar fazer para o PGCon Brasil 2009. Infelizmente isto custa dinheiro e todos os fornecedores só fecham negócio com uma quantidade mínima de cerca de 100 peças.

Diante deste tipo de dificuldade, resolvi fazer esta pesquisa para ver se há algum produto que interessaria mais a comunidade e se teríamos pedidos suficientes para cobrir as despesas com isto.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

by Telles at 05/08/2009 06:58

29/07/2009

Claudio Bezerra Leopoldino

Psql 8.4: Novas Funcionalidades!

O psql em sua nova versão apresenta uma série de pequenas novidades, inclusive a promessa de compatibilidade com versões anteriores do Postgres, permitindo que de um console se acesse bancos de servidores mais antigos. A lista de alterações completa pode ser vista aqui. Abaixo, comento algumas das mudanças que reputo como mais significativas:

Listando o Tamanho de Objetos

Pequenas funcionalidades podem ser ainda mais interessantes para o usuário do utilitário que os avanços mais complexos. A facilidade de se obter informações detalhadas, particularmente sobre espaço ocupado por objetos em disco certamente é uma delas.

O uso da sintaxe \dt lista as tabelas criadas no banco. Na versão 8.4, pode ser utilizada a sintaxe \dt+, que retorna o espaço em disco ocupado pela tabela.

Este recurso também pode ser utilizado para índices. Digite \di para informações dos índices, e \di+ para um maior detalhamento com espaço em disco ocupado e descrição.

Para bancos de dados, a sintaxe é a mesma. Digite \l para informações dos bancos de dados, e \l+ para um maior detalhamento com espaço em disco ocupado e descrição.

Abrindo Editor para Funções

Editar funções dentro do psql não é uma tarefa muito agradável. Paras códigos mais extensos chega a ser penosa. Para minorar o problema, a opção \ef abre um editor externo para edição do código.

A sintaxe é: \ef

No windows, abre o notepad. Edite o texto, salve e feche o editor. No psql, digite ';' e tecle ENTER. O sistema vai registrar as alterações na função.

by cbleopoldino (claudio.leopoldino@gmail.com) at 29/07/2009 09:05

26/07/2009

PostgreSQL Brasil

Dica: ZEOS Lib - Componente para acesso nativo ao PostgreSQL.

Bruno da Silva Reis nos enviou uma dica de uso da ZEOS Lib, que é um componente muito utilizado por desenvolvedores Delphi para acesso nativo ao PostgreSQL, sem que seja necessário o uso de drivers externos como ODBC, JDBC, BDE e outros artifícios.

Você pode fazer o download do componente aqui ou participar dos fóruns aqui

 

 

by guedes at 26/07/2009 06:26

07/07/2009

PostgreSQL Brasil

Resultados da pesquisa sobre o uso do PostgreSQL no Brasil.

Foi encerrada a "1ª pesquisa sobre o uso do PostgreSQL no Brasil".  Foram ao todo 164 pesquisas respondidas entre os dias 17/06/2009 e 01/07/2009. A pesquisa não possui um recorte estatístico no sentido de representar o universos de empresas brasileiras que utilizam bancos de dados, mas sim uma pesquisa de resposta espontânea sobre usuários de PostgreSQL que acompanham um pouco o universo da comunidade brasileira.

leia mais

by telles at 07/07/2009 04:00

06/07/2009

Fabio Telles

A lenda da Replicação Multimaster Síncrona em bases distribuídas

A história é conhecida e vira e mexe aparece alguém perguntando sobre isso. Bom, você tem uma mesma aplicação rodando em lugares geograficamente distintos. Podem ser países diferentes, podem ser estados, cidades ou até mesmo bairros diferentes, o problema é praticamente o mesmo. Imagine uma cadeia de empresas, todas elas rodando o mesmo aplicativo.

Você pode chegar nesta situação quando era apenas uma matriz que abriu uma filial. O banco de dados ficava só na matriz e a filial acessa o banco de dados remotamente, via Internet, conexão via rádio, linha privativa, etc. O problema é que a conexão com a filial tinha a mania de cair e quando isso acontece é como se acabasse a luz. Se pensarmos numa empresa que utiliza apenas a conexão da Telefônica aqui em SP, dá para imaginar o desespero.

Então a solução ideal se chama replicação multimaster síncrona: você tem alguns bancos de dados, cada um em um local diferente. Cada atualização realizada numa das bases é automaticamente replicada para as demais e vice-versa. Qualquer base pode sofrer atualizações. Uma vez realizada, ela é visível instantaneamente em todas as bases. Se você der um rollback em uma transação, o rollback será realizado de forma idêntica em todos os nós. Ou seja, tem de garantir o ACID em todos os nós, como se estivesse em apenas um banco de dados. Existe um recurso no PostgreSQL que visa garantir este comportamento, ele se chama commit em duas fases e está disponível a partir da versão 8.1 do PostgreSQL. O commit em duas fases é muito importante por realmente garantir a consistência através de todos os nós. Ele não resolve problemas como o uso intensivo de SEQUÊNCIAS ou o a equivalência de um TIMESTAMP com precisão absoluta, mas resolve o problema de ter um commit ou rollback sincronizado em todos os nós. Deve-se entender que o Commit em duas fases é implemento como comandos SQL e não como uma aplicação. Portanto a sua aplicação tem de ser desenhada específicamente para utiliza-lo.

Há uma solução no universo PostgreSQL conhecida como PGCluster, que não utiliza o commit em duas fases mas faz a replicação multimaster assíncrona através de um serviço de balanceamento de carga e outro serviço de replicação. E vai além disso, se a comunicação com um dos nós cair, ele sincroniza o nó quando ele volta a se comunicar com os demais. Não é ótimo?

Sim, o PGCluster é uma ideia muito interessante, mas não como uma solução de banco de dados distribuído. Cada alteração no banco de dados dispara uma atualização em cada nós que precisa ser confirmada em um por um e depois da confirmação, liberada em todos eles. Isto significa que o que seria feito em X tempo em um único nó, será feito em  2XNL tempo onde N é o número de nós envolvidos na replicação e L é a latência da rede. Isto significa que se os nós não estiverem dispostos lado a lado numa rede local de alta velocidade, a perda de desempenho é absolutamente intolerável.

Mesmo que você utilize fibras ópticas de última geração para interligar seus servidores localizados em lugares distintos, você sofrerá com uma limitação: a velocidade da luz. Até que se prove ao contrário, nada viaja a uma velocidade superior a da luz, inclusive a informação. E nas idas e vindas do commit em duas fazes, a velocidade da luz começa a ser relevante. Ou seja, o PGCluster só é funcional como solução de alta disponibilidade, para servidores que ficam todos no mesmo CPD. Ainda assim há uma perda de performance considerável em cada atualização do banco de dados (nas leituras a distribuídas da carga propcia uma melhora de desempenho). Para encerrar o assunto, vale lembrar que o PGCluster é uma solução complexa de instalar (são no mínimo 3 nós + o balanceador de carga + o replicador), sua última versão foi lançada em 02/2008 e não é uma solução realmente bem aceita pelos desenvolvedores do PostgreSQL.

Sim o commit em duas fases pode ser utilizado com sucesso para bancos de dados distribuídos, mas para sincronizar apenas algumas operações e não a base inteira. Se você pesquisar bastante sobre o assunto, irá esbarrar em outras soluções:

  • Houve algum tempo, se pensou numa forma nova para implementar uma replicação multimaster síncrona num projeto batizado como Slony II que rapidamente foi abandonado por ser considerado complexo demais e inviável na prática.
  • O PGCluster II  é uma tentativa de implementar algo semelhante ao Oracle RAC, que também é uma solução de alta disponibilidade e exige que todos os nós fiquem no mesmo local (eles tem de compartilhar o mesmo storage). Pelo que consta o PGCluter II ainda não teve nenhuma versão oficial lançada e não sei se ainda tem algum desenvolvimento ativo.
  • O Bucardo é uma solução já em produção, mas não é síncrona, ou seja, ela admite um atraso entre as atualizações em cada nó o que exige regras de resolução de conflito quando um mesmo registro é atualizados em diferentes nós. Ou seja, não garante nem tem como garantir o ACID. O Bucardo é indicado para sincronizar uma base principal com outras bases  com pouco volume de atualização, como no caso de forças de vendas que tem uma base isolada no notebook de cada vendedor.

Bom, mas então como resolvemos o problema das filiais??? Duas abordagens distintas:

  • Resolva o seu problema com o link e mantenha todos os seus dados numa única base. Pode parecer besteira, mas ainda é a solução mais utilizada por grandes empresas que podem investir na redundância de links de alta velocidade e alta disponibilidade;
  • Não integrar todos os dados em uma única base. Faça com que  cada filial tenha apenas uma fatia dos dados e ponto final. Uma variação mais eficiente é fazer com que uma chamada por informações que se encontram em outro servidor sejam desviadas  para o servidor correto. Isto se chama particionamento horizontal ou cluster shared nothing e é uma técnica bastante complexa, mas muito eficiente. Uma forma de implementar isto no PostgreSQL é utlizando o PL/Proxy do Skytools.

As duas abordagens podem parecer um tanto radicais para você? Bom, eu diria que 90% dos grandes bancos utilizam exatamente estas abordagens:  possuem cerca de 3 ou 4 sites (digamos que em SP, DF e PE) cada uma respondendo por todas as transações da sua região. Há um investimento pesado para conectar todos os terminais no site da sua região. Se você precisar de informações de um site em outra região, a conexão é desviada para o site correto.

Estas são as duas formas óbvias de encarar o problema: centralizar tudo numa única base, ou dividir logo todos os dados em bases isoladas. Isto é tudo o que você pode fazer sem ter que mexer na lógica da aplicação. No entanto, se você está disposto a mexer na sua aplicação, particularmente na modelagem desta, então existe sim um meio termo. A primeira coisa a se fazer é dividir as tabelas em partes conforme as regras de negócio para a sua atualização:

  1. Tabelas que não são atualizadas ou que são atualizadas raramente: inclua aqui tabelas de parâmetros e coisas do tipo. Se você puder realizar as atualizações em apenas um local então você pode fazer com elas caiam no segundo caso:
  2. Tabelas que são atualizadas apenas em um nó como a matriz e são consultadas por todas as outras filiais;
  3. Tabelas onde cada filial é responsável pela atualização de apenas um punhado de registros, sendo que cada filial não pode alterar os registros da outra filial;
  4. Tabelas onde cada filial deve poder atualizar qualquer registro da tabela, independente de qual filial seja.
  • Tudo que estiver nos casos 1 e 2 podem sofrer uma replicação multi/master, que é um pouco menos complexa e possui algumas boas ferramentas para implementar como o Slony I e o Londiste. A ideia é simples, você atualiza as informações em uma única base e as informações são replicadas para os demais nós.
  • Tudo que estiver no 3º caso deve ser modificado para cair no 2º caso através do particionamento de tabelas. Assim você divide uma única tabela em uma tabela pai e várias outras tabelas filhas, uma para cada filial. As atualizações só serão feitos na tabela relativa a filial onde ele está e as suas atualizações são replicadas para as demais filiais. O particionamento de tabelas no PostgreSQL é um pouco chato de ser feito (melhorou um pouco no 8.4 mas no 8.5 está prometida uma revolução), mas é bastante flexível, portanto, depois de particionar as tabelas, você cai numa situação onde a replicação master/slave pode ser aplicada novamente;
  • Se você tiver o azar de cair no 4º caso , então você não terá outra alternativa senão utilizar o commit em duas fazes. Em geral, com uma boa modelagem você consegue fugir deste tipo de situação ao máximo, mas quando não for realmente possível, a ferramenta é esta. Note que nos casos 2 e 3, não estou falando de replicação síncrona. Se você realmente precisar de transações síncronas, com ACID entre todos os nós, o commit em duas fases é a sua única opção.

Como você pode perceber, não existe solução fácil. Mas, feliz são os desenvolvedores que criam suas aplicações já pensando neste tipo de solução. É claro que hoje se utiliza muito SOA, REST e outras tecnologias para trafegar informações entre aplicações. Outros se aventuram com o envio de TXT, ou XML para lá e para cá das mais diversas formas. Há ainda aqueles que criam uma teia de DBLinks para interligar as bases. Eu como DBA não sou especialista neste tipo de solução, mas acredito que elas sirvam para resolver outro tipo de problema. Um exemplo clássico seria a disponibilização de informações ou serviços de uma aplicação para outra aplicação diferente e não para a replicação de informações dentro de uma mesma aplicação. Trocar informações entre aplicações é muito diferente de replicar informações em bases distribuidas. A chave do problema sempre estará nas diferenças entre síncrono e assíncrono, e master/slave e multimaster.

Bom, eu acho que é só por enquanto. Se alguém conhecer outro tipo de solução que não seja baseada em nenhum dos casos aqui ou se tiver uma experiência que refute os argumentos que apresentei aqui, por favor deixe um comentário abaixo para trocarmos umas figurinhas, ok?

by Telles at 06/07/2009 08:15

03/07/2009

Fernando Ike

Eu fui: FISL10

 

 

  O FISL é como uma festa religiosa, todo ano as pessoas fazem romaria para participar da festa. Para muitos de nós nerds/geeks o FISL é nossa festa santa, nossa Festa da Padroeira. :)

  O FISL 10 que acabou de acontecer foi especial pois é a comemoração de 10 anos de evento. Muita gente que deixou de vir, voltou a participar do FISL. Com um pouco mais de 8 mil pessoas, o evento contou com a ilustríssima presença do Presidente da República.  Não lembro se um presidente de um país fosse para um evento de Software Livre. :D

  Esse ano ajudei um pouco mais do que costumei, ajudei na avaliação das palestras  e apresentei uma palestra sobre o PostgreSQL 8.4, também ajudei  na coordenação do evento comunitário do PostgreSQL. É sempre bom reencontrar os amigos, conhecer pessoas e etc. Resumindo…

 

  Palestras

  As palestras estavam muito diversificadas, com palestras de excelente nível técnico à palestras mais filosóficas mas ainda sim muito interessante. Esse ano as palestras patrocinadas estavam marcadas com "P", facilitando que o participante do FISL identificadas como palestra de Patrocinadores, umas das grandes reclamações do ano passado foi atendida pela organização.

  Num universo de mais de 300 palestras, sempre tem as ruins, de pouca qualidade ou inexperiência do palestrante em apresentar. Esse ano foi diferente e isso faz parte do evento. Ter 100% de palestras excelentes é um desafio quase que impossível pela os diferentes interesses objetivos e interesse dos participantes. As poucas que vi, gostei.

  O Peter Sunde do Pirate Bay foi imperdível.  Richard Stallman, John Maddog Hall e Sérgio Amadeu fizeram suas apresentações tradicionalmente cheias e empolgantes.

  Para variar, eu sempre termino na última hora minha palestra, espero que as pessoas não tenham odiado demais.

 

  Infra-estrutura

   O problema com internet ainda continua sendo um problema para quem usou as diversas redes sem fio. Tinha tanta rede sem fio (criadas pelos participantes) lá que todos os canais de frequência estavam lotados, com muita interferência. Quem usou conexão 3G conseguiu usar internet melhor.

   Quem sabe no FISL 11 teremos uma rede MESH que resolverá esse tipo de problema? Voluntários?

   Esse ano foi mais organizado que o ano passado, as filas dos crachás foram pequenas comparado com os anos anteriores. Tinha boa sinalização das salas.Os estandes em maior quantidade e melhores, uma sala de imprensa e blogueiros. A impressão geral que esse ano estava mais organizado.

 

   Geral

    A relação do evento com instituições públicas e palestrantes internacionais ainda ficou um pouco a desejar. =/
    O evento acabar às 18 horas todos os dias (exceto sábado) não foi legal.
    Esse ano eu perdi a Festa de Lançamento do Lenny no estande do Debian, pensamos em aproveitar e comemorar junto o lançamento do PostgreSQl 8.4 mas não nos organizamos o suficiente (PostgreSQL Brasil), quem sabe o ano que vem. :)
    O César Cardoso quebrou sua missão de não assistir palestras e esse ano assistiu.
    Seria bom ano que vem ter uma mini-pgcon brasil dentro do FISL. :)
    Senti a falta do estande do Google e a presença da IBM e a Oracle estve com um estande
    Ah, ia deixar passar batido. Não participei mas pelo que vi o Festival de Cultura Livre foi bem bacana.
    Por fim, fazer o encerramento na área de estandes e comunidades foi bem legal. :D

by Fernando Ike at 03/07/2009 05:31

02/07/2009

Fernando Ike

PostgreSQL 8.4 lançado

    Continuando a nota anterior, esta semana é uma semana de lançamento de versões de alguns projetos importantes, a nota anterior comentava sobre o Firefox 3.5 que foi lançado essa semana. Foi lançado também a versão do PostgreSQL 8.4.

   Após um ciclo de um pouco mais de um ano, saiu a nova versão do PostgreSQL 8.4. Como poderia esperar, está mais rápido, com mais recursos e funcionalidades. :)

   A Nota de Lançamento tem maiores detalhes. A nova versão do PostgreSQL foi apresentada numa palestra no FISL 10 (toscamente feita por mim) e as lâminas da apresentação podem ser vista aqui abaixo ou baixar o arquivo da palestra. Aproveito para agradecer o Euler que deu uma senhora ajuda com a palestra. :)

   Ah! se for usuário de Debian, pode ficar tranquilo que o 8.4 já está empacotado. Agora para mim, tem muito trabalho pela frente, pois tenho alguns pacotes no Debian que precisarão ser recompilados. ;)

  

 

by Fernando Ike at 02/07/2009 02:57

01/07/2009

Fabio Telles

Lançado o PostgreSQL 8.4!!!

Sim senhores, muitas novidades e hora de preparar o calendário de migrações para a nova versão oficial do PostgreSQL, o banco de dados livre mais avançado do mundo.

Vejam a nota oficial de lançamento em pt_BR.

by Telles at 01/07/2009 08:28

Claudio Bezerra Leopoldino

PostgreSQL 8.4 Enfim Liberado!

O download do PostgreSQL 8.4 (8.4.0) foi enfim liberado!

A nova versão promete mais velocidade e facilidade de uso, melhorias no monitoramento e administração. É instalar e testar para ver! Em breve detalharei neste espaço as principais novidades deste aguardado release!

Abaixo, os links mais úteis:

* Download
http://www.postgresql.org/download/

* Notas de Lançamento
http://www.postgresql.org/docs/8.4/static/release-8-4.html

* Funções implementadas na versão
http://www.postgresql.org/about/press/features84.html

* Press Release
http://www.postgresql.org/about/press/presskit84.html

by cbleopoldino (claudio.leopoldino@gmail.com) at 01/07/2009 03:55

25/06/2009

Fabio Telles

Pesquisa sobre backup em PostgreSQL

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

by Telles at 25/06/2009 12:21

17/06/2009

Fabio Telles

Pesquisa sobre o uso do PostgreSQL no Brasil

Ouvi uma piada contada no PGCon Brasil 2007 que eu nunca esqueço: “O PostgreSQL é a amante dos bancos de dados. Todo mundo usa, mas quase ninguém confessa em público”. Ok, a piada pode te levar a comparações mais curiosas, mas a verdade é nua e crua: o Brasil é um dos países que mais utiliza o PostgreSQL, mas ninguém sabe onde. Sim, sabemos de inúmeros casos onde a empresa tem contratos que a proíbem até de divulgar que utilizam o PostgreSQL. Então, passados mais de um ano e após a prova cabal de que o Google Docs realmente funciona, resolvi fazer a coisa da forma mais simples possível: não leva nem 5 minutos para responder a pesquisa e deve gerar dados com um pouco do perfil dos usuários do PostgreSQL no Brasil.

Preencha a pesquisa agora aqui.

Mini FAQ

  • Sim, vamos públicar o resultado no final.
  • Não, não sei quando ainda, mas deve levar pelo menos um mês.
  • Não, não vamos divulgar nomes de empresas e pessoas que preencheram a pesquisa.
  • Sim, A chamada para a pesquisa foi divulgada hoje no site oficial da comunidade e é lá que vamos publicar os resultados em breve.
  • Sim, você pode e deve divulgar a pesquisa para aquele seu cliente que você sabe que utiliza PostgreSQL.
  • Sim, você pode e deve divulgar a pesquisa em sites, blogs, listas de discução, etc.
  • Sim, vamos fazer uma pesquisa qualitativa com mas detalhes sobre casos de uso brasileiros. Em breve…

by Telles at 17/06/2009 02:50

16/06/2009

Fernando Ike

Claudio Bezerra Leopoldino

PostgreSQL 8.4: Release Candidate Liberada!

Depois do teste de softwares em versões beta, a versão Release Candidate é a mais próxima da versão oficial. A poucos minutos a versão RC do PostgreSQL 8.4 foi liberada para download aqui!

Lembro que esta não é uma versão definitiva e não deve ser utilizada em sistemas de produção, mas pode ser utilizada, por exemplo, para o desenvolvimento de produtos enquanto a oficial não chega de fato. Teste e compartilhe suas primeiras impressões!

by cbleopoldino (claudio.leopoldino@gmail.com) at 16/06/2009 01:17

15/06/2009

Fabio Telles

Enquetes no SAVEPOINT

Bom, eu bem sei que não ando postando novos artigos por aqui. Mas, enquanto os longos artigos não voltam, vamos mexendo numa coisa aqui e outra ali. Dei uma boa melhorada na galeria de imagens:

Agora resolvi brincar com as enquetes. Não sei se vai vingar. Depende mesmo do número de pessoas que vão votar. Se tiver um número razoável, prometo ir atualizando por aqui.

Segue a primeira, que não poderia ser muito diferente. Em breve, algumas mais polêmicas devem se seguir. Aguardo os votos do pessoal.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

by Telles at 15/06/2009 01:51

Fernando Ike

Chamada de Trabalhos para PGCon Brasil 2009

 

 

   Sai alguns dias a chamada de trabalhos para PGCon Brasil 2009. Se gosta de PostgreSQL, ou quer conhecer um pouco está mais que convidado a participar do evento. Porém se tem um estudo de caso, fez uma coisa bacana com o PostgreSQL tem a oportunidade de apresentar para muitas pessoas que trabalham com PostgreSQL. :)

   O telles, com toda a pompa, fez um anúncio bacana e prôpos alguns temas interessantes. Ok, foi um pouco além e deu  nomes para várias palestras, se gostar de uma, diz que a idéia foi dele. :D

  Bom, acho que vou inscrever uma. ;)

by Fernando Ike at 15/06/2009 12:23

14/06/2009

Leandro Guimarães Faria Corcete DUTRA

A loja mágica de brinquedos do ſenhor Saito

Hoje fomos conhecer a famoſa loja mágica de brinquedos do ſenhor Morio ‘Mário’ Saito. Não ſaímos incólumes: o Felipe ‘quebrou o cofrinho’ (metaforicamente) e levou dois conjuntos Lego Guerra nas Eſtrelas, levamos uma maletinha Playmobil e mais quatro caixas de Lego Creative Building para noßa igreja.

Embora haja lugares que dizem ter maior variedade de conjuntos Lego, os preços de Saito-ſan ſão incrivelmente mais baixos — diferenças de um terço ſão comuns, e, nas promoções, metade do preço das lojas brasileiras, loucura total! E lá tem catálogos de Lego deſde a década de 1.990, ſabem os brinquedos que já paßaram por lá antes, tem muito Playmobil, muita coiſa da Haſbro como os Mighty Mugs, & outros como Cocoricó & por aí vai.

O dono tem oitenta anos de idade, ſua eſpoſa ſetenta & ſete, & cuidam ſozinhos da loja há quarenta & ſete anos, aparentemente com o meſmo mobiliário de madeira dos anos ſeßenta, e com aquela concepção de comércio antiquada, mas tão prazeroſa: prateleiras abarrotadas, caixas empilhadas ſobre caixas, e Saito-ſan vai eſcavando as caixas para achar o que queremos…

O dia que tivermos dinheiro, e tendo em viſta a alta quantidade de informatas amantes de Lego, o povo do PoſtgreSQL podia fazer um elefante azul (noßo maſcote) de Lego… ſeria um ſuceßo nos eventos de ſiſtemas livres mundo afora!

by DUTRA, Leandro Guimarães Faria Corcete (leandro.gfc.dutra@gmail.com) at 14/06/2009 08:06

13/06/2009

Leandro Guimarães Faria Corcete DUTRA

Palestra no FISL marcada para sábado, dia vinte & sete

Foi marcada para das dezenove às vinte horas de sábado, dia vinte e sete deste mês de junho de AD 2009, minha palestra sobre ‘ferramentas de modelagem literária e documentação automática em PostgreSQL e outros SGBDs livres’.

Na tradição da comunidade, o título da palestra é uma brincadeira com nosso mascote: O elefante ilustrado, procurando trazer a idéia de diagramação, e, portanto, modelagem de dados através do conceito de ‘ilustração’ — o que, de certa maneira, é um pouco enganoso porque meu foco é a modelagem, não a diagramação, uma vez que creio que os diagramas devem ser gerados automaticamente.

Agora é preparar-me…

by DUTRA, Leandro Guimarães Faria Corcete (leandro.gfc.dutra@gmail.com) at 13/06/2009 10:34

12/06/2009

Leandro Guimarães Faria Corcete DUTRA

Chamada de trabalhos para a III Conferência PostgreSQL Brasil (2009)

Está aberta a chamada de trabalhos para a III Conferência PostgreSQL Braſil (2009), a PgConBR 2009.

Se tens algum trabalho a apreſentar sobre PostgreSQL — pesquisa acadêmica, estudo de caso, novo desenvolvimento &c — faça-o o quanto antes! As PgConBRs são muito interessantes, mas principalmente para quem palestra: quem palestra é procurado pelas pessoas para conversar, e muita coisa interessante vem daí.

by DUTRA, Leandro Guimarães Faria Corcete (leandro.gfc.dutra@gmail.com) at 12/06/2009 07:29

Claudio Bezerra Leopoldino

Números Aleatórios com o PostgreSQL: A Função RANDOM()

Gerar números aleatórios é uma necessidade importante para a geração de grandes bases de dados de teste. Para maior veracidade nos testes, uma certa aleatoriedade é esperada deste tipo de base de dados. Aí entram em cena as rotinas de geração de números aleatórios.

A função RANDOM() é o método nativo do PostgreSQL para a geração de seqüências de números aleatórios. Neste post vamos apresentar exemplos práticos do uso desta função que podem ser úteis no cotidiano.

Ao se executar a função RANDOM(), é retornado um número aleatório entre zero e 1 com muitas casas decimais. Dependendo da necessidade, pode-se gerar um número positivo, um valor dentro de um determinado determinado intervalo. Valores e intervalos podem assumir valores nulos e negativos com pequenas variações de sintaxe.

* Sintaxe

1 - A sintaxe básica.

SELECT random();

Retorna: 0.896639783866704, 0.516120770014822...

2 - Busca de números com um valor dentro de um intervalo começado com zero é um pouco mais complicada. O exemplo abaixo retorna um valor entre 0 e 99. Para aumentar ou diminuir o intervalo, trocar o número 100 por outro valor. Ajustar as casas decimais do comando CAST se desejar valores fracionários. A função ROUND() elimina decimais indesejadas.

SELECT round(CAST (random()*100 AS NUMERIC),0);

3 - Busca de números com um valor dentro de um intervalo qualquer demanda atenção. O exemplo abaixo retorna um valor entre 27 e 90. Para aumentar ou diminuir o intervalo, trocar os números 27 e 91 por outros valores. Ajustar as casas decimais do comando CAST se desejar valores fracionários.

SELECT 27 + round(CAST (random()*(91-27) AS NUMERIC),0);

4 - Busca de números com um valor dentro de um intervalo começado com valor negativo. Bastante similar ao exemplo anterior.

SELECT -57 + round(CAST (random()*(91+57) AS NUMERIC),0);

by cbleopoldino (claudio.leopoldino@gmail.com) at 12/06/2009 10:16

03/06/2009

Claudio Bezerra Leopoldino

Geração de CPFs Fictícios com Pl/ PgSQL

A geração de massas de dados para teste é um processo muito importante, para verificar o comportamento de um banco de dados em relação à carga de processamento que o mesmo tem de desempenhar. A geração de CPFs fictícios é uma atividade relativamente comum em empresas brasileiras que armazenam este tipo de identificador. No entanto muitas vezes os testes são feitos com valores incorretos, isto é, que não respeitam as regras para os dois dígitos verificadores.

Abaixo está um código que se propõe a retornar CPFs aleatórios com dígitos verificadores corretos, implementado em Pl/ PgSQL.

Os comandos mais importantes deste código são:
- Random() - Geração de números aleatórios
- substring() - Extração de parte de uma string com base nso parâmetros fornecidos
- CAST () - Conversão de tipos no PostgreSQL
- trim() - Eliminação de espaços em branco de strings

Os testes foram muito positivos. Coloco para você, leitor, as seguintes perguntas:
- Este código segue um algoritmo correto?
- Ele pode ser melhorado? De que forma?

CREATE OR REPLACE FUNCTION gerar_CPF() RETURNS varchar AS $$
-- ROTINA DE GERAÇÃO DE CPF SEM LOOP
-- Retorna string com CPF aletório correto.
DECLARE
vet_cpf integer [11]; --Recebe o CPF
soma integer; -- Soma utilizada para o cálculo do DV
rest integer; -- Resto da divisão
BEGIN
-- Atribuição dos valores do Vetor
vet_cpf[0] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[1] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[2] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[3] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[4] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[5] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[6] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[7] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[8] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);

-- CÁLCULO DO PRIMEIRO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 10, 9, 8 e assim por diante...
soma:=(vet_cpf[0]*10)+(vet_cpf[1]*9)+(vet_cpf[2]*8)+(vet_cpf[3]*7)+(vet_cpf[4]*6)+(vet_cpf[5]*5)+(vet_cpf[6]*4)+(vet_cpf[7]*3)+(vet_cpf[8]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[9]:=0;
ELSE vet_cpf[9]:=(11-rest); END IF;
-- CÁLCULO DO SEGUNDO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 11, 10, 9 e assim por diante...
soma:= (vet_cpf[0]*11) + (vet_cpf[1]*10) + (vet_cpf[2]*9) + (vet_cpf[3]*8) + (vet_cpf[4]*7) + (vet_cpf[5]*6) + (vet_cpf[6]*5) + (vet_cpf[7]*4) + (vet_cpf[8]*3) + (vet_cpf[9]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[10] := 0;
ELSE
vet_cpf[10] := (11-rest);
END IF;
--Retorno do CPF
RETURN trim(trim(to_char(vet_cpf[0],'9')) || trim(to_char(vet_cpf[1],'9')) || trim(to_char(vet_cpf[2],'9')) || trim(to_char(vet_cpf[3],'9')) || trim(to_char(vet_cpf[4],'9')) || trim(to_char(vet_cpf[5],'9')) || trim(to_char(vet_cpf[6],'9')) || trim(to_char(vet_cpf[7],'9'))|| trim(to_char(vet_cpf[8],'9')) || trim(to_char(vet_cpf[9],'9')) || trim(to_char(vet_cpf[10],'9')));
END;
$$ LANGUAGE PLPGSQL;

Chamada da função, retornando um CPF aleatório.

select gerar_CPF() ;

A função para fazer o teste está neste post. O resultado para um CPF correto é 1.

select CPF_Validar_Sem_Loop(gerar_CPF());
select CPF_Validar_Sem_Loop('66067526557'); --Gerado pelo programa

by cbleopoldino (claudio.leopoldino@gmail.com) at 03/06/2009 01:28

31/05/2009

Fabio Telles

Aberta a chamada de trabalhos para o PGCon Brasil 2009

Sim senhores, agora é oficial e a corrida para o evento começou para valer. Esté aberta até 30/06/2009 a chamada de trabalhos para o PGCon Brasil 2009. Na nossa 3ª edição do evento, temos mais novidades nesta área: serão 4 modalidades diferentes (palestra, palestra avançada, tutorial e hacker talk). Se a chamada de trabalhos for um sucesso absoluto e tudo der certo, vamos passar pelo dilema terrível de ter que escolher os melhores trabalhos.

Aí as novidades continuam. O método de escolha foi muito debatido na comunidade. Haviam duas propostas em pauta:

  • Votação direta pelos membros da comunidade (ou inscritos nas listas). A votação garante que o evento vá de encontro com os interesses dos participantes o que é fundamental para a satisfação dos participantes.
  • O uso de uma banca avaliadora composta por 3 pessoas respeitadas da comunidade. Em 2007 foram os Srs. Diogo Biazus e Euler Taveira. Em 2008 foram os Srs. Leonardo César, Dickson Guedes e eu. Em 2008 se chegou ao consenso de que uma comissão com número ímpar seria interessante para não haver empates e que deveriamos alternar as pessoas envolvidas nesta banca. Para 2009 escolhemos os Srs. Luis Fernando Bueno, Leandro Dutra e Fernando Ike. A vantagem de usar uma comissão é a simplicidade e agilidade do processo e a capacidade de balancear temas e garantir a qualidade, uma vez que são pessoas que conhecem bastante de PostgreSQL no Brasil. Uma coisa interessante da comissão é a possibilidade de trazer temas novos, evitando que as mesmas palestras se repitam todos os anos.

Na dúvida ficamos com os dois. Haverá uma votação on-line entre os membros da lista PGBR-Geral. Esta votação irá apontar para as palestras mais populares e os temas mais solicitados e então uma comissão avaliadora composta de 3 pessoas fará uma seleção final.

Mas ainda temos cartas na manga: se houver um número muito grande de propostas, abriremos uma exposição de painéis (cartazes explicativos que são pendurados nos corredores do saguão com a presença de seus autores), como é comum se fazer em eventos acadêmicos. Desta forma, poderemos contemplar a participação de mais pessoas. Mas esperem, o melhor fica para o final! Vamos repetir o clima animado no final do evento de 2008: os Lightning Talks vão voltar! Na última semana antes do evento estaremos abrindo as incrições (que vão até o final do primeiro dia do evento) para as apresentações relâmpago, com duração máxima de 5 minutos cada.

Então senhores, se você já está trabalhando há algum tempo com PostgreSQL, envie sua proposta. Se você tem várias ideias, mande várias propostas. Escolha o formato mais adequado e mande para nós. Há inúmeros temas que você pode abordar. Este ano teremos mais espaço, 2 auditórios e uma sala VIP, então vale a pena compartilhar conosco um pouco da sua experiência. Você não precisa ser um gênio, basta apenas ter testado alguma coisa interessante e chegado a alguma conclusão no caminho. Muita gente acha que não tem nada de interessante para falar… eu digo que ao acompanhar a lista, tem um montão de gente respondendo e-mails que eu adoraria ver subir no palco e dividir um pouco mais do que sabe conosco. Vejo um zilhão de dúvidas que se repetem e dúvidas que mereciam um tutorial inteiro para explicar melhor como fazer.

Se você está realmente sem idéias, eu vou dar algumas (tem muuuuito mais, claro!) sugestões:

  • Técnicas para carga de grande volume de dados e ETL;
  • Desempenho, segurança e uso de Discos e Sistemas de Arquivos;
  • Testes com novos sistemas de arquivos como EXT4, ZFS, quem sabe BTRFS…
  • GUCs e dicas de configurações de parâmetros;
  • Segurança de aplicações usando PostgreSQL: técnicas para autenticar usuários e evitar SQL Injection;
  • Uso de Full Text Search;
  • PostGIS;
  • Uso de PostgreSQL em aplicações de suporte a decisão (BI);
  • Técnicas de Backup físico e lógico, ou melhor: técnicas de restauração!
  • Como encontrar SQLs lentos e reescrevê-los;
  • Como monitorar o uso de recursos com as novas funções, visões, opções de log e ferramentas do PostgreSQL;
  • Como criar índices realmente úteis e remover índices inúteis;
  • Utilizando técnicas de replicação multimaster assíncronas;
  • Comparação de diferentes técnicas de replicação: onde eu uso o que?
  • Tudo que você queria saber sobre internacionalização e localização e tinha vergonha de perguntar;
  • Refatoração de banco de dados sem perder a cabeça ou o emprego!
  • Migração para PostgreSQL (a partir de Oracle, MySQL, DB2, SQL Server, o que for);
  • Versionamento de banco de dados: gerenciando a mudança com responsabilidade!
  • Técnicas de auditoria e monitoramento de usuários;
  • Desempenho com responsabilidade: descubra o ponto G do PG…
  • Casos de sucesso, sim, queremos saber quem está usando o PostgreSQL por aí!
  • Casos de insucesso e dicas para evitar entrar em grandes roubadas. Tambem poderia ser: “Eu não disse que esse negócio de banco de dados livre não prestava…” (fala sério, alguém tem que fazer esta um dia)
  • Conhecendo um pouco do código fonte do PostgreSQL e funções SPI;
  • Ferramentas para modelagem e documentação de DDL para PostgreSQL (tem alguém me devendo essa)
  • 10 Coisas que ainda não funcionam bem no PostgreSQL,mas que estão em vias de se resolver (ou não) e como contornar estes problemas;
  • Os desafios em ambientes transacionais pesados e com grande volumes de dados;
  • PostgreSQL em aplicações científicas. Em 2008 aprovamos uma palestra de banco de dados para dados biológicos que cancelou na última hora, uma pena.
  • Modelagem utilizando tipos, vetores, domínios, funções de agragação e outros bichos;
  • Consultas recursivas com Common Table Expressions;
  • Cálculos complexos com Windowing Functions;
  • Stand By rápido e rasteiro.
  • A caixa de ferramentas do DBA: consultas e formas de se trabalhar para tornar a vida do DBA mais simples e produtiva;
  • Os 12 pecados do desenvolvedor que começa a utilizar o PostgreSQL pela primeira vez;
  • PostgreSQL para adminstradores de sistema: montando um servidor seguro, rápido e fácil de administrar;

Bom, estas são apenas algumas sugestões, existem várias outras que não pensei agora. Sugestões? De qualquer forma, estamos muito querendo ver novas caras do PGCon Brasil este ano, agora é só escrever e mandar.

by Telles at 31/05/2009 11:32

20/05/2009

Dickson dos Santos Guedes

Aberta chamada para Lightning Talks no PGDay Floripa!

As chamadas de trabalhos para os Lightning Talks (Papo-leve) estão abertas e se você tem interesse em palestrar, entre em contato...

by Guedes at 20/05/2009 11:49

13/05/2009

Claudio Bezerra Leopoldino

PostgreSQL no IV Festival Software Livre da Bahia

Eventos de software livre ganham maior relevância, à medida em que se consolidam. O III ENSL - Encontro Nordestino de Software Livre e o IV Festival Software Livre da Bahia, que antes eram iniciativas distintas, se fundiram em um único evento que será realizado nos dias 29 e 30 de maio de 2009, no campus da Universidade Estadual da Bahia (UNEB), em Salvador.

A programação é vasta e eclética e abrange cinco grandes áreas: Cultura Digital Livre; Casos de Sucesso; Ferramentas e Soluções; Desenvolvimento de Software e Educação e Inclusão Digital.

O PostgreSQL será discutido na palestra "Tuning de Banco de Dados Livre: O Caso do PostgreSQL", ministrada por mim.

A programação detalhada e as inscrições estão disponíveis até 24/05 no site do evento!

by cbleopoldino (claudio.leopoldino@gmail.com) at 13/05/2009 08:50

12/05/2009

Fabio Telles

[pgbr-geral] Campanha dos 5 pontos para melhorar o nível da lista

Tem dias que a gente não deveria começar o dia lendo e-mails idiotas: veja o resultado na lista do PostgreSQL PGBR-Geral. Me pareceu que não sou só eu que estou cançado de ver isso on-line. É bem verdade que a resposta do Sr. Roberto Mello me acordou para a dura realidade do “Never ending September“. Mas fica abaixo o registro.

Senhores, eu sei que muitos que estão utilizando o PostgreSQL são novatos, estudantes e entusiastas. Sei que não é de bom tom tratar estas pessoas de forma seca e dura, pois são pessoas que futuramente vão apoiar a comunidade e utilizar o PostgreSQL em cenários mais sérios e coisa e tal. Mas hoje me deu os 5 minutos de fúria.

Vamos escrever melhor gente? Eu seu que não sou uma pessoa que contribui ativamente aqui na lista. Não respondo muita coisa. Mas venhamos e convenhamos, o nível das perguntas (e muitas vezes das
respostas e comentários também) desanima qualquer pessoa letrada que se esforça para se comunicar adequadamente.

Antes de disparar com a metralhadora para todos os lados, eu quero
dizer: entendo que os erros de ortografia e de digitação fazem parte da nossa vida. Eu mesmo cometo erros terríveis no meu blog e nos e-mails. A língua portuguesa é chata mesmo. Quando estou ajudando o
meu filho de 6 anos a fazer a lição de casa eu percebo como as regras
são confusas: G e J, c, ç, ss, z ou c e q, m ou n, r ou rr, e por aí vai. Mas inventaram os corretores ortográficos e eles estão aí para nos livrar da peste, da fome e da danação.

Proponho lançar uma campanha de 5 pontos aqui (a exemplo de zilhões de campanhas semelhantes em trilhões de listas por aí):

  1. O nome do banco de dados livre mais avançado do mundo é ‘PostgreSQL’ ou simplesmente ‘postgres’. Sim, você pode escrever sem acentos e sem letras maiúsculas. Pode até abreviar para PG numa lista mais informal como a nossa. Mas não use nenhuma outra forma, ok? É como mandar um cartão de dia dos namorados com o nome da garota escrito errado. Na dúvida repita em voz alta para não errar mais:  postgres, postgres, postgres. Dá um bom mantra, é relaxante, tente novamente: postgres, postgres, postgres…
  2. Guarde o miguxes para os seus amigos do tempo do ensino fundamental. Se você escreve ou até fala assim, guarde este segredo terrível para você e aqueles que praticam isso. Não abrevie palavras como se estivesse num chat e principalmente não utilize expressões escritas propositalmente erradas. Conheço muita gente da velha guarda que sente dificuldade em ler menssagens assim. O resultado? Não respondem. Eu não respondo mais e sei de gente muito boa que também não responde.
  3. Descrevam o problema! Gente, nós não conhecemos o seu ambiente, não vemos os erros que estão acontecendo na sua tela e não sabemos o que você fez. Nós não vamos adivinhar se você não contar. Dizer simplesmente: “estou com um problema no postgres e nada funciona aqui” pode conter o nome do banco de dados escrito corretamente, pode até fazer um bom uso da língua portuguesa, mas não nos diz nada. Se você se sente apenas frustrado e quer desabafar, recomendo uma boa cerveja, ver desenhos animados na TV ou até mesmo conversar com alguém no IRC. Mas dizer que não funciona e não citar o contexto não vai lhe ajudar.
  4. Se o seu chefe/professor mandou você fazer um trabalho com PostgreSQL para ontem e você precisa de alguém que faça uma parte do trabalho para você, a lista será um ótimo lugar para você encontrar um profissional que lhe cobrará um preço justo pelos seus trabalhos. Não, não vamos fazer o trabalho de graça por você. Por favor não peça.
  5. Uma boa pergunta é metade do caminho para encontrar a resposta. Se você leu a documentação, pesquisou na Internet, testou e não conseguiu fazer o que você queria, você deve ter uma dúvida. Gaste um tempo na elaboração da pergunta. Pense um pouco.
    • Se você leu um monte de documentações (principalmente a oficial) e não entendeu nada, seu problema é de compreensão de texto. Estude inglês ou português e principalmente leia mais. Um livro por mês seria uma boa meta para você. Mas pelo menos 2 bons livros por ano é o mínimo que um cidadão alfabetizado deveria se habituar a ler. Revistas em quadrinhos são muito legais (eu adoro) mas não contam aqui.
    • Se você testou vários how-tos e receitas de bolo prontas e nada funcionou, vá ler a documentação oficial antes de sair perguntando. Um bom tutorial sempre tem referências. Leia as referências. Ocorre que um tutorial se refere a uma situação específica. Pode não ser o seu caso. Você pode precisar de adaptações. Para quem tem uma boa base de conhecimento (por exemplo, para quem leu a tal da documentação…) o tutorial é muito interessante. Para quem cai de paraquedas, costuma ser um desastre.
    • Se você pesquisou um bocado e leu um bocado e conseguiu evoluir até um certo ponto e depois travou. Você deve ter uma genuína dúvida. Mande um e-mail para nós. Escreva bem, descreva o seu processo e nós lhe ajudaremos. Mas antes de enviar o e-mail, lembre-se que você gastou um tempão para chegar onde está. Se você souber exatamente o que você não está entendendo e souber materializar sua dúvida em forma de um texto, seu problema estará muito próximo da solução. É muito comum se passarem 5 ou 10 e-mails numa lista até que as pessoas entendam precisamente o que você quer saber. Pergunte bem e você terá uma boa resposta. Mais que isso, você será respeitado pelo seu esforço em pesquisar antes e também pela sua capacidade de elaboração de questões relevantes.

Há alguns anos atrás, quando o PostgreSQL começou a ganhar mais visibilidade no Brasil (no lançamento do PostgreSQL 8.0 para ser mais exato), houve uma grande tensão na lista por causa da invasão dos miguxos, analfabetos digitais e até folgados mesmo que caiam diariamente de paraquedas na lista. Eu não acho que espantar esta turma nos ajudará em alguma coisa. Mas se as pessoas vem à lista para aprender alguma coisa, espero aqui estar dando a minha contribuição pedagógica. Sim, eu sou um brasileiro e não desisto nunca!

by Telles at 12/05/2009 05:48