Planeta PostgreSQL-BR

Palestras sobre PostgreSQL no Serpro: 24/07

2008-07-22T15:12:03+00:00

Vou estar no dia 24/07 no Serpro em Brasília para duas palestras técnicas sobre PostgreSQL falando sobre Alta-Disponibilidade e Tuning.

Grade preliminar da PGCon Brasil 2008

2008-07-22T08:59:18+00:00

Foi publico neste fim de semana a grade preliminar da PGCon Brasil 2008 e eu serei um dos paletrantes para falar um pouco Skytools, PL/Proxy e PgBouncer.

Palestras sobre PostgreSQL no Serpro: 24/07

2008-07-22T01:42:44+00:00

Vou estar no dia 24/07 no Serpro em Brasília para duas palestras técnicas sobre PostgreSQL falando sobre Alta-Disponibilidade e Tuning.

ribafs

2008-07-10T14:55:09+00:00

Estou iniciando uma coleção de modelos free, que oferecem os diagramas e também os scripts de alguns bancos de dados comuns. Pois ao efetuar uma boa busca na Internet não consegui encontrar algo parecido. Encontrei um ótimo site, com bons diagramas (http://www.databaseanswers.org/data_models/index.htm)
e agora estou com a intenção de gerar os scripts para alguns diagramas e em especial com foco em detalhes da nossa realidade brasileira.

Já elaborei modelos de dois bancos:
controle de estoque e vídeo locadora,
com os diagramas e respectivos scripts. Os scripts foram testados no PostgreSQL mas devem rodar em qualquer SGBD, já que usam apenas SQL padrão.

Na lista de PostgreSQL (pgbr-geral) estamos discutindo sobre os mesmos no intuito de melhorá-los. Traga sua sugestão e outros modelos que queira compartilhar. Deixe comentários na seção projetos do site:
http://pg.ribafs.net/content/view/15/34/

Torne-se um colaborador enviando artigos para o site: http://pg.ribafs.net (basta entrar em contato).

Participe da lista de discussão do PostgreSQL:
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Elaborar um projeto, por pequeno que seja, mesmo riscando algo no papel antes de começar de fato é algo que ajuda muito quando se cria um aplicativo, quando se cria um banco de dados e mesmo em muitas outras áreas.

A modelagem de bancos de dados é uma etapa que evita retrabalho na criação de bancos de dados e juntamente com outros conhecimentos da teoria dos bancos de dados, normalização, integridade referencial e outros ajuda a criar bancos robustos.

Controle de Estoque:
http://pg.ribafs.net/down/projeto//modelos_free/controle_estoque.jpg
http://pg.ribafs.net/down/projeto//modelos_free/controle_estoque.sql

Vídeo Locadora:
http://pg.ribafs.net/down/projeto//modelos_free/video_locadora.jpg
http://pg.ribafs.net/down/projeto//modelos_free/video_locadora.sql

PostgreSQL: Presença Fraca no Youtube

2008-07-09T09:13:29+00:00

A presença do PostgreSQL entre os grandes SGBDs pode ser medida de diversas formas. Em busca de vídeos interessantes de PostgreSQL, fiz uma busca no Youtube, e me decepcionei. Encontrei apenas 356 vídeos. É muito pouco para cobrir todas as funcionalidades e possibilidades deste banco de dados.

Considerando-se que este resultado envolve todos os idiomas, os resultados são ainda mais fracos, pois temos muito pouca coisa em Português. A qualidade da imagem também deixa a desejar, possivelmente pelo formato do Youtube, que reduz a resolução e prejudica apresentações que capturam telas do computador e as filmagens de apresentações em telões multimídia. Faltam comentários nos vídeos, a visualização ainda é pequena por parte da comunidade e muitos permanecem sem avaliação (o Youtube tem uma graduação que vai até 5 estrelas). Vi bons vídeos em italiano, mas acho que a estrada a ser trilhada pelo PostgreSQL em vídeo ainda está no seu início.

Para ter uma visão comparativa, fiz outras buscas para outros SGBDs. Entre os bancos de dados livres, apesar do PostgreSQL só estar atrás do MySQL, não se pode dizer que é uma boa colocação. A abrangência, quantidade e qualidade dos vídeos pode melhorar muito. O próprio campeão MySQL teve muito mais resultados encontrados, mas bem abaixo do que poderia ser. O fato é que ainda não utilizamos vídeos como forma de aprendizado e divulgação de conhecimento como poderíamos.

Mesmo os Bancos de Dados proprietários apresentam poucas opções, mas o SQL Server teve quase o dobro de vídeos que o PostgreSQL. O Oracle também decepcionou e pode ser alcançado pelo PostgreSQL com algum trabalho da comuindade.

O ranking total aparece abaixo. Faltam alguns SGBDs, mas o propósito não era uma busca exaustiva. A grande surpresa foi o DB2, com a terceira colocação. Os bancos de dados livres lideram com o MySQL e o PostgreSQL ocupa apenas uma posição intermediária, com o quinto lugar.

1 - MySQL: 1330
2 - SQL Server: 674
3 - IBM DB2: 461
4 - Oracle (busca por "Oracle SQL"): 406
5 -PostgreSQL: 356
6 - Firebird (busca por "Firebird SQL"): 171
7 - ACCESS (busca por "ACCESS SQL"): 50
8 - SQLite: 22
9 - ADABAS: 5
10 - HSQLDB: 0

O que podemos fazer a respeito?

Bom, creio que podemos influir positivamente quanto a esta questão:

- Assistir a vídeos de PostgreSQL no Youtube, dando feedback aos seus criadores, através de comentários e da colocação das estrelas, indicando os melhores. Esta ação permite que se possa estimular a produção de melhores vídeos e o reconhecimento dos autores.
- Postar novos fragmentos de palestras e de cursos com conteúdo novo e diversificados. Muitos eventos de Software Livre, de Banco de Dados em Geral e de PostgreSQL são gravados e poderia ser feita seleção e publicação de parte deste material.
- Produzir novos vídeos voltados para a internet. Podem ser pequenos, podem ser focados em temas específicos, indo do básico ao avançado. É a melhor forma de aprender a fazer mais e melhor.

Quem se habilita?

Este é um problema realmente grave?

Acredito que não, mas que é um ponto que pode ser melhor trabalhado pela comunidade do PostgreSQL.

Icedtea/OpeJDK e Pentaho

2008-07-08T22:33:39+00:00

Esses dias tenho tido bastante diversão já que a internet no trabalho tem algumas pequenas restrições. Na última semana precisa testar o Pentaho, como também precisava testar alguma versão da máquina virtual java que rodasse num Linux na plataforma SPARC.

Para uma linguagem multiplataforma que é possível facilmente olhar sua conta pela internet (internet banking) na plataforma AMD64 com Linux (meu caso Debian) nativamente e executar programas com Linux na plataforma SPARC. Ainda prefiro a velha e antiquada linguagem C. Isso é uma ironia, complemento de um nota antiga aqui no blog.

Depois de três brigando com o OpenJDK/IcedTea para compilar, consegui gerar os binários depois de 13 horas initerruptas. No SPARC não consegui fazer muito coisa mas no AMD64 em testes sem rigor científico, o tempo que demorou para a instância do JBoss 4.2 carregar com o Pentaho BI Plataform.

OpenJDK:
Tempo Médio: 56 segundos

Sun-Java6:
Tempo Médio: 59 segundos

Como o foco não era comparar as máquina virtuais java, somente fiz a média de carregar uma instância do JBoss com Pentaho. O equipamento é um Pentium Dual-Core, 2GB de RAM, Debian Lenny (AMD64), JBoss 4.2.2 e PostgreSQL 8.3.3. Gostaria de avançar mais nesse teste mas uma pequena falta de tempo me impede no momento.

ribafs

2008-07-08T14:40:27+00:00

O objetivo principal deste tutorial é mostrar como se cria gráficos (relatórios) bonitos diretamente de bancos do PostgreSQL ou de qualquer outro SGBD que gere arquivos de saída de suas consultas, como faz o psql. Apenas precisamos do SGBD e do software open-source GNUPlot.

O GNUPLOT é um aplicativo open source, destinado à construção de gráficos e superfícies. É uma poderosa ferramenta, usada por uma série de organizações por todo o mundo, como pode-se ver a partir dos links disponíveis na página oficial.

Veja o tutorial aqui:

http://pg.ribafs.net/down/docs/Tutoriais/Graficos/gnuplot_tutorial.pdf

Primeiros palestrantes do PGCon Brasil 2008 aprovados!!!

2008-07-04T15:12:04+00:00

A chamada de trabalhos para o PGCon Brasil 2008 foi realmente um sucesso. Foram quase 30 propostas de palestras. Coube a uma comissão de três pessoas a difícil tarefa de escolher algumas poucas palestras para o evento. Acredito que para o ano que vem, será factível termos duas salas simultâneas no evento.

Bom, vejamos aqui uma primeira versão da grade do evento:

26/09 - Sexta-feira

08:00 Credenciamento
09:00 Abertura (Fala de representantes da UNICAMP, Governo Federal, Comunidade PostgreSQL Brasileira, Conunidade PostgreSQL Internacional e Empresários).
09:50 Bruce Momjian - “PostgreSQL’s Path to the Future”
11:00 Intervalo
11:20 Palestra de patrocinador OURO (Dextra)
12:00 Almoço
14:00 Case / Palestrante Platina
14:50 — (a definir)
15:40 — (a definir)
16:30 Intervalo
16:50 Wagner Corrêa Ramos - “Projeto de replicação multi-master com 143 servidores”
17:40 Euler Taveira - “Monitorando o PostgreSQL”
18:30 David Fetter - “Trees in PostgreSQL”

27/09 - Sábado
09:00 Tutorial: Leandro Dutra - “O elefante aparelhado: ferramental e processo
de administração de dados em PostgresSQL”
11:00 Intervalo
11:20 Palestra de patrocinador OURO (OpenGEO)
12:00 Almoço
14:00 Lightning Talks (paineis de 5 minutos cada)
15:00 Eduardo Leal - “Utilizando o PostgreSQL em bancos de dados biológicos”
15:50 Fábio Telles - “PostgreSQL, o Elefante Encouraçado”
16:40 Intervalo
17:00 Dickson dos Santos Guedes - Replicação Síncrona - “Não existe
almoço de graça!”
17:50 Fernando Ike - “skytools, pgbouncer, plproxy”
18:40 Diogo Biazus - PostgreSQL Br - “Passado, Presente e Futuro”

Como vocês podem ver, temos ainda 2 vagas que estão sendo definidas pela comissão. Uma das vagas deverá ser de Geoprocessamento. Recebemos muitas propostas nesta área (5 ao todo) e estamos com dificuldades para escolher uma. Então, se a sua palestra não foi escolhida, aguarde mais um pouco. Você pode ser escolhido em breve.

Este ano ainda contaremos com duas novidades na programação:

Os Lightning Talks são uma novidade importada do PGCon internacional, por sugestão do Josh Berkus quando veio ao Brasil durante o IX FISL. A idéia é que as pessoas podem dar um “recado” no estilo painel contendo até alguns slides (acho que uns 2 ou 3, por exemplo). Assim, serão até 12 apresentações relâmpago. A idéia é fazer algo mais descontraído e dar a oportunidade para os 5 minutos de fama para os participantes do evento. Segundo o Fernando Ike, os Lightning Talks no PGCon em Otawa foram uma parte muito interessante do evento, acho que as pessoas vão gostar. A chamada de trabalhos para os Lightning Talks devem abrir às vésperas do evento e terminar no primeiro dia do evento. O Sr. Dickson Guedes será o organizador desta parte do evento e prometeu até levar um sino (sugestão do Josh) para tocar no final dos 5 minutos de cada um.
Haverá uma pequena sala (com com capacidade aproximada de 25 pessoas) onde se pretende dar algumas palestras destinadas a incentivar novos desenvolvedores do PostgreSQL. Serão poucas vagas e os tópicos abordados serão bem avançados. Então se você está com a intenção de se tornar um desenvolvedor do PostgreSQL, está na hora de desenferrujar o seu C e ficar de olho no que estamos por enquanto chamando de “hard talks”.

Bom, por enquanto é isso pessoal. Em breve estaremos atualizando o site do PGCon Brasil com a primeira versão oficial da grade. Lembre-se que o que apresentei aqui é apenas um rascunho da grade, sujeito a alterações sem aviso prévio.

O mínimo que você deveria aprender para se defender de ataques de injeção de SQL no PostgreSQL

2008-06-27T16:24:55+00:00

SQL Injection ou injeção de SQL é uma técnica de invasão de sistemas que se tornou famosa na Internet, mas pode ser utilizada em qualquer linguagem de programação. No entanto, na Internet temos uma combinação explosiva:

A aplicação está acessível para toda internet que possui milhares de usuários dispostos a quebrar seu sistema;
O uso de linguagens de script fracamente tipadas em conjunto com com tipos de dados fracamente tipados ajuda a abrir algumas brexas de segurança.
O protocolo HTTP tem peculiaridades que quando mal utilizadas podem tornar uma aplicação web mais vulnerável como o uso de parâmetros GET.

O exemplo clássico é o login de um usuário da aplicação. Você pede o nome e senha do usuário numa tela e depois envia um SQL com esta característica:

SELECT TRUE WHERE nome = 'telles' AND senha = 'abizi'

Na tela de login o usuário pode digitar no lugar da senha algo mais ou menos assim:

USUÁRIO: admin
SENHA: ‘ OR 1=1 –

Ao substituir as variáveis o seu SQL ficaria assim:

SELECT TRUE WHERE nome = 'admin' AND senha = '' OR 1=1 --'

Segurança contra o SQL Injection

Regra no mínimo privilégio

Veja que há uma série de problemas a serem analisados aqui. A primeira questão que qualquer sistema deve se preocupar em analisar é saber qual o potencial de destruição que o usuário vai ter se ele conseguir um ataque bem sucedido. Se o usuário que se conecta na aplicação é dono de objetos no banco de dados, como muitas aplicações gostam de fazer por uma questão de comodidade, você verá que o seu usuário terá permissões plenas sobre os seus objetos. Utilizando SQL Injection, ele poderá realizar operações como DROP, TRUNCATE, ALTER além do DELETE, INSERT, UPDATE e SELECT.

Então a primeira regra que deve SEMPRE ser seguida a risca é que:

“O USUÁRIO QUE A APLICAÇÃO UTILIZA PARA SE CONECTAR NO BANCO DE DADOS JAMAIS DEVE SER O DONO DOS OBJETOS CRIADOS NO BANCO DE DADOS”

Alguns artigos que tratam sobre SQL Injection ignoram solenemente esta recomendação. Alguns ficam desempregados inesperadamente. Então, precauções especiais devem ser tomadas em aplicações onde cada usuário da aplicação não tem seu próprio usuário criado no banco de dados - o que é comum em aplicações web com milhares de usuários que surgem sem controle do DBA. Você deve ter pelo menos 4 usuários para cada aplicação com este perfil:

Um usuário que é dono dos objetos criados no banco de dados. Este usuário deve estar sob controle somente e tão somente do DBA, tanto no ambiente de testes como em produção. Lembre-se que este usuário tem poderes plenos sobre estes objetos do banco de dados.
Um usuário ou grupo de usuários destinado aos desenvolvedores com poderes específicos para as suas tarefas. Pode-se determinar que no ambiente de produção ele tenha permissão de SELECT em todas tabelas e sequências e no ambiente de produção tenha poderes de SELECT, INSERT, UPDATE e DELETE.
Um usuário ou grupo de usuários destinado aos administradores da aplicação, que terão poderes específicos na aplicação como deletar registros ou atualizar valores em tabelas. Este usuário deve se conectar a partir de outro executável que não o utilizado pelos usuários normais. A aplicação utilizada para fins administrativos deve ter acesso restrito ao acesso local por exemplo. Este usuário terá permissões de DELETE, UPDATE e INSERT em tabelas que um usuário normal não terá permissão. Portanto, este usuário jamais deve ser utilizado em operações de rotina.
Um usuário para os usuários normais da aplicação. Este usuário deve seguir a risca a regra no menor privilégio. Ele deve apenas as permissões para acessar os objetos estritamente necessários. Privilégios de UPDATE e DELETE devem ser concedidos com muita cautela. Operações deste tipo quando executadas sem uma clausula WHERE adequada podem ser desatrosas. É este usuário que será alvo de ataques de SQL Injection. Se você for rigoroso com as permissões para este usuário, limitará muito a dimensão dos estragos que podem acontecer no caso de um ataque bem sucedido.

Use criptografia, visões e funções

Feito isso, você já terá um ambiente muito mais seguro, com certeza. A próxima parte do nosso trabalho será realizar um tratamento dedicado às informações mais sensíveis do seu sistema. Identifique estes objetos com cuidado. Existem dados sigilosos que podem ser alvo de criptografia. Senhas jamais devem ser armazenados sem criptografia. Use uma função como MD5 para isso. Lembre-se que você não poderá saber qual é a senha armazenada no campo, apenas poderá verificar se uma senha é igual a que está armazenada. No entanto, se apenas um grupo específico precisa ter acesso a estas informações você deve restringir o acesso a elas. Quando você quer restringir o acesso a apenas uma coluna ou grupo de columas de uma tabela a melhor alternativa é criar uma visão com apenas as colunas que o usuário vai precisar. De permissão ao usuário acessar esta visão não permita que ele leia a tabela diretamente.

Há casos em que a pessoa precisa alterar ou ler registros, mas você não quer que limitar a possibilidade de que o usuário altere todos os registros da tabela. Para isso, você pode criar funções que encapsulem toda a operação. Você passa para a função os parâmetros a serem alterados, a função checa a validade destes dados, faz todas as alterações em todas tabelas necessárias e retorna se realizou a operação com sucesso ou não, ou ainda retorna um valor desejado como se fosse um SELECT. O resultado disso é que você só precisa dar permissão ao usuário para executar a função e não precisa dar nenhum acesso a qualquer um dos objetos envolvidos na transação. Isto significa que o usuário só poderá realizar aquela transação especificada pela função, que se for bem codificada, evitará definitivamente qualquer chance de acesso indevido.

Procedimentos preparados

A terceira etapa é utilizar os procedimentos preparados ou “prepared statements’. Este procedimentos fazem com que você passe como parâmetros os valores a serem substituídos num comando SQL qualquer. As pessoas evitam utilizar este procedimento pois ele requer que você o execute em duas etapas: preparar o procedimento e executar o procedimento. Quando executado com freqüência, os procedimentos preparados não só são mais seguros, como também apresentam um ganho de performance.

Dollar Quoting

A quarta etapa que você pode utilizar é peculiar ao PostgreSQL, e chama-se “dollar quoting“. Ao invés colocar strings de caractere entre aspas simples em expressões SQL, você pode usar o $$ como em:

SELECT TRUE FROM users WHERE name = $$$$ AND senha = $$abizi$$;

Você ainda pode fazer coisas como:

SELECT TRUE FROM users WHERE name = $name$telles$name$ AND senha = $senha$abizi$senha$;

Note que você pode colocar suas strings entre $$, $nome$, $senha$ ou qualquer outra coisa, tendo somente que começar e terminar com a mesma marca. Usar este tipo de notação no código SQL pode parecer um tanto grotesco inicialmente, mas quando você for escrever funções, ela pode tornar a sua vida muito mais simples, pois você não terá situações bizarras como um grupo de várias aspas simples ou contra barras. Com o dollar quoting, você não precisa se preocupar com as aspas simples.

Checar o tipo de dados

A próxima barreira de defesa na luta contra a injeção de SQL é checar o tipo de dados utilizado. Um tipo comum de ataque é por exemplo ingetar código em parâmetros GET do protocolo http. Se você espera um número, tenha certeza de que ele é um número antes de substituir a sua variável no seu código SQL. Uma forma eficiente de fazer isso é utilizar a função ‘printf’. Quase toda linguagem de programação possui um comando semelhante ao printf da linguagem C. A nossa string SQL utilizando printf ficaria alguma coisa assim:

SQL = printf('SELECT TRUE FROM users WHERE nome = %s AND senha = %s', nome, senha)

A questão aqui é que a função printf vai forçar o uso do tipo de dados correto na função SQL. Não é uma solução perfeita, mas pode evitar alguns problemas além de evitar a conversão implícita de tipos de dados, fonte de muitas dores de cabeça no banco de dados.

Escapar as strings

A barreira mais conhecida na proteção contra a injeção de SQL é o uso de funções que escapem as strings. Hoje a maioria das linguagens de programação possuem funções para escapar caracteres como aspas simples em strings. Veja que uma aspa simples pode fazer parte de uma string como em “database’s security”. Para que uma string deste tipo seja aceita, é preciso escrevê-la desta forma numa expressão SQL:

INSERT INTO titulo VALUES ('database''s security');

Note que existem duas aspas simples e não uma aspas dupla. Esta é a única forma de se adicionar aspas simples numa string em banco de dados. Você deve esperar que o seu usuário por qualquer motivo digite uma aspa simples em qualquer string. A não ser que você remova explicitamente as aspas simples da sua string antes de construir o seu comando SQL, você deverá sempre escapa-las. Se a sua linguagem de programação possuir uma função de escape de strings específica para o seu banco de dados, utilize-a no lugar de uma função genérica.

Conclusão

Os problemas de segurança em geral são criados por profissionais mal informados ou por desenvolvedores que acreditam que segurança é um fator supérfluo e que implementar todas as barreiras necessárias é muito trabalhoso. O descuido com a segurança chega num ponto onde muitos servidores web exibem suas mensagens de erro diretamente na tela do usuário, no ambiente de produção. O uso de técnicas de SQL Injection em ambiente que não implantaram todas as barreiras citadas e ainda oferecem de bandeja os erros da aplicação na tela é absolutamente devastador. O usuário consegue descobrir o nome de todas as tabelas e colunas da sua aplicação, alterar qualquer registro ou mesmo apagar todas as informações de todas tabelas. Não é incomum encontrarmos aplicações de grande porte com furos homéricos de segurança. Não é incomum sites famosos e grandes corporações sofrerem com o vazamento de informações, fraudes e perda de dados. O prejuízo é sempre maior do que o custo de implementar a segurança de forma correta na aplicação.

Quando pensar novamente em segurança, lembre-se que a tarefa é de todos. Os ataques de SQL injections são muito simples de executar, a pondo de criarem a expressão “Script kiddie” para designar pessoas com pouco conhecimento técnico que utilizam receitas simples e eficientes para invadir sistemas. Não adiante a rede, o servidor e o banco de dados adotarem condutas rigorosas de segurança se você lança mão de aplicações (desenvolvidas por você ou por terceiros) que não tomam este tipo de precaução.

Jobs no PostgreSQL

2008-06-27T16:00:21+00:00

Um recurso interessante do Oracle e que não está presente nativamente no PostgreSQL é o agendamento de tarefas, popularmente conhecido como "Jobs". Embora o postgreSQL não saia do forno com o suporte a jobs, o PgAdmin3 instala o pgAgent, uma execelenete implementação de um sistema de jobs. O pgAgent é tão ...

Minhas propostas ingênuas palestras para o PgCon BR 2008

2008-06-27T15:13:38+00:00

Estou completamente sem originalidade — e sem tempo. Há outras coisas sobre o que escrever, mas, assim como duas vezes já nos últimos meses (e a segunda desde ontem) vou seguir o Fernando Ike com minha exposição de propostas ingênuas de palestras para a Conferência Brasileira de PostgreSQL 2008.

Lembrando que hoje (dia vinte e sete de junho do ano da Graça de dois mil e oito &c &c) é o último dia para apresentar as propostas.

Um elefante previdente: preparando-se para o futuro de seu sistema com uma boa arquitetura e modelagem de dados em PostgreSQL.

Palestra

Público Alvo: intermediário

Resumo

Freqüentemente vemos, em listas de discussões e outros fora de comunicações, pessoas pedindo ajuda com problemas decorrentes de abordagens ingênuas de arquitetura de sistemas, e dois dos aspectos mais problemáticos têm sido a arquitetura e a modelagem de dados. Muitas vezes os problemas só aparecem quando sua correção é praticamente impossível. Veremos quais conceitos básicos de administração e modelagem de dados são mais críticos para um sistema à prova de futuro, e como aplicá-los em sistemas PostgreSQL com alguns exemplos básicos em SQL e D.

Descrição

Problemas de arquitetura: a tragédia do cliente servidor e a crise de software.

Manipulando os dados onde estão: evitar turismo de bits.

Problemas de organização: saiba do que fala antes de abrir a boca.

Tipos (abstratos) de dados e domínios SQL: evitando a confusão.

Entidades e relacionamentos: cada coisa no seu porta-coisa.

Restrições de integridade: deixe a base de dados cuidar de si.

Problemas de modelagem: a otimização precoce é a raiz de toda sorte de males.

Normalização: otimizando o gargalo mais comum. Ou você quer mesmo fazer o disco se exercitar?

Desnormalização: ¿¡tem certeza!? Fazendo o disco trabalhar dobrado.

O elefante aparelhado: ferramental e processo de administração de dados em PostgreSQL.

Tutorial (pode também ser resumido numa palestra).

Público Alvo: intermediário

Resumo

Freqüentemente confunde-se modelagem e diagramação de dados, e aí vemos pessoas tentando ‘tirar leite de pedra’: criar um modelo apenas com ferramentas de diagramação, ou de mapeamento objeto-relacional.

Pior ainda, o trabalho de administração de dados não se resume à modelagem. A documentação, a manutenção do ciclo de vida de uma base de dados, o apoio ao desenvolvedor e ao usuário são também responsabilidades do administrador de dados.

Há toda uma variedade de ferramentas para auxiliar na administração de dados, e pretendemos mostrar algumas ao longo do ciclo de vida da base.

Descrição

Documentação: requisitos, interfaces e regras de negócio.

Rascunhos: cérebro, caneta e papel.

O modelo de dados: seu editor de textos preferidos, e DDL. Ou que tal algo melhor?: a possibilidade próxima futura de DDL relacional no Alphora Dataphor como uma interface relacional para PostgreSQL.

O diagrama de dados: AutoDoc e SQL::Fairy, deixe o programa trabalhar por você!

Documentos: AutoDoc, SQL::Fairy, LaTεχ e DocBook. Concentre-se no conteúdo, não na formatação.

Controle do ciclo de vida da base: versionamento, colaboração, e geração automática dos produtos.

ribafs

2008-06-26T23:37:41+00:00

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Em minhas aulas de PostgreSQL estarei dando o exemplo aos alunos, colaborando com os assuntos relacionados ao PostgreSQL e diretamente.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

2008-06-26T18:16:29+00:00

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe — quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

É uma idéia do Augusto Campos, da qual fiquei sabendo pelo Fernando Ike através do Planeta PostgreSQL Brasil.

Escolhi, além da Wikipædia, o OpenSSH, que é fundamental para a operação segura da Internet (além dos meus sistemas!). E viva a liberdade!

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

2008-06-26T03:29:59+00:00

Também estou participando da campanha do Augusto Campos com o seus sites BR-LInux e Efetividade. Você também pode ajudar os projetos de Software Livre/Código Aberto não só participando dessa campanha mas contribuindo diretamente.

Eu escolhi o Creative Commons além do Wikipedia para essa campanha. Já contribuo de forma pequenina para o PostgreSQL e Debian, e você.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Minhas propostas toscas para PGCon Brasil 2008

2008-06-25T14:34:06+00:00

Bom, para ajudar você que está inibido em enviar uma proposta de palestra para PGCon Brasil 2008, vou publicar aqui as três proposta que enviei até então:

A primeira

Título: HA em PostgreSQL: O Elefante disponível para além do infinito
Tipo: Palestra
Público Alvo: Intermediário
Resumo:
Alta-Disponibilidade para banco de dados é um das tarefas mais difíceis para qualquer profissional de TI, os desafios estão muito além do que somente trocar um endereço IP. Esta palestra tem como objetivo mostrar as estratégias e ferramentas possíveis de usar para Alta-Disponibilidade em PostgreSQL e também mostrar o que não funciona.

Descrição (até 3000 caracteres):
Existe um mito corriqueiro que alta-disponibilidade basta ter duas máquinas com um serviço simples de alta-disponibilidade ou que é simples montar um Cluster Multi-Master que a Disponibilidade do Banco de Dados está garantida. A simplicidade de encontrar a solução pode significar o fracasso de um projeto. Pois, para um projeto bem-sucedido de Alta-Disponibilidade é necessário avaliar as muitas variáveis que podem significar em pontos de falhas, tratando-se de
banco de dados as variáveis aumentam significativamente porque terá que avaliar se um projeto de Alta-Disponibilidade é em uma rede LAN ou WAN, Assíncrono ou Síncrono, aplicação está preparada para suportar replicação ou trabalhar em cluster.

Esta palestra visa desmitificar a idéia simplista de um projeto de Alta-Disponibilidade em Banco de Dados (PostgreSQL) e mostrar soluções com as principais ferramentas com suas funcionalidades e quais são as melhores soluções de Alta-Disponibilidade para essas ferramentas. Dentre elas, será citado: PgBouncer, PL/Proxy, PgPool-2, Slony, Log
Shipping, Sequoia, etc…

A segunda

Título: skytools, pgbouncer, plproxy
Tipo: Palestra
Público Alvo: Intermediário
Resumo:
Nos últimos anos o PostgreSQL tem aumentado sua participação em empresas em áreas importantes das mesmas. Com isso problemas como performance com grande quantidade de usuários e aumentar disponibilidade do banco de dados em ambientes que precisam de 99,9% do ano disponível. Por falta de opções disponíveis em Software Livre/Código Aberto empresas como Skype criaram suas próprias ferramentas e liberaram como Software Livre/Código Aberto como
SkyTools, PlProxy, PgBouncer. Essa palestra tem com objetivo mostrar um pouco dessas ferramentas.

A terceira

Título: Sinergia PostgreSQL e Debian, o melhor SGDB com o melhor SO.
Tipo: Palestra
Público Alvo: Iniciante
Resumo:
O PostgreSQL é considerado o melhor banco de dados em Software Livre/Código Aberto atualmente e a sinergia entre o PostgreSQL e o Debian é bem antiga e muito respeitada. Muitos instalam, configuram ou personalizam sem usar as ferramentas disponíveis no Debian aumentando ainda mais a extenuante tarefa de administrar um banco de dados. Esta
palestra visa demonstrar como gerenciar corretamente o PostgreSQL no Debian como também demonstrar como funciona o time de empacotamento do PostgreSQL, os pacotes dependentes e extensões disponíveis do
PostgreSQL no Debian, a possibilidade de gerenciar múltiplas instâncias. Enfim, ajudar muitos DBA’s e administradores de rede e sistema a ter mais tempo para tomar um café, cerveja e família.

Prorrogado prazo para enviar proposta de palestras para PGCon Brasil 2008

2008-06-25T04:09:07+00:00

O Leonardo Cézar enviou para lista de discussão pg-geral que foi prorrogado a inscrição de proposta de palestras para PGCon Brasil 2008. Aproveite que foi prorrogado envie uma proposta e compartilhe seu conhecimento com o banco de dados que nunca esquece (PostgreSQL).

Dica: remover os comentários do postgresql.conf

2008-06-19T15:19:33+00:00

Esses dias estava relatório para um cliente uma instalação e configuração . Precisava adicionar ao relatório as configurações do PostgreSQL e tive um pequeno problema para resolver, colocar todas as quinhentas (507 precisamente) com os comentários ou somente as linhas que foram alteradas?

Depois de algumas horas apanhando de expressão regular, lembei que o pgtesttool do Euler remove as linhas com os comentários do postgresql.conf.

Basicamente é:

sed -e ‘/^[[:space:]]/d’ -e ‘/^#/d’ -e ‘/^$/d’ postgresql.conf

ribafs

2008-06-15T21:56:16+00:00

Nasce mais um site sobre PostgreSQL.

Este site nasceu na necessidade de reunir material para um curso sobre PostgreSQL, portanto esse nome.

Conta com módulos sobre programação no cliente e no servidor, administração e projeto de bancos de dados.

Reuni o material e gerei PDFs de cada aula e também de cada módulo. Os três módulos juntos resultam em mais de 700 páginas.

Além do material para o curso que compartilho, também conta com uma grande quantidade de tutoriais de diversos assuntos, dicas, diagramas de modelos, exercícios e muita informação sobre o SGBD PostgreSQL.

Aqui - http://pg.ribafs.net

Ottawa: PGCon 2008 conclusões…

2008-06-14T21:16:13+00:00

Com muito atraso mas agora sobrou um tempinho para escrever melhor sobre a PGCon 2008. Vale a pena ir num evento fora mais específico porque é como o FISL ou outros eventos de Software Livre/Código Aberto no Brasil. É algo mais intimista e com parte técnica bem avançada.

Aquelas conversas de entusiastas que temos no Brasil, na PGCon elas eram diminutas, maior parte das discussões eram focadas em problemas técnicos, curiosidades culturais. Tenho que agradecer imensamente o Francisco Figueiredo Jr. pela paciência e presteza por me ajudar (praticamente co-palestrante) na palestra. A palestra ficou um pouco deficiente pois o Euler não conseguiu o visto para entrar no Canadá à tempo de ir para PGCon. Mérito que seja dito, essa paletra tem todo o mérito do Euler de ter sido realizadae espero que ano que vem ele esteja lá porque eu não vou de novo, só de pensar em dez horas de avião já me dá calafrios.

A PGCon me surpreendeu pela maneira que as empresas portaram-se durante o evento, não era o esquema das empresas daqui do "toma lá da cá". Eles patrocinam e incentivam pois sabem que o retorno indireto (melhora do PostgreSQL) é proporcional ou maior que ter a melhor posição do logo da empresa no site ou na camiseta do evento.

Para quem é usuário, entusiasta ou quer contribuir com o PostgreSQL, mais que recomendado ir para Ottawa na PGCon, conhecimento e experiência inesquecível. Principalmente pelo fato que a cidade de Ottawa em maio está maravilhosamente linda com muitos eventos acontecendo com a chegada do verão no hemisfério norte. Com tempo, posto melhor sobre Ottawa e posto umas fotos.

Validação de CPF com Pl/ PgSQL

2008-06-08T14:20:36+00:00

A partir de hoje passamos a divulgar algoritmos de funções e consultas que sejam de utilidade pública. A validação de CPF com Pl/ PgSQL foi escolhida em primeiro lugar por ser um algoritmo simples mas bastante útil (além disto, procurei em vários sites e não encontrei um exemplo em PL/ PGSQL).

O CPF é utilizado por muitos sistemas brasileiros como identificação dos indivíduos. Validar o CPF é fazer a verificação dos dois últimos dígitos que são gerados a partir dos nove primeiros. O código abaixo foi uma tradução mais ou menos literal do código em javascript deste site.

Talvez possa ser feita otimização ou melhoria neste algoritmo, mas a idéia é que vocês o melhorem e atualizem neste site. Estejam à vontade para utilizar e compartilhar este código.

CREATE OR REPLACE FUNCTION CPF_Validar(par_cpf varchar(11)) RETURNS integer AS $$
-- ROTINA DE VALIDAÇÃO DE CPF
-- Conversão para o PL/ PGSQL: Cláudio Leopoldino - http://postgresqlbr.blogspot.com/
-- Algoritmo original: http://webmasters.neting.com/msg07743.html
-- Retorna 1 para CPF correto.
DECLARE
x real;
y real; --Variável temporária
soma integer;
dig1 integer; --Primeiro dígito do CPF
dig2 integer; --Segundo dígito do CPF
len integer; -- Tamanho do CPF
contloop integer; --Contador para loop
val_par_cpf varchar(11); --Valor do parâmetro
BEGIN
-- Teste do tamanho da string de entrada
IF char_length(par_cpf) = 11 THEN
ELSE
RAISE NOTICE 'Formato inválido: %',$1;
RETURN 0;
END IF;
-- Inicialização
x := 0;
soma := 0;
dig1 := 0;
dig2 := 0;
contloop := 0;
val_par_cpf := $1; --Atribuição do parâmetro a uma variável interna
len := char_length(val_par_cpf);
x := len -1;
--Loop de multiplicação - dígito 1
contloop :=1;
WHILE contloop = (len -2) LOOP
y := CAST(substring(val_par_cpf from contloop for 1) AS NUMERIC);
soma := soma + ( y * x);
x := x - 1;
contloop := contloop +1;
END LOOP;
dig1 := 11 - CAST((soma % 11) AS INTEGER);
if (dig1 = 10) THEN dig1 :=0 ; END IF;
if (dig1 = 11) THEN dig1 :=0 ; END IF;

-- Dígito 2
x := 11; soma :=0;
contloop :=1;
WHILE contloop = (len -1) LOOP
soma := soma + CAST((substring(val_par_cpf FROM contloop FOR 1)) AS REAL) * x;
x := x - 1;
contloop := contloop +1;
END LOOP;
dig2 := 11 - CAST ((soma % 11) AS INTEGER);
IF (dig2 = 10) THEN dig2 := 0; END IF;
IF (dig2 = 11) THEN dig2 := 0; END IF;
--Teste do CPF
IF ((dig1 || '' || dig2) = substring(val_par_cpf FROM len-1 FOR 2)) THEN
RETURN 1;
ELSE
RAISE NOTICE 'DV do CPF Inválido: %',$1;
RETURN 0;
END IF;
END;
$$ LANGUAGE PLPGSQL;

Uso de SET em Funções Pl/PgSQL

2008-06-06T10:46:55+00:00

Na versão 8.3 do PostgreSQL foi implementado um recurso interessante, que permite a parametrização da execução de uma função utilizando o comando SET no momento da sua criação. Desta forma, a configuração é alterada apenas durante a sua execução, retornando aos valores prévios após o seu encerramento.

Valores de tablespace padrão (default_tablespace), encoding do cliente (client_encoding) entre outros são definidos de forma explícita, de modo que se force o comportamento esperado da função não importando que programa faça a sua chamada de execução.

Existe também a opção de utilização da cláusula FROM CURRENT para fazer com que a alteração de configuração seja mantida após a execução da função.

Nem todos os parâmetros de execução podem ser alterados com o comando SET dentro de uma função. Os erros são revelados no momento de criação da função.

O comando SHOW mostra a lista de parâmetros e seus valores correntes.

Criação de Função com Parâmetros de Configuração

O código abaixo mostra a criação de uma função que atualiza a tabela salário. Após o corpo da função são definidos os valores dos itens de configuração array_nulls, default_tablespace, commit_delay e client_encoding.

CREATE TABLE SALARIO (cod integer PRIMARY KEY, provento real);
INSERT INTO SALARIO VALUES (1, 1000.00);
INSERT INTO SALARIO VALUES (2, 100.00);

CREATE OR REPLACE FUNCTION salario_aumento() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET array_nulls = OFF
SET default_tablespace = 'pg_default'
SET commit_delay TO 10
SET client_encoding TO UNICODE;

Mantendo Alterações na Configuração

O código abaixo mostra a criação de uma função na qual é alterado e mantido o valor do client_encoding. A cláusula FROM CURRENT indica que parâmetro terá o valor de configuração que foi alterado mantido.

CREATE OR REPLACE FUNCTION salario_parametros() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET client_encoding TO UNICODE
SET client_encoding FROM CURRENT;

Ressalva no Uso de SET em Funções

Alguns dos itens de configuração não são alteráveis pelo comando SET dentro de uma função. Neste caso, será retornado erro no ato da criação da função. No exemplo abaixo, tanto o log_checkpoints quanto o transaction_isolation não puderam ser alterados no escopo de uma função.

-- Não funcionaram
CREATE OR REPLACE FUNCTION salario_parametros_teste() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET log_checkpoints = ON
SET transaction_isolation = SERIALIZABLE;

ERROR: parameter "log_checkpoints" cannot be changed now

********** Error **********

ERROR: parameter "log_checkpoints" cannot be changed now
SQL state: 55P02

Chamada de Trabalhos para o PGCon Brasil 2008

2008-06-03T17:45:55+00:00

Agora é a sua vez de mandar uma proposta de palestra para o PGCon Brasil 2008. A chamada já foi publicada e se encerra no dia 22/06. Portanto não perca tempo e mande logo a sua proposta. Está em dúvida sobre qual palestra submeter??? Mande mais de uma!

Está esperando o que??? Ah… você conhece uma pessoa que é fera em PostgreSQL? Convide-o a participar também! E não deixe de divulgar o evento!

PGCon 2008: Segundo dia

2008-06-02T03:44:39+00:00

Hoje foi um dia tenso, a primeira palestra com tradução simultânea português-inglês na PGCON (a minha). O Francisco Figueiredo Jr. gentilmente aceito a minha proposta insana de ser o tradutor da palestra. Tinha um público grande para uma desconhecido como eu (100). Foi uma experiência boa mas faz pensar em rever algumas prioridades…

O que vi no segundo dia, Approximate Search (Enrico Pirozzi), Security-Enhanced PostgreSQL (Kaigai Kohel), PostgreSQL Project and Release Management (Peter Eisentraut), Greg Mullane Sabino (Bucardo). Não consegui assistir as palestras do pessoal do skype mas foram bem comentadas.

A conclusão fica para um próximo post. ;)

