Planeta PostgreSQL-BR

Depois de muito pesquisar e testar algumas soluções finalmente consegui ver funcionando replicação no PostgreSQL.

Aqui mostrarei a solução que fiz funcionar, que usa o Slony-I e o pgAdmin, com PostgreSQL-8.2, tanto no Windows quanto no Linux (Ubuntu 7.10).

De início tive como base este tutorial:
http://people.planetpostgresql.org/dpage/index.php?/archives/51-Setting-up-Slony-I-with-pgAdmin.html

também divulgado na lista internacional do PostgreSQL.

Esse tutorial destina-se ao WindowsXP. Testei e funcionou direitinho no Windows.

Acontece que ele se refere de vez em quando ao Linux o que me motivou a tentar a mesma solução no Linux (Ubuntu 7.10).

Pesquisei outros tutoriais e um bom livro. Acabei por conseguir ver a replicação também no Linux.

Veja um PDF com os passos aqui:

http://postgresql.ribafs.net/slonywl

A última palestra que participei foi a do Diogo Biazus sobre replicação assincrona multi-mestre, expondo de maneira clara, profissional e bem-humorada, sua experiência com Bucardo

Apesar das limitações do Bucardo, na sua versão atual, para a sua proposta ele trabalha muito bem, e tem um futuro promissor. Já andei olhando seu código fonte, e fazendo alguns testes básicos e pretendo, seguindo as considerações expostas na palestra do Diogo, aplicá-lo em um ambiente com elevado número de transações por segundo e obviamente, os resultados serão postados aqui.

Em resumo, os contatos efetuados no FISL esse ano valeram a pena, bem como o elevado grau de informação, qualidade e profissionalismo dos palestrantes. Espero que o PgCon Brasil deste ano seja tão bom (ou melhor) quanto foram as palestras sobre o nosso elefantinho no FISL.

Bom é isso.

A Embrapa apresentou uma palestra sobre recuperação de informações em base de dados textuais, demonstrando sua experiência com o uso de ferramentas, tanto proprietárias quanto livres.
Ao iniciarem seus estudos com ferramentas livres várias alternativas foram utilizadas, inclusive o tsearch2 do nosso elefantinho foi testado, no entanto, para a necessidade deles de fazer indexação de textos, as alternativas eram mais complexas e exigiam o acoplamento de outras soluções mais especializadas.

Em uma visão geral da palestra foram apresentados os seguintes topicos.

Tecnicas de buscas textuais em banco de dados estudadas

Foram analisadas “Full Text Search” e “TSearch2″ (do nosso elefantinho), no entanto nenhuma delas satisfizeram as necessidades da Embrapa

Ferramentas de indexação textual

Foram analisadas SWISH-E, Lucene e OpenFTS, e delas a que mais se destacou foi a Lucene. principalmente pela compatibilidade com as linguagens de programação já utilizadas, que no caso seguiam a plataforma J2EE, e algo em PHP.

Resultados obtidos

O resultado pode ser visto no link: http://www.bdpa.cnptia.embrapa.br/busca.php e são bem expressivos em termos de tempo de resposta e sensibilidade ao contexto dos dados entrados.

Talvez esteja ai, uma extensão que nosso elefantinho posso começar a amadurecer, em minha singela opnião, acredito que um bom trabalho da comunidade poderia criar uma ferramenta que pudesse auxiliar nesse contexto, utilizando o PostgreSQL como servidor de aplicação.

Bom é isso..

O clima hoje não ajudou, aeroporto em POA fechado e acabei chegando atrasado ao FISL, perdendo assim a palestra do Fike. Imprevistos à parte, o clima esse ano no FISL está show de bola. A abertura dos estandes ao público e o ambiente universitário da PUCRS deram ao evento um clima bem descontraído e recheado de novidades.

Deu tempo de chegar para a palestra de Josh Berkus que foi bem interessante, as questões envolvendo segurança no PostgreSQL foram bem esplanadas. A diferença cultural não impediu que o publico participasse ativamente.

Logo em seguida, no mesmo auditório, David Fetter apresentou-nos sua palestra que exemplificou como utilizar o nosso Elefante como um Servidor de Aplicação. Dentre as inúmeras linguagens suportadas no PostgreSQL, ele focou seu exemplo em plperl/SQL frisando as questões de segurança, imutabilidade e clareza de código. Logo no início um pequeno trecho do Tropa de Elite que demonstra, segundo David Fetter, a maneira pela qual certamente não é a experiência que se tem ao se desenvolver algo utilizando PostgreSQL como um servidor de aplicações.

