Planeta PostgreSQL-BR

Claudio Bezerra Leopoldino: Coloque o PostgreSQL no seu Navegador!

cbleopoldino — 2010-08-30T10:16:28+00:00

Esse é uma dica para quem gosta de personalizar o seu computador com temas e papéis de parede.

O Personas é um complemento do navegador Firefox que permite a fácil instalação de temas. Também é possível criar a sua própria skin para o firefox, de uma forma relativamente fácil, embora demore alguns dias para a mesma passar pelo processo de aprovação. É uma oportunidade para exercer toda a sua criatividade e personalizar sua máquina!

Existem temas sobre filmes, personagens de anime, artistas e sobre softwares e é muito fácil escolher e aplicar novas opções sem afetar o desempenho do navegador. O linux, por exemplo, tem dezenas de opções!

Até a semana passada, não havia nenhum sobre o Postgres e criei o primeiro, penando muito no uso do Gimp: "PostgreSQL Simple", que aparece na imagem que ilustra este post. Espero que apareçam em breve outras opções mais criativas :)

Problemas:
- Preferível para o Firefor 3.6.* em diante, não estando disponível para outros navegadores como IE.

Claudio Bezerra Leopoldino: PostgreSQL Beta 4 Lançado!

cbleopoldino — 2010-08-30T10:07:16+00:00

Liberada nova versão de teste do Postgresql, a beta 4.

Vamos continuar testando e reportando problemas!

Notas de lançamento da versão aqui! Download aqui!

Fabio Telles: Projeto PGXN

2010-08-13T22:29:57+00:00

Todo usuário do PostgreSQL deveria conhecer o PgFoundry, lar de inúmeros projetos e extensões que tornam o nosso banco de dados ainda mais poderoso. Muitos programadores já devem ter ouvido falar do CPAN, um repositório com mais de 20 mil módulos para o PERL. Pois bem, o pessoal da PGExperts teve a ideia de criar um repositório no mesmo estilo para o Postgres.

Esta com certeza é uma funcionalidade muito interessante para a comunidade como um todo, além de facilitar a vida de muita gente. Mas é aí que VOCÊ entra. Eles montaram um site e estão pedindo a doação para financiar o desenvolvimento desta ferramenta.

A doação pode ser algo vultoso como USD5000 ou algo simples como 25 dólares. Então você, que sempre diz que gostaria de ajudar a comunidade, mas não tem tempo ou diz que não conhece tão bem assim programação e coisa e tal… chegou a sua vez de retribuir um pouco e fazer a sua doação.

Um dia nós brasileiros precisamos perder aquela fama de sanguessugas do Software Livre. Eu já fiz, minha doação, agora é a sua vez. Conheça o projeto e faça a sua parte:

PostgreSQL Extension network

Fernando Ike: FISL11: O Fim

Fernando Ike — 2010-08-02T20:12:50+00:00

O Fórum Internacional de Software Livre chegou na décima primeira edição. Com a mudança para o mês de julho e o ano 2010, digamos que literalmente (passamos) frio. Esse é um resumo de ideias que ruminaram.

Essa edição ficou nítida algumas mudanças:

Rede sem fio (wirelles/wifi) funcionou:

Incrível, não? Mas aparentemente funcionou para quem precisou usar. Os hotspots da Procempa atenderam bem quem usou, também acrescenta que muita gente já tem um modem 3g para usar com laptop ou celular com acesso a internet.

Estandes:

Esse ano não teve estande do Google e nem da Globo.com, esse ano foi a vez do Portal IG. Tinham algumas modelos com roupas inspiradas em Matrix, lógico que viraram a atração de todo evento.

Palestras:

     Foi a edição com o maior número de palestras, muita gente que nunca foi palestrante tiveram a oportunidade para falar. Isso é um dos pontos positivos da nova forma de avaliar palestras.
     O problema desse novo método é que um palestrante pode ter mais de uma palestra aprovada. Teve muita palestra fraca (não no sentido de palestra básica mas mal preparada), poderia adotar um dos critérios de avaliação dos anos anteriores que era: "um palestrante, uma palestra". Assim teria maior diversidade que já teve esse ano.
     Se tiver o vídeo no TV Software Livre, os cinco primeiro minutos de algumas palestras já mostram o quanto ruim eram. Em compensação, palestra muito boa do Igor Sysoev (NGINX).

Grupo de usuários:

O espaço deles no evento foi menor esse ano que dos anos anteriores. A maioria dos grupos tem organizado eventos específicos que podem deixados os Grupos de Usuários com pouco fôlego para estarem no FISL. Os eventos comunitários aconteceram mas em pouco número.

A PUC:

É um excelente espaço, principalmente para espantar o frio que estava em Porto Alegre.

Os palestrantes ídolos:

Jon Maddog Hall tem muitos fãs, eu sou um deles. Mas ele circulou tranquilamente por todo evento sem que houvesse grande assédio. Não só ele mas muitos outros palestrantes.

Participantes:

O perfil dos participantes está mudando. Tem diversas razões

- O Software Livre/Código Aberto de modo geral está bem mais aceito do que 10 ou 5 anos atrás. Hoje tem muitos que trabalham somente com tecnologias baseadas em SL/CA. Muitos dos profissionais do passado deixaram de ser técnicos e tornaram gerentes ou mudaram de profissão.

- Os novos participantes do FISL (generalizando) são fanboys de uma tecnologia que é SL/CA. Tanto que o carater ideológico dos anos anteriores não foi tão nítido nesta última edição. Isso também é refletido em outras formas, quantidade de computadores da Apple era bem destacado, sendo que as pessoas não se importam de usarem o Sistema Operacional proprietário da Apple.

Ao questioná-los, em muitos casos o argumento é que o Hardware é melhor (além de te olharem atravessado durante todo evento), Porém se o critério é melhor por que não usam a Máquina Virtual do .NET que é melhor que as outras máquinas virtuais? Ou por que não usam uma linguagem proprietária que é melhor que alguma SL/CA.

Creio que isso seja relfexo do debate sobre Código-Aberto (Eric Raymond) e Software Livre (Richard Stallman). A

Conclusão:

O FISL mudou, difícil dizer para melhor ou pior, reflexo da mudança das diversas áreas das sociedades que tiveram penetrado as ideias de SL/CA. O FISL está mais diversificado, essa diversificação irá refletir no futuro na própria extinção do FISL. A pulverização de eventos relacionados a SL/CA só irá aumentar.

O FISL como eu conheci ou como você conhece, daqui 5 anos será completamente diferente. Nem tão corporativo, nem tão técnico, nem tão ideológico, só diferente.

PS. Não comentei mas é sempre bom encontrar as pessoas envolvidas no PostgreSQL e no Debian.