Instalando e Implementando DBI-LINK no PostgreSQL

2008-05-29T20:01:04+00:00

Existem ocasiões onde temos 2 servidores distintos e precisamos de um merge dessas informações, como obter o retorno de um select se tenho dados em 2 servidores separados ???????

Seus problemas acabaram!!!! … Nesse caso temos 2 soluções DBLINK e DBI-LINK, sendo que se os 2 servidores forem postgres, use dblink mas se um for postgres e outro for Oracle, Mysql ou seja la qual banco … usamos o dbi-link.

Vendo o site da pgcon 2008 Internacional achei uma palestra muito bacana do David Fetter sobre o DBI-LINK 3.0 resolvi testar esse bicho … e querem saber ??? é muito bacana !!!!!!.

Antes de começar só vamoslembrar que quando usamos esse tipo de recurso temos que levar em conta que ficamos “refens” da rede, seja interna ou externa, uma vez que as informações estão em servidores distintos

Instalando o postgres

Baixando pacotes

# aptitude install ssh
# aptitude install gcc
# aptitude install make
# aptitude install libreadline-dev
# aptitude install zlib1gdev
# aptitude install zlibc
# aptitude install zlib1g-dev
# aptitude install libio-zlib-perl
# aptitude install perl
# aptitude install libyaml-perl
# aptitude install libconfig-yaml-perl
# aptitude install libyaml-syck-perl
# aptitude install libtest-yaml-meta-perl
# aptitude install libtest-yaml-valid-perl