Acabei perdendo a palestra do Telles por problemas particulares, mas ouvi ótimos comentários.

Em tempo, o estande do elefantinho está show de bola, vale a pena conferir..

Bom é isso… as fotos vem em breve assim que eu baixá-las…

E amanhã começa o FISL 9.0, as expectativas são grandes, as palestras bem interessantes, e esse ano teremos uma participação forte do nosso amigo elefante (leia-se PostgreSQL).

Acabei montando minnha agenda no google calendar e publicando-a aqui. Todas as palestras do elefantinho estão lá bem como outras que tenho interesse, monte a sua também, imprime-a e leve com você no FISL, esteja preparado pois eventuais mudanças de horário ocorrem e não esqueça de visitar nosso estande.

No decorrer do evento irei postar aqui no blog informações e imagens para os colegas que não puderem comparecer de alguma forma ou de outra ao evento.

E para ajudar o povo que está indo para lá alguns links:

Mapa de localização do evento

Mapa de localização do estande do PostgreSQL (indicador azul)

Palestras sobre PostgreSQL e Banco de dados

Minha agenda do FISL 9.0 com as palestras do PostgreSQL e outras

Quadro de palestras do FISL 9.0

Bom, é isso! Nos vemos por lá… ”

Josh Berkus, que faz parte da equipe Core do PostgreSQL desde 2002, falará sobre as principais características da nova versão 8.3, lançada no último mês de fevereiro. Entre as novas features que fazem parte do PostgreSQL 8.3 estão: suporte a XML, log em CSV (Comma Separated Values), Tsearch integrado, melhor monitoramento e HOT (Heap Only Tuples).

Para maiores informações acesse o site:
www.4linux.com.br

-Leo

Caros, hoje pretendo ser o mais breve possível apresentando uma dica rápida. Pois bem, apesar de existirem algumas ferramentas gráficas como o Aqua Studio, DbVisualizer e o próprio pgAdminIII, o meu fiel companheiro de todos os dias acaba sendo o bom e velho psql. Leve, simples e bastante completo ele me proporciona agilidade em muitas das minhas tarefas diárias.

Nessas últimas versões ele vem recebendo algumas características novas. Uma delas que podemos esperar para a versão 8.4, por exemplo, é uma melhoria do comando “\l+” que, nessa versão, mostra também os tamanhos que os bancos de dados ocupam:

analise=# \l+
                                                               List of databases
   Name    |   Owner   | Encoding |                    Access Privileges                     |  Size   | Tablespace |        Description
-----------+-----------+----------+----------------------------------------------------------+---------+------------+---------------------------
 analise    | postgres  | UTF8     | {sademo=CTc/postgres,postgres=CTc/postgres,=Tc/postgres} | 151 MB  | pg_default |
 bench     | postgres  | UTF8     |                                                          | 710 MB  | pg_default |
 postgres  | postgres  | UTF8     |                                                          | 4215 kB | pg_default |
 livraria   | sasebo    | UTF8     |                                                          | 4136 kB | pg_default |
 template0 | postgres  | UTF8     | {=c/postgres,postgres=CTc/postgres}                      | 4136 kB | pg_default |
 template1 | postgres  | UTF8     | {postgres=CTc/postgres,=c/postgres}                      | 4136 kB | pg_default | default template database

No entanto, para o comando “\d+”, não foi implementada a mesma idéia, ou seja, ele não lista o tamanho dos objetos (visões, tabelas, sequências, indices) e por isso eu acabei criando o patch abaixo que, uma vez aplicado na versão última versão do PostgreSQL no CVS, habilita essa característica no psql:

Index: describe.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.166
diff -c -r1.166 describe.c
*** describe.c	30 Mar 2008 18:10:20 -0000	1.166
--- describe.c	11 Apr 2008 04:59:56 -0000
***************
*** 1766,1775 ****
--- 1766,1781 ----
  						  gettext_noop("Table"));

  	if (verbose)