Fernando Ike: Beta 3 do PostgreSQL 9.0

Fernando Ike — 2010-07-28T00:13:47+00:00

Original da imagem aqui.

Já tem alguns dias mas vale o recado. Saiu o Beta 3 da nova versão do PostgreSQL (9.0), muitas correções no hot stanby que é uma novas funcionalidades mais aguardadas no PostgreSQL.

Fernando Ike: Dica: Artigo sobre replicação nativa do Postgres 9.0

Fernando Ike — 2010-07-26T17:36:31+00:00

O pessoal da Softa escreveu sobre o teste que eles fizeram com uma funcionalidade adicionada na versão 9.0 do PostgreSQL 9.0 que é a replicação por Hot Standby.

Vale à pena conferir, link aqui.

Claudio Bezerra Leopoldino: PostgreSQL Feature Matrix!

cbleopoldino — 2010-07-07T12:42:01+00:00

Você sabe a partir de que versão o Postgres implementa a cláusula RETURNING ou cursores atualizáveis? Essas informações são importantes para a compatibilidade entre as várias versões do SGBD, assim como para acompanhar a evolução da ferramenta a cada ciclo de desenvolvimento, e estão disponíveis na PostgreSQL Feature Matrix!

Atualmente a matriz de funcionalidades oficial do postgres apresenta as mudanças originadas nas versões 7.48 até 9.0, beta 2.

João Paulo (Jota): Im back

jotacomm — 2010-06-04T22:28:07+00:00

Olá, pessoal

Estou de volta após um longo período de inatividade. Em breve novos posts sobre PostgreSQL.

Abraços

Claudio Bezerra Leopoldino: PostgreSQL 9.0: Quais são as novidades? A visão das "funcionalidades da semana" - Parte 2!

cbleopoldino — 2010-05-31T08:35:44+00:00

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

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

31/05/2010 - Esta semana não teve "funcionalidade da semana". Nas colunas anteriores a coluna era escrita por David Fetter e Devrim GUNDUZ, mas o segundo não participou da coluna desta semana. Pode ser que a feature of the week volte, ou não...

23/05/2010 - Objetos grandes (lo_ *) agora possuem controles de acesso, como os demais objetos do banco de dados. É mais um fator positivo para a utilização de LOBs em geral.

16/05/2010 - O utilitário pg_ctl agora tem uma opçao initdb. Esta opção inicializa um servidor postgres. Mais informações aqui.

09/05/2010 - Você pode criar triggers por coluna, ou seja, que são disparads somente na modificação das colunas especificadas. Recurso utilíssimo!!!

A sintaxe, como descrita no SQL: 2008, é: CREATE TRIGGER trigger_name (BEFORE | AFTER) UPDATE OF col1 [,] ... ON col2 coln tablename FOR EACH ROW trigger_function PROCESSO EXECUTE ();

02/05/2010 - Agora você pode chamar funções com parâmetros nomeados, por exemplo, parameter_bar foo ('valor' AS parameter_foo, o valor 'outro' AS).

Recurso muito prático se você lembra o nome dos os parâmetros, mas não a ordem em que estão na declaração da função.

25/04/2010 - Funções podem agora ter valores padrão para parâmetros. Ótima e simples idéia!!!

18/04/2010 - GUCs agora são reguláveis por função e por banco de dados.

Você sabe o que é GUC? Global User Configuration (GUC) são configurações de servidor do arquivo postgresql.conf. Poder definir parâmetros de servidor para cada função é ter mais flexibilidade. Mas a forma como isso será implementado não parece clara ainda.

11/04/2010 - "You can now GRANT and REVOKE on objects schema-wide in a single command".

Mais recursos para configurar permissões de acesso, desta vez afetando todo o esquema do banco com apenas um comando. Faltam mais detalhes.

04/04/2010 - Existe agora um comando chamado ALTER DEFAULT PRIVILEGES, o qual permite o ajuste de privilégios que serão aplicados a objetos a serem criados no futuro.

É uma opção boa para préconfigurar os objetos do banco de dados utilzando grant e revoke para tabelas, sequências e funções.

01/04/2010 - "Distributed map-reduce functions in Erlang". Desconsiderem todo anúncio da equipe do Postgres feito no primeiro de abril!!!

Claudio Bezerra Leopoldino: PostgreSQL 9.0: Quais são as novidades? A visão das "funcionalidades da semana" - Parte 1!!!

cbleopoldino — 2010-05-31T08:32:49+00:00

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

28/03/2010 - Implementação do conceito de blocos anônimos de código (anonymous code blocks) através do comando DO nas linguagens PL/pgsql, PL/Perl, e PL/LOLCODE.

Estes blocos compreendem comandos que podem ser executados em um bloco de código sem um nome, utilizando as poderosas linguagens procedurais do PostgreSQL. Desta forma podem ser executados blocos de código sem que se precise criar funções dentro do banco. Parece uma ótima forma de se criar scripts.

O exemplo abaixo eu peguei aqui:

DO $$DECLARE r record;
BEGIN
  FOR r IN SELECT table_schema, table_name FROM information_schema.tables
           WHERE table_type = 'VIEW' AND table_schema = 'public'
  LOOP
      EXECUTE 'GRANT ALL ON ' || quote_ident(r.table_schema) || '.' || quote_ident(r.table_name) || ' TO webuser';
  END LOOP;
END$$;

21/03/2010 - Campos do tipo Hstore não tem mais o limite de 64kB para o limite de chaves e suportam árvore B e classes de operadores hash, permitindo GROUP BY, DISTINCT, etc.

Obs: Você sabe por acaso o que é HSTORE? Eu também não sabia, mas é um módulo que implementa um tipo de dados chamado HSTORE que agrega ao mesmo tempo uma chave e um valor, ambos strings. Este novo tipo de dado é útil para uma série de cenários. Mais informações podem ser obtidas aqui.

14/03/2010 - Em PL/pgsql, o comando MOVE agora funciona de forma compreensível com Cursores.

Obs: Não deu para entender o problema que havia antes, mas este comando reposiciona o cursor sem recuperar dados (NEXT, PRIOR, FIRST, LAST, ABSOLUTE count, RELATIVE count, FORWARD, ou BACKWARD).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abaixo, a redação oficial da coluna:

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

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

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

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

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

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

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

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

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

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

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

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

O que acharam destas novas funcionalidades?

Elas impactarão o seu trabalho atual?

Claudio Bezerra Leopoldino: Participe do PgDay de Brasília 2010!

cbleopoldino — 2010-05-28T11:34:03+00:00

Faltam poucos dias para o PgDay em Brasília! Informe-se e se inscreva aqui.

Fabio Telles: PGDay Brasília em 31/05

