http://www.dreamstime.com/-image2965530

Trabalhando com logs no PostgreSQL

Parece incrível mas existe um número grande de pessoas que não configura corretamente os logs no PostgreSQL. Muitos nem sabem onde ele fica e nunca foram olhar o que tem lá. É verdade que muitas aplicações que levam o PostgreSQL embarcado funcionam por anos sem nenhum problema. Mas um dia o problema vai surgir, e adivinha qual o primeiro lugar em que vamos olhar? Os logs claro. No entanto é bem frustrante chegar no cliente e ver que os logs não estão configurados, às vezes, sequer habilitados. Isto significa que a capacidade de verificar um problema ocorrido no passado é quase  nula.

A documentação possui um capítulo só com as configurações do log, vamos parar para olhar alguns pontos que você deveria conhecer, ok?

Onde logar

Aqui você vai configurar onde o arquivo de log vai ser gerado, o nome do arquivo, permissões no arquivo, tamanho do arquivo, etc. Preocupações com o local, nome e espaço em disco entram aqui.

  • log_destination: Aqui você pode escolher entre stderrcsvlogsyslog e se estiver utilizando o Windows, eventlog. O uso do syslog ou do eventlog faz com que os logs sejam direcionados para o destino padrão dos logs no seu sistema operacional. Se você é um administrador de redes e está preocupado na gestão de dezenas de servidores, é possível que esteja mais confortável como isso. Por outro lado, DBAs em geral preferem o stderr ou csvlog. O padrão é utilizar o stderr, que produz um log mais fácil para a leitura humana, mas se você pretende importar os logs para uma ferramenta externa de analise, o csvlog pode ser uma boa opção também.
  • logging_collector: Ligue e seja feliz. Deixe desligado e não me culpe se não souber te dizer o que houve de errado.
  • log_directory: o diretório (dentro do diretório raiz da sua) onde os logs serão gravados. A não ser que tenha um bom motivo para isso, deixe o padrão, ‘pg_log’.
  • log_filename: O nome do log gerado é muito importante para você. Pode acontecer de você gerar muitos logs por muito tempo e você tem que decidir se vai querer reaproveitar os logs antigos ou não. Se quiser rotacionar e manter apenas um log para cada dia da semana (manter apenas 7 dias de log) ou um para cada dia do mês (manter até 31 arquivos de log), você deve escolher um nome que seja sobrescrito periodicamente. Se você não tem alguém cuidando dos seus logs, pode ser melhor utilizar um esquema de rotação destes, não é o que eu prefiro, mas pode ser melhor do que ver seus logs lotando o espaço em disco sem que ninguém entenda o que está acontecendo. Parcimônia é uma boa pedida. Se você monitora o espaço em disco do seu servidor, não há motivos para mudar do padrão, que acredito que seja uma boa configuração.
  • log_file_mode: Não mexa a não ser que você tenha um bom motivo para isso.
  • log_rotation_age: O valor padrão faz com que pelo menos um novo log seja criado por dia. Gerar logs muito grandes torna muito difícil avaliar um problema. Meu conselho: deixe o valor padrão.
  • log_rotation_size: Configura o tamanho máximo de um arquivo de log antes dele quebrar num novo arquivo. Como eu disse, logs muito grandes são difíceis de analisar. O padrão, 10MB talvez seja muito pequeno, uns 50MB ou 100MB são tranquilos para qualquer bom editor de texto abrir.
  • log_truncate_on_rotation: Se você escolher um nome de arquivo em log_file_name de forma a ele reaproveitar os nomes anteriores, você precisa habilitar este parâmetros para ele apagar o log antigo.

Quando logar

Você pode dizer ao PostgreSQL em quais situações um log deve ser gerado. Essas demandas podem mudar o tempo todo e é importante saber quando e como mudar isso conforme a necessidade e o ambiente.

  • client_min_messages, log_min_messages, log_min_error_statementEstes 3 parâmetros possuem os mesmos valores que vão são DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL e PANIC. DEBUG5 é a opção que gera mais log e PANIC é a que gera menos log. DEBUG5 a DEBUG1 é utilizado em geral pelos próprios desenvolvedores do PostgreSQL. A opção PANIC por outro lado, é só vai registrar quando uma catástrofe absoluta acontecer. Um meio termo é o mais recomendado. Algo entre INFO e ERROR. O parâmetro client_min_messages se refere às mensagens enviadas para o usuário enquanto está interagindo com o banco de dados. Então a sua aplicação recebe mensagens que ela pode tratar. Um bom exemplo disso é quando você utiliza o psql. O log_min_messages é o que parâmetro que mede o que vai ser gravado de fato no nosso log. Por fim log_min_error_statement configura especificamente quando um comando SQL com erro vai ser gravado no log.  Vamos discutir um pouco mais sobre estes parâmetros mais tarde, eles são realmente importantes para nós.
  • log_min_duration_statement: Faz com que qualquer comando SQL que leve mais do que o valor em  milissegundos configurado aqui entre no log. Muito útil para pegar comandos que estão levando muito tempo. É comum esperar que a maioria das consultas levem apenas alguns milissegundos ou no máximo alguns segundos. Capturar todas as consultas que demorem por exemplo mais de um minuto, pode ajudar a pegar gargalos importantes de performance. Se você configurar este parâmetro com 0 (zero) você vai logar todos os comandos SQL enviados para o postgres, que pode gerar uma quantidade muito grande de log. Em todo caso, experimente para ver o que acontece. Muitas pessoas se surpreendem com o que encontram…

O que logar

Dependendo da situação você pode querer logar coisas diferentes, a maioria destes parâmetros não serão alterados com o tempo, ao contrário dos parâmetros da sessão anterior.

  • application_name: Não faz muito sentido ajustar este parâmetro aqui, mas é muito importante que sua aplicação saiba ajustar este parâmetro quando se conecta no postgres. Ajuda muito saber qual aplicação está conectada. Pode-se também alterar este valor para passar mais detalhes conforme a operação que vai executar ex: “Contabilidade | Cadastro de cliente”
  • debug_print_parse, debug_print_rewritten, debug_print_plan e debug_pretty_print: Nunca vi um bom motivo para mexer nisso em condições normais de temperatura e pressão.
  • log_checkpoints: Ativa o log dos checkpoints. Você pode não entender bem o que isso quer dizer, mas é uma informação que em geral não é gravada com muita frequência e pode ser bem útil para avaliação de performance. Deixe isso ligado.
  • log_connectionslog_disconnections: Faz com que cada conexão e desconexão de um usuário seja logada. Se você tem muitas conexões entrando e saindo com frequência, isso pode ser irritante, pois serão milhares de mensagens de log. Use com parcimônia.
  • log_duration: tem um efeito parecido com o log_min_duration_statement configurado com 0 (zero). A diferença é que aqui ele não mostra a consulta executada, apenas a duração. Em geral prefiro utilizar o log_min_duration_statement, mas você pode usar ele para ter a estatística da duração das consultas que levaram menos tempo que o estipulado em log_min_duration_statement
  • log_error_verbosity: em geral não há um bom motivo para mexer nisso nas condições normais de temperatura e pressão.
  • log_hostname: Se você confia nas suas configurações de DNS na rede, pode habilitar este parâmetro para mostrar o nome das máquinas que se conectam no banco ao invés do seus IPs. Caso contrário, isso pode acrescentar um custo de performance considerável.
  • log_line_prefix: Este parâmetro é muito importante e diz quais informações adicionais vem junto com os comandos SQL que aparecerem logados. Algumas ferramentas de análise de log (vamos discutir isso mais para frente) se beneficiam de determinadas configurações. Algumas coisas dependem do seu ambiente. Informação demais pode não ajudar. Por exemplo: se você utiliza um único banco de dados no seu ambiente, ou todos usuários utilizam um único usuário do banco, logar esta informação pode não ser tão útil. Mas não seja mesquinho também… Um exemplo de configuração pode ser algo como ‘%t [%p]: [%l] db=%d,user=%u ‘, ou seja, (%t) data e hora do evento, (%p) número do processo no SO, (%l) número da sequência de execução, (%d) nome da base, (%u) nome do usuário.
  • log_lock_waits: Loga eventos de espera com locks. Você deve deixar isso ligado.
  • log_statement: Loga tipos diferentes de SQL executados com sucesso, como DDL, MOD (DDL + DML), ALL (tudo) ou none (nada). Deixar em DDL costuma ser bastante razoável.
  • log_temp_files: Útil para ajustar o tamanho do parâmetro work_mem e caçar comandos SQL mal comportados. Usar com parcimônia
  • log_timezone: Em geral não costuma ser necessário mexer aqui.