+ 	{
  		appendPQExpBuffer(&buf,
  			  ",\n  pg_catalog.obj_description(c.oid, 'pg_class') as \"%s\"",
  						  gettext_noop("Description"));

+ 		appendPQExpBuffer(&buf,
+ 			  ",\n  pg_catalog.pg_size_pretty(pg_catalog.pg_relation_size(c.oid)) as \"%s\"",
+ 					  	  gettext_noop("Size"));
+ 	}
+
  	appendPQExpBuffer(&buf,
  					  "\nFROM pg_catalog.pg_class c"
  					"\n     JOIN pg_catalog.pg_roles r ON r.oid = c.relowner"
***************
*** 1809,1816 ****
  	processSQLNamePattern(pset.db, &buf, pattern, true, false,
  						  "n.nspname", "c.relname", NULL,
  						  "pg_catalog.pg_table_is_visible(c.oid)");
!
! 	appendPQExpBuffer(&buf, "ORDER BY 1,2;");

  	res = PSQLexec(buf.data, false);
  	termPQExpBuffer(&buf);
--- 1815,1825 ----
  	processSQLNamePattern(pset.db, &buf, pattern, true, false,
  						  "n.nspname", "c.relname", NULL,
  						  "pg_catalog.pg_table_is_visible(c.oid)");
!
! 	if (verbose)
! 		appendPQExpBuffer(&buf, "ORDER BY 1, pg_catalog.pg_relation_size(c.oid) DESC, 2;");
! 	else
! 		appendPQExpBuffer(&buf, "ORDER BY 1,2;");

  	res = PSQLexec(buf.data, false);
  	termPQExpBuffer(&buf);

O que eu faço é mostrar uma coluna a mais (”Size”), e ordenar a saída por Esquema, Tamanho (decrescente) e Nome do objeto. A saída fica algo assim:

analise=# \d+
                                      List of relations
 Schema  |                Name                | Type  |   Owner    | Description |    Size
---------+------------------------------------+-------+------------+-------------+------------
 teste   | tb_cliente                         | table | sa_analiseq   | Cliente     | 8192 bytes
 teste   | tb_compra                          | table | sa_analise   | Compra      | 8192 bytes
 teste   | tb_item_compra                     | table | sa_analise   | ItemCompra  | 8192 bytes
 teste   | tb_produto                         | table | sa_analise   | Produto     | 8192 bytes
 financ | tb_caixa                           | table | sa_analise   | Caixa       | 517 MB
 financ | tb_banco                           | table | sa_analise   | Banco       | 80 MB
 generic | tb_cliente                         | table | sa_analise | Cliente     | 250 MB
 generic | tb_pessoa                          | table | sa_analise   | Pessoa      | 140 MB

Bom, é isso! ”

Maiores informações clique aqui.

É antigo, mas somente pra descontrair:

http://www.dbdebunk.com/page/page/1477865.htm

A semana foi corrida, e o final de semana foi totalmente utilizado para descanso e lazer. Mas a vontade de escrever é maior, e cá estou novamente pronto para mais um post. A idéia hoje era falar sobre scripts SQL, então imaginei algo diferente, e pensei em mostrar como fazer um script interativo no PostgreSQL 8.3, associando o seu uso a um cenário hipotético. Vejamos…

Em um universo ideal, é muito comum existir um banco de dados de desenvolvimento, um de testes, um de homologação e um de produção. Neste cenário, imagine que seu Analista de Testes precise testar uma nova funcionalidade do sistema relacionada ao módulo de compras, e que para isso constantemente você tenha que aplicar a carga de testes desse módulo no banco de dados de teste, não é de se estranhar que você possua uma carga pronta (é o mínimo que você deveria ter).

Veja a seguir o script simplificado que representa esse cenário:

CREATE TABLE tb_cliente (
     nr_documento numeric(14,0) NOT NULL,
     nm_cliente character varying(60)
);
ALTER TABLE blog.tb_cliente OWNER TO postgres;

CREATE TABLE tb_compra (
     nr_nota_fiscal numeric(15,0) NOT NULL,
     dt_compra date,
     nr_documento_cliente numeric(14,0)
);
ALTER TABLE blog.tb_compra OWNER TO postgres;

CREATE TABLE tb_item_compra (
     nr_nota_fiscal numeric(15,0) NOT NULL,
     nr_referencia integer NOT NULL,
     qt_item smallint DEFAULT 1
);
ALTER TABLE blog.tb_item_compra OWNER TO postgres;

CREATE TABLE tb_produto (
     nr_referencia integer NOT NULL,
     ds_produto character varying(60) NOT NULL,
     vl_venda numeric(15,2)
);
ALTER TABLE blog.tb_produto OWNER TO postgres;

CREATE SEQUENCE tb_produto_nr_referencia_seq
     INCREMENT BY 1
     NO MAXVALUE
     NO MINVALUE
     CACHE 1;
ALTER TABLE blog.tb_produto_nr_referencia_seq OWNER TO postgres;

ALTER SEQUENCE tb_produto_nr_referencia_seq OWNED BY tb_produto.nr_referencia
ALTER TABLE tb_produto ALTER COLUMN nr_referencia SET DEFAULT nextval('tb_produto_nr_referencia_seq'::regclass);

ALTER TABLE ONLY tb_compra
     ADD CONSTRAINT pk_compra PRIMARY KEY (nr_nota_fiscal);
ALTER TABLE ONLY tb_item_compra
     ADD CONSTRAINT pk_item_compra PRIMARY KEY (nr_nota_fiscal, nr_referencia);
ALTER TABLE ONLY tb_cliente
     ADD CONSTRAINT pk_pessoa PRIMARY KEY (nr_documento);
ALTER TABLE ONLY tb_produt
     ADD CONSTRAINT pk_produto PRIMARY KEY (nr_referencia);

ALTER TABLE ONLY tb_compra
     ADD CONSTRAINT fk_cliente_compra_01 FOREIGN KEY (nr_documento_cliente) REFERENCES tb_cliente(nr_documento);
ALTER TABLE ONLY tb_item_compra
     ADD CONSTRAINT fk_compra_item_compra_01 FOREIGN KEY (nr_nota_fiscal) REFERENCES tb_compra(nr_nota_fiscal);
ALTER TABLE ONLY tb_item_compr
     ADD CONSTRAINT fk_produto_item_compra_01 FOREIGN KEY (nr_referencia) REFERENCES tb_produto(nr_referencia);

Esse é o conteúdo simplificado da entidade cliente no banco de dados de teste:

 nr_documento |        nm_cliente
--------------+---------------------------
74727756632 | Marta Antonia
56548986527 | Antonia Josefina
47040567970 | Adamantina Pereira
24348435149 | Carlos Augusto
80987468692 | José Silveira
56096344407 | Maria Eleontina de Castro
79056669606 | José da Silva Sauro
31887461081 | Ribamar de Castr
45792555043 | Manoel Bandeira

Esse é o conteudo simplificado da entidade produto no banco de dados de teste:

 nr_referencia |    ds_produto     | vl_venda
---------------+-------------------+----------
1 | Sapato Velho      |    15.00
2 | Sapato Novo       |    25.00
3 | Blusa Velha       |    35.00
4 | Blusa Nova        |    45.00
5 | Calça Jeans Velha |    29.50
6 | Calça Jeans Nova  |    49.50
7 | Peruca Masculina  |   439.9
8 | Camisola          |    19.50

E este é o Script de Carga de Teste para as entidades tb_compra e tb_item_compra:

postgres@banco $ cat ~/scripts/carga_compra_teste.sql
/***************************************************
*
* Script de geração de carga
* Modulo de Compras - Banco de dados de Teste
*
* (c) 2007 Dickson Guedes <guediz at gmail dot com>
*
****************************************************/

INSERT INTO tb_compra (nr_nota_fiscal, dt_compra, nr_documento_cliente
     VALUES (1234567890, now(), 56473847366);

INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1234567890, 6,  2);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1234567890, 4,  1);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1234567890, 3, 15);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item
     VALUES (1234567890, 2,  2);