2010-05-11T15:11:36+00:00

Atualização

Se inscreva no site do evento, vagas limitadas.

Sim, este ano tem Copa do mundo, eleição, e claro PGCon e PGDay.

O blog podia estar parado, mas a comunidade brasileira de PostgreSQL continua a todo o vapor. Já tivemos o PGDay BA, em Ilhéus, e em breve deverá sair a data do PGDay RJ. O próximo será o PGDay DF, em 31/05 no SERPRO. Então fiquem antenados para as inscrições no evento.

Palestrantes confirmados:

Nesse eu vou!

Bom, fui convidado para o evento e se nada der errado (fui escalado para uma migração na data do PGDay BA) estarei lá. Nada, já fiz uma mega amarração no trabalho, o meu chefe vai me substituir! Nesse eu vou mesmo.

Me ajude a escolher o tema para a palestra no PGDay DF!

Ocorre que o pessoal me deixou a vontade para escolher o tema da palestra. Eu que sou preguiçoso tenho uma forte tendência a reciclar artigos e palestras anteriores. Claro que para o PGCon Brasil, a gente sempre tras coisa nova, mas com menos de 20 dias para preparar a palestra (é claro que não estar na organização do evento já ajuda muito) a chance de eu dar uma atualizada em uma palestra antiga aumenta.

Então gostaria de saber se alguém tem alguma sugestão para o PGDay DF. Pode ser um artigo aqui do blog, pode ser uma palestra minha no Slide Share, ou pode ser um tema novo. Comentários com sugestões aqui no blog, até o final da semana (que é quando eu vou começar a mexer nisso) são bem vindos. É claro que se eu não mandar logo a descrição da palestra para a organização o povo lá me mata também!

http://postgreslogia.wordpress.com/

Fabio Telles: Dump não é backup!

2010-05-06T17:01:21+00:00

Não, não é. Pode chorar, pode xingar mas não é.

No ano passado fiz uma pesquisa aqui no blog sobre as rotinas de backup utilizados no PostgreSQL. O resultado foi que a maioria esmagadora só utiliza o pg_dump. Veja, eu não tenho absolutamente nada contra o pg_dump. Mas antes de me explicar, vamos pensar… PARA QUE SERVEM OS BACKUPS MESMO?

Se eu fizer uma pesquisa, 10 entre 10 irão dizer: para se recuperar em caso de desastres! Simples assim, eu faço uma cópia dos dados e caso tudo dê errado eu restauro a minha cópia e volto a trabalhar.

Simples não?

NÃO.

Não tem nada de simples nisso. Vamos avaliar melhor o caso. Primeiro temos que entender o que é “tudo dê errado”. Podem acontecer várias coisas diferentes…

Quanto tudo dá errado!

Desastre natural
O CPD pegou fogo, inundou (eu já vi acontecer), teve um terremoto, jogaram um avião no prédio… bom, nestes casos só um stand by em outro prédio (ou outra cidade, outro país) resolve a situação. Mas você bem que poderia guardar os seus backups fora do prédio onde está o CPD, não?
Falha de hardware (exceto os discos)
Um problema no hardware do servidor, que não seja o disco. Neste caso, basta substituir a peça com defeito e voltar a trabalhar, certo? Errado. Quem disse que você tem pentes de memória, fontes, processadores ou mesmo uma placa-mãe sobressalente para substituir naquele servidor. E no caso de você trocar algo como uma placa-mãe, provavelmente vai trocar por outro modelo, o SO pode se desentender com ele e pode exigir algum tipo de ajuste no SO.
Isto leva tempo, mas não exige que se mexa com backup, certo? Errado. Se você não pode esperar até uma nova peça chegar, você vai querer subir o seu banco de dados em outro servidor o mais rápido possível, e aí sim você vai precisar do seu backup.
Falha nos discos
Um problema físico num disco ou no seu storage. Bom, se você utiliza RAID (RAID 0 a princípio não é RAID e se você utiliza RAID 0 para guardar seus dados, saiba que existe um lugar especial no inferno reservado para você) e tem um Hot Spare configurado, você não precisa fazer nada naquele momento. Todo Storage descente não permite a criação de RAID sem o Hot Spare.
Se você tem um storage e paga o seu caríssimo contrato de manutenção, tudo que você terá de fazer e dizer para o técnico do storage entrar e substituir o disco. Em geral quem vai lhe avisar que um disco está com problema é o técnico que chegou para trocar o disco. Os storages devem ser monitorados remotamente pelo fornecedor. Em caso de defeito eles mandam um técnico para resolver o problema ANTES de você notar que perdeu um disco.
Mas, a vida não é perfeita, storages são caros e os contratos de manutenção também. Se você tem um RAID na sua controladora local e teve uma falha em um disco, provavelmente a vida vai continuar e você não vai nem perceber. É aí que mora o perígo. Alguém tem que monitorar os logs do SO para saber que um disco apresentou problema, apesar de tudo continuar funcionando. Se você não perceber isso, então a próxima falha no próximo disco (como os discos são comprados em geral do mesmo lote, eles tem esse péssimo hábito que queimar mais ou menos na mesma época…) vai gerar uma paralisação total dos banco. Aí você volta para o item 1 e com certeza vai ter de utilizar o seu backup para restaurar os dados. Isso se você não tiver aquela idéia maravilhosa de guardar os seus backups justamente naquele disco / RAID que deu problema. Assim fica a dica: monitore os logs do seu SO e nunca guarde o seu backup no mesmo disco que os seus dados.
Ok, o hardware está ótimo, mas o SO egripou do nada
Pegou um vírus (sem comentários), deu uma tela azul (pode escolher outra cor, o efeito é o mesmo) da morte ou um mesmo um kernel panic. Uma atualização do SO fez com que tudo o mais travasse. O banco de dados não sobe mais. Você pode até tentar reinstalar o SO, limpar o vírus, etc e tal. Mas se isso demorar, você vai querer voltar o backup em outro servidor;
O sistema de arquivos corrompeu
Após uma falta de energia, quando o luz voltou você teve uma grata surpresa: justamente a partição onde os dados estavam se corrompeu. Não vou entrar no mérito sobre qual sistema de arquivos é mais seguro agora. Ok, já vi gente que queria rodar um SGDB num Pen Drive… FAT não deveria servir para guardar nem base em .mdb! NTFS corrompe muito, mas EXT3, EXT4, ReiserFS, XFS, JFS, UFS, ZFS e outros também corrompem. Se você inventar de fazer um “ajuste de desempenho” no ser sistema de arquivos então…
Bom, se a ferramenta do seu sistema de arquivos não conseguir restaurar os dados em 100%, já viu… Formate tudo e volte o backup;
Um DBA ou sysadmin desastrado foi lá e apagou/alterou/moveu um arquivo do banco de dados
Vai corromper na hora. Volte o seu backup… e dê uma bronca ou PNB* no funcionário que fez esta besteira. Se foi o seu estagiário que fez isso, então peça demissão. Quem mandou deixar o estagiário chegar perto do seu banco de dados?
O banco de dados corrompeu por uma falha do próprio banco de dados
É raro mas acontece. Você vai ter que verificar os logs do SO e do banco para entender o que aconteceu. Pode ser preciso aplicar um patch no servidor ou implementar um “workarround”, mais conhecido como gambiarra. Depois de entender minimamente a causa do problema e tomar providências para que isso não ocorra novamente, você vai ter de voltar o seu backup;
Um usuário desastrado apagou uma tabela ou outro objeto do banco de dados
Primeiro você vai se perguntar: quem deu permissão para o usuário apagar alguma coisa no banco de dados? Se o usuário for um desenvolvedor, ídem. Se for o sysadmin, ídem. Se for o DBA… bom, sobra a bronca ou PNB*. E você vai ter que voltar o seu backup para o momento anterior ao desastre. É um detalhe importante. Tem gente que só nota a besteira dias depois de feita a besteira. Se você voltar o backup feito depois da besteira, vai continuar com o mesmo problema. Identifique quando o problema ocorreu antes de voltar o backup.

