sexta-feira, 25 de novembro de 2011

Criação de Crosstabs no PostgreSQL

Você já criou uma tabela cruzada, ou crosstab, utilizando SQL? Você sabia que era possível? Possivelmente você nunca precisou, mas criar crosstabs é um recurso à disposição que pode ser bastante útil!

Tabelas cruzadas apresentam mais de uma dimensão de forma integrada aos usuários, sendo uma forma importante para a melhor visualização de dados consolidados. Geralmente o cruzamento de dados neste tipo de tabela é feito na camada de apresentação das aplicações ou em componentes geradores de relatórios, mas isso não impede que você também possa implementar crosstabs via banco de dados.

Vamos exemplificar a criação de crosstabs no postgresql utilizando as tabelas abaixo:

* Tabela Loja - Basicamente apresenta a descrição da loja

-- Tabela Loja
CREATE TABLE loja (codigo integer, nomeloja varchar(20), observacao varchar(250));
INSERT INTO loja VALUES (1, 'Loja 1', 'Matriz');
INSERT INTO loja VALUES (2, 'Loja 2', 'Filial 1');
INSERT INTO loja VALUES (3, 'Loja 3', 'Filial 2');
INSERT INTO loja VALUES (4, 'Loja 4', 'Filial 3');


* Tabela Vendas - Apresenta as vendas realizadas para cada mês em cada loja.

-- Tabela Vendas

CREATE TABLE vendas (seqvenda integer, codloja integer, mesvenda integer, valor integer);
INSERT INTO vendas VALUES (1, 1, 1, 100);
INSERT INTO vendas VALUES (2, 1, 2, 100);
INSERT INTO vendas VALUES (3, 1, 3, 100);
INSERT INTO vendas VALUES (4, 1, 1, 100);
INSERT INTO vendas VALUES (5, 2, 2, 100);
INSERT INTO vendas VALUES (6, 2, 3, 100);
INSERT INTO vendas VALUES (7, 2, 1, 100);
INSERT INTO vendas VALUES (8, 2, 2, 100);
INSERT INTO vendas VALUES (9, 4, 3, 100);
INSERT INTO vendas VALUES (10, 4, 1, 100);
INSERT INTO vendas VALUES (11, 4, 2, 100);
INSERT INTO vendas VALUES (12, 4, 3, 100);


Vamos fazer consultas para mostrar as vendas com base em duas dimensões: a loja que fez a vendas e o período (mês) das vendas.

Em primeiro lugar, vamos colocar como colunas as lojas da tabela pai (loja), e como linhas as vendas da tabela filha, agrupando os dados por mês. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for da loja a ser apresentada na coluna.

-- CROSSTAB
-- COLUNAS - LOJAS
-- LINHAS - Vendas em cada Mês
SELECT
(CASE vendas.mesvenda WHEN 1 THEN 'JAN' WHEN 2 THEN 'FEV' WHEN 3 THEN 'MAR' ELSE 'ERRO' END) AS MES,
SUM (CASE vendas.codloja WHEN 1 THEN vendas.valor ELSE 0 END) AS MATRIZ,
SUM (CASE vendas.codloja WHEN 2 THEN vendas.valor ELSE 0 END) AS FILIAL_1,
SUM (CASE vendas.codloja WHEN 3 THEN vendas.valor ELSE 0 END) AS FILIAL_2,
SUM (CASE vendas.codloja WHEN 4 THEN vendas.valor ELSE 0 END) AS FILIAL_3
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY vendas.mesvenda
ORDER BY vendas.mesvenda;


O resultado da consulta mostra inclusive a filial 2, que esteve fechada durante o período:

 mes | matriz | filial_1 | filial_2 | filial_3
-----+--------+----------+----------+----------
 JAN |    200 |      100 |        0 |      100
 FEV |    100 |      200 |        0 |      100
 MAR |    100 |      100 |        0 |      200
(3 registros)


Agora vamos fazer uma inversão: vamos colocar como colunas as lojas da tabela filha, vendas, e como linhas as informações da tabela pai, loja, com os dados agrupados por loja. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for do mês a ser apresentado na coluna.

-- CROSSTAB 2
-- COLUNAS - Vendas em cada Mês
-- LINHAS - LOJAS
SELECT
(CASE loja.codigo WHEN 1 THEN 'MATRIZ' WHEN 2 THEN 'FILIAL 1' WHEN 3 THEN 'FILIAL 2' WHEN 4 THEN 'FILIAL 3' ELSE 'ERRO' END) AS LOJA,
SUM (CASE vendas.mesvenda WHEN 1 THEN vendas.valor ELSE 0 END) AS JAN,
SUM (CASE vendas.mesvenda WHEN 2 THEN vendas.valor ELSE 0 END) AS FEV,
SUM (CASE vendas.mesvenda WHEN 3 THEN vendas.valor ELSE 0 END) AS MAR
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY loja.codigo
ORDER BY LOJA;


Resultado da consulta:

   loja   | jan | fev | mar
----------+-----+-----+-----
 FILIAL 1 | 100 | 200 | 100
 FILIAL 3 | 100 | 100 | 200
 MATRIZ   | 200 | 100 | 100
(3 registros)


O exemplo acima pode ser incrementado e melhorado de várias formas (por exemplo, as tabelas não têm índices). Se você tem alguma sugestão ou forma alternativa de fazer crosstabs ou de melhorar os exemplos abaixo, não deixe de postar um comentário neste post!

Obs.: Existe um módulo do postgresql já bastante estável, chamado tablefunc que apresenta funções para a criação de tabelas cruzadas. É uma forma de criar crosstabs com menos trabalho, mas também com menos diversão e portabilidade! Mais informações sobre o tablefunc aqui.

A Função initcap()

A função initcap() é ao mesmo tempo simples e útil, e muitos desenvolvedores não a conhecem. Basicamente, a initcap() recebe como parâmetro uma string e a retorna de volta, colocando a primeira letra de cada palavra maiúscula, e as demais em letras minúsculas.

É bem prático para formatar strings de nomes de pessoas e lugares utilizando o próprio banco de dados.

Exemplo 1:

teste=# SELECT initcap('ALFA BETA GAMA');
    initcap    
