SAVEPOINT

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

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

26/09 - Sexta-feira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Segurança contra o SQL Injection

Regra no mínimo privilégio

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

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

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

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

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

Use criptografia, visões e funções

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

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

Procedimentos preparados

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

Dollar Quoting

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

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

Você ainda pode fazer coisas como:

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

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

Checar o tipo de dados

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

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

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

Escapar as strings

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

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

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

Conclusão

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

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

A tarefa é trivial, mas não é algo que você faz todo dia. Então resolvi documentar aqui para facilitar a minha vida. Há várias formas diferentes de se rearranjar tablespaces. Com a popularização dos RAIDs, não é mais tão comum ficar dividindo tablespaces através de discos isolados, mas ainda assim, há bons motivos para você criar todos os objetos em apenas um tablespace:

• O backup on-line pode ser feito um tablespace por vez, diminuindo a quantidade de logs gerados durante o backup;
• Você pode transportar tablespaces entre bases (teste e produção por exemplo) sem ter que exportar e importar todos os dados;
• Você pode utilizar diferentes parâmetros de storage, particionamento, etc;
• Fica mais fácil monitorar o crescimento da base com várias aplicações se cada aplicação possuir suas próprias tablespaces;
• Separar índices de tabelas ainda é uma boa política, especialmente porquê os índices podem ser reconstruídos e as tabelas não;
• Objetos especiais como LOBs e dados estáticos são bons candidatos a terem seu próprio tablespace;

Assim sendo, é comum você pegar uma tabela que cresceu muito e alocar um tablespace só para ela e coisas do tipo. Particularmente, quando os desenvolvedores tem a liberdade de criar objetos no ambiente de testes (sim, isso é polêmico e fonte para outra conversa), é comum ter que ajustar os parâmetros de storage antes de colocar os objetos no ambiente de homologação ou produção. Seja qual for o motivo da movimentação, você terá que fazer a migração em 3 etapas:

• Migrar tabelas com o comando:

ALTER TABLE nome_da_tabela MOVE TABLESPACE nome_do_novo_tablespace;

• Migrar índices com o comando:

ALTER INDEX nome_do_indice REBUILD TABLESPACE nome_do_novo_tablespace;

• Migrar LOBs com o comando:

ALTER TABLE nome_da_tabela MOVE LOB(nome_da_coluna_lob)
    STORE AS (nome_do_novo_tablespace);

Note tabelas que contem LOBs, possuem um índice que aparece na tabela DBA_INDEXES com data_type do tipo LOB. Se você tentar reconstruir estes índices em outro tablespace você terá um erro do tipo: “ORA-02327: cannot create index on expression with datatype LOB”. Por isso é importante a etapa de migração dos LOBs.

Segue aqui um script para fazer isso rapidamente num para todos objetos de um determinado esquema:

SELECT 'ALTER TABLE nome_do_esquema.' || table_name || ' MOVE TABLESPACE nome_do_novo_tablespace;'
  FROM dba_tables
  WHERE
    owner = 'nome_do_esquema';
 
SELECT 'ALTER INDEX nome_do_esquema.' || index_name || ' REBUILD TABLESPACE nome_do_novo_tablespace;'
  FROM dba_indexes
  WHERE
    owner = 'nome_do_esquema' AND
    index_type != 'LOB';
 
SELECT
  'ALTER TABLE nome_do_esquema.' || table_name ||
  ' MOVE LOB( ' || COLUMN_NAME ||
  ' ) STORE AS (TABLESPACE nome_do_novo_tablespace);'
  FROM dba_tab_columns
  WHERE
    owner = 'nome_do_esquema' AND
    data_type LIKE '%LOB';

Já faz tempo que algumas idéias me incomodam profundamente, isto não é segredo para os que já me conhecem. Há tempos atrás assisti há um filme interessante. Chama-se “O Segredo”. Uma amiga comentou, mas não falou exatamente sobre o que o filme se tratava e mediante a uma séria indecisão ao passar na locadora acabei levando. Sim, a curiosidade matou o gato.

Bom, a primeira questão é que o filme não conta história alguma. Não há algo emocionante que é revelado no final. O filme é uma sucessão de falas de narradores que prosperaram graças ao “segredo”. Todos os que assistiram ao filme ou viram o livro sabem do que eu estou falando. Sim, trata-se de auto ajuda. Mas há de se dar um bom crédito a sucessão de fatos e idéias apresentadas:

• Sim, existe o fator placebo. Pessoas que acreditam que estão sendo curadas apresentam melhora natural, mesmo que não estejam de fato recebendo tratamento algum. O efeito placebo é considerado em toda pesquisa científica na área da medicina;
• Sim, energias positivas atraem energias positivas e vice-versa. Se você está deprimido, as pessoas se afastam naturalmente de você pois não gostam de ficar em companhia de pessoas deprimidas. Se você está sempre feliz, você atrairá as pessoas pois elas acharão a sua companhia agradável.
• Planejar o futuro, criar metas e traçar planos são estratégias inteligentes para se atingir objetivos. Não se trata apenas esperar as coisas acontecerem. As pessoas que tomam atitudes certamente se aproximam mais da realização do que aqueles que ficam apenas esperando que as coisas aconteçam.

Não preciso entrar no mérito da religião, energias cósmicas, poderes ocultos do cérebro humano ou outras questões polêmicas para dizer que uma pessoa com depressão pode extrair lições valiosas do filme. Mas… sim, é claro que há um mas… e vejamos bem, não é apenas um, são vários.

A primeira questão que eu gostaria de levantar é a questão da fé. Nunca me esqueço de um discurso proferido por um dado representante de uma dada religião (realmente não vem ao caso qual). ao se pronunciar num ato junto aos seus seguidores relacionou a miséria humana com a falta de fé. É simples, as pessoas pobres são aquelas que não tem fé em XYZ ícone da religião em questão. Então eu vejo aqueles milhares de pessoas que se massacram em sua fé, com esperanças de que tudo irá melhorar, ou então de que este é o caminho da salvação, ou ainda de que está sofrendo uma provação ou castigo divino. Não é fácil dizer quem é pobre e quem tem fé exatamente. Então esta associação é fraca, passível de contraargumentação. Mas é uma pista.

É claro que você pode dizer que se a pessoa tem uma “fé equivocada”, se acredita na religião errada, está condenado a miséria humana. Mas se você é destas pessoas que acreditam que somente uma religião está correta e todas as outras estão erradas, por favor, pare de ler aqui. Você não vai concordar comigo adiante e eu nunca vou concordar com você então não perca o seu tempo, e não desperdice o meu.

Mas deixando de vez a questão da fé, há alguém que começou a trabalhar os males que afetam o indivíduo de forma diferente e trouxe profundo impacto e debate nos meios acadêmicos. Esta pessoa conduziu uma investigação científica sobre o suicídio. Ela descobriu que apesar de haverem fatores psicológicos que levam cada um a se suicidar, existem tendências de as pessoas fazê-lo em maior ou menor frequência dependendo do local e época onde vive. A questão é que o suicídio é também uma questão social e não apenas individual. Há fatores sociais, coletivos, não individuais, que influenciam o comportamento das pessoas. É por isso que psicólogos e sociólogos para sempre duelarão no campo das ciências e eventualmente nos bares e congressos por aí. Mas há um fato inegável. A sociedade oferece uma coerção que influencia na sua forma de agir. Esta coerção pode ser um olhar de desaprovação, uma carta de demissão ou mesmo a repreensão policial. Ela existe.