INSERT INTO tb_compra (nr_nota_fiscal, dt_compra, nr_documento_cliente
     VALUES (1122334455, now(), 56096344407);

INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1122334455, 6,  2);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1122334455, 4,  1);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item)
     VALUES (1122334455, 3, 15);
INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item
     VALUES (1122334455, 2,  2);

E para executá-lo e utilizo o utilitário psql:

postgresql@banco $ psql bdtesteWelcome to psql 8.4devel, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
     \h for help with SQL commands
     \? for help with psql commands
     \g or terminate with semicolon to execute quer
     \q to quit

postgres=# \i ~/scripts/carga_compra_teste.sql

E se eu quisesse tornar esse script interativo?

O utilitário psql além de aceitar instruções SQL, possui um conjunto de instrucoes proprias que nos permitem extenter suas funcionalidades. Utilizaremos duas delas: \echo, que permite enviar um texto para a console do psql e \prompt (a partir da versão 8.3 do PostgreSQL) que permite receber um dado da entrada e salvar um uma variável.

Nosso script acima poderia ficar assim:

/***************************************************
*
* Script de geração de carga
* Modulo de Compras - Banco de dados de Teste
*
* (c) 2007 Dickson Guedes <guediz at gmail dot com>
*
****************************************************/

\echo """"""""""""""""""""""""""""""""""""""""""
\echo " Gerando carga para o ambiente: TESTE   "
\echo "                                        "
\echo " Cenário: Prestacoes de compra a prazo  "
\echo "                                        "
\echo """"""""""""""""""""""""""""""""""""""""""
\echo
\echo Continuar..: Enter
\echo Cancelar...: Ctrl+C