----------------
 Alfa Beta Gama
(1 registro)


Exemplo 2:

teste=# SELECT initcap('alfa beta gama');
    initcap   
----------------
 Alfa Beta Gama
(1 registro)

A função initcap não altera caracteres numéricos, mas atua em qualquer "palavra" começada por caracteres, ainda que contenha números.

Exemplo 3:

 teste=# SELECT initcap('123 123');
 initcap
---------
 123 123
(1 registro)

teste=# SELECT initcap('a123a A123A');
   initcap  
-------------
 A123a A123a
(1 registro)


Esta função pode ser empregada na criação de índices(!), embora eu não veja nisso qualquer utilidade para a maioria das aplicações de banco de dados. Bom, se você conhece algum uso criativo desta função, não deixe de registrar nos comentários!

Exemplo 4:

teste=# CREATE TABLE simples(codi integer, nome varchar(50));
CREATE TABLE
teste=# CREATE UNIQUE INDEX indexnome ON simples((initcap(nome)));
CREATE INDEX


Outras funções similares mas mais conhecidas, são UPPER() e LOWER(), que passam a string passada como parâmetro para maiúsculas e minúsculas, respectivamente.

segunda-feira, 17 de outubro de 2011

201 Posts! Obrigado!

Em 2007 comecei a estudar mais sobre o Postgres, e criei este blog.

Estamos em 2011 e este é o post número 201.

Ainda há muito a estudar, muito mesmo!

Ainda há muito para postar, muitas ideias.

O tempo diminuiu. Bastante.

E nem ensino mais banco de dados.

Mas cada acesso, cada comentário feito, atestam que valeu a pena.

E continua valendo.

Agradeço a Deus!

Obrigado aos amigos da comunidade, muitos dos quais admiro sem conhecer pessoalmente.

Obrigado a quem acessa este site.

Obrigado aos brasileiros.

Obrigado aos paulistas, aos paranaenses e ao povo do Rio Grande do Sul pelos acessos! A todos os estados e ao meu Ceará!

E também aos americanos, portugueses e holandeses (!) que acessam.

E a todos os demais!

Obrigado por cada comentário, ainda que anônimo!

Este site é sobre uma ferramenta técnica.

Nunca vai chegar a um milhão de acessos.

Mas esse não era o objetivo.

Tampouco vender consultorias.


Espero ter tempo para continuar estudando e compartilhando!


Obrigado!

terça-feira, 11 de outubro de 2011

Unlogged Tables: Funcionalidade para Aumento de Desempenho!

Todos sempre buscamos melhorar o desempenho das operações de banco de dados. E um dos recursos de performance ainda pouco utilizados da versão 9.1 do postgres são as chamadas unlogged tables.

O que são Unlogged Tables?

Unlogged Tables são tabelas que não apresentam suporte a recuperação pós-falha. Não apresentam portanto log de transações (write-ahead-log - WAL). Essa característica possibilita um grande ganho de desempenho em todas as operações realizadas. O ganho de desempenho obtido se deve ao sacrifício da possibilidade de recuperar os dados em caso de falha de sistema.

Uma unlogged table tem seus dados automaticamente perdidos em caso de falha, pois é truncada automaticamente, o que gera um ganho no tempo de recuperação do banco de dados.

Os dados de uma unlogged table não sofrem replicação dentro do postgresql.

Em unlogged tables não há necessidade de se manter o log e sincronizá-lo com o banco de dados, fator importante para o de ganho de desempenho.

Em que situações é recomendado utilizar este tipo de tabela?

Em situações em que a durabilidade dos dados não seja realmente importante:
- Para parâmetros de aplicações web;
- Cache de dados em geral;
- Tabelas de status de aplicações, entre outras possibilidades.


Acredito que apenas uma pequena parte de sistemas de bancos de dados possa ser armazenada em tabelas unlogged.

As operações de inserção, alteração, alteração e consulta a dados de uma "tabela sem log" são diferentes de uma tabela "normal"?
A forma de fazer e os comandos utilizados permanecem os mesmos. No entanto, internamente, não há write-ahead-log (WAL), o que faz com que os dados da tabela seja perdidos em caso de quedas de sistema. A velocidade das operações tende a ser bem maior.

Como criar Unlogged Tables?

A criação de tabelas sem log é bastante simples. Basta colocar a cláusula "UNLOGGED" no comando de criação da tabela.

teste=> CREATE TABLE LOGADA (cod integer, descricao varchar(50));
CREATE TABLE
teste=> CREATE UNLOGGED TABLE NAO_LOGADA (cod integer, descricao varchar(50));
CREATE TABLE
teste=>

É permitido indexar este tipo de tabela?

Não existem restrições à indexação, exceto para índices GIST em que este recurso não está implementado. É possível inclusive reindexar, se for o caso! Os índices de uma unlogged table também são "unlogged", isto é, são truncados em caso de falha do sistema.

teste=> CREATE INDEX UNLOGT ON NAO_LOGADA(cod);
CREATE INDEX
teste=>
teste=> insert into NAO_LOGADA values (1, 'Teste 1');
INSERT 0 1
teste=> insert into NAO_LOGADA values (2, 'Teste 2');
INSERT 0 1
teste=> insert into NAO_LOGADA values (3, 'Teste 3');
INSERT 0 1
teste=> REINDEX TABLE NAO_LOGADA;
REINDEX

De quanto é o ganho esperado em desempenho?

DEPENDE da operações realizada. Veja o link abaixo e depois faça seus próprios testes:
http://pgsnaga.blogspot.com/2011/10/pgbench-on-unlogged-tables.html

Considerações Finais

Unlogged Tables são um recurso válido para ganho de performance em certos casos específicos. No entanto, a definição de que tabelas devem ser unlogged pode gerar erros graves e impossibilitar a recuperação de dados relevantes. Esta decisão deve ser sempre bastante embasada e levar em conta as necessidades de todos os usuários do banco.

segunda-feira, 12 de setembro de 2011

PostgreSQL 9.1 Lançado Oficialmente!

A muito aguardada versão 9.1 do PostgreSQL está disponível para download. O destaque são as mudanças relacionadas a performance e replicação, mas existem melhorias em praticamente todos os campos. É baixar, instalar e usar!