O que isso tem haver com “O Segredo”? Bom, em primeiro lugar, foram estes estudos que levaram a conclusão de que existem vários fatores que levam as pessoas a pobreza. Você pode até interpretar a ira divina na forma de desastres naturais como a evidência da religião na questão… mas existem outros fatores muito importantes também. E surgem outras explicações mirabolantes. Uma que está na moda hoje em dia é o da falta de escolarização, por exemplo. Hum… faça um exercício, pegue o número de vagas disponíveis que exigem alta escolarização na Grande São Paulo. Agora imagine que por intervenção divina (não vai achar que algum país bom samaritano vai fazer isso, vai?) venha e pegue todos os pobres da cidade e mande-os por 10 anos para as melhores universidades e escolas do planeta. Alimente-os adequadamente, dê formação integral, tudo do bom e do melhor. Traga-os de volta para a Grande São Paulo… tente arrumar emprego para eles… adivinha o que vai acontecer? Vão ficar desempregados e vai haver uma queda nos salários das pessoas que estão bem empregadas devido ao aumento na oferta de mão-de-obra especializada.

Veja, não é falta de estudo ou fé que faz um país inteiro miserável. As pessoas daquele lugar não são más por natureza. Os pigmeus da Africa, quando bem alimentados cresciam normalmente. Eu imagino o povo de “O Segredo” indo para países miseráveis ensinando suas lições valiosas e o tudo mudando em poucos anos… será? Bom, os miseráveis não costumam comprar livros nem ingressos de cinema.

Note que no tom de harmonia celestial do filme, não há mais luta… basta desejar. Você é compelido no filme a não reclamar das coisas. Reclamar vai lhe atrair energias negativas. Não existem mais escolhas, apenas desejos, não exitem direita e esquerda, proletários e capitalistas. Tudo isso some no filme. Basta desejar. O Sr. Charles Wright Mills já se preocupava muito com isso no final da II Guerra Mundial, afinal, a paz e o conformismo chegaram para ficar. Sua preocupação era com as estruturas de poder no mundo. Estruturas que mudam o tempo todo com o passar dos séculos. Mas por incrível que pareça, nós nos conformamos com ela como se ela sempre existisse, e fosse eterna e imutável e não uma construção social, construída por seres humanos de carne e osso como nós. Quando olhamos ao longo dos séculos vemos inúmeras lutas, avanços e reveses no nosso processo civilizatório. Seja qual for o futuro da nossa moderna “civilização”, a questão é que o poder e a dominação, econômica, militar e cultural existe, e a forma de entender o mundo pode e deve ser visto conforme a sua posição nestas cadeias de poder. Entender esta situação, traz a tona um emaranhado de conseqüências capazes de desvendar inúmeros discursos e opiniões sobre a nossa sociedade. Resumindo, existem 4 posições:

• Os reacionários que já estiveram no poder e cobiçam resgata-lo. São aqueles que glorificam os bons tempos passados. O exemplo clássico são os nobres em suas monarquias que foram substituídos por repúblicas. Os reacionários não são velhos e insignificantes. Eles muitas vezes retomam o poder pois acumularam muita força durante seu período de glória. Também não é verdade que eles são obrigatoriamente melhores ou piores que os conservadores. São os que estavam no poder antes e foram depostos por algum motivo histórico.
• Os conservadores são os que estão no poder hoje. Para eles a história acabou. Não existe futuro nem passado e nada deve sair do lugar. A sociedade é como um corpo que deve funcionar de forma saudável e regular. Toda e qualquer disfunção que tente modificar o estado de coisas deve ser tratado como uma infecção a ser combatida e eliminada. Assim os que estão no cérebro e comandam os demais. Comandam os glóbulos brancos, a distribuição dos alimentos e dizem qual é a forma correta de agir para todos os demais;
• Os reformistas, são aqueles que acham que a sociedade não é justa, mas é possível melhorar ela gradualmente até que ela chegue num estado ótimo. Basta que se realizem os ajustes corretos e tudo entrará nos eixos e todos seremos mais felizes. Os reformistas se auto denominam como pessoas de bom censo, pois são um ponto de equilíbrio na sociedade entre os conservadores e os revolucionários. Na verdade se equilibra entre a possibilidade ascenção e o risco de desabar para a pobreza;
• Os revolucionários são aqueles dispostos a dinamitar a sociedade e reconstruí-la pedra por pedra novamente, custe o que custar. Eles sabem que a sociedade é injusta e não acreditam ser possível reformar a sociedade sem mudanças radicais. Os revolucionários são o contra-peso da sociedade que fazem denúncias constantes sobre atual da injustiça social.

Veja que a sociedade oscila entre estas posições, e vão de um lado para outro conforme suas posições no tabuleiro mudam. Este é o real segredo dos discursos na humanidade. A luta pelo poder jamais sumiu do mapa e ela rege a nossa vida de forma avassaladora. Wright Mills se preocupava sobre como as pessoas deixaram de se preocupar com isso e passaram a resolver seus problemas no divã ou na religião. A riqueza e a pobreza não podem ser vistas apenas no plano individual. São fenômenos coletivos e construídos historicamente. Não importa o quanto você pague ao seu analista ou quanto você se penitencie, estas forças continuarão atuando sobre você. Vender livro de auto-ajuda é fácil, mas acabar com a miséria humana não. Há pessoas lutando para manter o seu poder sobre as demais e há multidões tentando não serem esmagadas. Enquanto você fica apenas desejando a abundância e a prosperidade… alguém está pensando em como as engrenagens da sociedade funcionam.

Alguém aí já pensou se realmente é possível prover com abundância tudo aquilo que desejamos para todos? Imagine por exemplo quais são os bens mínimos que uma família moderna precisa para sobreviver? Uma casa com um fogão e uma geladeira? Não haveria reservas de metal suficiente para produzir os milhões de geladeiras e fogões para todas as famílias do planeta. Não haveria eletricidade e gaz para alimenta-los. Veja o desastre ambiental provocado pelo aumento de consumo na China. Os recursos naturais são escaços, não há o suficiente para todos. A única saída está realmente no coletivo e não no indivíduo. É o transporte público, o restaurante comunitário, o não consumismo e o fim dos bens descartáveis.

Será que é isso que você deseja? O fim de todo o conforto sonhado? Bom, se você pensa no conforto possível para todos, talvez estas sejam as únicas alternativas viáveis. Mas será que as pessoas que já desfrutam de muitas das comodidades modernas como o carro, o microondas, os produtos eletrônicos, a comida pelo telefone e outras tantas coisas que gostaríamos de ter e não estão tão longe dos nossos dedos estão dispostas a abrir mão delas? É claro que não. Mas a questão ambiental pode ser facilmente contornável se apenas alguns tiverem acesso a estes bens…

Onde você está? Como você pensa? Você acredita em auto-ajuda? Até onde? É possível uma sociedade melhor? Para todos ou só para alguns? Como esta sociedade seria? Será mesmo vivendo num dos países com maior desigualdade social do mundo nós conseguimos ficar indiferente a tudo isso? Basta colocar mais policiais nas ruas para que pessoas como o Luciano Huck não tenham seu relógio rolex roubado? O mundo vai acabar amanhã? Você fará o que for preciso se prometerem não acabar com a cerveja no planeta? Deixe seu comentário… a porta está aberta!

Não qual vai ser o impacto na Internet neste dia…

Se isso ajudar as pessoas a usarem menos o IE…

Eu fico feliz.

E aí… está esperando o que?

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

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