\prompt continua
\unset continuar

\echo
SELECT nr_documento || ' -> ' || nm_cliente AS "Lista de Clientes" FROM tb_cliente;
\echo
\prompt 'Informe um dos números de CPFs acima.: ' v_nr_document
\prompt 'Informe o número da nota fiscal......: ' v_nr_nota_fiscal

\echo '* Inserindo compra para o cliente:' :v_nr_documento 'com número de nota fiscal:' :v_nr_nota_fiscal

INSERT INTO tb_compra (nr_nota_fiscal, dt_compra, nr_documento_cliente) VALUE
     (:v_nr_nota_fiscal, now(), :v_nr_documento);

INSERT INTO tb_item_compra (nr_nota_fiscal, nr_referencia, qt_item) VALUES
     (:v_nr_nota_fiscal, 2, ((RANDOM()*5)+1)::int2),
     (:v_nr_nota_fiscal, 4, ((RANDOM()*5)+1)::int2),
     (:v_nr_nota_fiscal, 7, ((RANDOM()*5)+1)::int2),
     (:v_nr_nota_fiscal, 5, ((RANDOM()*5)+1)::int2);

\echo "* Script finalizado!"

E para executá-lo e utilizo também o utilitário psql:

postgresql@banco $ psql bdtesteWelcome to psql 8.4devel, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute quer
\q to quit

postgres=# \i ~/scripts/carga_compra_teste.sql

DICA 1: quando usar o \prompt você pode usar 2 (dois) argumentos: um texto explicativo seguido do nome da variável que você deseja armazenar o valor recebido.
DICA 2: os valores das variáveis são recuperados utilizando-se o dois pontos (”:”) precedendo o nome da variável que se deseja ler o valor, como por exemplo \echo ‘Valor da variavel é’ :variavel_qualquer.

DESAFIO 1: Tente alterar o script acima para que os produtos também sejam aleatórios, ou seja, cada vez que o script for executado ele gere uma carga diferente.

DESAFIO 2: Como você trataria o problema de um erro de digitação ou problema de violação de chaves? Você poderia utilizar transações?

Em um ambiente corporativo com aplicações de missão crítica, qualquer instante de instabilidade pode causar um grande prejuízo para seu cliente, e conseqüentemente para sua empresa. Neste universo, onde todas as camadas de infra-estrutura que dão suporte ao funcionamento de suas aplicações precisam estar altamente-disponíveis, faz-se necessário tomar medidas preventivas a fim de identificar, pro-ativamente, qualquer incidente que pode acarretar em um grande problema.

Neste cenário, o papel do DBA é muito importante, pois ele pode identificar, já na camada de Banco de Dados, possíveis candidatos a problemas futuros. No entanto, ele precisa de ferramentas de apoio para tal tarefa, a fim de tornar seu trabalho produtivo e pró-ativo e não reativo, como em muitas empresas.

Sendo assim, gostaria de falar hoje sobre o nosso amigo ptop, que é uma espécie de ‘top’ para o PostgreSQL. Inspirado no top dos sistemas UNIX-like, ele permite:

• Visualizar a instrução SQL sendo executada por um processo;
• Visualizar o plano de execução de um SELECT rodando no momento;
• Visualizar os locks de um determinado processo;
• Visualizar as estatísticas das tabelas de usuário;
• Visualizar as estatísticas dos índices de usuário;

Obtendo e Instalando

A última versão estável do ptop é a 3.6.1 mas já existem versões beta disponíveis que podem ser baixadas e testadas. No nosso caso utilizaremos a última versão estável, fazendo o download e salvando em um diretório temporário, como por exemplo: /tmp.

Vamos supor que você deseja monitorar via ptop um ambiente de desenvolvimento com as seguintes características:

Nome do bando de dados: desenvolvimento
Porta: 5432
Usuário: monitor
Senha: m0n1t0r

(Para esse exemplo foi criado um usuário monitor no PostgreSQL, sem qualquer privilégio a mais, apenas de conexão ao banco)

Salve o arquivo baixado no servidor que deseja monitorar e siga os passos:

# Descompacte o arquivo ...
tar zxvf ptop-3.6.1.tar.gz

# Acesse o diretorio criado
cd ptop-3.6.1/

# Leia os arquivos README e INSTALL
# (sim eles não têm esses nomes à toa… ”  )
less README
less INSTALL

# Configure e compile o codigo
./configure && make

# Após compilar um arquivo executável sera criado
ls -la ptop
-rwxr-xr-x 1 guedes guedes 140282 2008-04-01 20:48 ptop