Abaixo o texto do anúncio oficial:

------------------------------------------------------------------------------------

The PostgreSQL Global Development Group announces the release of
PostgreSQL 9.1.  This latest version of the leading open source database
offers innovative technology, unmatched extensibility, and new features
such as synchronous replication, K-Nearest Neighbor indexing, and
foreign data wrappers.

"PostgreSQL 9.1 provides some of the most advanced enterprise
capabilities of any open source database, and is backed by a vibrant and
innovative community with proven customer success.  PostgreSQL is well
positioned for building and running applications in the cloud," said
Charles Fan, Sr. VP R&D, VMware.

Responding to Users

Version 9.1 delivers several features which users have been requesting
for years, removing roadblocks to deploying new or ported applications
on PostgreSQL.  These include:

* Synchronous Replication: enable high-availability
  with consistency across multiple servers
* Per-Column Collations: support linguistically-correct
  sorting per database, table or column.
* Unlogged Tables: greatly improves performance for ephemeral data

"Heroku runs the largest PostgreSQL database-as-a-service in the world,"
said James Lindenbaum, Heroku co-founder. "The release of synchronous
data replication with 9.1 provides our customers with innovative new
ways of protecting mission-critical data, and validates PostgreSQL as
one of the fastest-moving datastores available."

Advancing the State of the Art

Our community of contributors innovates with cutting-edge features.
Version 9.1 includes several which are new to the database industry,
such as:

* K-Nearest-Neighbor Indexing: index on "distance" for
  faster location and text-search queries
* Serializable Snapshot Isolation: keeps concurrent transactions
  consistent without blocking, using "true serializability"
* Writeable Common Table Expressions: execute complex multi-stage
  data updates in a single query
* Security-Enhanced Postgres: deploy military-grade security
  and Mandatory Access Control

"OpenERP has always relied on the enterprise-class features of
PostgreSQL to provide a fast, reliable and scalable foundation for the
Business Applications supporting our customers' operations every day.
Data integrity in highly concurrent and transactional contexts is a
critical topic for us, and we're very enthusiastic about the new
Serializable Snapshot Isolation of PostgreSQL 9.1!"  said Olivier Dony,
OpenERP Community Manager.

Extending the Database Engine

PostgreSQL's extensibility enables users to add new functionality to a
running production database, and use them for tasks no other database
system can perform.  Version 9.1 adds new extensibility tools, including:

* Foreign Data Wrappers: attach and query other databases
  from PostgreSQL
* Extensions: easily create, load, and manage new database features

In PostgreSQL's 25th year of database development, our community
continues to advance database technology with every annual release.
Download version 9.1 now and experience the most advanced open source
database system in the world.

More information on PostgreSQL 9.1:
* Release notes
  http://www.postgresql.org/docs/9.1/static/release-9-1
* Presskit
  http://www.postgresql.org/about/press/presskit91
* Guide to 9.0:
  http://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.1

Download 9.1 now:
* Main download page:
  http://www.postgresql.org/download
* Source code:
  http://www.postgresql.org/ftp/source/v9.1.0
* One-click installer, including Windows installer:
  http://www.enterprisedb.com/products/pgdownload.do






sexta-feira, 9 de setembro de 2011

PgBr 2011 - Inscrições Abertas! Último dia para Submissão de Trabalhos!

A PgBr 2011, o maior evento de Postgres do país, está com inscrições abertas. O valor da inscrição aumenta à medida em que se aproxima a data do evento: 3 e 4 de novembro, em São Paulo. A inscrição vip dá direito a almoço com os palestrantes. Se inscreva agora!

Hoje, 09 de setembro, é o último dia para Submissão de Trabalhos!

Serpro Ultrapassa os 200 Bancos de Dados PostgreSQL!



Ao atingir o volume de 220 bancos de dados, o PostgreSQL passa a ocupar a
posição de destaque como tecnologia livre de bancos de dados no Serpro - Serviço Federal de Processamento de Dados. O MySQl apresenta 200 bancos de dados implementados.

Confira esta informação na página 19 da edição 207 da versão online de revista TEMA. Outro artigo com destaque para o Postgres é o do encarte TEMATEC "Expresso em Nuvem", que mostra uma implementação de grande porte com Postgres e PgPool.

quinta-feira, 21 de julho de 2011

A Função clock_timestamp()

Você já ouviu da função clock_timestamp? Ela retorna a data e hora com bastante precisão junto com a time zone do servidor, da mesma forma que as funções now() e current_timestamp. Então para quê implementar esta nova função? O interessante da clock_timestamp é que a mesma retorna o timestamp do término da transação, enquanto now e current timestamp retornam a data/hora do início da transação corrente.

É uma função que pode ser importante para aqueles que necessitam de alta precisão ao lidar com variáveis temporais.

Exemplos:

1 - Sintaxe básica

teste=# SELECT clock_timestamp();
        clock_timestamp       
-------------------------------
 2011-07-21 09:34:12.645251-03
(1 registro)


2 - Extração de parte do valor retornado.

teste=# SELECT SUBSTRING(CAST(now() AS VARCHAR) FROM 1 FOR 10);
 substring 
------------
 2011-07-21
(1 registro)



3 - Lado a lado o resultado de clock_timestamp() e now() na mesma transação. Observe que os valores são diferentes e indicam o timestamp de início e de término da transação.

teste=# SELECT SUBSTRING(CAST(now() AS VARCHAR) FROM 1 FOR 10);
 substring 
------------
 2011-07-21
(1 registro)

teste=# SELECT now() || '   ' || clock_timestamp();
                           ?column?                           
---------------------------------------------------------------
 2011-07-21 10:21:46.592655-03   2011-07-21 10:21:46.592828-03
(1 registro)


4 - Diferença entre clock_timestamp() e now(), mostrando o tempo decorrido entre o início e o término da transação.

teste=# SELECT clock_timestamp() - now();
    ?column?    
-----------------
 00:00:00.000099
(1 registro)

sexta-feira, 15 de julho de 2011

sexta-feira, 1 de julho de 2011

Baixe os RPMs de Instalação da versão 9.1 Beta2!