Depois de muita insistência do sysadmin do Midstorm, finalmente atualizei a versão do wordpress aqui no Savepoint. Migração tranquila, sem problemas. Ainda estou me adaptando às novidades. O editor WYSIWYG deu uma melhorada considerável e a interface administrativa abusa cada vez mais do AJAX. Muito bacana. Agora estou procurando alguns novos plugins e temas para dar uma turbinada no blog. Aceito sugestões.

Uma coisa que fiz questão de implementar, e que me deu um bom trabalho, foram as TAGs que se tornaram uma funcionalidade padrão do Wordpress nas últimas versões. A nuvem de TAGs está na barra lateral direita, achei o recurso bacana (espero que o Google também ache). Deu um trabalho considerável editar as TAGs, são 206 posts, 116 TAGs e 10 categorias. Acho que valeu a pena. Notei que algumas TAGs não apareceram na núvem… não sei ainda qual o motivo. De toda forma, estou pensando em remover as categorias e deixar apenas a nuvem de TAGs para enxugar um pouco a barra lateral.

Qualquer comentário ou sugestão é bem vindo.

Hoje recebi um e-mail de alguém me perguntando porque os testes dele com o pgbench variam tanto, mesmo usando os mesmos parâmetros todas as veses. Para quem não sabe o pgbench é um pequeno aplicativo que lhe ajuda a fazer medições de perfomance no banco de dados simulando um teste TPC-B. Ele é muito simples de se utilizar e permite realizar testes com diferentes volumes de dados, conexões simultâneas e transações por conexão. O pgbench NÃO SERVE para fazer tuning em servidores de produção, mas serve para ajudar medir a diferença entre diferentes hardwares, SOs, sistemas de arquivo, etc. No mínimo, com o pgbench você vai começar a aprender muito sobre performance no PostgreSQL, comparando seus resultados em diferentes cenários.

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Está no ar o site do PGCon Brasil 2008. Para quem não sabe, esta é a sigla da “Conferência Brasileira de PostgreSQL”. Na sua segunda versão, o evento ocorrerá dentro da Unicamp, em Campinas/SP. A data também já está fechada: 26 e 27 de Setembro, numa sexta e sábado. Então, já reserve a data para “o maior evento sobre bancos de dados livres do Brasil”. Após contar com mais de 200 participantes em 2007, a expectativa é de ter mais de 300 pessoas este ano.

Alguns detalhes interessantes:

• A chamada de trabalhos internacional. Espera-se a vinda de 2 desenvolvedores internacionais, além dos desenvolvedores nacionais.
• O número de desenvolvedores nacionais parece que está aumentando neste ano e o número de colaboradores na organização do evento também.
• O plano de captação do evento já está no ar também, se você conhece alguém que poderia patrocinar o evento, não deixe nos avisar.
• Se você quer ajudar a divulgar o evento, já temos banners para você colocar no seu blog, site, etc.
• As inscrições para o evento ainda não começaram, mas quem quiser ir fazendo reservas num hotel, você já pode fazer sua reserva. Conseguimos proços especiais para os participantes do evento.
• Para se ter uma idéia, para fazer o site do evento, foram dezenas de e-mails trocados na lista pgbr-dev o que tornou a lista mais movimentada que a lista pgbr-geral. Um recorde. Gostaria de agradecer a contribuição do Dickson S. Guedes, Euler Taveira, Leandro Dutra, Leonardo César, Rodrigo Gomes Santana, Rodrigo Marins, Sebastian SWC, Thiago Risso e outros que não lembro agora por terem contribuído para o site sair.

Em breve, estaremos melhorando o site do evento, colocando mais informações, abrindo a chamada de trabalhos nacional e abrindo as incrições também. Por enquanto é só pessoal.

Já faz um tempo que ando investigando a parte de segurança em Bancos de Dados. Passei um tempão estudando a parte de segurança no Oracle e andei investigando algumas questões sobre o assunto aqui e acolá neste blog e na palestra sobre melhores práticas que fiz no FISL 9.0 e no PGCon Brasil 2007. Calhou de ontem eu estar conversando com o Dickson Guedes no IRC e resolvemos escrever um pouco sobre segurança no PostgreSQL. A idéia é para variar um pouco um tanto ambiciosa: fazer uma lista de possíveis melhorias que seriam interessante implementar no PostgreSQL para melhorar a segurança. Uma segunda etapa seria colocar a mão na massa e tentar implementar algum patch no PostgreSQL. Particularmente eu tenho muito receio de abrir o código fonte e sair mexendo. Manjo pouco de C e não tenho tanto domínio assim do funcionamento interno de SGDBs para fazer isso. Mas por outro lado, se eu não fizer o fike nunca vai me deixar em paz… e ao fim e ao cabo, a gente só aprende a fazer fazendo!!! Por fim, existe uma segunda intenção, que é começar a escrever coisas mais detalhadas sobre este assunto, iniciando assim alguns capítulos do livro sobre PostgreSQL que começa a sair do papel entrar no ar. Particularmente, eu acho que só a parte de segurança já é suficiente escrever mais de 100 páginas. Bom, de toda forma, todos aqueles que lerem este texto e sentir que há algum equívoco ou que falta alguma coisa está convidadíssimo a colaborar, seja nos comentários, seja enviando um e-mail ou mesmo no IRC.

Caramba… mas segurança é um tema tão complexo assim? Bom, depende de como você define o que é segurança em SGDB para você. Vamos começar pensando em duas ou três formas de se enarar o problema:

• Segurança em SGDB não se refere apenas ao seu banco de dados, diz respeito a toda a cadeia tecnologia associada a sua aplicação, uma vez que um único elo fraco da sua solução de TI põe em risco o conjunto como um todo. Então não basta pensar no SGDB isoladamente. Temos que pensar no equipamento onde o SGDB se encontra, no SO, na instalação do SGDB, nos dados contidos no banco de dados, na aplicação acessando o banco de dados e finalmente no usuário que precisa destas informações;
• Todos estão carecas de saber, mas não custa repetir: os bancos de dados guardam um patrimônio valioso: informação. Quando você tem um problema de segurança num SGDB, são os seus dados que estão ameaçados. A pergunta que sempre se faz é “quanto vale a informação guardada nos bancos de dados”. Melhor pergunta seria: “quanto custa a perda destes dados?”.
• Segurança tem haver com coisas com o potencial de tirar o sono/emprego de toda uma equipe de TI. O desempenho é importante. Algumas vezes é muito importante. Mas em geral, a segurança vem em primeiro lugar. Esta importancia hoje tem nome, endereço, telefone, e-mail e tudo o mais. Depois da onda gerada pelo SOx nos Estados Unidos, a segurança passou a ser mais importante ainda. O COBIT e o ITIL e suas normas e regulamentações associadas são representam mais uma pressão na busca por mais segurança em torno das informações.

Muito bonito tudo isso… mas enfim, quando falamos em segurança qual é a pauta em questão? Ah sim… muitas coisas, vejamos algumas:

• Integridade: tem muito haver com ACID. Seus dados não podem se corromper, independente do que venha a acontecer. Mesmo que seus dados se tornem indisponíveis durante um certo período (devido a uma queda de energia, falha na rede ou num disco por exemplo) você tem que garantir que uma vez que o problema de indisponibilidade esteja resolvido, todos os dados tem que reaparecer intactos. Integridade também tem muito haver com o uso de restrições de integridade, para que um erro do usuário ou da aplicação não permita que os dados sejam corrompidos. O uso das restrições de integridade devem proteger seus dados contra alterações que não estão de acordo com as suas regras de negócio;
• Perda de dados: a preocupação número 1 de todo administrador de banco de dados é evitar ao máximo a perda de dados. Aí entra em cena a mais tediosa das tarefas: o backup. Ocorre que em bancos de dados, não existe uma única forma de se fazer um backup, existem várias estratégias. De toda forma, é preciso definir antes de mais nada: qual é o volume máximo de dados que admissível perder? Os dados relativos a última semana de operação? Talvez o último dia? A última hora? Nem um segundo sequer? Bom, é claro que ninguém quer perder nada, mas você sabe realmente qual é a o grau de proteção que a sua atual política de backup lhe oferece?
• Disponibilidade: capacidade de manter o acesso às informações de forma contínua. Falhas humanas, falhas de software e falhas de hardware podem gerar indisponibilidade a qualquer momento. A sua tolerância a indisponibilidade vai variar conforme a importância e rítimo de operação das suas aplicações. Algumas não podem parar nunca e trabalham em regime 24/7. Outras só precisam estar ativas em horário comercial, mas não admitem um minuto sequer de indisponibilidade neste período. Seja como for, é importantíssimo definir qual é o SLA agregado aos serviços prestados pelo banco de dados para que se possa traçar uma estratégia adequada para se atingir estes objetivos. Sua estratégia deve garantir que mesmo ocorrendo uma falhas, mesmo graves, os dados devem estar disponíveis no prazo determinado pelo seu contrato de SLA.
• Controle de Acesso: capacidade de que as informações disponíveis no banco de dados estejam disponíveis para as pessoas corretas, que terão permisão de acesso apenas as operações permitidas para o seu perfil. Geralmente o controle de acesso se dá a partir de objetos do banco de dados, mas pode se re referir ao acesso de apenas um parte dos dados de um objeto, como apenas algumas linhas de uma tabela. O controle de acesso pode limitar a quantidade de recursos que você pode utilizar no banco de dados. Os recursos podem ser o número de conexões ativas, memória, processador, volume de dados acessados em disco, etc.
• Auditoria: registro de operações realizadas no banco de dados. O registro pode conter informações sobre quem, realizou que tipo de operação, sobre qual objeto e em qual momento. O registro também pode conter quais foram as alterações realizadas, permitindo reconstruir os dados num estado anterior se necessário. A auditoria também pode significar monitorar outras condições do banco de dados, como picos de utilização, espaço em disco e outros detalhes que se deseje registrar.

Como se pode ver, ao falar em segurança, temos inúmeros desafios pela frente. Temas consagrados como “Alta Disponibilidade”, “Backup”, “Política de Mínimo Privilégio”, “Trilhas de auditoria” entre outros, fazem parte do dia-a-dia (ou seria noite-a-noite?) dos que se preocupam com segurança. Em grandes equipes de TI, há pessoas especializadas em segurança. Muitas vezes, encontramos Administradores de Bancos de Dados especializados em um ou dois aspectos da segurança, como o controle de acesso e auditoria. Administradores de Dados são especialistas em avaliar problemas de restrição de integridade enquanto os Administradores de Sistemas costumam se preocupar com backup e alta disponibilidade.

Com isso, em mente, vejamos alguns capítulos de deveremos abordar em seguida:

• Trabalhando de forma segura:
  • Escrevendo código robusto e flexível;
  • Usando o psql;
  • Documentando o trabalho realizado;
• Ambientes de Trabalho
  • Isolar para proteger
  • Ambiente de Produção
  • Ambiente de Homologação
  • Ambiente de Testes
  • Ambiente de Laboratório
• Integridade
  • Modelagem de Dados;
    • Domínios;
    • Sequências;
    • Chaves Primárias;
      • Chaves Primárias artificiais X naturais;
      • Quando é permitido criar uma tabela sem PK?
    • Chaves Estrangeiras;
    • Restrição UNIQUE;
    • Restrição NOT NULL;
    • Restrição CHECK;
    • Gatilhos;
    • Visões Materializadas;
  • ACID
    • Transações
    • MVCC
    • LOCKs
    • Write Ahead Log
      • Espelhamento dos logs;
      • Arquivamento e Stand By;
      • Recuperação de instância;

• Perda de Dados e Disponibilidade;
  • Backup
    • Backup lógico;
    • Backup físico off-line;
    • Backup físico on-line;
      • Dificuldades com grandes bases;
    • Backup via Snapshot;
  • Técnicas de fail over
    • Hardware Redundante;
      • RAID
    • LVM e RAID por software;
    • Stand By;
    • Heart beat;
    • Replicação X Clusterização;
  • Replicação
    • Replicação Síncrona X Assíncrona;
    • Replicação Multi Master X Master/Slave
    • Replicação via log de transação;
    • Replicação via commit em duas fases;
    • Replicação via gatilhos;
    • Replicação via Midleware;
    • Implementações para PostgreSQL;
  • Cluster
    • Shared Nothing
    • Shared All
    • Implementações para PostgreSQL;
• Controle de Acesso
  • Política do Privilégio Mínimo;
  • SQL Injection;
  • Segurança na autenticação
    • Visões;
    • Funções;
    • Serviços de Diretório;
  • Ferramentas de controle no PostgreSQL;
    • GRANT / REVOKE
    • Roles
    • Limite de acesso aos recursos do servidor;
    • pg_hba.conf
    • SELinux
  • Estratégias de Autenticação da Aplicação;
    • Autenticação Interna;
      • Uso de grupos de usuários;
      • Impedindo os usuários de obterem acesso por fora da aplicação;
      • Lidando com senhas;
    • Autenticação Externa;
    • Autenticação via Aplicação;
      • Pool de Conexões;
• Auditoria
  • Auditoria dos dados:
    • Utilizando campos adicionais em tabelas já existentes;
    • Utilizando tabelas de autitorias alimentadas por RULEs e TRIGGERs;
    • Utilizando o log do PostgreSQL;
    • O problema da identificação do usuário em aplicações com Autenticação via Aplicação;
      • Criando uma variável de sessão;
    • Protetendo as informações de auditoria;
  • Monitorando o seu servidor:
    • Monitorando a disponibilidade;Monitorando a performance;
    • Monitorando o espaço em disco;
      • Dividir para melhor enchergar;
    • Disparando alertas;

Como se pode ver, temos muito assunto pela frente. Não tenho nenhum ímpeto de escrever seguindo uma órdem específica, provavelmente eu deverei escrever numa ordem caótica e tentar juntar as peças aos poucos.

Veja, eu respeito o SGDB Oracle. Ele não apenas é um dos primeiros bancos de dados relacionais do mercado como também é robusto, confiável e possui uma miríade de recursos. Mas convenhamos, para um SGDB que está a tempos no mercado, algumas coisas são realmente incríveis. É claro que existem algumas explicações que dizem respeito a história de como o produto surgiu e muitas que tem mais haver com a estratégia de marketing da Oracle.