# Execute-o com a opção –help
./ptop –help
./ptop: invalid option — -
Top version 3.6.1
Usage: ptop [-ISTWbcinqu] [-x x] [-s x] [-o field] [-z username]
              [-p PORT] [-U USER] [-d DBNAME] [-h HOSTNAME] [number]

Visão geral do ptop

Para executar o ptop use:

./ptop -U monitor -d desenvolvimento -h localhost -W

Será solicitada a senha do usuário ‘monitor‘, informe-a corretamente. A tela que surge é semelhante a esta:

Com o ptop sendo executado, é possível ver uma série de informações úteis sobre o servidor e os processos do PostgreSQL. A semelhança do mesmo com o utilitário top do UNIX é visível e não é mera coincidência…

Principais comandos do ptop e suas telas

Obtendo ajuda no ptop: pressione ‘?’ ou ‘h’

Obtendo o plano de execução de um processo: pressione ‘E’ (maiúsculo) e digite o número de um determinado processo (PID) para visualizar o plano de execução do mesmo.

Obtendo as estatísticas das tabelas em uso: pressione ‘R’ (maiúsculo)

Obtendo as estatísticas dos índices em uso: pressione ‘X’ (maiúsculo)

Visualizando os locks de um determinado processo: pressione ‘L’ (maiúsculo) e digite o número do processo (PID) que deseja visualizar

DESAFIO 1: tente alterar a ordem de classificação dos processos (por cpu, tempo de execução ou utilização de recursos, por exemplo).
DESAFIO 2: tente alterar o número de processos a serem mostrados.

Bom, é isso! ”

Mini Tutorial sobre a Ferramenta PostgreSQL Autodoc

O autodoc é um utilitário que roda para tabelas do PostgreSQL e retorna documentos HTML, Dot, Dia e DocBook XML com a descrição e diagramas das tabelas. Existe integração com o DIA (http://www.gnome.org/projects/dia/) e com o GraphViz (http://www.research.att.com/sw/tools/graphviz/).

Autodoc site oficial - http://www.rbt.ca/autodoc/

Instalar

Para quem tem Linux Ubuntu basta atualizar seus repositórios e no terminal executar:

sudo apt-get install postgresql-autodoc

Aproveitar e instalar também o DIA para visualizar os diagramas:

sudo apt-get install dia

Instalar também o GraphViz:

sudo apt-get install graphviz

Para Executar

Acesse um terminal e faça login como usuário do PostgreSQL

su - postgres

postgres@cmiin07 postgresql_autodoc –help

Exemplo:

Com este exemplo estou gerando diagramas e DDLs de um esquema (comercial) do banco dba_projeto2.

postgres@cmiin07 postgresql_autodoc -u postgres -d dba_projeto2 -s comercial -p 5433 –password=postgres

Ele gerará um arquivo em HTML contendo a estrutura dos objetos do esquema, gerará um arquivo do diagrama para o DIA, um XML e vários outros.

Agora um exemplo abrangento todo o banco, que contém dois esquemas:

postgres@cmiin07 postgresql_autodoc -u postgres -d dba_projeto2 -p 5433 –password=postgres

Agora transformando o .dot em png:

postgres@cmiin07 dot -Tpng -o dba_projeto2.png dba_projeto2.dot

Com este comando gerará uma imagem oriunda do .dot.

Veja o arquivo anexo contendo uma amostra do exemplo citado.

Pelo visto existem muito mais recursos nesta ferramenta. O form para comentários pode enriquecer as informações aqui contidas.

A ferramenta de análise de logs pgfouine é sem dúvida nenhuma uma ferramenta indispensável para qualquer DBA no quesito de análise de logs.

Confesso que fui utilizador assíduo do PQA (antecessor falecido do pgfouine) e quando conheci o pgfouine foi amor à primeira vista e acabei largando um pouco o ruby em troca de um php bem escrito ;-).

Deixarei um pouco a paixão de lado pra falar de uma funcionalidade caracterizada como deficiente no pgfouine, IMHO.

A questão é que para funcionamento correto, o pgfouine exige um formato padrão da variável de configuração log_line_prefix (’%t [%p]: [%l-1]), e diga-se de passagem é bem conciso, mas muitas vezes não aceitável.

Quem já precisou alterar uma variável de um servidor que não pode ser reiniciado vai entender de que estou falando; ou pior ainda, quem precisa manter um formato consistente com normas internas porque existe uma política na empresa para arquivamento de logs também vai perceber.