Os instaladores para linux da versão 9.1 Beta 2 estão disponíveis para quem quiser testar. Esse é mais um indício de que a versão 9.1 logo será oficialmente lançada.

Baixe os RPMs aqui e teste à vontade!

terça-feira, 28 de junho de 2011

JMeter: Brincando de Testar seu Servidor PostgreSQL!

Testes de performance de servidores de bancos de dados são importantes para se avaliar ambientes de produção antes da implantação de projetos que envolvam muitos usuários e grande tráfego de informações. Uma ferramenta boa e estável para este tipo de teste é o Jakarta Jmeter.

Através do JMeter é possível configurar conexões ao servidor, criar requisições JDBC (comandos, chamadas de funções, etc.), submetê-las ao servidor e analisar o resultado da execução. A ferramenta permite ainda criar múltiplas threads simulando um grande número de usuários simultâneos, e executar para cada thread as requisições mais de uma vez, gerando uma grande carga de acessos que testa os limites de carga aceitos pelos bancos de dados.


Adicionalmente, é possível utilizar ouvintes (listeners) para apresentar os resultados da execução dos comandos na forma de tabelas, árvores e gráficos diversos.

O JMeter é compatível com qualquer banco que aceite conexão JDBC, incluindo o postgres e pode testar ainda outros tipos de requisição como ftp e http. Baixe o jmeter agora!

Vamos mostrar as principais etapas de utilização da ferramenta utilizando um teste feito no postgresql.

1. Instalação

Baixe a ferramenta, descompacte os arquivos em uma pasta. Observe que existem vários subdiretórios. As pastas mais relevantes são a LIB e a BIN.

Copie o arquivo do driver jdbc do postgresql (e o dos demais bancos com os quais trabalhar) para a pasta LIB do JMeter.

2. Execução

No windows pode ser utilizado o arquivo jmeter.bat, na pasta BIN da ferramenta (jakarta-jmeter-2.4/bin no meu caso). No Linux existe o arquivo jmeter.sh.

Existe a opção de rodar diretamente do arquivo .JAR, digitando:

java  -jar ApacheJMeter.jar

A tela inicial apresentada é bastante simples, com uma barra de menu e uma árvore onde são apresentados hierarquicamente os comandos dos planos de testes.

A árvore apresenta duas grandes divisões: plano de testes e área de trabalho. A área de trabalho pode ser utilizada para colocar comandos que não serão executados, enquanto que o plano de testes é a parte da treeview que apresenta os comandos do plano que serão executados, sendo que comandos de teste podem ser arrastados livremente entre área de trabalho e plano de testes.




3. Número de Usuários Simulados no Teste

O primeiro passo é definir o número de usuários que seu teste deseja simular.  Se o seu teste tiver muitos usuários, pode ser caracterizado como teste de carga. Caso tenha apenas um, executando uma vez cada comando, pode ser entendido como um teste funcional. Cada plano de testes pode agregar dezenas de requisições (testes) de banco de dados (JDBC), FTP, HTTP, entre outras possibilidades.


Com o botão direito do mouse sobre o plano de trabalho acione o menu "Plano de Testes\ Adicionar\ Threads (Users)\ Grupos de Usuários". A tela mostrada permite que se defina quantos usuários virtuais serão simulados, o tempo de inicialização de cada usuário e o número de vezes que cada usuário simulado executará os próximos comandos do plano de testes. Caso se deseje 100  usuários, executando 10 vezes cada teste, uma execução do plano de testes testará 10000 execuções do plano.



4. Configurando o JDBC

Para fazer testes de banco de dados, devemos configurar a conexão JDBC. 

Com o botão direito do mouse sobre o plano de trabalho acione o menu "Plano de Testes\ Adicionar\ Elemento de Configuração\  Configuração da Conexão JDBC".

A tela mostrada permite que se defina os parâmetros de conexão com o servidor, tais como limite de conexões, tempo máximo de conexão, intervalo para timeout de conexão, entre outros. A figura abaixo mostra os principais parâmetros utilizados.


5. Criação do Teste de Banco

Para criar os testes de banco de dados em si, basta se definir o SQL a ser submetido. O comando será executando tantas vezes forem definidas na seção "Grupo de Usuários" do plano de testes.

Com o botão direito do mouse sobre o plano de trabalho acione o menu "Plano de Testes\ Adicionar\ Testador\ Requisição JDBC".

A tela mostrada permite que se forneça o comando SQL a ser testado. Não utilize ponto e vírgula ";", pois pode gerar erro de execução.



6. Adicionando Ouvintes (Listeners)

Antes de executar os testes, deve ser definido de que forma o resultado da execução será apresentado. Os ouvintes monitoram os testes e apresentam o resumo das execuções de várias formas.

Um mesmo teste pode ser visualizado de mais de uma forma, o que facilita o entendimento, seja como árvore, tabela, gráfico ou geração de arquivo.


Com o botão direito do mouse sobre o plano de trabalho acione o menu "Plano de Testes\ Adicionar\ Ouvinte\ Árvore de Resultados".  Acrescente outros ouvintes como "Relatório Agregado" e "Ver Resultados em Tabela". As figuras abaixo mostra o resultado de um teste visto por mais de um ouvinte.




7. Executando Testes

Utilize a barra de menu para executar os testes:
- "Executar\ Iniciar" - Executa os testes do plano de trabalho atual
- "Executar\ Limpar Tudo" - Limpa os resultados de testes anteriores para nova rodada de testes
- "Arquivo\ Salvar" - Salva o Plano de Testes


Independentemente de termos boas ferramentas como o JMeter, temos sempre de testar as nossas aplicações, e não podemos descuidar dos bancos de dados. O JMeter tem potencial para automatizar boa parte dos testes feitos com bancos de dados sem grande esforço, o que não elimina a necessidade de bons testadores e de cuidado na hora de se realizar e interpretar os resultados apresentados.

Teste o JMeter e me diga o que achou dele! Não se esqueça que a qualidade do seu teste é consequência de um bom plano de testes!

quarta-feira, 15 de junho de 2011

Atualize seus Drivers JDBC3 e JDBC4 para PostgreSQL