• A Oracle possui uma enorme documentação. Toda ela está disponível on-line para qualquer um baixar. O mesmo acontece com os softwares (não as atualizações, claro). Uma das coisas que eu aprecio na documentação da Oracle, são as suas recomendações quanto as melhores práticas. Algumas delas são específicas em relação ao seu produto, mas muito do que está lá se aplica a qualquer banco de dados. Dito isso, me explique: qual o motivo de tantos produtos da Oracle não seguirem as suas próprias recomendações. Você não acredita? Quem conhece as restrições das aplicações feitas em FORMS sabe do que eu estou falando. Agora imagine um ERP inteiro sem uma FK (chave estrangeira). Isso mesmo… o famoso ERP da Oracle não tem nenhuma. Alguém me explica isso?
• Eu falei bem da documentação da Oracle, não? Pois é, os caras fazem um bom trabalho nela. Mas tem um problema. Algumas coisas misteriosamente não estão lá. É quase inacreditável que eles esqueçam de documentar coisas tão importantes na documentação. Realmente não faz nenhum sentido. Vou lhes dizer que não é pouca coisa.
• Mais um detalhe bizarro sobre a documentação da Oracle. Você já olhou o manual de instalação deles? Bom, eles tem uma lista de dependências que devem ser instaladas para que você não falhe miseravelmente no meio do caminho. No entanto há algumas coisas bizarras lá. Eu nunca entendi o que o gnome-libs, o xscreensaver e o control-center fazem na lista de dependências. São completamente inúteis. Você definitivamente não precisa delas no seu servidor, mesmo que você queira usar o instalador gráfico. Ainda assim, se você cair na besteira de ler a documentação que acompanha os CDs do Oracle, ou a documentação que vem junto com os binários que você baixa no site, você pode encontrar sérios problemas no caminho. Algumas dependências simplesmente não estão descritas nesta versão da documentação, como você poderia esperar. Não esqueça, sempre olhas os “Release Notes” na documentação on-line. Particularmente, se você for fazer uma instalação em Linx com 64 bits, você me agradecerá muito por esta dica. Isto acontece porquê o instalador do Oracle de 64 bits roda em 32 bits. Surpresa, as dependências de 32 bits não estão na documentação original.
• Sim, o famoso processo de instalação do banco de dados está longe de ser um processo simples. Eu realmente não conheci o Oracle nas suas versões mais antigas. Só conheço ele a partir da versão 8. Não tenho nada contra as zilhões de recomendações de acertos no SO antes da instalação. Na verdade, isso é até bem bacana. Uso muito destas recomendações com outros SGDBs. Mas o instalador gráfico deles é simplesmente horrível. Porquê? É muito simples… ele força você a instalar a interface gráfica no seu servidor. Para os usuários do Windows, tudo bem, mas no mundo Unix isto é uma heresia. Para complicar ainda mais… o instalador é feito em Java e pesa uma tonelada. Fazer um instalador em modo texto não seria tão complexo assim. Não é que seja impossível fazer a instalação em modo texto. Claro que é possível. Mas você tem de criar um arquivo enorme de configurações que pode ser um inferno de editar, conforme forem as suas necessidades. Eu mesmo já criei alguns scripts para me ajudar a criar os arquivos de isntalação em modo texto. Daí para criar um instalador em modo texto seria realmente um pulo. Convenhamos que esta não seria uma tarefa árdua para a Oracle.
• O SQL*Plus número um dos DBAs Oracle. É claro que surgiram coisas mais amigáveis como o SQL Developer, mas o SQL*Plus é a única ferramenta em modo texto que você tem para utilizar. Eu realmente gosto muito das interfaces gráficas. Mas na hora do aperto elas não me servem muito. Quando preciso rodar uma rotina pesada ela também não me ajuda muito. E principalmente, quando quero fazer algum script rápido que acesse o SGDB, o SQL*Plus é uma mão na roda. Mas há um detalhe muito bizarro nele. Ele não tem suporte a biblioteca mais manjada das ferramentas em linha de comando: a ReadLine. Sem ela ou outra substituta a altura, voltamos para a idade do bit lascado. Até as setas do seu teclado perdem a utilidade. É realmente lastimável a perda de produtividade que este detalhe nos proporciona no dia a dia. Para quem está acostumado com o Bash, isto é simplesmente irritante.
• O metalink é a porta de entrada para um universo a parte da Oracle. Patches de segurança, zilhões de documentos sobre erros bizarros, uma maravilha. Só tem um problema. Parece que a Oracle usou seus próprios produtos para criar o seu site. E vou lhes dizer uma coisa… eles parecem que nunca utilizaram o gmail na vida. Definitivamente nunca ouviram falar em AJAX. Para completar, ainda usam FLASH para montar um site lento, feito e com uma péssima usabilidade. Depois que você se acostuma com o jeito tosco do site, até dá para se virar bem, a não ser é claro, que você esteja com um pepino enorme na mão e a sua conexão com a Internet esteja lenta. Se for esse o seu caso, vou lhe dizer qual é a forma de rezolver seus problemas de forma mais rápida, interativa e eficiente: entre no servidor de IRC da freenodes na sala #oracle. Você vai descobrir que o “suporte livre” realmente funciona.
• O padrão SQL já vai completar 20 anos em 2009. Ele surgiu em sua primeira versão oficial em 1989. Ficou famoso pela versão de 1992, e depois contou com mais duas grandes versões sendo a última em 2003. É verdade que a moral da ISO anda meio baixa nos últimos tempos. Mesmo assim, não há motivos para a Oracle ser tão lenta na adoção dos padrões. O tipo de dado TIMESTAMP surgiu apenas na versão 9i. O tratamento com os nulos, o nvarchar, a ausência do tipo inteiro e outras coisas estranhas do Oracle lhe garantem não conformidades significativas com o padrão SQL.
• A Oracle tem uma tara por arquivos binários que nenhum ser usuário possa ler. A coisa não se limita aos dispositivos crús (Raw Devices), vai dos backups com RMAN, ao rastreamento de erros com trace. Enfim, o negócio é confiar na Oracle…

Você não concorda com as minhas observações? Diria que tem outros itens para acrescentar a lista? Coloque nos comentários então!

Tive que subir a interface gráfica na mão no Red Hat estes dias e me deparei com a necessidade de instalar pacote por pacote. No Debian você tem alguns pacotes especiais que puxam um monte de dependências para você. No Red Hat você tem os gupos, mas nas páginas do man não encontrei nada sobre esta funcionalidade do up2date. Então resolvi documentar aqui para não esquecer mais.

Para saber quais grupos de software existem use:

# up2date --show-groups</code>

Administration Tools
Arabic Support
Assamese Support
Authoring and Publishing
Base
Bengali Support
Brazilian Portuguese Support
British Support
Bulgarian Support
Catalan Support
Chinese Support
Compatibility Arch Development Support
Compatibility Arch Support
Core
Cyrillic Support
Czech Support
DNS Name Server
Danish Support
Development Libraries
Development Tools
Dialup Networking Support
Dutch Support
Editors
Emacs
Engineering and Scientific
Estonian Support
FTP Server
Finnish Support
French Support
GNOME
GNOME Desktop Environment
GNOME Software Development
Games and Entertainment
German Support
Graphical Internet
Graphics
Greek Support
Gujarati Support
Hebrew Support
Hindi Support
Hungarian Support
ISO8859-2 Support
ISO8859-9 Support
Icelandic Support
Italian Support
Japanese Support
KDE
KDE (K Desktop Environment)
KDE Software Development
Korean Support
Legacy Network Server
Legacy Software Development
Mail Server
Miscellaneous Included Packages
MySQL Database
Network Servers
News Server
Norwegian Support
Office/Productivity
Polish Support
Portuguese Support
PostgreSQL Database
Printing Support
Punjabi Support
Romanian Support
Ruby
Russian Support
Serbian Support
Server
Server Configuration Tools
Slovak Support
Slovenian Support
Sound and Video
Spanish Support
Swedish Support
System Tools
Tamil Support
Text-based Internet
Turkish Support
Ukrainian Support
Web Server
Welsh Support
Windows File Server
Workstation Common
X Software Development
X Window System
XEmacs