Exemplos de configurações

Alterar as configurações de log é muito simples. Você deve ter uma configuração base bem robusta para o seu ambiente e pode altera-las para situações específicas onde precise de mais informações. Isto pode ser feito em uma base específica, para um usuário específico, uma função ou mesmo uma sessão. Algumas configurações no entanto se aplicam à todo o cluster e precisam que o PostgreSQL seja reiniciado para que a alteração faça efeito. Se quiser descobrir como lidar com os parâmetros do PostgreSQL, leia este artigo que publiquei sobre o assunto.

Vejamos algum alguns exemplos que utilizo no dia-a-dia. Outras possibilidades para situações específicas podem ocorrer, se quiser fazer uma sugestão, esteja à vontade para postar nos comentários.

Servidor de produção PostgreSQL dedicado

Aqui temos um log que será gerado em $PGDATA/pg_log e rotacionado todos os dias, ou quando o log atingir 64MB, ou quando o servidor for reiniciado. Optamos por um logar todos os comandos SQL que demorarem mais de 2 minutos para executarem, DDLs, uso do TEMP, locks, checkpoints. Logar todos os comandos pode ser inviável em termos de volume de logs gerados. Se você utiliza muitas tabelas temporárias, usar o log_statemente em ‘ddl’ pode ser um exagero também. Da mesma forma, logar conexões e desconexões pode gerar um excesso de logs.

Servidor de produção embarcado

Aqui queremos um log mais enxuto, pois raramente alguém irá olhar para eles. Também vamos manter um log por dia do mês e depois reescrever eles. Também  diminuímos o número de mensagens e deixamos só as mais importantes.

Servidor de testes / homologação / desenvolvimento

Aqui deixamos o log mais verboso para pegar possíveis erros. Em geral o volume de logs nunca é tão grande como na produção, pois a base não é utilizada com a mesma intensidade.

Alterando parâmetros em pleno vôo