Compilando
$ tar -xvzf postgresql-8.3.1.tar.gz

$ mv postgresql-8.3.1 postgresql-8.3
$ cd postgresql-8.3
$ cd src/include/
$ vi pg_config_manual.h

#define BLCKSZ 8192 – Usado em BI por isso o bloco de gravação é maior
#define BLCKSZ 4096 – Usado em Transacionais por isso o bloco de gravação é menor

$ cd ../../
$ ./configure –prefix=/home/postgres/postgresql-8.3 –with-python –with-perl
$ make $$ make install

Criando o cluster

O diretório pg83 deve ser criado para alocar o novo cluster

$ mkdir -p /postgres/pg83/dados/
$ /home/postgres/postgresql-8.3/bin/initdb -D /postgres/pg83/dados/ –encoding=latin1

Subindo o banco

$ cd /postgres/pg83/dados/
$ /home/postgres/postgresql-8.3/bin/pg_ctl -D . start

Baixando os pacotes para para DBI-LINK

Para esse procedimento são necessários 2 pacotes: DBI-LINK e o DBD-Pg

Instalando os pacotes

Esse recurso para ser instalado necessita de alguns pré requisitos, ou seja, alguns pacotes instalados:

DBI-LINK

build, test, and install Perl 5 (at least 5.6.1)