Para instalar um grupo, o pulo do gato é usar um ‘@’ antes do nome do grupo. Se nome do grupo contiver espaços em branco, você precisará colocar tudo entre aspas. Ex:

#  up2date -i "@Brazilian Portuguese Support"
#  up2date -i "@X Window System"
#  up2date -i  @GNOME

Segue o link para algumas fotos do pessoal do PostgreSQL no FISL 9.0. Não tirei muitas fotos por lá e cheguei atrazado e não pude ficar lá no sábado, então faltaram algumas figuras importante que não apareceram. De toda forma, fica aqui um registro parcial.

Coloquei hoje na área de downloads um arquivo contendo 3 diagramas que utilizei para explicar o funcionamento da parte de storage no Oracle RAC. Se alguém encontrar algum erro nos diagramas, por favor me avisem.

Custei a chegar em Porto Alegre. O aeroporto estava “sem teto” em Porto Alegre devido neblina, que depois fiquei sabendo, é típica desta época do ano. O resultado foram 5 horas de espera em Guarulhos. Isto não chegou a ser um grande problema, pois havia bastante gente para bater papo no aeroporto. Havia uma verdadeira caravana no aeroporto. Enfim, consegui chegar na PUCRS perto das 12h.

O evento estava realmente lotado. Segundo a organização, cerca de 7500 pessoas estavam lá, fora os alunos da PUCRS que passeavam livremente por lá, trazendo uma contribuição significativa para o “astral” do evento. Os corredores estavam lotados. As salas estavam lotadas e tinha palestra com gente sentada no chão e amontoado na porta. A pesar das boas palestras, o melhor foi reencontrar os amigos por lá. Gente que eu não via faz tempo. Foi muito bom.

O Stand do PostgreSQL estava bem organizado, mas logo se mostrou apertado para a multidão que aparecia por lá no intervalo das palestras. Tive a oportunidade de conversar com muita gente interessante por lá. Muita gente querendo saber mais sobre PostgreSQL, tirar dúvidas, fazer entrevistas, comprar camisetas ou mesmo bater papo e tomar um café! Não tenho a menor idéia de quantas pessoas passaram por lá, mas foi muita gente.

As maioria das palestras de PostgreSQL se concentraram no primeiro dia. Casa cheia em todas as palestras, inclusive na minha que ocorreu no último horário, ás 20h. Muita gente ficou depois do término da palestra para tirar dúvidas. Fomos convidados a nos retirar da sala pela organização que precisava liberar o local. Para todos aqueles que me pediram cópias dos meus slides, eles estão disponíveis para download aqui. Para quem não sabe, a palestra foi parecida com a do PGCon Brasil 2007, com o título “Fazendo um Elefante Passar Debaixo da Porta”, sobre melhores práticas para DBAs e desenvolvedores. Melhorei algumas coisas e possivelmente piorei outras. Acredito que em breve teremos todas as palestras do PostgreSQL no site da comunidade.

Infelizmente não pude ficar até o final do evento, fui embora na 6ª feira a noite, mas deu para curtir um bocado do evento e tomar algumas Polares com os amigos e renovar meu estoque de camisetas . Hoje devo estar indo ainda em outro evento com a presença dos nossos palestrantes internacionais do FISL. Eles estarão na UNICAMP para o Dia PostgreSQL promovido pela Dextra.. Na verdade eu devo aproveitar o momento para acertar alguns detalhes do PGCon Brasil 2008, que vai ocorrer na UNICAMP nos dias 27 e 28 de setembro. Muito em breve teremos notícias.

Bom, vou ficando por aqui… hoje vou poupa-los de um post enorme para descrever em detalhes o FISL. Fico apenas com a descrição do David Fetter no PostgreSQL Weekly News: “FISL had almost 7500 participants this year, making it the world’s largest FLOSS conference.”

Já faz algum tempo que eu leio documentações de informática. Acabei aprendendo a ler em inglês pois não havia nenhum manual para o editor Magic Windows II que eu rodava no Apple II em português. De lá para cá li muita coisa que eu gostei e coisas que eu prefiro nem lembrar. Entre as coisas que eu gostei de ler está o livro Programação Perl dos Srs. Larry Wall, Tom Christiansen e Jon Orwant. É bom pois é bem abrangente, bem escrito, com boa profundidade e bom humor. A documentação oficial do PostgreSQL também é bem escrita e bem abrangente. Uma boa diferença é que como o livro de Perl não pretende ser uma documentação oficial, ele é mais descontraído. Esta é uma característica comum das documentações relacionadas com Software Livre.

Uma outra diferença fundamental é que a documentação do PostgreSQL mostra detalhadamente “o que” mas mostra pouco “como”. Isto não significa que precisamos de um livro do tipo “Torne-se um DBA PostgreSQL em 7 dias”. Estes livros costumam ter o péssimo hábito de emburrecer as pessoas com receitas de bolo prontas e não convida o leitor a pensar ou tomar decisões. Quando li a documentação oficial do PostgreSQL pela primeira vez, me senti finalmente encorajado a começar a modelar meu primeiro sistema dedicado a ele. No entanto, uma infinidade de desafios e decisões apareceram no caminho, e a documentação oficial tinha pouco a me dizer naqueles momentos. Eu ainda tinha pouca experiência e isso me levou a tomar decisões baseadas muitas vezes no meu bom senso e outras em alguns poucos artigos que encontrei na Internet. Mas… já dizia o Sr. Hobbes, que o bom senso é o dom mais democrático e contraditório da humanidade: todos acham que os outros carecem e bom senso e se julgam igualmente possuidores de boas doses dele. Resultado, fracassei miseravelmente em diversos aspectos.

Com o tempo e envolvimento com a comunidade, fui descobrindo um erro aqui e outro acolá. Aprendendo sobre outros bancos de dados, principalmente olhando para as diferenças entre eles, percebi algumas coisas nas entrelinhas que nem sempre estão explícitas na documentação. Isto me levou a escrever alguns artigos neste blog, particularmente nos últimos tempos, quando comecei a me sentir mais corajoso no sentido de expor minhas idéias e me permitir errar, expondo idéias inacabadas. Isto culminou com uma palestra no PGCon Brasil 2007. A idéia da palestra “Como Fazer um Elefante Passar Debaixo da Porta” era a de ajudar as pessoas que estão começando a utilizar o PostgreSQL, mas não tem tanta experiência como DBA. Olhando para o público do evento, percebo que existe uma minoria de DBAs na platéia. A maioria eram desenvolvedores/analistas/programadores e haviam também administradores de sistemas/redes. A questão é a de que praticamente não existem cursos de graduação para formar Administradores de Bancos de Dados. A meu ver, a maioria dos DBAs foram administradores de sistemas ou desenvolvedores que por alguma razão misteriosa decidiram se especializar nesta área.

Se formos pensar bem, o DBA fica justamente numa posição entre o desenvolvedor e o administrador de sistemas. O novo DBA trás certamente as melhores práticas da sua área de origem. Os administradores de sistema trarão uma preocupação com o uso e monitoramento dos discos, métodos de autenticação autenticação, ajustes do SO e por aí vai. O desenvolvedor trás um padrão de codificação, esquemas de autenticação da aplicação, modelagem, distribuição de objetos, etc. Mas bancos de dados não são novos… já em priscas eras, os computadores utilizam bancos de dados. O modelo relacional, no qual todos os grandes SGDBs se baseam (e ao contrário do que o pessoal da programação orientada a objeto imagina, continuará assim por um bom tempo) foi criado há mais de 30 anos. O livro “Introdução a Banco de Dados” do C. J. Date também já é pode ser considerado um clássico e está em sua oitava edição.