Outros usos para o backup

Você pode utilizar o seu backup para outras coisas além de recuperação de desastres:

Mover dados entre bases. Particularmente atualizar dados de homologação com os dados da produção. Operação bastante comum em que se utiliza o backup. Sempre que você quer fazer um teste de performance ou validar uma atualização da aplicação, alguém solicita uma atualização deste tipo.
Auditoria. Você pode guardar backups realizados após fechamentos cíclicos (como mensal ou anual) para efeito de auditoria. Estes backups são em geral guardados por vários anos, pelo menos 5 anos em geral.
Criação de novos ambientes de homologação / teste. É muito comum projetos específicos exigirem análises destrutivas dos dados e para isso utilizarem uma base/esquema separados para isso.

O tal do SLA

Antes de definir a sua estratégia de backup, você deve determinar qual o seu SLA ou Service Level Agreement. Seja pessimista e defina o quanto você pode suportar em caso de desastre. Não adianta dizer que você quer 100% de alguma coisa. 100% não existe e os famosos “five nines” ou 99,999% custam uma verdadeira fortuna. O cofre não pode ser mais caro que o ouro que você guarda. Então pense com realismo (ou pessimismo, como você preferir) nos seguintes limites:

Quanto tempo você pode ficar com o banco de dados indisponível em caso de parada não prevista em horário comercial? E se for em horário não comercial?
Quanto tempo você pode ficar com o banco de dados indisponível em caso de uma parada prevista (uma manutenção) em horário comercial? E se for em horário não comercial?
Respire fundo…. você pode perder dados relativos a quanto tempo de operação?

Ok, a resposta para as 3 perguntas sempre deveria ser ZERO. Mas como eu já disse, não existe como garantir isso, e chegar perto disso custa muuuito caro. Cada uma das suas respostas vai te levar para uma estratégia de backup diferente.

Tempo necessário para restaurar um backup em caso de desastre.

Este é um ponto crítico que poucos sabem responder. Então vejamos como calcular isso. O tempo vai variar muito conforme alguns fatores:

Você já testou uma restauração completa do backup?
Você tem equipe disponível no local para fazer a restauração?
Você tem equipe disponível para fazer a restauração fora do horário comercial?
As pessoas disponíveis para fazer a restauração fora do horário comercial tem acesso remoto ao servidor?
Você tem o procedimento de restauração documentado em papel?
A documentação está atualizada?
Você tem hardware de contingência disponível?

Vamos ao cálculo:

Tempo de restauração do hardware. Se você tem peças sobressalentes e equipe adequada, isso deve ser rápido, mas tem gente que sai no meio de um feriado buscando uma peça para comprar. Se for um órgão público então… O ideal é ter um servidor de Stand by para o banco de dados. Isso vai lhe poupar de toda a dor de cabeça de ir atrás de hardware;
Tempo para restaurar o SO. Se você tiver que reinstalar o SO num novo servidor, quanto tempo isso leva? A documentação da instalação está disponível e atualizada? As mídias de instalação na mesma versão do servidor de produção estão disponíveis? Equipe para a instalação disponível? Novamente, um servidor de stand by vai lhe poupar este tipo de dor de cabeça e fazer você pular esta parte.
Tempo para restaurar o SGDB. Se você tiver que reinstalar o PostgreSQL num servidor novo, quanto tempo isso leva? E as mesmas considerações para o SO são válidas. E novamente o Stand by é uma opção que pula esta etapa.
Quanto tempo leva para restaurar o backup (alguns chamam isso de “restore”) para o disco do servidor. Se você utiliza fita, isso pode levar um tempo considerável. Se antes de copiar para a fita você faz uma cópia para outro servidor, pode ser mais rápido. Se o backup for grande, uma rede gigabit ou uma conexão Fibre Channel numa BAN (Backup Area Network) pode fazer toda a diferença. Sim, backup custa bem mais caro do que parece. Sim, mais uma vez o stand by permite a você pular esta etapa, para a maioria dos casos (se você precisa voltar o backup de uma versão mais antiga, o stand by não vai resolver o seu problema)
Quanto tempo leva para fazer a recuperação do banco de dados a partir do backup (alguns chamam isso de “recover”). Aqui a sua estratégia de backup vai fazer toda a diferença. Vamos falar mais longamente sobre este aspecto logo mais.

Bom, supondo que você tenha uma base de até 1GB, sem muitas demandas de desempenho, tudo fica simples. Você pode instalar o PostgreSQL em qualquer servidor com um pouco de folga no desempenho e alguns GB de espaço em disco sobrando em subir um dump guardado em outro servidor. Pode não levar mais do que uns 30 minutos para fazer tudo. Neste caso o pg_dump parece fazer sentido.

Agora se você precisar subir um novo servidor dedicado para abrigar uma base com 100GB, então você terá problemas com o pg_dump. Importar um dump para criar uma base de 100GB deve levar várias horas. Se a base tiver alguma tabela muito grande, você poderá precisar fazer ajustes específicos para conseguir recriar seus índices. Se a base tiver algo em torno de 500GB por exemplo, isso pode levar dias. Mesmo com a paralelização do processo, se você souber fazer isso com cuidado.

Como evitar a perda de dados?