BDB-PG

build, test, and install Perl 5 (at least 5.6.1)
build, test, and install the DBI module (at least 1.52)
build, test, and install PostgreSQL (at least 7.4)
build, test, and install Test::Simple (at least 0.47)

Descompacte os pacotes e execute o Makefile.pl para que a instalação seja feita:

$ tar - xvjf dbi-link-2.0.0.tar.bz2
$ cd dbi-link-2.0.0
$ perl Makefile.PL
Writing Makefile for dbi-link

$ tar -xvzf DBD-Pg-2.7.2.tar.gz

O Makefile padrão usa algumas variáveis que devem ser definidas antes da instalação:
POSTGRES_HOME - Instalação do PostgreSQL
POSTGRES_LIB - bilbiotecas do PostgreSQL
POSTGRES_INCLUDE - Diretório de include do PostgreSQL

Para fazer o export das variáveis:

$ export POSTGRES_LIB=”/home/postgres/postgresql-8.3/lib/”
$ export POSTGRES_HOME=”/home/postgres/postgresql-8.3/”
$ export POSTGRES_INCLUDE=”/home/postgres/postgresql-8.3/include/”

Os primeiros passos da instalação devem ser feitos com o usuário comum postgres:

$ cd DBD-Pg-2.7.2
$ perl Makefile.PL
Configuring DBD::Pg 2.7.2
PostgreSQL version: 80301 (default port: 5432)
POSTGRES_HOME: /home/postgres/postgresql-8.3/
POSTGRES_INCLUDE: /home/postgres/postgresql-8.3/include/
POSTGRES_LIB: /home/postgres/postgresql-8.3/lib/
OS: linux
Checking if your kit is complete…
Looks good
Using DBI 1.604 (for perl 5.010000 on i486-linux-gnu-thread-multi) installed in /usr/lib/perl5/auto/DBI/
Writing Makefile for DBD::Pg