Certamente você vai querer alterar alguns parâmetros em alguns momentos, particularmente em produção para pegar casos específicos. Um exemplo seria habilitar o log de conexões e desconexões, outro seria habilitar o log de arquivos temporários. Um caso realmente comum é o de se alterar o log_min_duration para zero e assim logar todos os comandos SQL por um período específico de tempo até que o problema que se deseja investigar se reproduza. Depois voltamos à condição anterior. Vejamos como fazer isso nas versões anteriores ao 9.4 do PostgreSQL (à partir do 9.4 você pode utilizar o ALTER SYSTEM para editar o arquivo postgresql.conf

  1. Editar o arquivo postgresql.conf. Suponhamos aqui que iremos mexer especificamente nas configurações do log_min_duration_statement, log_connections e  log_disconnections:

    Você pode deixar comentada a opção que vai alterar e copiar a linha com o novo parâmetro para guardar como referência para quando for retornar à configuração anterior. Também pode tirar uma cópia do seu arquivo postgresql.conf e depois restaurar a cópia para voltar as configurações originais
  2. Carregar as configurações e rotacionar o log. Além de enviar um sinal de SIGHUP para o postgres recarregar as configurações alteradas, seria bom rotacionar o log (claro, a não ser se você não utiliza uma configuração no log_filename que facilite isso) para isolar o arquivo que contem as configurações diferenciadas:
  3. Esperar o evento que você quer verificar ocorrer.  Monitore o diretório pg_log e verifique o tamanho e volume dos arquivos gerados. Não seria uma boa ideia deixar a partição lotar com logs. Monitorar é importante. Claro que você deve sempre colocar o pg_log numa partição separada da raiz. Mesmo assim, monitore o volume de logs gerados.
  4. Depois que o evento ocorreu e você acha que já coletou logs por tempo suficiente, edite o postgresql.conf novamente e vote para a configuração original;
  5. Recarregue novamente as configuraçõeserotacioneolog, da mesma forma que fizemos no passo 2:

Ferramentas para análise de logs

Analisar logs pode ser uma tarefa árdua. Um bom editor de texto é uma ferramenta importantíssima. Uma das coisas que você deverá fazer com frequência é seguir uma sessão do inicio ao fim. Para isso o grep será seu grande amigo. Você pode fazer algo simples como:

Também pode filtrar por aplicação ou mesmo por PID, para pegar uma sessão específica. Isso ajuda muito a avaliar o comportamento da aplicação e ver o que realmente está acontecendo no banco de dados. Uma coisa que descobrimos como DBA é que o desenvolvedor muitas vezes não sabe o que a sua própria aplicação faz no banco de dados. Você descobre problemas crônicos apenas com este tipo de análise.

Mas haverá momentos em que você deverá descobrir onde está um gargalo de performance e existe um caso bem chato de pegar: quando um comando é repetido milhares de vezes apenas mudando os parâmetros. Por exemplo: a aplicação resolve atualizar em 10% o preço de todos os produtos e resolve fazer um UPDATE em cada produto um por vez ao invés de fazer um único UPDATE para todos os produtos. Nesta situação, outros métodos de análise falham em achar gargalos deste tipo, pois se baseiam em olhar comandos SQL lentos. Acontece que um UPDATE simples em si é bem rápido. Mas o conjunto de milhares de UPDATEs é bem lento. Uma ferramenta de analise de logs vai te ajudar nesta tarefa com muita eficiência.

pgBadger

O pgBadger é a ferramenta mais utilizada e mais eficiente que eu conheço para analisar logs do PostgreSQL. Fácil de instalar e muito rápida, ela analisa vários logs de uma vez, um intervalo de tempo específico, tem várias opções bacanas, mas se você não utilizar nenhuma delas, provavelmente já terá um resultado excepcional. Apenas tome cuidado com o parâmetro log_line_prefix, que pode ter que ser ajustado.  Segue aqui um exemplo de geração de relatório analítico do pgBadger:

O arquivo out.html pode ser aberto em qualquer navegador e possui dezenas de informações úteis. Veja aqui um exemplo de relatório gerado por ele.

Outras ferramentas

  • pgFouine: Ferramenta de analise de logs largamente utilizada antes do advento do pgBadger. Caiu em desuso.
  • Logs em CSV: Você pode gerar logs no formato CSV e utilizar outras ferramentas externas para analisar os logs. Pode inclusive utilizar o comando COPY  e importar os logs numa tabela. Assim você pode utilizar comandos SQL para filtrar e analisar os logs;
  • auto_explain: Esta ferramenta gera o EXPLAIN de comandos SQL no log que obedecerem alguns critérios.
  • Elasticsearch: Uma plataforma de analise de dados com inúmeras opções avançadas.

Conclusão

Uma parte considerável do trabalho do DBA é gasta analisando logs. É a melhor forma de se avaliar o que aconteceu no passado. Um log bem configurado possibilita um trabalho bem feito. E a chance do seu problema ser resolvido aumenta em probabilidade, velocidade e qualidade. Outra coisa importante é manter o log limpo. É comum ver aplicações que geram lixo no log ou cometem “erros inocentes” que não geram nenhum problema na prática, mas entopem o log de lixo. O log é uma fonte imprescindível de informações no PostgreSQL. Ele possui capacidades bem avançadas para trabalhar com seus logs, mas você precisa pelo menos configura-los corretamente.

canivete

Aprenda a trabalhar com as configurações do PostgreSQL

O PostgreSQL tem um monte de botões e chavinhas para você ajustar uma série de parâmetros. A maioria destes parâmetros podem ser configurados a partir de 2 arquivos:

  • postgresql.conf: aqui são ajustadas as configurações do PostgreSQL que serão utilizadas em todo o cluster (entenda aqui clister como o conjunto de bases associadas à uma única instância ou conjunto de processos do PostgreSQL).
  • pg_hba.conf: aqui são ajustadas configurações de permissão de acesso e autenticação que serão utilizadas para todo o cluster,  por base, por usuário ou role.

A versão 9.4 do PostgreSQL adicionou uma nova cláusula SQL chamada ALTER SYSTEM. Com este comando, você pode editar diretamente as configurações do arquivo posqtgresql.conf.

Conhecendo a view pg_setting

Para entender melhor como funcionam as configurações do PostgreSQL (também conhecidas como GUCs ou Grand Unified Configuration) , é fundamental conhecer a view pg_settings (que é baseada na função pg_show_all_setting):

Vamos analisar cada campo detalhadamente, pois eles envolvem vários conceitos importantes no meio:

  • name: nome da variável ou GUC, como os desenvolvedores do postgres gostam de chamar;
  • setting: o valor atual no contexto atual para aquela variável. Note que o contexto pode variar de acordo com varias coisas, como a forma como o PostgreSQL foi compilado, parâmetros passados para o postmastar ao subir o serviço, configurações do postgresql.conf, base em que você está conectada, usuário conectado e finalmente, alterações realizadas na sessão atual;
  • unit: Algumas variáveis podem ter valores que remetem a unidades específicas como: ms (milisegundos), s (segundos), min (minutos), kB (kiloBytes) e 8kB. Preste a atenção nas unidades, particularmente quando o valor estiver em unidades de 8kB, pois o valor em setting, pode lhe confundir. Um valor de 256 com uma unidade de 8kB significa na verdade 256 x 8kB =  2mB;
  • category: As variáveis estão agrupadas em categorias, vide a documentação. Fazer uma consulta apenas nas variáveis que estão na categoria que você procura pode ajudar a filtrar seus resultados ou ordenações.
  • short_desc: Descrição sucinta sobre a variável;
  • extra_desc: Descrição e detalhes adicionais sobre a variável. Não chega a substituir a documentação, mas pode lhe ajudar em alguns momentos;
  • context: Diz em qual tipo de situação a variável pode ser alterada. Os níveis mais baixos sempre podem ser alterados nos níveis mais baixos, mas não o contrário:
    • internal – não podem ser alteradas de jeito nenhum. Algumas podem ser alteradas durante a compilação do PostgreSQL. Ou seja, não adianta tentar sair alterando. Estão lá mais por referência.
    • postmaster – só podem ser alteradas após reiniciar o postgres. Você pode alterar parâmetros no postgresql.conf (ou usar o ALTER SYSTEM), mas as novas configurações só entrarão em vigor após reiniciar o postgres. Você também pode ajustar algumas variáveis passando parâmetros para o postmaster. Não recomendo fazer isso.
    • sighup – podem ser alterando com um reload (sinal SIGHUP ou usar a função pg_reload_conf).
    • backend – também podem serem alterados quando a conexão é estabelecida utilizando as variáveis de ambiente PGOPTIONS. No entanto uma vez iniciada a sessão, o valor configurado não pode ser mais alterado durante toda a vida desta sessão;
    • superuser – podem ser alterados com os comandos SET, ALTER ROLE e ALTER DATABASE, mas apenas super usuários podem executar estas alterações. Na prática isto significa que sessões de usuários que não são superusuários não podem ser alteradas no meio de uma sessão.
    • user – também podem ser alterados com SET, ALTER ROLE e ALTER DATABASE, mas não precisa ser um superusuário para fazê-lo.
  • vartype: sim senhores, os valores em no campo setting vem todos no formato texto… então você precisa saber que tipo de valor é permitido neste campo! As variáveis podem ser dos tipos  bool, enum, string, integer ou real.
  • source: Esta opção lhe diz de onde vem o valor configurado para aquela variável. Uma vez que dependendo do contexto, a variável pode ter sido ajustada em diversos contextos, ou apenas estar assumindo o valor padrão: o valor default no campo source significa que em nenhum momento esta variável foi alterada. Os possíveis valores para o campo source são: default,override, configuration file, environment variable, client, database ou user.
  • min_val: valor mínimo permitido caso o tipo do valor seja numérico
  • max_val: valor máximo permitido caso o tipo do valor seja numérico
  • enumvals: valores permitidos caso o tipo do valor seja enum
  • boot_val: valor assumido pela variável ao iniciar o postgres se ela não for configurada em nenhum local
  • reset_val: valor assumido pela variável se um RESET for solicitado no meio de uma sessão
  • sourcefile: nome do arquivo de configuração onde a variável foi ajustada. Só faz sentido utilizar este campo se você utilizar includes dentro do postgresql.conf
  • sourceline: linha do arquivo que alterou aquela variável.

Como você vê, muito da vida das suas GUCs pode ser bem investigada com um bom SELECT na pg_settings. Existem outras formas mais simples de visualizar o valor atual de uma variável, como o comando SHOW ou a função current_setting:

Note aqui que utilizando o comando SHOW ou a função current_setting, ocorre uma conversão do valor numa unidade mais fácil de se entender.

 Alterando valores

Existem várias formas de se alterar um parâmetro, mas isto depende do contexto permitido. Veja o campo context da pg_settings.

context = ‘internal’

Uma variável cuja o contexto é internal, não pode ser alterado em nenhum momento, depois que o binário foi compilado. Veja:

context = ‘postmaster’

Agora, se tentarmos alterar um parâmetro cuja o contexto é postmaster, o valor só será alterado após reiniciar o postgres:

Note que alteramos o parâmetro shared_buffers, com sucesso, mas ao rodar a função pg_reload_conf, o valor não foi alterado. Apenas após reiniciar o banco a alteração surtiu efeito. Por outro lado, se tentarmos alterar a mesma variável no meio de uma sessão com o comando SET teremos um erro:

context = ‘sighup’

Agora vejamos o que acontece quando tentamos alterar uma variável de contexto SIGHUP:

Como você vê, não foi preciso reiniciar o postgres, apenas dar um reload nele. E assim como antes, o comando SET não pode ser executado neste contexto de variável.

context = ‘backend’

Note aqui que apenas após enviar o sinal de SIGHUP e reiniciar a conexão que o valor aparece. Existe ainda a opção de ajustar a variável de ambiente PGOPTIONS antes de estabelecer a conexão:

A alteração da variável log_connections só é válida para esta sessão específica. Diferentes linguagens de programação que utilizam a bibilioteca libpg para se conectar no postgres tem formas semelhantes de ajustar opções ajustando o PGOPTIONS ao estabelecer a conexão.

context = ‘superuser’

Agora vamos finalmente poder utilizar o comando SET, ALTER ROLE e também o ALTER DATABASE:

Aqui, quando utilizamos o ALTER SYSTEM, precisamos rodar o pg_reload_conf para a alteração surtir efeito. Mas a alteração vale para todas as conexões.  Quando rodamos o SET, a alteração entra em vigor imediatamente, mas só vale para aquela sessão.

Agora vamos tentar alterar o parâmetro para uma base específica:

Aqui, criamos uma nova base e configuramos um valor diferente para o parâmetro log_mim_messages apenas para aquela base. Podemos fazer a mesma coisa com um usuário qualquer:

Agora note que o usuário novo não é um superusuário, portanto ele não pode alterar o parâmetro:

 context = ‘user’

A única diferença aqui é que até mesmo um usuário comum pode alterar parâmetros com este contexto no meio da sua sessão.

contexto: dentro de uma transação

Por padrão, sempre que você altera uma configuração usando o comando SET, esta configuração dura até o final da sessão ou até que outro comando SET seja executado alterando o mesmo parâmetro. No entanto, existe a opção LOCAL que faz com que esta configuração dure apenas a transação corrente. Ou seja: após um COMMIT ou ROLLBACK, o parâmetro retorna para o valor anterior, veja:

Outra opção equivalente ao comando SET é a função set_config, que possui uma opção chamada is_local que determina também se a alteração deverá durar para toda a sessão ou apenas para aquela transação. O único cuidado é que o valor a ser configurado deve sempre vir entre aspas simples, pois a função recebe o valor utilizando o tipo de dado text.

 GUCs rocks!

A flexibilidade como podemos ajustar diversos parâmetros tornam uma série de atividades mais simples. Agora com o comando ALTER SYSTEM, você pode trabalhar com todos os parâmetros de contexto SIGHUP para baixo só utilizando SQL. A gama de situações em que podemos ajustar em situações específicas é enorme. Um exemplo seria ajustes no work_mem para conexões que precisem gerar relatórios mais complexos. Ou alterações nos logs para gerar debug em situações específicas. E por aí vai. Se você aprender a trabalhar corretamente com as GUCs, vai descobrir que a vida pode ser mais simples e dinâmica.

Boa diversão!

postgresql-logo

Oracle X PostgreSQL – Parte III: Vantagens do PostgreSQL

Parte I – Semelhanças

Parte II – Vantagens do Oracle

  • Suporte: Eu sei, a Oracle possui suporte. Mas como todo suporte de software proprietário, é um monopólio. Você não tem opção. Se quiser ter acesso ao patches de correção, tem que chamar a Oracle. Se quiser que alguém decifre o que tem nos arquivos de trace binários tem de chamar a Oracle, e por aí vai. Com o PostgreSQL você pode contratar qualquer empresa que possui em seu quadro de funcionários desenvolvedores que você provavelmente estará em terreno seguro. Você pode contratar a Timbira que possui ótimos desenvolvedores do PostgreSQL na sua equipe. Se não gostar da gente, contrate outra. É só entrar no site PostgreSQL e escolher uma. E se você acha que precisa ter alguém para processar quando der tudo errado, saiba que na licença de uso da Oracle ela não se responsabiliza por dados pelo seu uso. Se quiser, vai lá e tenta processar a Oracle, boa sorte.
  • Custo: Não é apenas o custo da licença do Oracle que é alta, senhores. É todo o ecossistema: suporte, cursos, certificação e tudo o mais. Alguém tem que pagar os eventos, propaganda, projetos naufragados, “verbas de representação”, aquisições e outros custos que vão muito além do desenvolvimento do software em si. Certo dia recebemos um vendedor da Oracle que demonstrou para o cliente o Exatada. O hardware (ou “a lata” como eles diziam) custava apenas alguns minhões, mas as licenças do Oracle, muitos milhões! Só para lembrar, custo com treinamento e suporte você tem com qualquer um.
  • Leveza: Você consegue rodar o PostgreSQL no seu vídeo-game, ou em alta plataforma. Você escolhe. Isso confere uma flexibilidade muito grande. Muita gente instala o PostgreSQL embarcado junto com a aplicação e o cliente mal sabe que existe um banco de dados lá. Você não vai ver pessoas usando o Oracle em appliances por exemplo.
  • Simplicidade:  As coisas podem ser simples e intuitivas. Você instala o PostgreSQL em qualquer máquina em segundos. Se quiser compilar e enfeitar um pouco, não leva mais do que 5 minutos. Criar uma base, renomear e operações assim são quase instantâneas. Muitas vezes testei uma nova funcionalidade sem sequer ler documentação. Simplesmente funciona do jeito que você imagina que deveria funcionar. Compare o uso do psql com o SQL*Plus, e você irá concordar comigo.
  • Liberdade: A licença BSD é uma das licenças mais livres que existem. Você pode inclusive fechar o código do PostgreSQL, e muitas empresas de fato o fazem. Até a Oracle pode usar o código do postgres se desejar. Assim como o Windows e o MacOS usam código do FreeBSD. A única limitação é citar de onde o código original vem. No Oracle você tem uma licença de uso. Não é qualquer um que pode usar o Oracle e não é para qualquer coisa. Você não pode sequer publicar um teste de desempenho usando  Oracle sem autorização prévia. Sério.
  • Particionamento: Sim, o particionamento no PostgreSQL não é simples e tem vários problemas. Mas tem vantagens em relação ao Oracle também. No Oracle, se você precisar particionar uma tabela já existente, vai ter que reconstruir isso do zero. Isso significa abrir uma boa janela de manutenção para fazer isso. O PostgreSQL consegue particionar uma tabela com o sistema em pleno voo, aos poucos e de forma bem flexível. Outra questão é na hora de fazer um expurgo de uma partição com o DROP. No Oracle você tem que desabilitar as FKs apontadas para ela antes de fazer isso.
  • PLs: Praticamente todo banco de dados tem uma Procedure Language embutida. O PostgreSQL, além do C, possui o PL/pgSQL, que é baseado no PL/SQL do Oracle. Mas a brincadeira vai muito além disso, você pode usar as linguagens mais comuns como PL/Python, PL/PHP, PL/Java, PL/Perl, PL/sh ou coisas mais específicas como PL/R, PL/LOL entre outros.
  • Foreign Data Wraper: A habilidade de se comunicar com o universo nunca foi tão importante. Os grandes e pesados bancos de dados deixam pouco a pouco de ser o centro da aplicação. Outras bases entram em cena e a comunicação entre aplicações é regra hoje em dia. Claro que a Oracle possui o famoso Gateway, um das raras opções do Oracle que podem ser adquiridas para quem tem uma versão Standard do Oracle. Mas o FDW se mostra uma opção mais simples, robusta e flexível. A infraestrutura existente não só permite o PostgreSQL se comunicar com praticamente qualquer coisa, como também permite que em apenas poucas horas de trabalho em C, você crie um conector novo para uma situação diferente.
  • Extensibilidade: O PostgreSQL possui vários níveis de extensibilidade: Você pode criar uma nova funcionalidade e mandar para a equipe de desenvolvimento e incluir esta nova funcionalidade no código do PostgreSQL. Assim, quando uma nova versão for lançada, seu código irá vir junto. É comum algumas empresas encomendarem o desenvolvimento de novas funcionalidades e elas depois fazerem do conjunto. Dependendo do caso, esta funcionalidade pode entrar como um módulo separado e opcional, mas ainda assim distribuído em separado na pasta contrib. Estas funcionalidades são conhecidas como extensões, assim como as extensões do seu navegador. Mas qualquer um pode criar uma nova extensão e publicar no PGXN, que é uma rede de extensões para o PostgreSQL que podem ser instaladas apenas com um comando “CREATE EXTENSION”. Este é um cenário simplesmente inimaginável no Oracle. Claro, só ecossistemas baseados em Software Livre conseguem este tipo de proeza. E o PostgreSQL tem realmente uma comunidade vibrante neste sentido.
  • ISO SQL: Já foi-se o tempo em que eu confiava nas decisões tomadas pelo comitê do ISO que cria as norma. No entanto, ter um padrão ruim é sempre melhor que não ter nenhum. O PostgreSQL segue bem o padrão e prima por fazê-lo o tempo todo. O Oracle foge bem disso, embora algumas coisas tenham melhorado nos últimos tempos, não é cultura dos usuários do Oracle utilizar as opções que são padrão ISO.
  • Tipos de dados: Isto é uma das coisas mais inexplicáveis da Oracle em minha opinião. Não possuir tipos de dados como INTEGER ou BOOLEAN. Os formatos de data são bem confusos. O campo do tipo DATE guarda data e hora. Não existe um tipo de dada TIME. O tipo INTERVAL se subdivide em dois subtipos YEAR TO MONTH e DAY TO SECOND. O PostgreSQL possui uma infinidade de tipos, inclusive alguns muito úteis como  ENUM, ARRAYs, tipos de intervalo, geométricos, HSTORE, entre outros. A Oracle possui uma variedade maior de dados dentro do PL/SQL, mas para armazenar em tabelas e utilizar em SQL puro não. Daí você já vai vendo a confusão e as limitações que isso implica.
  • DDL transacional: Todo comando DDL gera um COMMIT implícito no Oracle. Isto complica muito o deploy de novos objetos e algumas rotinas mais complexas. No postgres, qualquer CREATE, DROP ou ALTER é transacional e você pode fazer um ROLLBACK à qualquer momento.
oracle-database

Oracle X PostgreSQL – Parte II: Vantagens do Oracle

Parte I – Semelhanças

Parte III – Vantagens do PostgreSQL

Comparar dois produtos com longa história e com comunidades vibrantes é sempre complicado. Quando publiquei minha comparação entre Oracle e PostgreSQL em 2007, muitos comentários de pessoas que não conheciam Oracle ou PostgreSQL surgiram. Uns dizendo que o Oracle não fazia isso ou aquilo e na verdade faz e o inverso também. Por isso me dei ao trabalho de falar sobre as semelhanças primeiro.

O que eu achei interessante relendo os artigos de 2007 é que a lista de hoje deverá se renovar bastante, pois muitas coisas que eu sentia falta naquele tempo foram implementadas no PostgreSQL e outras eu não considero mais tão importantes atualmente. Então teremos uma lista bem diferente agora, vamos à ela:

  • Parallel Query: O Oracle RAC é uma tecnologia que avançou muito nos últimos anos mas realmente está longe de ser uma solução definitiva para performance ou alta disponibilidade. Não garante performance quando o gargalo é I/O, que é o maior problema dos bancos de dados, particularmente escrita em I/O. Bons discos flash ajudam muito mais. Não resolvem o problema de alta disponibilidade se seus discos corromperem, um standby resolve melhor essa questão. Mas se você tem um Datawarehouse ou consultas monstruosas em tabelas gigantes, a possibilidade de quebrar uma única consulta em vários processos é uma boa. A Oracle faz isso há muito tempo e faz bem. O PostgreSQL lançou recentemente a versão 9.4 com a infraestrutura para fazer a mesma coisa. É esperado que na próxima versão essa funcionalidade esteja presente. Eu diria que em 2 anos isto deverá estar maduro no postgres.
  • Multitenant Architecture: Já faz muito tempo que o PostgreSQL trabalha com várias bases sob o mesmo cluster, dividindo um catálogo global, processos, etc. Também sempre foi uma questão de segundos criar uma nova base. Mas de fato, se você tem varias bases num cluster,  migrar apenas uma base para um outro servidor é isso uma tarefa um pouco complexa. A versão 12c da Oracle tem se esforçado tornar este tipo de tarefa mais simples e tornar a convivência na nuvem mais simples.
  • Exadata: Mesmo antes da Oracle comprar a Sun, já havia sido lançada a primeira versão do Exadata. O Exadata, além de ser uma forma de empacotar hardware, sistema operacional e banco de dados numa caixa preta, é possui também algumas integrações entre storage em banco de dados muito interessantes que aceleram muito algumas operações. Este nível casamento entre hardware e software provavelmente não será visto no PostgreSQL tão cedo.
  • Ferramentas gráficas: O Enterprise Manager até a versão 10g era um problema. Muitas vezes o maior ofensor da base era justamente ele. Mas parece que aos poucos foram melhorando ele. Ainda acho ele bem pesado, mas é uma ferramenta que permite uma visão rápida sobre muitos aspectos do Oracle. O PostgreSQL não possui nenhuma ferramenta gráfica nativa, mas possui alguns projetos livres, notadamente o PGAdmin3 e o PGphpadmin. Assim como no caso do Oracle, algumas das melhores ferramentas são pagas.
  • Assistentes de performance: Para um DBA júnior, os assistentes realmente são uma mão na roda e apontam problemas críticos sem muito esforço. Claro que existem erros e um DBA experiente deve saber quando não confiar nesse tipo de coisa, mas de fato ajuda muito numa avaliação inicial.
  • Particionamento: O particionamento de tabelas continua sendo um ponto forte do Oracle. Possui inúmeras funcionalidades avançadas e é bem robusto. Já escrevi extensivamente sobre particionamento no PostgreSQL aqui. Muita coisa foi melhorando no PostgreSQL nas últimas versões, mas ainda está longe do Oracle.
  • Flashback Query: Levanta a mão quem nunca quis saber o que tinha numa tabela antes de rodarem um UPDATE desastroso… Voltar a base toda para trás no tempo com um Point In Time Recovery pode não ser a melhor solução. O Flashback já me ajudou algumas vezes nesses casos, funciona bem e é bem simples de usar. Só não pode demorar demais, senão os dados somem do UNDO.
  • Transações dentro de um PL: Isso é uma coisa que me chateia ainda em alguns momentos. Eu sei que pode não ser elegante dar um COMMIT ou ROLLBACK dentro de um PL. Eu sei que trabalhando bem com EXCEPTIONs muito desse problema pode ser minimizado, mas se eu quero criar um processo em lote com milhões de transações, eu quero poder dar um COMMIT de x em x registros processados e tenho que construir uma aplicação externa só para isso. Acho que isso o PostgreSQL nunca vai mexer. Só não confundam isso com a aberração do Autonomous Transaction, que é algo que a Oracle jamais deveria ter inventado.
  • Recovery Manager (RMAN): Eu realmente não iria colocar este item aqui, mas sei que vai aparecer nos comentários depois, então vou me adiantar logo. O RMAN é um item obrigatório para quem usa ASM, que é uma forma de RAW Devices mais sofisticada da Oracle. Eu realmente não sou fã de forma alguma do ASM, nem do RMAN. Gosto de ver meus datafiles no sistema de arquivos e poder lidar diretamente com eles. Engana-se quem acha que com RMAN e ASM coisas ruins não vão acontecer. Vão sim e eu tenho boas histórias de terror para contar. O ganho de performance de 5% a 20% não justifica para mim perder completamente o controle da base. Claro que para quem usa RAC, o ASM se tornou praticamente obrigatório. Veja que o PostgreSQL tem uma arquitetura completamente diferente da Oracle em relação aos seus datafiles, que é muito mais simples e eficiente. Isso significa que varias limitações do Oracle em relação à sua arquitetura simplesmente não existem no PostgreSQL. Para quem bradar pela falta do backup incrementar no PostgreSQL, saiba que o clone do RMAN, o pg_rman, já existe faz tempo. Mas assim como o backup incremental, conheço poucas pessoas realmente usam o pg_rman. Mas quem faz backup utilizando o rsync no PostgreSQL sabe que a vida pode ser muito mais simples. E você pode utilizar o pg_basebackup que é bem simples e funciona de forma bem tranquila. O que não existe é uma integração nativa com ferramentas de backup em fita. Isto realmente falta. E por último, vale lembrar que quem faz backup de bases com vários terabytes sem snapshot via storage, perdeu o bonde da história.
amewarexit

Oracle X PostgreSQL – Parte I: Semelhanças

Parte II – Vantagens do Oracle

Parte III – Vantagens do PostgreSQL

Em 2007, escrevi 2 textos falando sobre as vantagens do Oracle sobre o PostgreSQL e vice-versa. Naquela época, minhas observações foram baseadas no Oracle 10.2 e PostgreSQL 8.2. Depois disso a Oracle lançou as versões 11.1, 11.2 e 12.1. O PostgreSQL lançou o 8.3, 8.4, 9.0, 9.1, 9.2, 9.3 e 9.4. Enfim, muita coisa mudou de lá para cá… a febre da Internet não passou e trouxe a onda no NOSQL para a mesa. Eu também mudei bastante, amadureci muitas opiniões e acho que está mais do que na hora de retomar este assunto. Outra coisa que preciso dizer para o leitor que não me conhece é que este texto não é imparcial. Sou um defensor do PostgreSQL, mas trabalho há 12 anos com Oracle também e reconheço algumas fraquezas e vantagens de um e de outro. Mas em nenhum momento aqui vou enganar o leitor me fazendo crer imparcial. Os comentários estão aí para você complementar ou corrigir qualquer informação que julgar relevante. Apenas peço o de faça de forma educada.

Para começar, devo explicar que para mim não faz muito sentido comparar o PostgreSQL com bases NOSQL ou com MySQL. São produtos com fins diferentes. Talvez comparar o PostgreSQL com o SQL Server faça mais sentido, mas o mais próximo que temos, sem dúvida é o Oracle mesmo. Vejamos aqui algumas semelhanças entre ambos que os tornam próximos:

  • Origens semelhantes: No começo da década de 70 a IBM publicou os primeiros documentos que mais tarde dariam origem ao System R (que por sua vez dariam origem ao DB2) escritos pelo Sr. Edgar Frank Codd, dois grandes projetos fora da IBM se iniciaram seguindo suas publicações.
    • Em 73, na universidade de Berkeley o Sr. Michael Stonebraker junto com alguns coletas começaram a desenvolver o Ingres. O Ingres seria a base de muitos outros bancos de dados relacionais como O Sybase e o SQL Server. Em 1985, ainda em Berkeley, o sr. StoneBraker decide começar do zero uma nova versão do Ingres chamada Postgres, incluindo novos conceitos como orientação a objetos.
    • Em 77, o Sr. Larry Ellison se juntou com alguns amigos para criar o Oracle. Em 79 lançam a primeira versão do banco de dados relacional que mais tarde viria a se tornar o líder de mercado, à frente até mesmo do DB2 da IBM que cunhou o padrão SQL.
  • Ambientes semelhantes:
    • Tanto o Oracle quanto o PostgreSQL praticamente nasceram em ambientes UNIX. Ambos até hoje tem como ambiente primário este ambiente até hoje: LInux e Solaris para o Oracle e Linux e FreeBSD para o PostgreSQL.
    • Ambos possuem versões para rodar em outros sistemas operacionais, inclusive o Windows. Notavelmente o PostgreSQL roda até em videogames.
    • Ambos foram escritos em sua maior parte em C.
  • Ambos possuem um ótimo suporte a transações já nas primeiras versões e levam até hoje muito a sério os requisitos do ACID. Sendo assim, são bancos de dados muito confiáveis e que levam muito a sério a questão da consistência dos dados. Este não é o caso do MySQL ou do NOSQL.
  • Ambos trabalham há muito tempo com o conceito de MVCC, tão caro à bases transacionais e ambientes de alta concorrência, onde o fato de você estar alterando um registro não impede que a versão não alterada do mesmo seja lida em outras sessões até que a transação atual confirme a alteração em andamento (read commited).
  • Ambos são extremamente robustos e trazem há muito tempo o conceito de Point In Time Recovery. Isto permite que um backup antigo possa rolar para pontos no tempo posterior ao backup utilizando cópias dos logs de transação (conhecidos como archives) até um ponto no tempo específico. Ou seja, se você fizer seu backup corretamente, a perda de dados em caso de desastre é muito pequena.
  • Ambos implementaram um rico arcabouço de funções e linguagens de programação procedural embutida no banco de dados. O Oracle criou o PL/SQL e as suas funções em C enquanto o PostgreSQL copiou esta linguagem e criou o PL/pgSQL e mais uma infinidade de outras como PL/Python, PL/PERL, C e outras mais.
  • Ambos possuem ótima performance em ambiente OLTP, Data Warehouse (ou BI) e mistos. Assim conseguem um bom desempenho em variadas situações.
  • Ambos tem a capacidade de trabalhar com ambientes severos, seja com bases ou objetos com grande volume de dados, grande volume de transações ou alta concorrência;
  • Ambos são bastante seguros. Patches com correções de segurança são liberados com frequência e as eventuais falhas são corrigidas. Ambos se preocupam muito com a questão e tem mecanismos bem robustos para evitar ataques externos, injeção de SQL e outros perigos.

Conselhos para um futuro pai

Cumprindo a minha promessa de 10 anos do SAVEPOINT, segue o primeiro post encomendado, só que este não é técnico, vem de um grande amigo que a beira de seus 40 anos, vai ser pai pela primeira vez e logo de gêmeos!

A primeira coisa que eu acho realmente importante para quem vai ser pai ou mãe é que sinceramente, eu prefiro não fazer muita distinção entre pai e mãe – salvo raras exceções óbvias como amamentação e coisas em que biologicamente não tem como trocar os papeis. Se você acredita realmente que pai e mãe tem papeis completamente distintos, volte para a sua caverna….  hoje é comum ter mulheres que ganham melhor que os maridos e está tudo bem. Depois que o filho nasceu e foi amamentado (por favor insistam na amamentação, é sério, o único mamífero que nasceu para tomar o leite de vaca é o bezerro mesmo, não importa o que o comercial da Parmalat ou da Nestlé digam) pai e mãe podem trocar de pais à vontade. Se não acredita, a antropologia e a história estão  aí com inúmeros exemplos para mostrar que certas regras só existem na nossa cabeça.

Dito isso, é preciso que se repita sempre: ter filhos não é sinônimo de felicidade. Aquela fórmula de que você precisa arrumar um bom emprego, casar e ter filhos para ser feliz é uma grande balela. Depois que os anticoncepcionais se tornaram uma realidade acessível e aceitável para todas as pessoas civilizadas (os que são contra anticoncepcionais, por favor, parem de ler aqui e vão se ocupar com sua caverna) ter filhos se tornou uma opção. Toda vez que eu encaro um engarrafamento monstruoso eu penso que a sobrevivência da espécie não depende mais de termos muitos herdeiros, e sim de ter menos pessoas pressionando o consumo dos nossos escaços recursos naturais. Então se você não quer ter filhos, além de ter mais tempo e dinheiro para viajar e se divertir, você também está sendo ecologicamente correto. Mas de qualquer forma cada casal tiver um ou dois filhos, estaríamos mantendo a população atual e não aumentando… o que já seria bem razoável. Conheço casais que decidiram não ter filhos e são muito felizes, muito mesmo. Claro que passou pela cabeça deles terem filhos, mas optaram por não ter e vivem muito bem com isso.

Mas vocês decidiram ter um filho. Eu sei que sempre quis ter um, já novo eu sabia que queria ter um. Se tive no momento certo ou com a pessoa certa, é outra questão. Mas sempre quis ter um. Se você teve a sorte de conhecer alguém, casar com ela, viver anos com essa pessoa e depois decidirem juntos que querem ter filhos naquele momento da vida, meus parabéns! Fico feliz quando conheço histórias assim. Vocês já deram um grande passo. Seu filho deve nascer um ambiente bem mais tranquilo. Agora, se seu casamento está de mal a pior e você acha que um filho vai ajudar a unir ambos, não sabe o tamanho da encrenca em que está se metendo. A separação vai ser bem mais dolorosa depois. Pais separados são algo para lá de corriqueiro hoje em dia. Não é um bicho de 7 cabeças. Eu sei que você sabe, mas não custa repetir: filho não segura casamento.

Não depositar sua felicidade ou sua tristeza na criança que vai nascer. Sua felicidade não pode depender de outra pessoa que não você mesma. Se você acha que vai deixar de ser triste quando finalmente tiver um filho, prepare-se… vai piorar. Você vai ter mais responsabilidades, vai ter menos tempo para si mesmo, vai ter menos dinheiro para gastar consigo mesmo, e a criança não vai fazer o que você espera que ela faça. Se você fizer muitos planos, é bem possível que você se frustre vendo que nada daquilo vai se realizar. Ou pior: você vai frustrar a criança, obrigando ela a seguir o seu planejamento e suas expectativas e não a vida que ela mesma vai desejar.

Mas ser pai é uma experiência que eu sempre achei e continuo achando que vale à pena. Particularmente para mim, acho que me tornei uma pessoa bem melhor depois que errei muito nesse ofício. E continuo errando. Conheci uma moça que leu um monte de livros sobre como educar os filhos… eu não li nenhum, mas sou filho e sou pai. Acho que estas experiências devem nos orientar. A capacidade de reflexão e autocrítica também. No final, o tal do bom senso não vem de graça. Não se guie pela última tendência ou modismo. Se tem vontade de abraçar seu filho abrace. Se acha que determinados comportamentos são passíveis de punição, puna. Só não mude a regra no meio do caminho de uma hora para outra. Não ceda a chantagens ou choramingos. Uma coisa é analisar, rever e corrigir o rumo de algumas coisas. Outra coisa é não resistir a pressão ou se dobrar pela culpa. Você pode negociar um castigo por bom comportamento, mas não deve comprar o vídeo game novo sabendo que sua condição financeira não permite, não importa o quanto ele te pressione.

Mas tudo pode ser negociado. Dividir as responsabilidades na casa é sempre uma ótima opção. Dividir tarefas e responsabilidades é algo que deve-se fazer logo cedo. Não dá para fazer aquela super viagem? Sente com a família e avalie as possibilidades juntos. Discuta o que o orçamento atual permite ou não. Traga os seus filhos para o  processo de decisão e compartilhe a responsabilidade pelo sucesso ou fracasso. Você não precisa ser o herói ou o vilão sempre. Da mesma forma, pagar os filhos para ajudarem na casa, ou para estudarem na escola é uma grande besteira. Os filhos devem estudar por eles mesmos, não pelos pais. É o futuro deles que está em jogo, não o seu. Passou de ano, parabéns! Não passou, problema seu. Seu filho não tem a obrigação de fazer doutorado, mas se não quer estudar, seria uma boa começar a trabalhar cedo.  A não ser que ele tenha nascido para ser  herdeiro. Eles devem ajudar em casa por uma questão de solidariedade, pois todos tem responsabilidades na casa, não apenas os pais. Quer fazer um bolo? Lave a louça depois. Quer andar de meia pela casa? Sem problemas, lave as suas meias.

Como dizia o Sr. Antônio Abujamra dizia para o seu filho: “Cada um tem o direito de estragar a sua vida do jeito que achar melhor”. O filho se tornou músico…

Meu pai foi pediatra e cresci ouvindo sobre como cuidar de uma criança envolvia em primeiro lugar em cuidar dos pais. Todo psicologo vai concordar que não adianta fazer terapia com uma criança se não tratar também dos pais. Tive pais excepcionais. Gosto de me gabar disso e gosto de pensar que as coisas boas que tive deles deveriam ser referência para mim como pai. Minha mãe não teve a mesma sorte, o meu avô era uma pessoa muito dura de uma concepção bem tradicional de educação. Ele também foi referência para a minha mãe, no sentido de não querer repetir os mesmos erros deles. Seja como for, a gente sempre tem uma referência, positiva ou negativa. A vantagem de ter uma referência positiva é que você já tem um modelo para seguir, já tem exemplos e acredita que é possível fazer isso dar certo. Assim como tem gente que acredita que a escola é sempre ruim, há quem acredite que não terá a capacidade de ser um bom pai. Então, seja qual a sua referência, acho que vale dizer que você nunca será tão ruim e nem tão bom quanto os seus pais. Será diferente. Você teve outras experiências, se casou (ou não) com outra pessoa que tem outra história e vive em outros tempos.

O quanto você vai se esforçar depende de você, mas tenha em mente que se você for uma pessoa infeliz, vai tornar a vida do seu filho infeliz também. Apesar de você ter seu direito à felicidade, você tem uma responsabilidade. Você não é obrigado a abrir mão da sua vida pessoal para o resto da vida (embora nos primeiros anos aconteça muito isso), mas tem uma responsabilidade da qual se espera que você não fuja. Tem gente que curte tudo, mas sinceramente, acordar com choro de madrugada, trocar fraldas, etc, dá trabalho e cansa. O grau de ansiedade e estresse da família faz toda a diferença nessas horas. Assim como tem gente que consegue passear com um cão tranquilamente pela rua, quase sem usar a guia, tem gente que é quase arrastado pelo animal. Os filhos tem algo parecido… a tensão familiar vai toda para a personalidade da criança. Se cuidar dela é uma tarefa angustiante para você, essa angústia vai fazer parte da personalidade da criança. Da mesma forma, se a criança se torna a única razão do seu viver, e tudo for lindo e maravilhoso, você está criando uma expectativa de que tem a obrigação de fazer tudo pela criança e adorar isso, para o resto da vida.

Me pai dizia que tanto o pai quanto a mãe ganhavam uma cartela com a palavra NÃO. E cada um vai usando com o tempo. Aquele que convive mais tempo com a criança acaba gastando a cartela primeiro, e depois que acontece, você pode dizer NÃO o quanto quiser, não vai mais funcionar como antes. Por isso precisa de parcimônia com tudo. Não dá para deixar uma criança brincar com o fogão por exemplo… mas dá para deixar ela tomar um choque na tomada… algumas coisas a criança pode experimentar por conta própria, como experimentar suco com sal ao invés de açúcar. Mas não dá para deixar ela atravessar a rua engatinhando. A importância de deixar a criança aprender sozinha é enorme. A frustração deve ser aprendida logo cedo. Mas a tirania deve ser sempre evitada. Bom senso não é fácil. O quanto você vai proteger e o quanto você vai castrar depende de você. Não existe fórmula correta. Pai e Mãe devem traçar acordos claros em relação a isso… não é nada fácil educar num ambiente onde pai e mãe tem visões muito diferentes nisso. Acordos devem ser estabelecidos antes de chegar na criança. Ela vai saber muito bem explorar essas diferenças. Quando ela quiser segurança ela vai procurar o castrador e quando quiser liberdade vai procurar o permissivo.

Outra coisa valiosa que aprendi com meu pai é a admiração pela forma como o Sr. Monteiro Lobato escreve para crianças: dentro do seu universo, elas são tratadas como adultos. Nada de mimimi e ficar filtrando tudo. Seja honesto sempre que puder. Tente explicar exatamente o que ocorre ao invés de inventar histórias. Não precisa iniciar uma criança de 4 anos nos horrores da segunda guerra mundial, nem matar o papai noel antes do tempo. Também não precisa proibir a criança de ver TV. Na verdade a questão é não inventar um universo à parte para a criança. Ela vai sacar logo do que você gosta ou não. Vai te imitar nos gestos e opiniões. Mas… não onde você espera. Se você bebe na garrafa, provavelmente ela vai te imitar. Se você gosta de música erudita, pode ser que ela não goste… Mas seja como for, tente explicar como as coisas realmente são, mesmo que ela não entenda tudo. A atitude é que faz a diferença. O seu esforço tem um significado importante: seus filhos sentirão que você tem uma relação de respeito  elas. Esse negócio de ser outra pessoa quando veste o uniforme de pai é bem complicado. Trate-os como Monteiro Lobato, de igual para igual, não no que tange responsabilidades e papeis, mas no que tangue à capacidade intelectual. Seus filhos não são retardados, eles podem não ter um diploma de nível superior, mas você se surpreenderá com à capacidade de fazer relações com coisas do universo deles que eles tem. É mais… eles vêem TV, acessam a internet, conversam com os amigos da escola, vivem um monte de coisas que você não vai ter como acompanhar.

Cuidado com as receitas de bolo que dizem que existem etapas bem definidas para cada coisa. Se você se guiar por aí, vai ter a expectativa de que ele cresça em determinado rítmo, ande, fale, aprenda, tire as fraldas, largue a chupeta, etc. Tenho um primo que custou a crescer… os pais achavam que ele estava nanico e levaram num pediatra que indicou um especialista que fez uma mega bateria de exames e prescreveu uma super dieta rigorosa. Passaram alguns anos e ele não cresceu. Aí ele foi num especialista mais fodástico ainda, fez exames mais caros e detalhados e descobriu o óbvio. Ele não tinha nada. Ele só tinha um rítmo de crescimento diferente. Pararam com a tal dieta e os remédios. Hoje ele tem mais de 1,9m.

Mas tudo isso no final é uma grande besteira, parece um monte de recadinhos do facebook…. O importante mesmo, o fundamental, o cerne da questão,  (vasculhando a caixa de chavões e letras de músicas impactantes), bom, eu não tenho a menor ideia. Um monte de gente deve achar que eu crio meu filho de forma completamente equivocada. Não tem regra que sirva para todos. Não se iluda procurando uma. Curta, os filhos são um companheiros diferentes de todas as namoradas, amigos e parentes que você já teve. Diferente do seus alunos ou subordinados. Diferentes até mesmos dos seus animais de estimação……

Vai lá e tenta. Curta. Erre. Torça! Preocupe-se. Chore. Erre novamente. Depois você me conta o que achou.

10 anos de SAVEPOINT!!!

veleiro-wallpaperEstava aqui acompanhando as divagações do Daniel Duclos sobre blogs quando notei que o SAVEPOINT já fez seus 10 anos!!! Na verdade faz mas que isso, mas a história é mais ou menos assim:

  • Em 2001 eu peguei uns textos meus e resolvi montar um site para reunir-los com HTML estático mesmo. Achei que tava dando muito trabalho e desisti;
  • No final de 2004 sob influência do Sr. Fernando Ike começo a blogar em alguns sites na Internet, como o wordpress.com e o Multiply.
  • Em 2006 eu migro o blog para o a plataforma XOOPS, hospedando no servidor do Fernando Ike, o midstorm.org. Nesse domínio ficavam também os blogs do próprio Fernando Ike, e o do compadre Jefferson Alexandre. Alguns posts iniciais do blog foram limados mas em essência, quase todo o conteúdo foi migrado manualmente.
  • No meio de 2007 ainda no mesmo domínio migrei para o WordPress. Desta vez fiz a migração copiando os dados diretamente das tabelas do XOOPS usando um pouco de SQL. Assim todo o conteúdo veio junto de uma vez. Apesar das novidades no caminho, continuo com o Worpress até hoje. Me atende.
  • Em 2012 o Midstorm foi desfeito e eu deixei o blog temporariamente no tellesr.wordpress.com. Tenho que agradecer aqui o Fernando Ike por me hospedar por estes anos!
  • Ainda no final de 2012 eu peguei o domínio atual e pretendo ficar com ele por um bom tempo…  hospedei o blog no DreamHost, mas ele estava insuportavelmente lento…
  • Em 2013 o Jefferson Alexandre gentilmente se ofereceu para me hospedar na VM dele na Digital ocean. Ficou rápido novamente e o tráfego voltou ao normal .

O Importante é que agora o domínio pelo menos é meu e eu não pretendo mais trocá-lo. Trocar de domínio deixa seu blog no limbo por muito tempo. Posts que eram muito visitados antes nunca mais se recuperaram…

Hoje em dia o Facebook assumiu o posto de muro das lamentações, e tenho escrito menos coisas pessoais. Na verdade no início do blog ele realmente tinha muito mimimi… aos poucos vieram algumas reflexões pessoais mais longas e finalmente os posts técnicos mais sérios. Sempre teve de tudo um pouco aqui. São mais de 340 posts até agora, e contando. Alguns bem longos, alguns curtos. Cheguei a ganhar um prêmio da comunidade brasileira de PostgreSQL pelos artigos escritos em 2013, que foi bem legal. De fato o blog ganhou uma certa vida entre os usuários brasileros de PostgreSQL.

Atualmente ando mais preocupado em pedalar, viajar e dar conta dos compromissos de trabalho. Muita coisa acontecendo e pouco tempo disponível, além é claro, da preguiça e falta de inspiração para escrever.

Mas já tá na hora de tirar poeira do blog…  janeiro sempre foi uma boa época para escrever. Apesar que tem chovido trabalho, estou querendo me dedicar a novos temas aqui. Então resolvi pedir ajuda…

Sugira um tema para um novo post aqui no blog e eu prometo tentar escrever o tema mais solicitado aqui.

Claro, não dá para falar sobre o que eu não conheço… então tem de ser algo viável. Então, se quiser encomendar um artigo, essa é a sua chance. Em homenagem aos 10 anos do SAVEPOINT, hoje o leitor está com a palavra!

Deixe seus comentários…

Timbira lança cursos on-line de PostgreSQL

A notícia não é tão nova… já está no ar há uns dias na comunidade de PostgreSQL. Mas o fato é que no ano passado decidimos criar na Timbira 3 cursos on-line de 8 horas cada para serem realizados on-line. Cada um dos sócios vai ministrar um curso a saber:

Nos links acima você pode ver o custo, datas e o conteúdo. Eu serei o responsável pelo primeiro curso, o de Backup e Restore que começa em breve, no dia 7 de junho. Depois será a vez do Euler Taveira e do Fabrízio de Royes Mello. Será a minha primeira experiência com um curso on-line e acho que vai ser bem divertido. Já faz um bom tempo que estou afastado da sala de aula e eu venho esperando esta oportunidade por um bom tempo. Isso porque deixei de acreditar em uma série de cursos que vejo no mercado por aí. Não acho que despejar uma quantidade incrível de conteúdo em pouco tempo para pessoas com pouca familiaridade com determinada tecnologia seja algo muito produtivo. Espero fazer algo um pouco mais interessante que isso e trazer um pouco da minha bagagem na educação para este projeto novo da Timbira. Esse foi um dos motivos para isso levar tanto tempo para sair do papel. O outro, como alguns mais próximos sabem, foram questões pessoais que mudaram bastante o rumo da minha vida recentemente.

O número de vagas em cada turma é bem limitado, pois não quisemos abrir mão da qualidade do curso. A primeira turma já está quase no limite, mas ainda tem algumas vagas pelo que eu pude ver. Claro que é bem possível que novas turmas virão. Tudo vai depender da demanda e de termos tempo de preparar novos cursos. Escolhemos os temas com cuidado e dando foco em questões bem práticas que nossos clientes solicitam continuamente. A Timbira já tem feito cursos In Company faz uns anos, é a primeira vez que abrimos um curso para o público em geral. Estamos experimentando isso, vendo como é a demanda do mercado e tudo o mais. Existem muitos planos para o futuro se isso der certo agora.

Agora estou muito feliz com esse novo momento da Timbira que tem me dado novas alegrias a cada dia. Estamos crescendo num ritmo que às vezes até assusta e este é definitivamente um momento para a gente descontrair e se divertir um pouco. Digo isso pois estar numa sala de aula é um prazer para mim e foi uma das metas que eu estabeleci para mim este ano.

E para aqueles que tiverem a oportunidade de participar do curso… até breve!!!

OBS: Veja outros cursos da Timbira.

Novidades com PostgreSQL no ar…

chelnik-crochetSei que faz um tempo que não escrevo sobre PostgreSQL por aqui…  mas isso não significa que as coisas estão paradas na comunidade. Quem acompanha o planeta internacional, ou a série “Waiting for …” do Depez sabe que existem muitas novidades para a versão 9.4 por vir. Uma das que tem causado um certo frisson na comunidade é o novo tipo de dados, o jsonb, um tipo de dados binário para json.  A ideia é que trabalhar com dados semi estruturados de forma mais inteligente e flexível no PostgreSQL, tornando a necessidade de usar bases noSQL cada vez menor. A cada dia que passa fica mais fácil ter a flexibilidade e o desempenho de uma base noSQL junto com a robustez de a confiabilidade de uma base SQL transacional tudo dentro do PostgreSQL! Nossos amigos russos não param de nos surpreender!

Além disso um monte de coisas bacanas por aqui. Andei testando o PostgreSQL Studio que é uma interface de administração em Java feita pelo pessoal do Heroku e o Data Filler, uma ferramenta para criar massas de dados. Ainda estou testando ambas as ferramentas, o PostgreSQL Studio é bem simples e para algo feito em Java, até que não parece pesado. O Data Filler merece um post só sobre ele, é uma ferramente que pretendo usar muito ainda. Realmente algo que todo desenvolvedor deveria ter debaixo do braço.

Enquanto isso no Brasil….

Bom, depois do PGBR 2013 em RO, algumas pessoas podem pensar que tudo anda meio devagar por aqui… Realmente não há novos PGDays à vista este ano. Eu mesmo não devo organizar nada neste semestre, mas se alguém tiver alguma sugestão, topo fazer algo no segundo semestre. Como eu esperava, não deveremos ter um PGBR2014…  mas tenho quase certeza de que em 2015 teremos mais uma boa edição do PGBR. Como eu já disse antes, acho que é um evento que funciona bem a cada 2 anos. O nosso maior revés recentemente foi a invasão do nosso site, o www.postgresql.org.br . Ainda estamos trabalhando para reestabelecer o serviço, mas a lista de discussão por e-mail continua no ar, pelo menos.

Agora, na área de desenvolvimento… muitas novidades sim! O Francisco Figueiredo lançou recentemente mais uma versão do seu driver para . Net o Npgsql. O Euler Taveira e o Fabrízio de Royes Mello estão com vários patches no PostgreSQL 9.4 e agora o Fabrízio está se candidatando para o Google Summer of Code de 2014 também. É claro que isso é motivo de orgulho para nós. A Timbira é sem dúvida a empresa que mais contribui com código para o PostgreSQL no Brasil e acho que podemos afirmar com tranquilidade que temos os melhores consultores também. Podemos ser uma empresa pequena, mas quem já teve uma base recuperada por nós, sabe que fazemos coisas que provavelmente ninguém mais no Brasil faria. Eu mesmo já tive um cliente que após migrar para uma versão nova do PostgreSQL (claro, faltou homologar melhor antes de migrar, normal) descobriu um bug na nova versão…. e nós tínhamos um patch com a correção no dia seguinte. Agora me conta quem é que faz isso por aqui?

Então, se você acha que a comunidade está parada, saiba que o mais importante continua rolando: a lista continua dando suporte para os usuários e os desenvolvedores continuam desenvolvendo novas funcionalidades! E posso garantir que a versão 9.4 traz muitos elementos bacanas no PostgreSQL. Algo me diz que não chegaremos na versão 9.5… pois tem muita coisa boa para acontecer nos próximos anos, eu chuto que iremos para uma versão 10.0 em breve!!!

Parênteses 1.0

Como todo nerd que trabalha com informática, eu também me assombro com os aplicativos para celular que fazem pessoas milionárias da noite para o dia. E também já fiquei pensando em uma ideia original para colocar em prática…

Já faz um tempo que venho com a mesma ideia na cabeça, um aplicativo que seria realmente útil para mim. Sou daqueles que falam muito, muito mesmo. Assunto para mim é uma coisa inesgotável quando estou conversando com pessoas interessantes. Só tem um problema, os parênteses. Aquela coisa do Miguel de Cervantes de abrir uma história dentro da outra e não saber mais sobre o que estava falando…. vira e mexe eu me perco e não consigo retomar para a história anterior, depois de tantas abertas. É como navegar nos primórdios da internet, sem abas e sem usar os favoritos. Uma hora você se perde.

Estou em busca de pessoas criativas para levar o meu super aplicativo a cabo! O “fechador de parênteses”. Basta marcar toda vez que abrimos um novo parênteses e lembrar onde estávamos quando fecharmos cada um deles. Para alguns papeadores mais densos como eu, isso pode ser de grande ajuda e dar um senso estético mais acabado para a sua conversa. Você com certeza vai se sentir menos louco. Ou então vai ver quantitativamente o tamanho da sua loucura… Conheço mais algumas pessoas tão prolixas quanto eu que tenho certeza que seriam bons clientes. Não sei se seria um best seller com um Angry Birds, mas aposto que se funcionar, terei um público fiel para o resto da vida!

Talvez se for para eu ganhar dinheiro mesmo, seja melhor eu escrever livro de auto ajuda!!!