Outro problema com o pg_dump. Quanto tempo de operação em produção você está disposto a perder? Suponha que você faça o backup toda madrugada, e seu desastre ocorra no final da tarde. Se você voltar o seu backup, você vai perder todas as alterações realizadas ao longo do dia. Isso é muito grave e intolerável para a maioria dos ambientes OLTP. É claro que você pode realizar o pg_dump mais de uma vez por dia, mas fazer isso em horário comercial costuma ter um impacto muito negativo na performance. Quais as soluções para contornar este problema?

Replicação: existem N ferramentas de replicação. Algumas síncronas, outras assíncronas. Existe uma excelente documentação sobre os principais tipos de replicação para PostgreSQL. De qualquer forma, podemos categoriza-las em:
- As ferramentas síncronas garantem a perda ZERO de dados. Cada vez que um COMMIT é realizado no servidor de produção, outro COMMIT é realizado na réplica. Somente após o COMMIT ser realizado com sucesso na base de produção e na réplica é que a operação prossegue. Resultado: ZERO em perda de dados e um gargalo de performance terrível. Para conseguir ter uma performance razoável com replicação síncrona, você vai ter que gastar muito em hardware e em ajustes de performance.
- As ferramentas assíncronas não garantem ZERO de perda de dados, todos possuem algum atraso na sincronia entre o servidor de produção e a réplica.
Point In Time Recovery: é uma técnica que consistem em fazer uma cópia do WAL (Write Ahead Log) do PostgreSQL e utilizar estas cópias para atualizar um backup até um horário específico. O PITR é uma técnica consagrada em todos os SGDBs sérios do mercado. Você não precisa instalar nenhum software extra para faze-lo funcionar. O PITR também não penaliza o desempenho do seu servidor, uma vez que o WAL já é gerado normalmente. O único overhead é a cópia deles. Você também pode ajustar o intervalo máximo entre as cópias do WAL, o que lhe permite um ajuste do período máximo de perda de dados que você terá com o PITR (ele é assíncrono então não garante perda ZERO de dados).

Se você escolher logo uma estratégia de replicação, pense em primeiro lugar no Stand by. Com o lançamento da versão 9.0 o Stand by sofreu melhorias importantes e tudo indica que a próxima versão terá mais melhorias ainda. Combinar um Stand By com outras técnicas de backup é a melhor forma de se proteger contra a perda de dados e o downtime. Você estará utilizando uma solução nativa, relativamente simples, bem testada e documentada, com baixo impacto em performance e com um custo realmente baixo em comparação com outras alternativas.

Backup físico, o primeiro passo.

É claro que apesar de recomendar o uso do stand by, ele não é algo tão simples e barato assim. Você precisa de um servidor com capacidade semelhante ao de produção para suportar a mesma carga, lembre-se disto. Novamente, existe excelente documentação sobre como criar um standby. Você também precisa aprender com perfeição a fazer backups físicos e saber restaurá-los de forma adequada.

Existem dois tipos de backup físico, o frio e o quente. O frio é feito com o banco de dados desativado. Você copia todos os arquivos do banco (inclusive os de configuração) e depois reativa o banco de dados. Este método é muito simples e seguro, mas tem aquele problema básico: você precisa tirar o banco de dados do ar. Se você não tem janela para isto ou o seu sistema é 24X7, então você terá que recorrer ao backup quente. O quente é um pouco mais complicado, pois exige que você avise o PostgreSQL quando vai começar a copiar os arquivos e quando terminou. Ele também EXIGE que você faça a cópia dos logs do WAL, utilizando o parâmetro “archive_command“. Não vou me alongar sobre o assunto aqui. Leia a documentação atentamente sobre isso.

Depois que você se tornar um expert em fazer backups e recuperações de backups físicos quentes, já estará de quebra fazendo o PITR de forma natural e estará pronto para fazer o seu Stand By, que utiliza o backup quente como princípio para a sua criação.

Então eu não preciso mais do pg_dump?

Precisa sim. Não para a recuperação de desastres, mas para os outros casos mencionados. Suponhamos que você precisa restaurar um backup feito há 8 anos atrás. Provavelmente o servidor onde este backup foi gerado não existe mais. Talvez o DBA que criou o procedimento de backup não trabalhe mais na empresa. Certamente o SO e a versão do SGDB mudaram, pode ser que você não tenha mais versões compatíveis disponíveis. Então o backup físico não é indicado para estas situações. Ele é adequado para recuperação de desastres, mas não para reter backups por um longo período. Com um backup feito pelo pg_dump, você pode migrar os dados para outra versão do PostgreSQL ou até mesmo para outro SGDB.

E tem mais um detalhe, backups físicos são monolíticos. Você precisa restaurar o banco de dados no mesmo SO, com a mesma versão do PostgreSQL, com a mesma estrutura de diretórios, o mesmo sistema de arquivos e além de tudo precisa restaurar o banco de dados inteiro. Suponhamos que você só precise de algumas tabelas, o pg_dump oferece todo o tipo de flexibilidade para restaurar apenas uma parte dos dados.

Estratégia de backup.

Ok, o pg_dump não é O backup, ele é parte de uma estratégia de backup. Você precisa do pg_dump para gerar backups esporádicos e guarda-los por um longo período. Para a recuperação de desastres você deve ter um backup físico (quente ou frio), cópia dos logs do WAL e cópia dos arquivos de configuração. Você não precisa guardar o backup físico pro muito tempo, alguns dias é razoável. Depende de quanto você deseja voltar no tempo se necessário, e de quanto você confia na sua mídia de armazenamento. Lembre-se da máxima: quem tem um backup não tem nada. Faça o backup físico uma vez por dia e não sobreescreva o backup do dia anterior. Você pode fazer o backup físico para o disco em outro servidor e gravar este backup em fita diferentes todos os dias por exemplo. Já a cópia do WAL é feita automaticamente, mas deve ser copiada para fora do servidor também, se não imediatamente no comando do “archive_command”, faça isso em intervalos curtos para evitar a perda de dados em caso de desastres.

Conclusões :

(atualizado em 17/05/2010)

Backup não é simples, mesmo em bancos de dados pequenos;
Backup exige estudo, dedicação e disciplina;
Backup não deve ser responsabilidade de estagiários, deve ser criado e verificado diariamente por pessoas qualificadas e de confiança;
Backup é caro: os recursos de hardware são caros e os recursos humanos também;
Nunca diga que você está 100% seguro, você não está;
Você pode e deve estimar o tempo para se recuperar de desastres e qual o SLA que você pode entregar com os recursos disponíveis. Documente isso e protocole a entrega deste documento junto ao seu superior. Sim, isto pode salvar o seu emprego e de toda a sua equipe junto. Sua família agradece.

Atualização:

Em tempo, existe uma nova ferramenta para backup incremental chamada pg_rman. Sim, é um clone do RMAN do Oracle para o PostgreSQL. A ferramenta é relativamente nova, mas parece que o projeto está bastante ativo. Alguém aí já testou?