$ make

O make install criará alguns diretórios em locais de sistema que não é permitido a usuário comum, sendo assim execute-o com o usuário root

# make install

Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /usr/local/lib/perl/5.10.0/auto/DBD/Pg/Pg.so
Installing /usr/local/lib/perl/5.10.0/auto/DBD/Pg/Pg.bs
Installing /usr/local/lib/perl/5.10.0/Bundle/DBD/Pg.pm
Installing /usr/local/lib/perl/5.10.0/DBD/Pg.pm
Installing /usr/local/man/man3/Bundle::DBD::Pg.3pm
Installing /usr/local/man/man3/DBD::Pg.3pmWriting /usr/local/lib/perl/5.10.0/auto/DBD/Pg/.packlist
Appending installation info to /usr/local/lib/perl/5.10.0/perllocal.pod

Adicionando um DBI-LINK

Antes de tudo é necessário criar a linguagem plperl no banco em questão, pois o dbi-link foi desenvolvido em PL/PERL.

$ createlang plperlu portgres

Agora rode o script que criará toda estrutura dbi-link

$ psql -p 5432 < /home/postgres/dbi-link-2.0.0/dbi_link.sql

Note que no banco foi criado o schema dbi_link, com 3 tabela, 26 funções e 1 trigger

Adicionando uma conexão Remota