Então, antes que tudo se desabe e voce no 5o. andar de seu prédio saia de maneira inconsolável de sua mesa em direção a janela mais próxima, eis que surgem as expressões regulares. Sim, sim elas!
Basta entender a forma como o parser do pgfouine trabalha para alterar nada mais de que (com sorte) uma única linha do núcleo desta ferramenta.

Deixemos de enrolação e vamos realmente ao que interessa:

O programa pgfouine.php inicializa o percurso que os trechos de log deverão seguir até o parser. Esta parte do fluxo tem por objetivo fazer algumas validações e configurações iniciais (informações de banco, opções escolhidas, &ca) e por fim carregar a classe GenericLogReader que baseada nas opções do usuário invoca o acumulador (Acummulator) de logs específico. A função do acumulador é avaliar o eventType de listener e armazenar o resultado em um stream para análise futura pelo parser mais adequado. Basicamente existem duas classes (tipos) maiores de eventType: uma de erro e outra de instruções SQL. Os detalhes sobre os event listeners podem ser localizados em $PGFHOME/include/listeners. A próxima etapa (e a que mais nos interessa), é a fase de parser os logs.
O pgfouine ainda não foi internacionalizado (i18n) portanto pode ser necessário alterar as expressões regulares em $PGFHOME/include/postgresql/PostgreSQLRegexps.lib.php. Basta ver qual o formato de seu arquivo de log e literalmente substituir as strings desse arquivo pelas correspondentes nos logs. Agora os arquivos responsáveis por gerar a informação que o pgfouine “confia” para criação dos gráficos, estatísticas e demais recursos visualizados no produto final, são os arquivos StderrPostgreSQLParser.class.php e SyslogPostgreSQLParser.class.php localizados em $PGFHOME/include/postgresql/parsers e estão na última etapa do percurso da conversão log -> documento. As classes StderrPostgreSQLParser e
SyslogPostgreSQLParser fazem a análise de stderr e syslog respectivamente como é óbviamente notado. Ambas possuem em seus construtores uma propriedade inicializando um objeto do tipo RegExp que é o assunto principal desse post e deve ser alterado para “casar” com o formato de seu log_line_prefix. Em nosso caso estava bem simples e foi apenas alterar o caracter especial de início de linha para “casar” com o formato do log, mas conhecendo um pouquinho de expressões regulares voce será capaz de combinar qualquer formato da linha de seus logs com o pgfouine sem a alteração da variável de configuração log_line_prefix e sem reiniciar o servidor de banco de dados.

-Leo

Depois de muito trabalho, finalmente o Planeta PostgreSQL foi migrado para um novo banco. Os dados, que antes se encontravam em DB2, agora estão rodando perfeitamente em SQLite hospedado em servidores gentilmente cedidos a nós pela Sony, Tokyo, Japão.

Para que você saiba, passo a passo, como tudo foi feito, disponibilizamos o artigo neste link. Bem como informações de infra-estrutura aqui neste outro.

Criando Novos Clusters no PostgreSQL para Windows

Para criar um novo cluster:
Crie um diretório para abrigar o novo cluster (lembre que o usuário postgres deve ter permissão de escrita nele).
- Ex.: data2 no diretório bin.

Criar o novo cluster (acesse o terminal no diretório C:\Program Files\PostgreSQL\8.3\bin) e execute:
- C:\Program Files\PostgreSQL\8.3\bin>initdb -U postgres -D data2

Editar o data2\postgresql.conf e alterar a porta para 5444

Iniciar o servidor do novo cluster
- pg_ctl -D data2 start

Acessar a console (psql) do novo cluster
- psql -p 5444 -U postgres

Listar os bancos
- \l — Observe que somente existem os bancos de templates. Temos um novo cluster.

Obs.: No Windows não consegui dar suporte a latin1 em novos clustes nem o original suporta.
Isso só foi conseguido em novos clusters no Linux.

Tecle Ctrl+Alt+Del no Windows ou ‘ps ax|grep post’ no Linux e veja que agora temos dois pg_ctl na memória.

———————————————————————
Criação de Novos Clusters no PostgreSQL 8.3 for Linux (Ubuntu 7.10):
———————————————————————

Criando os clusters

cluster em latin1

Criação do diretório para o cluster, data_latin1, tornando o usuário postgres seu dono:
mkdir data_latin1
su - postgres
export LANG=pt_BR.ISO-8859-1
bin/initdb –encoding latin1 -D data_latin1
Editar o script data_latin1/postgresql.conf e alterar a porta para 5433

Conectando no cluster em latin1