Os bancos de dados relacionais atravessaram a era dos sistemas centralizados em mainframes (que continuam existindo), a era cliente-servidor e a era programação em 3 camadas. O PostgreSQL tem suporte para utilizar tudo isso, mas nem sempre os novos DBAs tem consciência desta história toda. Ao ler a documentação do PostgreSQL, hoje eu vejo décadas de história relacionadas com as suas funcionalidades. Então fica claro para mim, qual livro falta ser escrito para o PostgreSQL. Não é um livro que substiua a documentação oficial. Vale muito mais a pena complementar e traduzir a documentação oficial do que escrever pequenos livros que repetem boa parte do que já existe lá. Hoje eu descobri mais um pequeno livro sobre PostgreSQL. Nada contra o livro. Mas eu não preciso ler ele para saber como ele é. Este tem apenas 240 páginas. Para um livro genérico, isso mal dá para começar. Segundo a editora, a Érica que tem fama de fazer livros didáticos, que mais parecem apostilas. Terceiro, o autor, com quem eu já tive aula, tem dezenas de livros editados no mesmo estilo.

Minha idéia não seria esta, muito pelo contrário. Acredito que um bom livro de melhores práticas deveria estimular o leitor a ler a documentação com freqüência, citando-a em diversos pontos. Mesmo porquê, existe um trabalho intenso da comunidade em atualizar a documentação oficial a cada nova versão do PostgreSQL. Um livro de melhores práticas deveria se um pouco menos dependente de uma versão específica.

Um livro de melhores práticas deveria servir como subsídio didático para cursos de PostgreSQL, deveria conter inúmeros exemplos práticos e conduzir o leitor ao erro. Sim, ao erro. Somente a pessoa que erra tem condições de aprender de fato. Não são os acertos sucessivos que nos fazem acertar, e sim os erros e como corrigi-los. Assim, eu imagino uma aplicação sendo construída a partir do seu início, e as decisões sendo tomadas no meio do caminho. Imagino o livro conduzindo a decisões e discutindo as implicações destas decisões. Imagino muita polêmica onde não há um único caminho correto a seguir. Imagino a coleta de diferentes opiniões que convidem o leitor a pensar e escolher o seu próprio caminho. Imagino exemplos concretos de como seria a implementação em cada um destes caminhos. A questão ao fim é mostrar “como” e não “o que”.

O livro passaria certamente por tópicos que não são específicos do PostgreSQL. Uma coisa interessante seria mostrar as diferenças da implementação do PostgreSQL com as implementações de outros bancos de dados, quando isso for comparável. Imagino particularmente comparações entre implementações do Oracle, DB2, SQL Server e MySQL. Imagino também comparações com o padrão SQL e comparações com versões anteriores do próprio PostgreSQL. Seria muito interessante abrir o jogo aqui. O PostgreSQL não é perfeito e nunca será. Se ele fosse perfeito a humanidade teria esgotado a sua insatisfação e imperfeição eternas. Poderia-se mostrar onde outros bancos de dados oferecem vantagens e desvantagens em relação ao PostgreSQL. Pode-se dizer o mesmo em relação ao padrão SQL, que não é perfeito. No entanto, melhor do que criticar o padrão SQL - afinal, querendo ou não é o padrão que nós temos - devemos comparar os Bancos de Dados tendo o padrão SQL como referência.

Imagino algumas premissas para escrever o livro:

• Escrito a várias mãos. É preciso de alguém para organizar o livro, mas é preciso pegar o que há de melhor na especialidade de cada um. Uns conhecem melhor modelagem de dados, outros conhecem melhor que ninguém como ajustar a performance do seu servidor ou de uma consulta. Em momentos polêmicos, poderíamos citar mais de um autor e deixar o leitor tirar suas próprias conclusões.
• Licença livre. Seria imprecindível adotar uma licença que permita a cópia e modificação do livro. Gostaria no entanto de preservar a contribuição de cada pessoa no livro. Já vi trechos da documentação do PostgreSQL em diversas apostilas por aí. Sim, daquele curso que você está pensando também. Acho que manter os créditos é uma questão de respeito. Cada um pode alterar o livro para as suas necessidades e utilizar da forma que melhor entender, mas por favor, cite os autores que lhe ajudaram.
• Precisaria ser construído aos poucos. A idéia não seria juntar um monte de texto, revisar, publicar e abandonar. Muito pelo contrário, seria feito em capítulos, sendo que qualquer capítulo poderia sofrer acréscimos e correções a qualquer momento, eternamente.
• Precisaria ser construído via Internet. Não há como um projeto colaborativo prescindir do uso da internet. Não tenho certeza sobre a ferramenta correta a se adotar. Imagino que ao mesmo tempo deveria ser tão simples como usar uma ferramenta de escritório, fácil de se transformar em outros padrões como SGML (utilizado na documentação oficial), fácil de agregar novos colaboradores como uma ferramenta Wiki e tavez tão universal como o Google Docs.
• Precisa de um case real a ser desenvolvido. Para que os exemplos se tornem consistentes ao longo do livro, precisaríamos eleger um problema inicial a ser desenvolvido sob diferentes aspectos. Num determinado ponto do livro, chegaríamos a um pequeno grupo de tabelas e demais objetos que seriam explorados por todo o restante do livro. Só precisaríamos definir algumas regras de negócio bem básicas para que o exemplo se desenrole pelo restante do livro. Algumas licenças poéticas poderão ser admitidas, pois algumas técnicas só fazem sentido quando temos centenas de transações concorrentes ou tabelas com milhões de registros. A minha idéia inicial seria utilizar o pagila que já é mantido pela comunidade e vai sendo atualizado conforme novas versões do PostgreSQL vão surgindo. Ele pode ser tão simples e auto-explicável quanto se queira e também pode possuir graus de complexidade bem grandes para exemplificar algumas coisas;
• O público alvo seriam novos DBAs PostgreSQL, que podem ser estudantes, desenvolvedores, administradores de sistemas ou mesmo DBAs que estejam acostumados com outros bancos de dados.
• Deve ter profundidade na sua abordagem. Se sabemos que é possível fazer de algum jeito alguma tarefa, temos que mostrar como. Isto significa ter de desenvolver scripts e procedimentos em diversos pontos, bem como demonstrar a sua utilização com testes reais.
• Citar com cuidado e precisão. Realizar citações com links para a origem com a maior freqüência possível e apenas de fontes com boa credibilidade.

Possíveis tópicos a serem abordados:

• Implementando uma aplicação:
  • Ferramentas de trabalho: editores de texto em Windows e *nix, em modo gráfico e texto, formas de se trabalhar no dia-a-dia.
  • Modelagem básica: criação de tabelas, PK, FK;
  • Padrões de codificação: case sensitive, nomes para objetos, codificação explicita X implícita;
  • Domínios e tipos de dados;
  • Sequências e o uso de chaves artificiais e naturais;
  • ORDER BY, WHERE, GROUP BY, usos práticos;
  • Visões e visões atualizáveis (utilizando o RULEs);
  • Dados hierárquicos, abordagens possíveis;
  • Exportação de dados com dump, copy e PL;
  • Joins e subselects na clausula FROM, WHERE e SELECT;
  • Trabalhando com números: Localização, formatação;
  • Trabalhando com data e hora: Localização, internacionalização, conversão, formatação;
  • Trabalhando com texto: codificação de caracteres, internacionalização, conversão, formatação e manipulação;
  • Busca textual;
  • Desnormalização controlada: Gatilhos, funções e visões materializadas;
  • Uso de esquemas;