MYSQL

Criando nova conexão

SELECT dbi_link.make_accessor_functions(
‘dbi:mysql:database=teste;host=localhost’,–Driver:banco:host‘root’, – usuário
”, – senha
‘— AutoCommit: 1 RaiseError: 1 ‘, – atributos do banco remoto
NULL, – ambiente de conexão
NULL, – schema remoto
NULL, — catalogo remoto
‘teste’ — schema local

Usando a conexão

SELECT * FROM teste.tabela;

Transferindo dados de um banco para outro

É possivel transferir dados direto de um banco para outro, porém com algumas restrições (que serão resolvidas futuramente, segundo o desenvolvedor). Todos os dados retornados do banco externo são formato text, sendo assim ou a tabela destino tem os campos text ou trate as informações antes de fazer a inserção.

CREATE SCHEMA testepg
AUTHORIZATION postgres;
GRANT ALL ON SCHEMA testepg TO postgres;

CREATE TABLE testepg.tabela
(
campo1 character varying,
campo2 character varying,
campo3 character varying,
campo4 date,
campo5 character varying,
campo6 text
CONSTRAINT tabela_pk PRIMARY KEY (campo1)
)
WITH (OIDS=FALSE);
ALTER TABLE testepg.tabela OWNER TO postgres;

INSERT INTO testepg.tabela
(SELECT campo1:: character varying,
campo1:: character varying,
campo2:: character varying,
campo3:: date,
campo4:: character varying,
campo5:: text
FROM teste.tabela
WHERE campo1 = ‘XXX’);

Bom .. por hoje é só pessoal !!!!!!
PS: vou fazer mais algumas brincadeiras com o DBI-LINK e posto aqui.
PS2: Conversei com o David e vou traduzir o pacote dele !!!

Kenia Milene

PostgreSQL - Funcionalidades de Performance

2008-05-29T09:43:26+00:00

Comentários sobre as funcionalidades voltadas para a melhoria de desempenho da versão 8.3 do PostgreSQL. Coloco o texto original em inglês e abaixo uma nota explicativa sobre a nova implementação:

- HOT: "Heap Only Tuple (HOT) dramatically reduces the database maintenance issues associated with frequently updated data, reducing the need to vacuum and giving substantial throughput improvements for some applications."

Nota: O HOT - Heap Only Tuple é uma alteração que reduz a necessidade do banco de dados fazer atualizações nos índices. No PostgreSQL, cada alteração nos dados gera uma nova versão do registro. Caso seja alterado um campo de um arquivo e este campo não seja parte do índice, o mesmo não precisa mais ser atualizado. A entrada original de índice aponta, ainda que indiretamente, para o dado alterado. Esta implementação de HOT traz um ganho substancial, especialmente em dados alterados com muita freqüência. O termo "Heap only" significa exatamente que os dados estão apenas no arquivo de dados, não nos índices.


- Asynchronous Commit: "Allows the ability for COMMIT to return control without waiting for a physical disk write. This gives better response time at the expense of potentially losing a set amount of transactions in the event of system failure."

Nota: a implementação de commits assíncronos faz com que os mesmos sejam mais rápidos em geral. No caso de commits síncronos, operações mais lentas fazem com que as mais rápidas tenham que esperar, impactando a performance como um todo. A alteração implementada faz com que o PostgreSQL não tenha de esperar a conclusão de operações feitas para disco para prosseguir o commit, acelerando este tipo de operação tão freqüente.


- Spread Checkpoints: "Checkpoint autotuning: delays and spreads out checkpoints, reducing the impact of checkpoints on response times."

Nota: periodicamente o banco de dados necessita sincronizar o que está no banco com o que está armazenado em log. Este momento é chamado de checkpoint e toma tempo de processamento e acesso a disco. A alteração realizada no PostgreSQL faz com que este evento possa ser atrasado quando não há real necessidade de fazê-lo imediatamente. O ganho de desempenho se dá pela economia de tempo de processamento de checkpoints.

Just-in-time background writing strategy: "Auto-tuning for the Background Writer estimates how many buffers it should try to clean based on statistics about recent activity."

Nota: A sentença "Just-in-time background writing strategy" significa uma melhor alocação de memória durante os processos de gravação feitos em background. É um processo crítico para o desempenho e passa a sofrer um Auto-tuning (auto ajuste) baseado na atividade mais recente do servidor. O resultado final é maior ganho em desempenho e facilidade de utilização.

Particionamento de Tabelas no PostgreSQL

2008-05-26T16:54:01+00:00

Quando temos uma tabela muito grande, ou seja com milhões de linhas a melhor opção é particiona-la para uma melhor performance do banco. Para isso, é necessário algumas regras na tabela principal e criar as tabelas auxiliares:

Veja abaixo.

1 – Crie a tabela principal

CREATE TABLE salario(
funcionario numeric(10) NOT NULL,
centro_custo character varying(10) NOT NULL,
valor_resultado numeric(13,2),
data_evento date,evento numeric(3),
conta numeric(10),cargo numeric(5)
)
WITH (OIDS=TRUE);

2 – Crie as tabelas particionadas para inserção dos dados, sendo que as mesmas devem herdar as caracteristicas da tabela principal, para isso usamos o () INHERITS

–JANEIRO

CREATE TABLE salario_jan () INHERITS (salario);

–FEVEREIRO

CREATE TABLE salario_fev () INHERITS (salario);

……………………..

–DEZEMBRO

CREATE TABLE salario_dez () INHERITS (salario);

3 – Crie a regra que no caso de uma tabela de pagamentos de funcionarios, Nesse caso, o campo referencia é a data de pagamento tendo base o mês. Sendo assim crie uma rule para cada mês, onde a cada insert feito na tabela mãe … os dados são filtrados e inseridos em cada tabela filha correspondende ao mês.

– JANEIRO

CREATE OR REPLACE RULE insert_jan AS
ON INSERT TO salario
WHERE date_part (’month’::text, new.data_evento)=1
DO INSTEAD INSERT INTO salario_jan (funcionario, centro_custo, valor_resultado, data_evento, evento, conta, cargo)
VALUES (new.funcionario, new.centro_custo, new.valor_resultado, new.data_evento, new.evento, new.conta, new.cargo);

– FEVEREIRO

CREATE OR REPLACE RULE insert_fev AS
ON INSERT TO salario
WHERE date_part(’month’::text, new.data_evento)=2
DO INSTEAD INSERT INTO salario_fev (funcionario, centro_custo, valor_resultado, data_evento, evento, conta, cargo)
VALUES (new.funcionario, new.centro_custo, new.valor_resultado, new.data_evento, new.evento, new.conta, new.cargo);

……………………………

– DEZEMBRO

CREATE OR REPLACE RULE insert_dez AS
ON INSERT TO salario
WHERE date_part(’month’::text, new.data_evento)=12
DO INSTEAD INSERT INTO salario_dez (funcionario, centro_custo, valor_resultado, data_evento, evento, conta, cargo)
VALUES (new.funcionario, new.centro_custo, new.valor_resultado, new.data_evento, new.evento, new.conta, new.cargo);

Explicando …

A função data_part, vai extrair uma determinada parte da data a ser imposta pela regra.

No caso desse particionamento a referencia é o mês. Sendo assim no momento do insert, será verificado o mês em questão e redirecionado para tabela particionada correspondente.

É importante dizer que se um registro não atender a uma determinada regra, ele será inserido na tabela principal.

E que a tabela principal se comportará como uma tabela MERGE, sendo assim ela mostrará todos os registros !!

4 – Criando os Indices ..

Para a busca ser mais rápida é interessante a criação de indice nas tabelas particionadas.

– JANEIRO

CREATE INDEX salario_jan_idx
ON salario_jan
USING btree
(data_evento);

– FEVEREIRO

CREATE INDEX salario_fev_idx
ON salario_fev
USING btree
(data_evento);

………………………..

– DEZEMBRO

CREATE INDEX salario_dez_idx
ON salario_dez
USING btree
(data_evento);

4 – Criando as views …..

As views vão auxiliar na vizualização dos dados particionados por mês, sendo assim, algumas views são interessantes ….

View para cada mês CORRENTE.

CREATE OR REPLACE VIEW vw_salario_jan AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario_jan a
WHERE date_part(’month’::text, data_evento) = 1
AND date_part(’year’::text, data_evento) = now()
ORDER BY a.data_evento;

CREATE OR REPLACE VIEW vw_salario_fev AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario_fev a
WHERE date_part(’month’::text, data_evento) = 2
AND date_part(’year’::text, data_evento) = now()
ORDER BY a.data_evento;

—————–

CREATE OR REPLACE VIEW vw_salario_dez AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario_dez a
WHERE date_part(’month’::text, data_evento) = 12
AND date_part(’year’::text, data_evento) = now()
ORDER BY a.data_evento;

View de anos anteriores.

Para vizualização dos anos anteriores as seguintes views

CREATE OR REPLACE VIEW vw_salario_2006 AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario a
WHERE date_part(’year’::text, a.data_evento) = 2006
ORDER BY a.data_evento;

CREATE OR REPLACE VIEW vw_salario_2007 AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario a
WHERE date_part(’year’::text, a.data_evento) = 2007
ORDER BY a.data_evento;

CREATE OR REPLACE VIEW vw_salario_2008 AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta, a.cargo
FROM salario a
WHERE date_part(’year’::text, a.data_evento) = 2008
ORDER BY a.data_evento;

View dos ultimos 6 meses apartir do 1o dia util

CREATE OR REPLACE VIEW vw_6meses_anteriores AS
SELECT a.funcionario, a.centro_custo, a.valor_resultado, a.data_evento, a.evento, a.conta,a.cargo
FROM salario a
WHERE a.data_evento >= (current_date - (date_part( ‘day’ , current_date)::integer -1)) - interval ‘6 months’
ORDER BY a.data_evento;

Bom … apartir dai .. é possivel a criação de varias views para ver os dados …
Espero que seja util para vcs como foi pra mim !!!!

Kenia Milene