OBS: Gostaria de dedicar este humilde texto à todos aqueles que me contrataram para recuperar seus bancos de dados (desculpe, somente àqueles que não me deram calote depois, os que não pagaram vão para o mesmo lugar daqueles que utilizam RAID 0). Àqueles que sofreram durante madrugadas intermináveis com a pressão de não saber se a empresa voltaria a funcionar no dia seguinte e todas as conseqüências que daí decorrem.

* PNB = Pé Na Bunda, demissão mesmo.

Claudio Bezerra Leopoldino: Erros de "Permission Denied na Criação de Tablespaces"

cbleopoldino — 2010-04-20T08:39:12+00:00

Em muitos casos os problemas que mais incomodam são os mais simples. No caso do Postgresql, um problema bem comum mas que causa estresse é a falta de permissão para a criação de tablespaces.

Tablespaces permitem um maior controle sobre a localização física dos dados, metadados, índices e estatísticas do banco. Informações sobre criação de tables paces podem ser obtidas aqui. O postgresql utiliza o sistema de arquivos fornecido pelo sistema operacional, o que muitas vezes gera problemas de autorização de acesso que impedem a sua criação, o clássico erro "permission denied".

Neste post vamos mostrar como definir corretamente as permissões para criação de tablespaces em ambiente windows.

Passo 1: Criar pasta do tablespace.
Crie uma pasta sem arquivos dentro para a definição do novo tablespace.

Passo 2: Abrir tela de configuração
Entre no Windows Explorer e acione o menu "Ferramentas/ Opções de Pasta...".
O sistema apresentará uma tela com as opções de pasta.
Desmarque a opção "Usar Compartilhamento Simples de Arquivo (Recomendado)" e confirme a operação. Isso habilitará a aba de segurança das pastas, que serrá utilizada para definir as permissões para a criação do tablespace.

Passo 3: Configuração da segurança da pasta
Na pasta criada para o tablespace, clique com o botão direito e acione o menu “Propriedades”.

Em seguida, clique na aba segurança.

Na tela apresentada, clique em “Adicionar”. Aparecerá uma tela como a que aparece abaixo. Defina o local (no botão "Locais") e, no nome do objeto, coloque o usuário do banco que vai ter acesso ao tablespace. Confirme com o botão “OK”.

Na aba de segurança aparecerá o novo usuário. Marque a opção de “Controle Total”, o que fará com que o banco de dados possa efetivamente acessar o tablespace.

Passo 4: Criação do tablespace.

Utilize para isso o comando CREATE TABLESPACE.

Este post teve contribuição de Jeferson Gallina.

Claudio Bezerra Leopoldino: Versão Alfa do PostgreSQL 9.0 Lançada!

cbleopoldino — 2010-03-01T13:57:17+00:00

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

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

Faça o download aqui!

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

Claudio Bezerra Leopoldino: Select - Cláusulas FOR UPDATE, FOR SHARE e NOWAIT

cbleopoldino — 2010-02-19T10:10:44+00:00

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

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

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

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

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

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

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

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

Exemplos:

1 - Sintaxe simples com FOR UPDATE.

SELECT * FROM pai FOR UPDATE;

2 - Sintaxe simples com FOR SHARE.

EXPLAIN SELECT * FROM pai FOR SHARE;

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

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

4 - Uso de NOWAIT.

SELECT * FROM pai FOR UPDATE NOWAIT;

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

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

Claudio Bezerra Leopoldino: Algoritmos: Caixa de Banco Simulado no PostgreSQL

cbleopoldino — 2010-01-27T16:51:44+00:00

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

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

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

Chamada da função e resultado apresentado:

SELECT caixa_elet(1078);

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

SELECT caixa_elet(2189);

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

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

Aguardo suas contribuições nos comentários!

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

cbleopoldino — 2010-01-21T14:43:43+00:00

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

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

Você concorda com essa atitude?

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

cbleopoldino — 2009-12-18T17:27:27+00:00

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

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

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

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

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

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

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

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

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

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

Claudio Bezerra Leopoldino: GreenSQL: O Rinoceronte Amigo do Elefante!

cbleopoldino — 2009-12-17T16:11:36+00:00

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

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

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

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

Claudio Bezerra Leopoldino: Enquete aponta que PostgreSQL Crescerá com a Compra do MySQL

cbleopoldino — 2009-12-10T10:50:55+00:00

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

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

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

O artigo original pode ser obtido aqui.

Rodrigo Hjort: PostgreSQL monitoring on ZABBIX

Rodrigo HJORT — 2009-12-08T06:12:39+00:00

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

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

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

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


# PostgreSQL custom parameters

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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

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

References:

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

PostgreSQL Brasil: Agenda Livre

2009-12-07T11:19:58+00:00

A agenda livre é um lugar para compartilhar com todos os eventos de tecnologia e software livre que acontecem no país. Se você quiser participar ou compartilhar esta agenda, basta colocar o código abaixo no seu portal.

<iframe src='//www.google.com/calendar/embed?height=600&wkst=1&bgcolor=%23ffffff&src=c1lp1q1iv9s2p6of0pi5g38gqg%40group.calendar.google.com&color=%2328754E&ctz=America%2FSao_Paulo' style=' border-width:0 ' width='100%' height='600' frameborder='0' scrolling='no'></iframe>

leia mais

Claudio Bezerra Leopoldino: O Comando Table

cbleopoldino — 2009-11-27T09:52:51+00:00

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

Consultas com a sintaxe abaixo, por exemplo:

SELECT * FROM tabela;

Poderiam ser simplificadas para:

TABLE tabela;

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

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

Exemplo 1:

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

Exemplo 2:

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

Exemplo 3:

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

Exemplo 4:

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

Rodrigo Hjort: Auction5 sample web application released

Rodrigo HJORT — 2009-11-07T18:52:02+00:00

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

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

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

Please send me your comments and or suggestions.

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

PostgreSQL Brasil: Replicação de dados com java

2009-11-04T00:06:55+00:00

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

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

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

Outros links sobre replicação:

leia mais

Leandro Guimarães Faria Corcete DUTRA: Convite Google Wave

DUTRA, Leandro Guimarães Faria Corcete — 2009-10-31T22:50:09+00:00

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

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

PostgreSQL Brasil: PGCon Brasil 2009

2009-10-31T00:11:54+00:00

João Cosme: HA em Postgresql = Warm Stand By + HeartBeat + HAPM

joaocosme — 2009-10-30T17:49:57+00:00

Prefácio hehehe

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

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

Mandando o SALVE!!

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

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

Um salve pro Minerin “Cara de coveiro”…

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