Esse link é importante para quem trabalha com JDBC. O site postgresql.org apresenta uma farta oferta de opções de drivers JDBC para o Postgres, além da documentação e detalhes do desenvolvimento.

São disponibilizados drivers para as versões em produção e para as em desenvolvimento do postgres. Confira e atualize seu ambiente!

segunda-feira, 13 de junho de 2011

Conecte o PostgreSQL com o LibreOffice via JDBC!

A interface visual do LibreOffice (BrOffice) é similar à do ACCESS, e muito superior à da interface do psql. Um grande sonho seria poder visualizar e operar o seu banco do postgresql por meio desta interface.

Já falamos aqui da integração BASE-POSTGRESQL via SDBC. No entanto um artigo da revista brasileira do BrOffice mostra como se conectar via JDBC. Acesse aqui o artigo "BASE E POSTGRESQL: Acomodando um elefante no escritório" de Leonardo Cezar.

O texto é bastante didático e bem ilustrado, facilitando a replicação dos procedimentos, e as próximas edições prometem a continuação da matéria detalhando a operacionalização do trabalho com o postgres dentro do LibreOffice Base. É imperdível para quem está procurando uma nova ferramenta visual.

Qual é a versão do seu Postgres?

Você sabe qual é a versão do seu servidor Postgres? Sabe mesmo? E do cliente (estava pensando que é sempre a mesma?)? Ele é 32 ou 64 bits? Para muitos desenvolvedores a resposta é não, e em vários casos nem se sabe como recuperar estas informações.


A melhor maneira de se saber a versão de um servidor banco de dados é simplesmente consultando-a. E no caso do postgresql a função que retorna estas informações é a VERSION().

Exemplo: 
- Consulta padrão:
SELECT version();


Resultado:
PostgreSQL 9.0.4 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 32-bit
Para recuperar informações de versionamento do cliente do banco deve se utilizar o utilitário psql:

Exemplo:
psql --version

Resultado: 

psql (PostgreSQL) 9.0.4
contém suporte a edição em linha de comando


Agora você pode visualizar facilmente a versão atual do seu postgres. Então é bom passar mais alguma informação sobre como interpretar o número de versionamento.

O postgres é versionado em um sistema de numeração com três números, no formato "A.B.C". A versão de produção atual, seguindo este formato, é a 9.0.4. A sistemática de numeração de versão do postgres pode ser conferida aqui.

- A - Número de versão principal. Quando este número muda significa que aconteceram alterações radicais na estrutura e funcionamento do banco. A versão atual é 9, e não há planejamento para uma versão 10 no momento.

- B - Número de versão secundário. Quando este número muda significa que aconteceram alterações na estrutura e funcionamento do banco que demandam. Os números A e B devem ser considerados em conjunto, e não apenas o primeiro número de versão, pois indicam uma versão em especial. O B da versão atual é 0, mas existe uma versão beta do postgres 9.1 e planejamento da versão 9.2.

- C - Número de atualizações aplicadas à versão "A.B". Na versão 8.4, por exemplo, já foram aplicadas 10 atualizações. O valor inicial de C é 0 e atualmente estamos na versão 9.0.4, indicando que a versão 9.0 já sofreu 4 atualizações. É importante acompanhar os informes de atualização especialmente quando solucionam questões chave de segurança, performance e bugs que afetam de alguma forma o desenvolvimento dos sistemas e a disponibilidade dos servidores de banco.

Que tal conferir agora a versão que está no seu sistema?

quarta-feira, 8 de junho de 2011

Utilize o PSQL como Gerador de Relatórios!

Uma boa maneira de utilizar o utilitário psql é como meio para executar scripts que recuperem informações e as armazenem em arquivos. Desta forma, podemos gerar relatórios de alta relevância e complexidade a um custo mínimo.

A sintaxe abaixo, lê um script de um arquivo de entrada com o programa e o executa no PSQL:

psql -U usuario -d banco_de_dados -f arquivo_de_entrada

Mas como gerar relatórios de forma fácil com o psql? Simplesmente as opções são infinitas, pois podemos mesclar comandos SELECT, funções como a current_timestamp e comandos do psql. A solução depende da sua criatividade.

Abaixo coloco um script simples que recupera informações sobre os objetos do banco. A opção "\o" especifica um arquivo de saída do relatório. Para se executar o script, o mesmo foi gravado no arquivo "entrada.txt" e foi executado no prompt do psql através da chamada "psql -U postgres -d teste -f entrada.txt". O script foi testado no Postgresql 9.0.

\o saida.txt
\echo Cabecalho
SELECT 'Inicio: ' || current_timestamp as Inicio;
\echo Relatorio no Arquivo Saida.txt
SELECT '#####################################################################' AS Titulo UNION ALL
SELECT '### Relatorio de Banco de Dados 1.0 #################################' AS Titulo UNION ALL
SELECT '### Claudio Leopoldino              #################################' AS Titulo UNION ALL
SELECT '### Script para livre distribuição e utilização #####################' AS Titulo UNION ALL
SELECT '### http://postgresqlbr.blogspot.com/ ###############################' AS Titulo UNION ALL
SELECT '#####################################################################' AS Titulo;
\echo Lista de Bancos de Dados
\qecho '#########################################################################################'
\qecho '### Bancos de Dados #####################################################################'
\qecho '#########################################################################################'
\l
\echo Lista de Bancos de Dados com Detalhe
\l+
\echo Lista de Usuarios
\qecho '#########################################################################################'
\qecho '### Lista de Usuarios ###################################################################'
\qecho '#########################################################################################'
\du
\echo Lista de Tabelas
\qecho '#########################################################################################'
\qecho '### TABELAS #############################################################################'
\qecho '#########################################################################################'
\dt
\echo Lista de Tabelas com Detalhe
\dt+
\echo Lista de Tabelas de Sistema
\dtS
\echo Lista de Tabelas de Sistema com Detalhe
\dtS+
\echo Lista de Indices
\qecho '#########################################################################################'
\qecho '### INDICES #############################################################################'
\qecho '#########################################################################################'
\di
\echo Lista de Indices com Detalhe
\di+
\echo Lista de Sequencias
\qecho '#########################################################################################'
\qecho '### SEQUENCIAS###########################################################################'
\qecho '#########################################################################################'
\ds
\echo Lista de Visoes
\qecho '#########################################################################################'
\qecho '### VISOES ##############################################################################'
\qecho '#########################################################################################'
\dv
\echo Lista de Visoes com Detalhe
\dv+
\echo Lista de Visoes de Sistema
\dvS
\echo Lista de Visoes de Sistema com Detalhe
\dvS+
\echo Lista de Privilegios de Acesso
\qecho '#########################################################################################'
\qecho '### PRIVILEGIOS DE ACESSO ###############################################################'
\qecho '#########################################################################################'
\dp
\echo Lista de Large Objects
\qecho '#########################################################################################'
\qecho '### LARGE OBJECTS #######################################################################'
\qecho '#########################################################################################'
\dl
\echo Lista de Funcoes
\qecho '#########################################################################################'
\qecho '### FUNCOES #############################################################################'
\qecho '#########################################################################################'
\df
\echo Lista de Operadores
\qecho '#########################################################################################'
\qecho '### OPERADORES ##########################################################################'
\qecho '#########################################################################################'
\do
\echo Lista de Tipos de Dados
\qecho '#########################################################################################'
\qecho '### TIPOS DE DADOS ######################################################################'
\qecho '#########################################################################################'
\dT
\echo Rodape
SELECT 'Final: ' || current_timestamp as Final; \q