bin/pg_ctl -D data_latin1 start
bin/psql -U postgres postgres -p 5433
\l — Veja que a codificação de todos os bancos é a latin1.

create database testeutf8 with encoding ‘utf8′;

Obs.: Cluster em latin1 com suporte a UTF-8.

cluster em utf-8

su - postgres
bin/initdb -D data_utf8

Como utf8 o default no Ubuntu, não preciso passar parãmetro.
Editar o script data_utf8/postgresql.conf e alterar a porta para 5434

Conectando no cluster utf-8

bin/pg_ctl -D data_utf8 start
bin/psql -U postgres postgres -p 5434

Bem, a saída para quem quer usar o 8.3.x e precisa de latin, no Linux, é esta (dica que recebi na lista de PostgreSQL pgbr-geral, do Euler).

Pessoal,

Conforme prometido no último pgcon e com apoio financeiro da BEA Systems, é com orgulho que envio o patch que tem como objetivo retirar o autovaccum do backend.

A principal idéia responsável por esse avanço foi a criação de uma ferramenta chamada autoclean.

O componente autoclean atua como um processo filho de postmaster e toda vez que uma página é alterada, o autoclean detecta quais páginas estão disponíveis para armazenar e em seguida mover para áreas disponíveis em VacPageData. Para isso free_space_pages deve estar configurado corretamente.

Outra função do autoclean é detectar páginas sujas e enviá-las para uma área reservada de reciclagem (C:\Meu Computador\Desktop\Lixeira) aliviando a carga do background writer.

Existe ainda a possibilidade de uma página, já reciclada, estar “parcialmente” suja e o autoclean avaliar de acordo com heurísticas uma chamada para a rotina void AutoCleanDirtyClothes(Page *page) que irá causar uma limpeza total daquela página e coloca-la em VacPageListData.

TransactionId wraparound

Com a implementação do autoclean foi criado também um novo tipo para a variável TransactionId para suprir a necessidade de “zerar” o contador de transações, o uint128, um novo tipo com suporte para 128 bits (o segredo aqui foi a geração de um algoritmo de ponto flutuante para suporte ao tipo em servidores de 32 e 64 bits). Dessa forma XID agora foi tipado com uint128.

Outra novidade é que transações já nascem marcadas como XID=2 (Frozen), então o MVCC não precisa mais “adivinhar” qual é a transação mais recente e … Espera aí!! Mas então porque precisamos tipar XID com 128 bits uma vez que usa apenas 1 ??? Hmm, hora de volta à prancheta …

Gente, quanta besteira!!!

Só pra não esquecer que hoje é 1º. de abril.

Abraço!

-Leo

Um dos fatores fundamentais que movimenta o universo do software livre é justamente a grande quantidade de usuários que estão prontos (e qualificados) para ajudá-lo desde as dúvidas mais simples, até as mais “cabeludas”. Pois bem, nesses mesmo barco, onde todos estamos remando, existe um “pacto”, não chega a ser uma ordem ou lei, mas sim um pré-requisito básico, que todo aquele que quer entrar nesse universo deveria se certificar de checar, um ação simples: antes de perguntar, pesquise!

Sim, é muito comum ver perguntas recorrentes na lista pgbr-geral em que muitos de seus questionadores não se deram o luxo de, no mínimo, dar uma googlada. Conclusão? Muitas vezes eles acabam saindo frustrados com uma resposta default: “Veja o histórico da lista.”

Já outros possuem espírito aventureiro, questionam-se noite e dia, procuram, encontram, testam, erram, procuram, encontram, testam, acertam … e nesse ciclo rumo ao conhecimento, algumas perguntas surgem, duvidas pelas quais alguns de nos passamos também, cujas respostas não encontramos em uma ferramenta de busca, mas sim nas entrelinhas do conhecimento alheio. E nesse caso, onde buscar então? É ruim perguntar na lista? Não! É perfeito! As respostas mais básicas estão la no histórico da lista… algumas complexas também… e você percebe a diferença entre elas pelo número de threads que um tópico mais complexo pode gerar. Veja como exemplo quantos tópicos sobre Codificação de caracteres já surgiram esse mês.

Em resumo, antes de perguntar leia o site oficial do PostgreSQL, ou o site brasileiro, veja o histórico de nossas listas, procure no Planeta PostgreSQL pesquise no Google. Ainda assim você tem dúvidas cujas respostas dependem da opinião e experiência de outros colegas? Perfeito, pergunte na lista ou procure-nos no IRC. Sim, no IRC… lembra? Lá a resposta pode ser mais rápida, ou a disc