Um salve pro Jovem “J”

Um salve pro Telles

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

Um salve pro Diogo Biazus

Um salve pro pequeno inseto (Ele sabe quem é)

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

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

Um salve pro GUTO de BSB….

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

Um salve pro DUTRA.

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

Um salve pro …. pra……

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

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

Um salve pro Emanuel “EL Aprendiz” da Argentina !

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

Voltando ao Post….

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

Cenário

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

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

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

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

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

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

Configurando o Ambiente!

Anota ai jovem…

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

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

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

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

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

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

Como usuário root:

mkdir /psql-archive

chown postgres.postgres /pgsql-archive

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

exportfs -a

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

O que os comandos acima fazem??

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

Agora na máquina primária

mkdir /psql-archive

chown postgres.postgres /psql-archive

mount IP_SLAVE:/psql-archive /psql-archive

O que os comandos acima fazem??

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

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

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

archive_mode = on

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

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

Vamos por partes!!!

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

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

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

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

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

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

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

Reiniciar o serviço do PostgreSQL

/etc/init.d/Postgresql-8.3 restart

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

Prova dos 9!

Vamos lá…

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

psql -U postgres

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

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

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

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

\q para sair

postgres=# select pg_start_backup(‘meu_backup’);

pg_start_backup

2/CE005F40

(1 registro)

postgres=# \q

# su – postgres

# cd /var/lib/Postgresql/8.3/

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