Agora você pode executá-lo e incrementá-lo para extrair e formatar toda informação que você desejar. Pode ainda criar novos e melhores scripts! Explore opções para layouts mais agradáveis, consultas mais específicas e o que mais a sua necessidade exigir e a sua criatividade for capaz de propor!

Como melhorar este relatório? Te convido a compartilhar com a comunidade nos comentários deste post. Sua contribuição é sempre bem vinda!

terça-feira, 31 de maio de 2011

Booktown e outros Bancos de Dados de Exemplo para PostgreSQL

Exemplos de bancos de dados são úteis para o ensino e a aprendizagem sobre as ferramentas e sobre situações práticas que ocorrem no cotidiano dos profissionais da área. Já falei previamente sobre o pagila, mas é sempre bom ter mais opções.

O Booktown é um script que cria o banco de dados de uma livraria completa, incluindo alguns registros e possibilitando um bom banco de dados para testes e ensino de banco de dados. Originalmente, a base booktown foi utilizada nos exemplos do livro Practical PostgreSQL.

Baixe o script aqui.

segunda-feira, 30 de maio de 2011

Automatize o seu Backup do PostgreSQL via Python!

Vi esse script no site do David Goodwin e achei interessante. Mas ao executá-lo posteriormente tive outra boa surpresa: ele executa "de primeira", sem a necessidade de se fazer qualquer correção. A idéia é através de um programa em python chamar os utilitários de backup do postgres para realizar o backup, e o código deste script pode ser alterado para automatizar outras tarefas de modo bastante simples.

As etapas de utilização são simples:

- Instale o python e o postgres. Esta etapa eu não precisei fazer, porque já o tinha instalado aqui. Teste a versão digitando: "python --version". A versão da minha máquina é a 2.6.5 e do postgres é 9.0.
- Crie um arquivo de script com o código. Use a extensão ".py" como padrão para não misturar seus códigos python os de com outras aplicações.
- Edite os campos "usuário", "senha", "caminho do pg_dump", a "lista de bancos que devem sofrer backup" e salve o arquivo. Destaquei abaixo estes parâmetros em vermelho
- Execute o script. Utilizei "python -v py_backup.py". A opção -v significa VERBOSE, isto é, gera uma descrição de tudo o que está sendo feito durante o backup. Existem outras boas opções do pg_dump e do python, mas isso fica como pesquisa paras os interessados.

Abaixo coloco o código do script, mas acesse também o site original:


#!/usr/bin/python
from time import gmtime, strftime
import subprocess
import os
database_list = [ 'database1', 'database2', 'etc' ]
USER = "postgres"
PASS = "postgres-password"
BACKUP_DIR = "e:\\postgresql_backups\\"
# dump using PostgreSQL's custom format, with maximum compression. (-F c, -Z 9)
dumper = """ "c:\\program files\\postgresql\\8.1\\bin\\pg_dump" -U %s -Z 9 -f %s -F c %s  """                  
os.putenv('PGPASSWORD', PASS)
for database_name in database_list :
        print strftime( "%Y-%m-%d-%H-%M-%S" , gmtime()) + ":dump started for %s"%database_name
        time = str (strftime("%Y-%m-%d-%H-%M"))
        file_name = database_name + '_' + time + ".sql.pgdump"
        #Run the pg_dump command to the right directory
        command = dumper % (USER,  BACKUP_DIR + file_name, database_name)
        subprocess.call(command,shell = True)
        print strftime( "%Y-%m-%d-%H-%M-%S" , gmtime()) + ":finished"


Tente utilizar o python para chamar outros utilitários do postgres. Se quiser fazer um backup de todas as bases de dados, pode utilizar por exemplo o PG_DUMPALL.

Tem sugestões de melhoria para este script? Poste aqui no nosso fórum!

segunda-feira, 23 de maio de 2011

A Revista Oficial do PostgreSQL!

É apenas um teste, mas pode se concretizar. O primeiro número da revista oficial do PostgreSQL está no ar e você pode baixar gratuitamente. Acesse e confira! Caso a recepção seja boa, a revista ganhará novas edições.

O primeiro número me agradou bastante, explorando vários itens sobre as futuras versões do Postgres, questões de performance e dicas específicas para  sistemas operacionais, o que nem sempre é fácil de se encontrar.

Você pode colaborar adquirindo a versão impressa ou submetendo matérias para os editores. Confira!

quinta-feira, 19 de maio de 2011

Participe: Edital para Instrutor de PostgreSQL - UNESCO/ FUNAI

Aos instrutores de banco de dados, segue a notícia de edital para instrutor de PostgreSQL. A indicação foi do amigo Bruno Rebello. Participem e divulguem entre os possíveis candidatos! Os editais estão nos sites da UNESCO e da FUNAI.  