• Trabalhando com dados binários:
  • Tipos de uso por tamanho de arquivos, volume total, tipo de acesso e concorrência;
  • Uso do Bytea, OID e sistemas de arquivo;
  • Desempenho, flexibilidade e confiabilidade;
• Autitoria:
  • Campos de auditoria;
  • Tabelas de auditoria;
  • Logs de auditoria;
  • Ferramentas de auditoria;
• Segurança:
  • A rede, o SO, o PosgreSQL e a aplicação;
  • Ambiente de produção, homologação e testes;
  • Arquitetura da aplicação e estratégias de autenticação;
  • Encriptação de dados;
  • Obfuscando código;
  • Contornando falhas de segurança;
• Monitoramento de usuários:
  • Descobrindo o que os usuários estão fazendo no banco;
  • Locks de tabelas;
  • Uso de índices e estatísticas de uso;
  • Logs externos ao banco;
• Backup e Alta Disponibilidade;
  • Escolhendo a melhor estratégia;
  • Backup Lógico;
  • Transferindo dados entre bases;
  • Backup físico off-line;
  • Point-In-Time-Recovery;
  • Backup físico on-line;
  • Stand by;
  • Replicação assíncrona;
  • Replicação síncrona;
• Discos:
  • Planejando o volume de dados;
  • Particionamento do servidor;
  • Volumetria e monitoramento;
  • Distribuição de carga e uso de Tablespaces;
  • Sistemas de Arquivo;
  • LVM;
  • RAID por software e hardware;
• Instalação e Manutenção:
  • Compilação X Pacotes binários;
  • Testando e migrando de uma nova versão;
  • Flexibilidade para o ambiente de testes;
  • Segurança para o ambiente de produção;
  • Simetria entre ambientes;
  • Isolando ambientes no mesmo servidor;
  • Autovacuum manual, automático, full;
  • Reindex;
• Integrando aplicações:
  • DBLink;
  • DBILink;
  • Cargas de dados com dump, copy , via aplicações e outros métodos;
  • Validação, e auditoria na integração;
• Desempenho:
  • EXPLAIN e ANALYZE;
  • PREPARED STATEMENT;
  • Subconsultas;
  • Monitoramento avançado;

Eis aqui uma dica para você, que usa o PostgreSQL e sabe que em comparação com outros bancos de dados, a quantidade de documentação existente é ínfima. Então se você começar a escrever mais sobre PostgreSQL, você se tornará irresistível ao sexo oposto (e/ou ao mesmo sexo dependendo da sua preferência…), vai emagrecer, crescer cabelo, ficar milionário, famoso, respeitado mundialmente, etc, etc, etc. A questão é que há espaço na web para os seus artigos esperando por você. O site nacional do PostgreSQL é um wiki, qualquer um pode se registrar e atualizar um artigo existente lá ou criar novos artigos.

Ok, você não é fã de wiki? Então você pode montar um blog, todo seu. Existem inúmeras ferramentas que permitem como o blogger e o wordpress que permitem você criar um blog em minutos e sem gastar um tostão. E para provar que você terá público garantido, agora existe o Planeta PostgreSQL que reúne as publicações de vários blogs que tem por hábito publicar artigos sobre PostgreSQL em pt_BR. Para entrar no Planeta, basta seguir as instruções e todos os seus artigos relacionados com o PostgreSQL vão aparecer automaticamente por lá.

Há tempos, foi proposto reformular o site do PostgreSQL Brasil, e colocar o Drupal no lugar do MoinMoin. Na verdade o MoinMoin não seria desativado, mas passaria a ser utilizado para organização interna da comunidade. Por inúmeros fatores isto não aconteceu ainda. Eu reconheço que inclusive ajudei a atrapalhar um pouco a história. Mas o curioso é que na época em que isso foi proposto, um monte de gente se propôs a escrever e ajudar. Foi aí que surgiu a proposta do Planeta, que é algo mais simples de criar e manter. Bom, o Planeta está no ar… mas o curioso é que temos apenas 5 blogs nele até agora. É muito pouco na minha opinião… gostaria de ver mais gente escrevendo.

Ok, confesso que tenho escrito poucos artigos técnicos por aqui também… já até me puxaram a orelha… mas se você não sabe sobre o que escrever, então você pode tirar alguns posts que estão na minha fila de espera:

• Monitoramento vi psql e shell;
• Estratégias de autenticação de aplicações e segurança no PostgreSQL;
• Tipos de ferramentas de replicação e suas aplicações práticas;
• Estratégias de backup, recuperação de desastres e alta disponibilidade;
• Ambientes heterogêneos com DBI-Link;
• Usando e abusando das tabelas do pg_class e informatio_schema;
• Configurando logs para diversos propósitos;
• Como criar métricas de performance;
• Procurando gargalos de performance;
• Skytools;
• Ptop;

E por aí vai…

Até agora (21/03) já temos 5 palestras sobre PostgreSQL aprovadas na grade do FISL 9.0:

• Fernando Ike: HA em PostgreSQL: O Elefante disponível para além do infinito HA em PostgreSQL: O Elefante disponível para além do infinito
• Josh Berkus: Using SQL tools to secure your database application
• David Fetter: The Postgres Application Server
• Fábio Telles: Fazendo Um Elefante Passar Debaixo da Porta
• Diogo Biazus: Replicação Assíncrona Multi-Mestre com Bucardo

E se você acha pouco… então venha conhecer a Comunidade PostgreSQL, no Stand M3 que já está na planta baixa do evento bem em frente das salas “John Maddog Hall” e “Richard Stallman”. Vejo vocês por lá!

A exemplo do ano passado, estou soltando uma pesquisa para saber quais são os temas que as pessoas gostariam de ver no PGCon Brasil 2008.

Entre lá e dê sua opinião, agora!

Atualizado: além de inúmeros erros de ortografia (estava usando uma máquina sem corretor ortográfico…) adicionei uma parte sobre a meritocracia, que julgo ser importante.

No ano passado ocorreu algo inusitado durante o PGCon Brasil 2007. Um dos palestrantes sumiu do mapa de repente e ficamos com um furo na grade do evento. Então, eis que o Sr. Diogo Biazus em tempo recorde prepara uma palestra intitulada “PostgreSQL Br - Manual de Uso“. A palestra foi um grande sucesso e abordou um assunto que me incomoda há tempos: como participar de comunidades de SL. Infelizmente os slides da palestra do Diogo não revelam a riqueza da palestra. É claro que em alguns minutos de preparação não seria possível fazer melhor, mas o fato é que eu gostaria de compartilhar um pouco do assunto com as pessoas que não estiveram no evento e combinar isso com a minha experiência pessoal.

<devaneio>
Este post começou com uma provocação de um grande colega, o mestre fike. Eu dizia no IRC que me sentia frustrado por ter encampado uma campanha desastrosa para numa ação específica da comunidade de PostgreSQL-BR. Aí veio a provocação: “E o que você aprendeu com isso?”. Eu tinha a resposta na ponta da língua. Na verdade eu ainda estou com as sábias palavras do Sr. Diogo Biazus eco