tar: Removendo `/’ inicial dos nomes dos membros

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

…..

…..

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

psql -U postgres -h localhost

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

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

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

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

\q para sair

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

postgres=# select pg_stop_backup();

pg_stop_backup

—————-

2/D000BC0C

(1 registro)

postgres=# \q

Na máquina secundária novamente

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

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

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

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

tar -xzvf /var/lib/Postgresql/8.3

Mandando bala descompactando o danado…

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

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

rm -Rf ./pg_xlog/*

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

Vamos vamos…. Vamos !!!!!

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

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

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

Iniciando o servidor Stand by

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

* Starting Postgresql 8.3 database server

[ OK ]

# tail -f /tmp/pg_standby.log

Keep archive history : 000000000000000000000000 and later

running restore : OK

Trigger file : /psql-archive/trigger.done

Waiting for WAL file : 000000020000000200000088

WAL file path : /psql-archive/000000020000000200000088

Restoring to… : pg_xlog/RECOVERYXLOG

Sleep interval : 60 seconds

Max wait interval : 0 forever

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

Keep archive history : 000000000000000000000000 and later

Que lindo Que lindo …. Vamos Vamos…

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

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

#psql -U postgres -h localhost

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

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

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

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

Começaremos a gerar alguns arquivos Wals .

# psql -U postgres

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

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

\h para ajuda com comandos SQL

\? para ajuda com comandos do psql

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

\q para sair

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

SELECT

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

SELECT

postgres=#\q

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

# ls -l /psql-archive

total 738184

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agora criaremos o arquivo /tmp/trigger.done.

touch /psql-archive/trigger.done

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

To be continued…

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

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

2009-10-26T18:26:43+00:00

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

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

Fabio Telles: COMMIT

2009-10-25T10:37:24+00:00

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

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

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

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

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

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

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

YES, WE CAN!!!

IS DONE

IS JUST THE BEGINING…

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

Rodrigo Hjort: Echoing hidden psql statements

Rodrigo HJORT — 2009-10-18T20:40:39+00:00

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

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

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

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

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


# \set ECHO_HIDDEN

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


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

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

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

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


# \unset ECHO_HIDDEN

That's it! :D

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

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

2009-10-14T09:16:37+00:00

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

Faça já sua inscrição!

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

Ribamar FS: Dicas e Truque do SQL no PostgreSQL

ribafs — 2009-10-08T15:31:34+00:00

Trabalhando com SQL

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

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

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

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

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

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

Uso do Like e de Expressões Regulares

Registros:
Ribamar Ferreira de Sousa
João Pereira Brito

Usando LIKE e ILIKE

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

Usando Expressões Regulares

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

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

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

5) Exemplos de Joins

Join com 4 tabelas

$w_sql = ” TRUE “;

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

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

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

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

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

7) Renomear Tabela
ALTER TABLE tabela RENAME TO nomenovo;
ALTER TABLE produtos RENAME TO equipamentos;

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

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

Tamanho de Tabela
select pg_tablespace_size(’nometabela’);

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

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

9) Validação de e-mails

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

10) Temos um campo (insumo) com valores = 1, 2, 3, … 87
Queremos atualizar para 0001, 0002, 0003, … 0087

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

Outra saída mais elegante ainda:

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

11) Retornar o número de usuários conectados
select count(*) from pg_stat_activity

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

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

select * from pg_stat_user_indexes;

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

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

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

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

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

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

Visualizar os processos do portgresql num UNIX:

ps auxww | grep ^postgres

Formato de retorno:
postgres: user database host activity

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

SELECT datname, age(datfrozenxid) FROM pg_database;

age acusa mais de 2 bilhões

Tarcizio Meurer

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

<?php

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

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

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

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

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

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

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

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

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

?>
14) Uso da Constraint check

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

Alternativas:

check (preco > desconto)

check (desconto > 0 AND preco > desconto)

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

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

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

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

Manutenção em Tabela
vacuum analize tabela;

Reindexar Banco, tabela ou índice
reindex database banco;

Exibir plano de consulta
explain select * from tabela;

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

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

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

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

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

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

select pg_stat_activity;

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

Pode usar também o current_date ou o localtimestamp.

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

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

Tenho o seguinte conteudo numa tabela de contas:

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

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

Estou executando:

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

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

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

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

Dica do Euler Taveira de Oliveira
21) Formato de moeda

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

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

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

pg_relation_size()
pg_total_relation_size()

-Leo
–
Leonardo Cezar
23) Último Saldo
Fernando Brombatti

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

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

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

Além de ser mais simples:

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

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

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

Abraço!

-Leo
25) Como Localizar e Deletar registros duplicados

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

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

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

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

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

Analise.
Wandrey

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

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

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

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

UPDATE page SET myrand = DEFAULT;

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

This approach has some problems:

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

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

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

Thiago Boufleuhr

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

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

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

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

Colaboração: Frederico Palma

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

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

stats_command_string = true

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

pg_ctl reload

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

Realizando a consulta:

SELECT datname,procpid,current_query FROM pg_stat_activity

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

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

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

32)

Rodrigo Hjort: PGCon Brasil 2009

Rodrigo HJORT — 2009-10-07T11:26:48+00:00

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

Confira maiores informações no site do evento:

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

Fernando Ike: PGCon Brasil 2009 tá logo aí!!!

Fernando Ike — 2009-09-26T23:43:38+00:00

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

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

João Paulo (Jota): PGCon 2009 Inscrições abertas

jotacomm — 2009-09-26T14:43:25+00:00

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

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

Claudio Bezerra Leopoldino: Monitoração de Comandos com PG_STAT_STATEMENTS

cbleopoldino — 2009-09-24T14:22:29+00:00

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

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

shared_preload_libraries = '$libdir/pg_stat_statements'

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

Show shared_preload_libraries

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

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

1 - Consulta padrão

select * from pg_stat_statements;

2 - Consultas ordenadas pelo número de chamadas

select * from pg_stat_statements order by calls desc;

3 - Consultas ordenadas pelo tempo total utilizado

select * from pg_stat_statements order by total_time desc;

4 - Consultas ordenadas pelo número de linhas retornado

select * from pg_stat_statements order by rows desc;

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

1 – Limpando dados coletados

select pg_stat_statements_reset();

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

2009-09-15T22:51:07+00:00

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

Garanta já sua inscrição!!!

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

Rodrigo Hjort: Tips on PostgreSQL tuning

Rodrigo HJORT — 2009-09-08T19:48:02+00:00

At last I found something more concise towards PostgreSQL DBMS fine tuning. :)

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Rodrigo Hjort: Cedrus PostgreSQL Management versão 2.0

Rodrigo HJORT — 2009-09-08T19:47:42+00:00

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

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

Referências:

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

PostgreSQL Brasil: Replicação de dados com java

2009-09-04T00:06:55+00:00

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

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

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

Outros links sobre replicação:

leia mais

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

cbleopoldino — 2009-08-24T09:24:28+00:00

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

O concurso apresenta várias categorias:

Consulta ou script;
Artigo;
Artigo traduzido;
História em quadrinhos; (!!!)
Estudo de caso;

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

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

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

Fabio Telles: Concurso “O elefante está entre nós”

2009-08-22T10:54:33+00:00

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

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

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

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

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

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

João Paulo (Jota): Usando o DBLink para interligar dois bancos PostgreSQL

jotacomm — 2009-08-16T18:56:23+00:00

Pessoal,

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

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

Para compilar é necessário executar o seguinte comando:

make

make install

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

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

Carregando o arquivo dblink.sql no banco01.

psql banco01 -f dblink.sql

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

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

Então vamos a prática:

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

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

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

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

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

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

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

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

Conferindo:

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

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

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

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

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

Abraços

João Paulo (Jota): PostgreSQL 8.4 Agora com GRANT/REVOKE por coluna

jotacomm — 2009-08-15T19:02:21+00:00

Olá, pessoal

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

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

Segue um exemplo bem simples:

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

postgres=# CREATE DATABASE exemplo_grant_revoke;

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

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

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

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

Inserção de dois registros na tabela.

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

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

exemplo_grant_revoke=# CREATE ROLE usuario_grant_revoke LOGIN;
CREATE ROLE

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

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

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

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

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

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

Conexão com o superuser (postgres).

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

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

exemplo_grant_revoke=# GRANT SELECT ON tabela01 TO usuario_grant_revoke;
GRANT

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

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

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

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

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

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

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

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

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

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

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

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

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

Conexão ao banco.

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

Remoção dos privilégios concedidos.

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

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

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

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

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

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

Verificando os privilégios.

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

Abraços

Claudio Bezerra Leopoldino: PostgreSQL 8.4: Falta um bom instalador para Windows!

cbleopoldino — 2009-08-13T09:46:38+00:00

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

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

Mais informações aqui!

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

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

Complemento 13/08/2009:

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

João Paulo (Jota): PGCon 2009 Grade oficial do evento

jotacomm — 2009-08-11T21:31:46+00:00

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

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

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

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

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

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

Abraços

Fabio Telles: Saiu a grade do PGCon Brasil 2009!!!

2009-08-10T19:13:18+00:00

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

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

Vou contar um pouco dos bastidores do evento:

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

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

Fabio Telles: Pesquisa sobre lembranças para o PGCon Brasil 2009

2009-08-05T18:58:52+00:00

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

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

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

Claudio Bezerra Leopoldino: Psql 8.4: Novas Funcionalidades!

cbleopoldino — 2009-07-29T09:05:26+00:00

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

Listando o Tamanho de Objetos

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

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

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

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

Abrindo Editor para Funções

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

A sintaxe é: \ef

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

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

2009-07-26T18:26:43+00:00

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

PostgreSQL Brasil: Resultados da pesquisa sobre o uso do PostgreSQL no Brasil.

2009-07-07T16:00:25+00:00

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

leia mais

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

2009-07-06T20:15:10+00:00

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

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

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

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

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

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

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

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

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

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

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

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

Tabelas que não são atualizadas ou que são atualizadas raramente: inclua aqui tabelas de parâmetros e coisas do tipo. Se você puder realizar as atualizações em apenas um local então você pode fazer com elas caiam no segundo caso:
Tabelas que são atualizadas apenas em um nó como a matriz e são consultadas por todas as outras filiais;
Tabelas onde cada filial é responsável pela atualização de apenas um punhado de registros, sendo que cada filial não pode alterar os registros da outra filial;
Tabelas onde cada filial deve poder atualizar qualquer registro da tabela, independente de qual filial seja.

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

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

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

Para saber mais sobre os diferentes tipos de Cluster e Replicação, veja neste blog o texto: Cluster != Replicação.
Para saber mais sobre soluções de alta disponibilidade e balanceamento de carva, veja o texto da documentação oficial: High Availability, Load Balancing, and Replication

Fernando Ike: Eu fui: FISL10

Fernando Ike — 2009-07-03T17:31:42+00:00

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

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

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

Palestras

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

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

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

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

Infra-estrutura

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

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

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

Geral

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

Fernando Ike: PostgreSQL 8.4 lançado

Fernando Ike — 2009-07-02T02:57:42+00:00

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

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

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

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

PostgreSQL 8.4

View more presentations from fernandoike.

Fabio Telles: Lançado o PostgreSQL 8.4!!!

2009-07-01T20:28:14+00:00

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

Vejam a nota oficial de lançamento em pt_BR.

Claudio Bezerra Leopoldino: PostgreSQL 8.4 Enfim Liberado!

cbleopoldino — 2009-07-01T15:55:41+00:00

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

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

Abaixo, os links mais úteis:

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

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

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

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

Fabio Telles: Pesquisa sobre backup em PostgreSQL

2009-06-25T12:21:51+00:00

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

Fabio Telles: Pesquisa sobre o uso do PostgreSQL no Brasil

2009-06-17T14:50:22+00:00

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

Preencha a pesquisa agora aqui.

Mini FAQ

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