Avisem sempre que tiverem vagas de seleções e concursos relacionados como PostgreSQL para divulgação neste espaço!

_______________________________________________________________


EDITAL 002/2011 - A UNESCO e FUNAI, por meio do Projeto 914BRA4008 – “Impactos do Desenvolvimento e Salvaguarda de Comunidades Indígenas”, seleciona na modalidade “PRODUTO”, 01 profissional com Graduação na área de Tecnologia da Informação e/ou pós-graduação de, no mínimo, 360 horas, mestrado ou doutorado em área de Tecnologia da Informação fornecido por instituição reconhecida pelo Ministério da Educação para Capacitação de técnicos/servidores da FUNAI, para operação e administração do banco de dados PostgreSQL, banco de dados utilizado para armazenar toda a estrutura de dados projetada no desenvolvimento do Sistema Indigenista de Informações - sistema esse que monitora a implantação dos Planos de Salvaguarda da FUNAI.

Os interessados deverão enviar o CV do dia 16/maio/2011 até às 23h 59 do dia 23/maio/2011 para o endereço unescobra4008@gmail.com, no formato Word, Open Office ou PDF , indicando o número do edital e o nome do perfil em que se candidata. Serão desconsiderados os CVs remetidos após a data limite indicada neste edital. Para mais informações, consultar o edital completo que será publicado nos sites www.funai.gov.br e www.unesco.org.br

Acesso ao Edital: 914BRA4008 Edital 002/2011, Anexo II (modelo padrão currículo).

Em atenção às disposições do Decreto nº 5.151, de 22 de julho de 2004 é vedada a contratação, a qualquer título, de servidores ativos da Administração Pública Federal, Estadual, do Distrito Federal ou Municipal, direta ou indireta, bem como de empregados de suas subsidiárias e controladas, no âmbito dos projetos de cooperação técnica internacional.
Estas contratações serão efetuadas mediante processo seletivo simplificado (análise de currículo e entrevista), a ser realizado com no mínimo 03 (três) candidatos, por vaga, com currículos válidos e maior pontuação, sendo exigida, destes profissionais, a comprovação da habilitação profissional e da capacidade técnica ou científica compatível com os trabalhos a serem executados.
De acordo com a Portaria nº 717, de 09/12/2006, é vedada a contratação de consultor que já esteja cumprindo contrato de consultoria por produto vinculado a projeto de cooperação técnica internacional.

Data de Publicação do Edital: 16/05/2011

segunda-feira, 16 de maio de 2011

Squirrel Client: Suas Conexões em um Único Lugar!

Conexões são muito importantes e temos de gerenciá-las. Quando temos conexões para vários bancos de dados distintos em múltiplos servidores e ambientes de desenvolvimento, produção e homologação, esta gestão pode se tornar complicada. O Squirrel Client é uma boa ferramenta que permite a gestão das conexões, a visualização e a manipulação de dados do PostgreSQL e da maioria dos bancos de dados livres e proprietários, unificando em um ponto esta função. (eles só não têm um logotipo decente, então ilustrei com esse que encontrei na internet)



A instalação é bem fácil e se desejar baixar e executar direto do arquivo JAR ou do script .SH sem precisar instalar a ferramenta, não há segredos (é o que eu faço no cotidiano). No windows pode ser acionado pelo arquivo .BAT.

Para utilizar o Squirrel Client, basta baixar a ferramenta e o driver do banco de dados que se deseja acessar. A lista de bancos suportados pela ferramenta é muito vasta, e as configurações a serem feitas não são sofisticadas:

Primeiro passo: Configurar driver

No caso do PostgreSQL, o driver pode ser baixado facilmente. Neste exemplo foi utilizado um driver jdbc, copiado para a pasta lib do squirrel client.

Selecione a aba "Drivers" à esquerda da tela. Informe a string de conexão, dê uma descrição para o driver e confirme.


 


Segundo passo: Configurar conexão

Uma vez que um  driver pode ser utilizado em várias conexões, deve-se configurar a conexão que utiliza o driver.

Acione a aba"Aliases" e clique no ícone "+" para criar uma nova conexão. Informe o nome, o driver que você criou, a string de conexão, usuário e senha, conforme a figura e confirme.

Para conectar, clique no primeiro ícone da aba "Aliases".


Visualizando o banco de dados

A conexão faz com que sejam mostradas duas abas: "Objects" e "SQL".  A aba "Objects" permite a visualização do banco de dados através de uma treeview e de várias abas internas que são dinamicamente preenchidas à medida em que um objeto do banco de dados é selecionado.

A interface é bem detalhada e são apresentadas informações detalhadas a respeito dos metadados que não são comumente mostradas em outras ferramentas similares como permissões de acesso de tabelas e colunas.

Observe que as informações só serão 100% confiáveis se a coleta de estatísticas do banco de dados estiver atualizada.



Trabalhando com o banco de dados

A aba SQL permite a realização de consultas e a criação, salvamento e recuperação de scripts sql. 

Funções como auto correct/ abreviations e bookmarks podem aumentar a produtividade do usuário.

A execução simultânea de várias conexões é muito útil para evitar a abertura de vários visualizadores em ferramentas distintas.

É possível criar um ou mais diagramas utilizando o botão direito do mouse sobre as tabelas e selecionando a opção "add to a graph", um bônus muito interessante, pois mostra os relacionamentos e permite imprimir de várias formas! 



Limitações

Por ser uma ferramenta de acesso a dados, não apresenta recursos de design mais avançados para a opção de elaboração de diagramas, que gera diagramas através do esquema SQL, mas não gera esquema SQL com base no diagrama. No entanto isso não chega a ser um limitador, apenas não é o propósito da ferramenta.

O suporte a Hibernate não foi testado neste post, mas parece ser uma das features mais interessantes para os usuários deste framework.

A única restrição que encontrei foi o fato do sistema não apresentar o plano de execução das consultas que utilizei no teste (não testei outros bancos além do Postgresql). Possivelmente as novas versões supram esta necessidade futuramente.

O squirrel client se mostra adequado para manter e centralizar conexões a múltiplos bancos de dados, visualizar seus metadados e realizar operações no banco que demandem SQL. Veja os screenshots, baixe, instale e teste!

sexta-feira, 13 de maio de 2011

Ordene Registros Fisicamente com o Comando CLUSTER!

O comando CLUSTER permite a ordenação física dos dados de uma tabela com base em um índice. Esta pode ser uma boa opção quando um grande número de leituras sequenciais for realizado com base em um ou mais campos. É um comando já antigo, mas pouco conhecido e utilizado.

A operação de ordenação é feita uma vez no momento da execução do comando, e caso se deseje que os dados continuem ordenados fisicamente, deve-se reexecutar o comando após alterações nos registros, o que pode tomar muito tempo de processamento.

Um problema com este comando é a utilização de arquivos temporários que pode exigir espaço em disco extra, além de acessos a disco que tornem a operação mais demorada..

A sintaxe é relativamente simples:

CLUSTER [VERBOSE] table_name [ USING index_name ]
CLUSTER [VERBOSE]

A cláusula VERBOSE faz com que sejam mostradas informações do andamento da clusterização.

A sintaxe com nome da tabela e nome do índice é a mais segura, pois se sabe exatamente que tabela e que índice são utilizados.

A redação com o nome da tabela e sem o nome do índice assume que será utilizado para a ordenação o último índice utilizado.

A utilização de CLUSTER sem indicação de tabela ou índice reordena todas as tabelas que já tenham sido clusterizadas, o que pode ser arriscado, pois estas classificações de dados podem tomar um tempo substancial.

Por ser uma operação muito custosa, durante a clusterização a tabela fica indisponível para leituras e escritas, o que faz com que esse comando seja um candidato para momentos do dia de menor quantidade de acessos.

Abaixo temos um exemplo de clusterização, com criação de tabela, índices e dados e execução dos comandos de clusterização:

/*
Criação da tabela e inserção nos dados
*/

begin transaction;

drop table TAB_CLUSTER;
/*
drop index TAB_CLUSTER_COD;
drop index TAB_CLUSTER_VALOR;
*/

CREATE TABLE TAB_CLUSTER (
COD INTEGER, DESCRICAO VARCHAR(50), DATAHORA TIMESTAMP, VALOR INTEGER);

create index TAB_CLUSTER_COD on TAB_CLUSTER(COD);
create index TAB_CLUSTER_VALOR on TAB_CLUSTER(VALOR);

insert into TAB_CLUSTER values (round(CAST (random()*500 AS NUMERIC),0), 'Teste do comando Cluster', current_timestamp, round(CAST (random()*500 AS NUMERIC),0));
insert into TAB_CLUSTER values (round(CAST (random()*500 AS NUMERIC),0), 'Teste do comando Cluster', current_timestamp, round(CAST (random()*500 AS NUMERIC),0));
insert into TAB_CLUSTER values (round(CAST (random()*500 AS NUMERIC),0), 'Teste do comando Cluster', current_timestamp, round(CAST (random()*500 AS NUMERIC),0));
insert into TAB_CLUSTER values (round(CAST (random()*500 AS NUMERIC),0), 'Teste do comando Cluster', current_timestamp, round(CAST (random()*500 AS NUMERIC),0));
insert into TAB_CLUSTER values (round(CAST (random()*500 AS NUMERIC),0), 'Teste do comando Cluster', current_timestamp, round(CAST (random()*500 AS NUMERIC),0));

commit transaction;

cluster tab_cluster using tab_cluster_cod;

cluster tab_cluster using tab_cluster_valor;


Alternativas ao comando CLUSTER envolvem o uso de CREATE TABLE AS (sintaxe recomendada por compatível com Pl/ PgSQL) ou SELECT INTO. Ambos os comandos leem um conjunto der registros, ordenam e gravam em um local determinado:

- CREATE TABLE tab_cluster_teste1 AS SELECT * FROM tab_cluster ORDER BY cod;
- SELECT * INTO tab_cluster3 FROM tab_cluster ORDER BY cod;

quinta-feira, 12 de maio de 2011

PostgreSQL no Ubuntu: Primeiros Passos Após a Instalação

Este post é uma continuação do de instalação do postgresql 9.0 no Ubuntu. Desta vez o referencial veio do site stuartellis.eu.

Uma vez instalado o banco, o serviço está ativo.

Por padrão existe um banco de dados postgres e um usuário postgres. É necessário configurar o acesso para poder cadastrar usuários.

Entre no terminal e siga os seguintes passos:

- sudo -u postgres psql - Abre o utilitário PSQL utilizando o usuário logado na máquina
- ALTER ROLE postgres WITH ENCRYPTED PASSWORD 'senhaforte'; - Dentro do psql, define a senha do role postgres
- \q - Encerra a sessão do psql


Agora altere os arquivos postgresql.conf e pg_hba.conf para habilitar o acesso:

- cd /etc/postgresql/9.0/main
- sudo gedit postgresql.conf - Alterar parâmetro listen_addresses para '*' ou para a lista de endereços desejada
- sudo gedit pg_hba.conf - Alterar configuração de segurança
- sudo postgresql service restart - Reiniciar o serviço atualiza os parâmetros alterados


Agora você pode entrar no psql como usuário postgresql, executar scripts, etc:

- sudo -u postgres psql -d postgres




 

Minha Instalação do PostgreSQL 9.0

A minha instalação de postgresql 9.0 no Ubuntu Linux, que já está defasada em relação à nova versão de desenvolvimento (9.1 - anúncio, download), eu fiz com base no link do sítio do Vinicius.

Utilizei estes comandos no terminal:
- sudo apt-get update  - atualização das listas de pacotes do apt-get
- sudo apt-get install postgresql-9.0 - instala o pacote do postgresql, versão 9.0
- sudo apt-get install pgadmin3 - instala o pgadmin
- sudo apt-get autoremove - removendo pacotes não mais necessários
- service postgresql status - teste se a instalação está funcionando. A resposta foi: "Running clusters: 9.0/main". O servidor está no ar!

Agora é executar, estudar e fazer testes!

Claro que existem dezenas de sítios com tutoriais e boas dicas sobre como fazer a instalação, e este post não visa aprofundar o tema. Mas é sempre bom lembrar: que versão está na sua máquina?