http://howfuckedismydatabase.com/

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

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

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

PostgreSQL Extension network

Bom, não é algo do outro mundo, mas segue aqui um pequeno script que mostra como fazer isso. Você só precisa editar os parâmetros iniciais e só chamando ele, já temos um teste. Depois é só passar o assunto e mensagem como parâmetro na procedure e você já pode enviar seus alertas para todo mundo.

Segue abaixo o script:

 
CREATE OR REPLACE PROCEDURE envia_email(
  p_assunto          VARCHAR2      := 'Teste de envio',
  p_mensagem         CLOB          := 'Teste'
) IS
  v_remetente        VARCHAR2(50)  :='fabio.telles@midstorm.org';  -- Remetente
  v_destinatario     VARCHAR2(50)  :='cliente@midstorm.org';       -- Destinatário
  v_destinatario_cc  VARCHAR2(50)  :='dba@savepoint.org';          -- Com cópia
  v_smtp             VARCHAR2(20)  := '192.168.0.1';               -- Endereco IP do SMTP
  v_smtp_user        VARCHAR2(50)  := 'dba@midstorm.org';          -- Usuário autenticado no SMTP
  v_smtp_user_pass   VARCHAR2(50)  := 'sua_senha';                 -- Senha do usuário SMTP
  v_conn             utl_smtp.connection;                          -- Abre conexão SMTP e HTTP
BEGIN
  -- Abre conexão com um Servidor SMTP, porta padrão é 25
  v_conn := utl_smtp.open_connection (v_smtp,25);
  utl_smtp.helo (v_conn, v_smtp);
  utl_smtp.command (v_conn, 'AUTH LOGIN');
  utl_smtp.command (v_conn, utl_raw.cast_to_varchar2(utl_encode.base64_encode(
    utl_raw.cast_to_raw((v_smtp_user)))));
  utl_smtp.command (v_conn, utl_raw.cast_to_varchar2(utl_encode.base64_encode(
    utl_raw.cast_to_raw((v_smtp_user_pass)))));
  utl_smtp.mail (v_conn, ('<' || v_remetente || '>'));
  utl_smtp.rcpt (v_conn, ('<' || v_destinatario || '>'));
  utl_smtp.rcpt (v_conn, ('<' || v_destinatario_cc || '>'));
 
  utl_smtp.open_data(v_conn);
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw('From:'    || v_remetente  
    || utl_tcp.crlf));
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw('To:'      || v_destinatario 
    || utl_tcp.crlf));
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw('Cc:'      || v_destinatario_cc 
    || utl_tcp.crlf));
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw('Subject:' || p_assunto 		
    || utl_tcp.crlf)); 
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw(' '        || utl_tcp.crlf));
  utl_smtp.write_raw_data(v_conn, utl_raw.cast_to_raw(utl_tcp.crlf || p_mensagem)); 
 
  utl_smtp.CLOSE_DATA(v_conn);
  utl_smtp.QUIT (v_conn);
 
EXCEPTION
  WHEN OTHERS THEN
    utl_smtp.quit (v_conn);
    RAISE_APPLICATION_ERROR(-20011,'Não foi possível enviar o e-mail devido ao seguinte erro: ' 
      || sqlerrm);
END ENVIA_EMAIL;

Vira e mexe você precisa dar uma geral num banco de dados que você nunca viu antes. Bom, então segue abaixo um pequeno script para lhe ajudar na tarefa. Eu, sei, podia melhorar muito, aceito sugestões, claro. Em todo caso, já dá para começar:

SET serveroutput ON SIZE 1000000 FORMAT WRAPPED
SET autotrace    OFF
SET feedback     OFF
SET wrap         OFF
SET trimspool    ON
SET pagesize     100
SET linesize     200
 
ALTER SESSION SET NLS_DATE_FORMAT = 'DD/MM/YY';
 
DECLARE
  v_media_archive   number;
  v_inst_num        number;
  v_spfile          varchar(10);
  v_version         v$version.banner%TYPE;
  v_host            v$instance.host_name%TYPE;
  v_instance        v$instance.instance_name%TYPE;
  v_thread          v$instance.thread#%TYPE;
  v_startup_time    v$instance.startup_time%TYPE;
  v_dbid            v$database.dbid%TYPE;
  v_name            v$database.db_unique_name%TYPE;
  v_created         v$database.created%TYPE;
  v_resetlogs_time  v$database.resetlogs_time%TYPE;
  v_log_mode        v$database.log_mode%TYPE;
  v_open_mode       v$database.open_mode%TYPE;
  v_platform        V$database.platform_name%TYPE;
 
BEGIN
  SELECT DECODE(COUNT(*),0,'PFILE','SPFILE') INTO v_spfile FROM v$spparameter
    WHERE isspecified != 'FALSE';
  SELECT banner INTO v_version FROM v$version  WHERE ROWNUM < 2;
  SELECT UPPER(host_name), UPPER(instance_name), thread#, startup_time
    INTO v_host, v_instance, v_thread, v_startup_time
    FROM gv$instance
  ;
  SELECT count(1) INTO v_inst_num FROM gv$instance;
  SELECT dbid, db_unique_name, created, resetlogs_time, log_mode, open_mode, platform_name
    INTO v_dbid, v_name, v_created, v_resetlogs_time, v_log_mode, v_open_mode, v_platform
    FROM v$database
  ;
 
  dbms_output.put_line('');
  dbms_output.put_line('Informações de ' || v_name);
  dbms_output.put_line('========================');
  dbms_output.put_line('');
  dbms_output.put_line('Informações Gerais');
  dbms_output.put_line('------------------');
  dbms_output.put_line('DBID..................: ' || v_dbid);
  dbms_output.put_line('Servidor..............: ' || v_host || ' / ' || v_platform);
  dbms_output.put_line('Versão................: ' || v_version);
  dbms_output.put_line('Número de intâncias...: ' || v_inst_num);
  dbms_output.put_line('Instância / Thread....: ' || v_instance || ' / ' || v_thread);
  dbms_output.put_line('Criado em.............: ' || to_char(v_created,'DD/MM/YYYY'));
  dbms_output.put_line('Último RESETLOG.......: ' || to_char(v_resetlogs_time,'DD/MM/YYYY'));
  dbms_output.put_line('Última inicialização..: ' || to_char(v_startup_time,'DD/MM/YYYY'));
  dbms_output.put_line('Inicializado com......: ' || v_spfile);
  dbms_output.put_line('Modo ARCHIVE..........: ' || v_log_mode);
  dbms_output.put_line('Status................: ' || v_open_mode);
  dbms_output.put_line('');
 
  dbms_output.put_line('Opções ativas');
  dbms_output.put_line('=============');
 
FOR options IN (SELECT parameter FROM v$option WHERE value = 'TRUE') LOOP
    dbms_output.put_line(options.parameter);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Limites utilizados');
  dbms_output.put_line('==================');
  dbms_output.put_line('Inst. | Sessões  | Usuários | CPUs | Cores');
  dbms_output.put_line('------|----------|----------|------|------');
 
FOR license IN (
  SELECT
    RPAD(inst_id,5) inst_id,
    RPAD(sessions_max,8) AS sessions,
    RPAD(users_max,8) AS users,
    RPAD(cpu_core_count_highwater,4) AS cpu,
    cpu_socket_count_highwater AS socket
      FROM  gv$license
      ORDER BY inst_id
  ) LOOP
    dbms_output.put_line(license.inst_id || ' | ' || license.sessions || 
      ' | ' || license.users || ' | ' || license.cpu || ' | ' || license.socket);
  END LOOP;
  dbms_output.put_line('');
 
--SELECT * FROM v$configured_interconnects;
 
  dbms_output.put_line('Localização');
  dbms_output.put_line('===========');
  dbms_output.put_line('Parâmetro            | Valor');
  dbms_output.put_line('---------------------|------');
  FOR nls IN (
    SELECT RPAD(description,20) parameter, property_value
      FROM database_properties
      WHERE property_name IN ('NLS_CHARACTERSET', 'NLS_DATE_FORMAT','NLS_LANGUAGE',
        'NLS_NUMERIC_CHARACTERS', 'NLS_TERRITORY', 'DBTIMEZONE')
  ) LOOP
    dbms_output.put_line(nls.parameter || ' | ' || nls.property_value);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Memória');
  dbms_output.put_line('=======');
  dbms_output.put_line('Parâmetro                 | Valor(MB)');
  dbms_output.put_line('--------------------------|----------');
  FOR mem IN (
    SELECT RPAD(name,25) parameter, ROUND(value/1024/1024) valor_mb
      FROM v$parameter
      WHERE name IN ('db_cache_size','large_pool_size','java_pool_size',
        'sga_max_size','shared_pool_size','pga_aggregate_target')
      ORDER BY name
  ) LOOP
    dbms_output.put_line(mem.parameter || ' | ' || mem.valor_mb);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('REDO');
  dbms_output.put_line('====');
  dbms_output.put_line('Grupo | Tamanho | Arquivo');
  dbms_output.put_line('------|---------|--------');
  FOR log IN (
    SELECT f.GROUP# AS grupo, ROUND(l.bytes/1024/1024) AS tamanho, f.member AS arquivo
      FROM v$logfile f, v$log l
      WHERE f.GROUP# = l.group#) LOOP
    dbms_output.put_line(lpad( log.grupo,5) || ' | ' || lpad(log.tamanho,7) ||
      ' | ' || log.arquivo);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Control File');
  dbms_output.put_line('============');
  FOR control IN ( SELECT name FROM v$controlfile) LOOP
    dbms_output.put_line(control.name);
  END LOOP;
  dbms_output.put_line('');
 
  IF v_log_mode = 'ARCHIVELOG' THEN
    SELECT ROUND(SUM(blocks * block_size) / to_number( MAX(first_time) -
      MIN(first_time)) /1024/1024) media
      INTO v_media_archive
      FROM V$ARCHIVED_LOG; 
 
    dbms_output.put_line('ARCHIVE');
    dbms_output.put_line('=======');
    dbms_output.put_line('Quantidade média de archive gerado: ' || v_media_archive ||
      'MB / dia');
    dbms_output.put_line('');
    dbms_output.put_line('ID | Status     | Tipo       | Destino    | Arquivo');
    dbms_output.put_line('---|------------|------------|------------|--------');
 
    FOR arch IN (
      SELECT RPAD(dest_id, 2) id, RPAD(STATUS,10) STATUS, RPAD(binding,10) tipo,
        RPAD(target,10) destino, destination arquivo
        FROM v$archive_dest WHERE destination IS NOT NULL) LOOP
      dbms_output.put_line(arch.id || ' | ' || arch.STATUS || ' | ' || arch.tipo ||
        ' | ' || arch.destino || ' | ' || arch.arquivo);
    END LOOP;
    dbms_output.put_line('');
  END IF;
 
  dbms_output.put_line('Logs do grupo ADMIN');
  dbms_output.put_line('===================');
  dbms_output.put_line('Nome            | Diretório');
  dbms_output.put_line('----------------|----------');
  FOR admin IN (
    SELECT RPAD(name,15) log, value
      FROM v$parameter
      WHERE name IN ('audit_file_dest', 'background_dump_dest', 'core_dump_dest',
        'user_dump_dest')
      ORDER BY NAME) LOOP
    dbms_output.put_line(admin.log || ' | ' || admin.value);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Configurações de auditoria e segurança');
  dbms_output.put_line('======================================');
  dbms_output.put_line('Parâmetro       | Valor');
  dbms_output.put_line('----------------|------');
  FOR security IN (
    SELECT RPAD(name,15) log, value
      FROM v$parameter
      WHERE name IN ('audit_trail', 'os_authent_prefix', 'remote_os_authent',
        'remote_login_passwordfile', 'utl_file_dir')
      ORDER BY NAME) LOOP
    dbms_output.put_line(security.log || ' | ' || security.value);
  END LOOP;
  dbms_output.put_line('');
 
END;
/
 
SET serveroutput OFF
SET serveroutput ON SIZE 1000000  FORMAT WRAPPED
 
BEGIN
  dbms_output.put_line('JOBs');
  dbms_output.put_line('====');
  dbms_output.put_line('    Nº | Esquema         | Dur.(min) | BK| Intervalo    ' ||
    '                       | SQL');
  dbms_output.put_line('-------|-----------------|-----------|---|--------------' ||
    '-----------------------|----');
  FOR job IN (
    SELECT LPAD(job,6) id, RPAD(schema_user,15) esquema, RPAD(TRUNC(total_time/60),9) dur_mi,
      broken, RPAD(interval,35) interval, what
      FROM dba_jobs
      WHERE interval !='null'
  ) LOOP
    dbms_output.put_line(job.id || ' | ' || job.esquema || ' | ' || job.dur_mi || ' | '
      || job.broken || ' | ' || job.interval || ' | ' || job.what);
  END LOOP;
  dbms_output.put_line('');
END;
/
 
SET serveroutput OFF
SET serveroutput ON SIZE 1000000  FORMAT WRAPPED
 
BEGIN
  dbms_output.put_line('Segmentos por esquema, tablespace e tipo');
  dbms_output.put_line('========================================');
  dbms_output.put_line('Esquema         | Tablespace      | Tipo de Objeto  | QT   | Tam(MB)');
  dbms_output.put_line('----------------|-----------------|-----------------|------|--------');
  FOR schema IN (
    SELECT
      RPAD(owner,15) schema,
      RPAD(tablespace_name, 15) tablespace,
      RPAD(segment_type,15) type,
      LPAD(count(*),4) qt, LPAD(ROUND(SUM(bytes)/1024/1024),6) mb
        FROM dba_segments
        WHERE OWNER NOT IN ('SYS','OUTLN','SYSTEM','WMSYS','XDB','SISMON')
        GROUP BY owner, tablespace_name, segment_type
        ORDER BY owner, tablespace_name, segment_type) LOOP
    dbms_output.put_line(schema.schema || ' | ' || schema.tablespace || ' | '
      || schema.type || ' | ' || schema.qt || ' | ' || schema.mb);
  END LOOP;
  dbms_output.put_line('');
END;
/
 
SET serveroutput OFF
SET serveroutput ON SIZE 1000000  FORMAT WRAPPED
 
BEGIN
  dbms_output.put_line('Objetos inválidos por esquema e tipo');
  dbms_output.put_line('====================================');
  dbms_output.put_line('Esquema         | Tipo de Objeto  |  QT');
  dbms_output.put_line('----------------|-----------------|----');
  FOR invalid IN (
    SELECT RPAD(owner,15) AS esquema, RPAD(object_type,15) tipo, LPAD(COUNT(*),4) qt
      FROM dba_objects
      WHERE STATUS != 'VALID'
      GROUP BY owner, object_type) LOOP
    dbms_output.put_line(invalid.esquema || ' | ' || invalid.tipo || ' | ' || invalid.qt);
  END LOOP;
  dbms_output.put_line('');
END;
/
 
SET serveroutput OFF
SET serveroutput ON SIZE 1000000 FORMAT WRAPPED FORMAT WRAPPED
 
BEGIN
  dbms_output.put_line('Diretorios');
  dbms_output.put_line('==========');
  dbms_output.put_line('Esquema         | Nome                           | Diretório');
  dbms_output.put_line('----------------|--------------------------------|----------');
  FOR directory IN (
    SELECT
      RPAD(owner,15) AS esquema,
      RPAD(directory_name,30) nome,
      directory_path AS path
        FROM dba_directories ORDER BY owner, path) LOOP
    dbms_output.put_line(directory.esquema || ' | ' || directory.nome || ' | ' ||
      directory.path);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Database Links');
  dbms_output.put_line('==============');
  dbms_output.put_line('Esquema         | Nome            | Criacao    |' ||
    ' Esquema remoto  | Host remoto');
  dbms_output.put_line('----------------|-----------------|------------|' ||
    '-----------------|------------');
  FOR dblink IN (
    SELECT
      RPAD(owner,15) AS esquema,
      RPAD(db_link,15) nome,
      RPAD(username,15) esquema_destino,
      host host_destino,
      to_char(created,'DD-MM-YYYY') criacao
        FROM dba_db_links ORDER BY host, owner) LOOP
    dbms_output.put_line(dblink.esquema || ' | ' || dblink.nome || ' | ' ||
      dblink.criacao || ' | ' || dblink.esquema_destino || ' | ' || dblink.host_destino);
  END LOOP;
  dbms_output.put_line('');
 
  dbms_output.put_line('Visões Materializadas');
  dbms_output.put_line('=====================');
  dbms_output.put_line('Esquema         | Nome            | Q Len | Atualiz. | DBLink');
  dbms_output.put_line('----------------|-----------------|-------|----------|-------');
  FOR mview IN (
    SELECT RPAD(owner,15) esquema, RPAD(mview_name,15) nome, RPAD(master_link,15) link,
      LPAD(query_len,5) len, last_refresh_date FROM dba_mviews
  ) LOOP
    dbms_output.put_line(mview.esquema || ' | ' || mview.nome || ' | ' || mview.len ||
      ' | ' || mview.last_refresh_date || ' | ' || mview.link);
  END LOOP;
  dbms_output.put_line('');
 
END;
/
SET feedback ON
SET LINESIZE  120

Se inscreva no site do evento, vagas limitadas.

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

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

Palestrantes confirmados:

• Euler Taveira
• Fábio Telles
• Fernando Ike
• Leonardo César
• João Cosme

Nesse eu vou!

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

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

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

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

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

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

Simples não?

NÃO.

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

Quanto tudo dá errado!

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

Outros usos para o backup

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

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

O tal do SLA

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

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

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

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

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

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

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

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

Como evitar a perda de dados?

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

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

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

Backup físico, o primeiro passo.

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

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

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

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

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

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

Estratégia de backup.

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

Conclusões :

(atualizado em 17/05/2010)

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

Atualização:

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

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

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

Bom, o script a seguir cria um arquivo com os usuários, grupos (ok, o nome certo é ‘roles’), permissões em tabelas, privilégios de sistema, roles, quotas de tablespace e mais alguma coisa. Se você precisa atualizar bases entre versões diferentes (como do 9i para o 10g ou para o 11g), ou entre Sistemas Operacionais diferentes (se você tem o Oracle Enterprise dá para usar o conceito de tablespace transportável).

Enfim, todo DBA sabe utilizar as ferramentas de geração de Dump (exp ou expdp) e importação de Dump (imp, impdp). E quase todos costumam importar os dados por esquema e não tudo de uma vez (full=y).  E como sempre, antes de importar o esquema, o usuário deve existir da base de destino.

Chega de blá, blá, blá. Segue o script:

--
-- mov_user.sql
--
-- Exporta usuários roles e privilegios.
--
--
-- Criado por Fábio Telles Rodriguez
--
-- Última atualização: 05/05/2010
--
--
 
-- Ajusta parâmetros de visualização do SQL*Plus
SET DEFINE OFF
SET PAGESIZE 0
SET WRAP      ON
SET TRIMSPOOL ON
SET SERVEROUTPUT ON
SET VERIFY OFF
SET FEED OFF
SET HEADING OFF
SET LINESIZE  120
 
-- Gera arquivo em mov_user.sql
SPOOL mov_user_.sql
 
-- Verifica se está conectado com o usuário SYS
WHENEVER SQLERROR EXIT;
 
DECLARE
  v_user varchar(100);
BEGIN
  SELECT user INTO v_user FROM dual WHERE user = 'SYS';
EXCEPTION
  WHEN OTHERS THEN
    RAISE_APPLICATION_ERROR(-20000,
        'ERRO! Você deve estar conectado como SYS para rodar este script!!!');
END;
/
 
-- Cria profiles, e altera o DEFAULT
BEGIN
  FOR profile IN (SELECT DISTINCT profile FROM dba_profiles) LOOP
    IF profile.profile = 'DEFAULT' THEN
      dbms_output.put_line('ALTER PROFILE ' || profile.profile || ' LIMIT');    
    ELSE
      dbms_output.put_line('CREATE PROFILE ' || profile.profile || ' LIMIT');
    END IF;  
    FOR prof_limit IN (
      SELECT resource_name, LIMIT 
        FROM dba_profiles 
        WHERE 
          profile = profile.profile AND 
          LIMIT != 'DEFAULT') LOOP
      dbms_output.put_line('    ' || prof_limit.resource_name || ' ' || prof_limit.LIMIT);
    END LOOP;
    dbms_output.put_line(';');
    dbms_output.put_line('');
  END LOOP;
END;
/
 
 
--Cria usuários
SELECT
    'CREATE USER "' || username || '"'
    DECODE (password,
            'EXTERNAL',' IDENTIFIED EXTERNALLY',
            'GLOBAL',' IDENTIFIED GLOBALLY AS ''' || external_name,
            ' IDENTIFIED BY VALUES ''' || password || '''') || CHR(10) ||
    '    DEFAULT TABLESPACE ' || default_tablespace || CHR(10) ||
    '    TEMPORARY TABLESPACE ' || temporary_tablespace || CHR(10) ||
    '    PROFILE ' || profile || CHR(10) ||
    DECODE (account_status,
        'OPEN',                           '    ACCOUNT UNLOCK;',
        'LOCKED',                         '    ACCOUNT LOCK;',
        'LOCKED(TIMED)',                  '    ACCOUNT LOCK;',
        'EXPIRED & LOCKED',               '    ACCOUNT LOCK PASSWORD EXPIRE;',
        'EXPIRED & LOCKED(TIMED)',        '    ACCOUNT LOCK PASSWORD EXPIRE;',
        'EXPIRED(GRACE) & LOCKED',        '    ACCOUNT LOCK PASSWORD EXPIRE;',
        'EXPIRED(GRACE) & LOCKED(TIMED)', '    ACCOUNT LOCK PASSWORD EXPIRE;',
        'EXPIRED',                        '    ACCOUNT UNLOCK PASSWORD EXPIRE;',
        'EXPIRED(GRACE)',                 '    ACCOUNT UNLOCK PASSWORD EXPIRE;') mov_user
  FROM dba_users
  WHERE
    default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM','SYSAUX')
  ORDER BY default_tablespace, username
;
 
-- Concede quotas para usuários
SELECT
    'ALTER USER ' || LOWER(username) ||
    ' QUOTA UNLIMITED ON ' || LOWER(tablespace_name) || ';'
  FROM dba_ts_quotas;
 
-- Especifica planos de recursos para usuários
SELECT
    'EXEC DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING' || CHR(10) ||
    '(DBMS_RESOURCE_MANAGER.ORACLE_USER, ''' || LOWER(username) ||
    ''', ''' || LOWER (INITIAL_RSRC_CONSUMER_GROUP) || ''');'
  FROM dba_users
  WHERE
    default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM','SYSAUX') AND
    LOWER (INITIAL_RSRC_CONSUMER_GROUP) !='default_consumer_group'
  ORDER BY default_tablespace, username
;
 
-- Cria ROLEs
SELECT
    'CREATE ROLE "' || name || '" ' ||
    DECODE (password,
        NULL,'NOT IDENTIFIED;',
        'EXTERNAL',' IDENTIFIED EXTERNALLY;',
        'GLOBAL',' IDENTIFIED GLOBALLY',
        ' IDENTIFIED BY VALUES ''' || password || ''';')
  FROM sys.user$
  WHERE
    type# = 0 AND
    name NOT IN ('PUBLIC', '_NEXT_USER', 'AQ_ADMINISTRATOR_ROLE', 'AQ_USER_ROLE',
      'AUTHENTICATEDUSER', 'CONNECT', 'CTXAPP', 'DBA', 'DELETE_CATALOG_ROLE', 'EJBCLIENT',
      'EXECUTE_CATALOG_ROLE', 'EXP_FULL_DATABASE', 'GATHER_SYSTEM_STATISTICS',
      'GLOBAL_AQ_USER_ROLE', 'HS_ADMIN_ROLE', 'IMP_FULL_DATABASE', 'JAVADEBUGPRIV',
      'JAVAIDPRIV', 'JAVASYSPRIV', 'JAVAUSERPRIV', 'JAVA_ADMIN', 'JAVA_DEPLOY',
      'LOGSTDBY_ADMINISTRATOR', 'MGMT_USER', 'OEM_ADVISOR', 'OEM_MONITOR',
      'PLUSTRACE', 'RECOVERY_CATALOG_OWNER', 'RESOURCE',  'SCHEDULER_ADMIN',
      'SELECT_CATALOG_ROLE', 'SNMPAGENT','WM_ADMIN_ROLE', 'XDBADMIN', 'XDBWEBSERVICES')
;
 
 
-- Gera GRANTs em roles
SELECT
    'GRANT ' || granted_role || ' TO "' || grantee || '"' ||
        DECODE(admin_option,'YES','WITH ADMIN OPTION;',';')
  FROM dba_role_privs p, dba_users u
  WHERE
    u.username = p.grantee AND
    u.default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM','SYSAUX')
;
 
-- Altera roles que não são padrão
DECLARE
  v_non_default   NUMBER;
BEGIN
  SELECT COUNT(*) INTO v_non_default
        FROM dba_role_privs WHERE default_role = 'NO';
  IF v_non_default > 0 THEN
    FOR u IN (SELECT DISTINCT grantee
                FROM dba_role_privs
        WHERE default_role = 'NO'
        ORDER BY grantee)
    LOOP
      DBMS_OUTPUT.PUT('ALTER USER ' || LOWER(u.grantee) || ' DEFAULT ROLE ALL EXCEPT ');
      SELECT count(*) INTO v_non_default
        FROM dba_role_privs
        WHERE grantee = u.grantee AND default_role = 'NO';
      FOR r IN (SELECT rownum, granted_role
                  FROM dba_role_privs
                  WHERE grantee = u.grantee AND default_role = 'NO')
      LOOP
        DBMS_OUTPUT.PUT(LOWER(r.granted_role));
        IF r.rownum != v_non_default THEN
          DBMS_OUTPUT.PUT(',');
        END IF;
      END LOOP;
      DBMS_OUTPUT.PUT_LINE(';');
    END LOOP;
  END IF;
END;
/
 
-- Gera GRANTs em privilégios de sistema
SELECT
    'GRANT ' || privilege || ' TO "' || grantee || '"' ||
        DECODE(admin_option,'YES','WITH ADMIN OPTION;',';')
  FROM dba_sys_privs p, dba_users u
  WHERE
    u.username = p.grantee AND
    u.default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM','SYSAUX')
;
 
-- Gera GRANTs em objetos
SELECT
    'GRANT ' || privilege ||
    ' ON ' || DECODE(privilege,'READ','DIRECTORY ','WRITE','DIRECTORY ') || 
    '"' || owner || '"."' || table_name ||
    '" TO "' || grantee || '"' ||
    DECODE(grantable,'YES',' WITH GRANT OPTION',' ') ||
    DECODE(hierarchy,'YES', ' WITH HIERARCHY OPTION;',';') AS gr
  FROM dba_tab_privs p, dba_users u
  WHERE
    u.username = p.grantee AND
--    u.default_tablespace NOT IN ('EXAMPLE','DRSYS','CWMLITE','ODM','XDB','SYSTEM','SYSAUX')
u.USERNAME  = 'DBAMV'
;
 
-- Gera GRANTs em colunas
SELECT
    'GRANT ' || privilege || '("' || column_name || '")' ||
    ' ON "' || owner || '"."' || table_name ||
    '" TO "' || grantee || '"' ||
    DECODE(grantable,'YES',' WITH GRANT OPTION;',';')
  FROM dba_col_privs;
 
 
SPOOL OFF

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

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

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

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

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

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

YES, WE CAN!!!

IS DONE

IS JUST THE BEGINING…

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

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

Garanta já sua inscrição!!!

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

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

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

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

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

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

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

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

Vou contar um pouco dos bastidores do evento:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vejam a nota oficial de lançamento em pt_BR.

Preencha a pesquisa agora aqui.

Mini FAQ

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

[Show as slideshow]

[View with PicLens]

Agora resolvi brincar com as enquetes. Não sei se vai vingar. Depende mesmo do número de pessoas que vão votar. Se tiver um número razoável, prometo ir atualizando por aqui.

Segue a primeira, que não poderia ser muito diferente. Em breve, algumas mais polêmicas devem se seguir. Aguardo os votos do pessoal.

Aí as novidades continuam. O método de escolha foi muito debatido na comunidade. Haviam duas propostas em pauta:

• Votação direta pelos membros da comunidade (ou inscritos nas listas). A votação garante que o evento vá de encontro com os interesses dos participantes o que é fundamental para a satisfação dos participantes.
• O uso de uma banca avaliadora composta por 3 pessoas respeitadas da comunidade. Em 2007 foram os Srs. Diogo Biazus e Euler Taveira. Em 2008 foram os Srs. Leonardo César, Dickson Guedes e eu. Em 2008 se chegou ao consenso de que uma comissão com número ímpar seria interessante para não haver empates e que deveriamos alternar as pessoas envolvidas nesta banca. Para 2009 escolhemos os Srs. Luis Fernando Bueno, Leandro Dutra e Fernando Ike. A vantagem de usar uma comissão é a simplicidade e agilidade do processo e a capacidade de balancear temas e garantir a qualidade, uma vez que são pessoas que conhecem bastante de PostgreSQL no Brasil. Uma coisa interessante da comissão é a possibilidade de trazer temas novos, evitando que as mesmas palestras se repitam todos os anos.

Na dúvida ficamos com os dois. Haverá uma votação on-line entre os membros da lista PGBR-Geral. Esta votação irá apontar para as palestras mais populares e os temas mais solicitados e então uma comissão avaliadora composta de 3 pessoas fará uma seleção final.

Mas ainda temos cartas na manga: se houver um número muito grande de propostas, abriremos uma exposição de painéis (cartazes explicativos que são pendurados nos corredores do saguão com a presença de seus autores), como é comum se fazer em eventos acadêmicos. Desta forma, poderemos contemplar a participação de mais pessoas. Mas esperem, o melhor fica para o final! Vamos repetir o clima animado no final do evento de 2008: os Lightning Talks vão voltar! Na última semana antes do evento estaremos abrindo as incrições (que vão até o final do primeiro dia do evento) para as apresentações relâmpago, com duração máxima de 5 minutos cada.

Então senhores, se você já está trabalhando há algum tempo com PostgreSQL, envie sua proposta. Se você tem várias ideias, mande várias propostas. Escolha o formato mais adequado e mande para nós. Há inúmeros temas que você pode abordar. Este ano teremos mais espaço, 2 auditórios e uma sala VIP, então vale a pena compartilhar conosco um pouco da sua experiência. Você não precisa ser um gênio, basta apenas ter testado alguma coisa interessante e chegado a alguma conclusão no caminho. Muita gente acha que não tem nada de interessante para falar… eu digo que ao acompanhar a lista, tem um montão de gente respondendo e-mails que eu adoraria ver subir no palco e dividir um pouco mais do que sabe conosco. Vejo um zilhão de dúvidas que se repetem e dúvidas que mereciam um tutorial inteiro para explicar melhor como fazer.

Se você está realmente sem idéias, eu vou dar algumas (tem muuuuito mais, claro!) sugestões:

• Técnicas para carga de grande volume de dados e ETL;
• Desempenho, segurança e uso de Discos e Sistemas de Arquivos;
• Testes com novos sistemas de arquivos como EXT4, ZFS, quem sabe BTRFS…
• GUCs e dicas de configurações de parâmetros;
• Segurança de aplicações usando PostgreSQL: técnicas para autenticar usuários e evitar SQL Injection;
• Uso de Full Text Search;
• PostGIS;
• Uso de PostgreSQL em aplicações de suporte a decisão (BI);
• Técnicas de Backup físico e lógico, ou melhor: técnicas de restauração!
• Como encontrar SQLs lentos e reescrevê-los;
• Como monitorar o uso de recursos com as novas funções, visões, opções de log e ferramentas do PostgreSQL;
• Como criar índices realmente úteis e remover índices inúteis;
• Utilizando técnicas de replicação multimaster assíncronas;
• Comparação de diferentes técnicas de replicação: onde eu uso o que?
• Tudo que você queria saber sobre internacionalização e localização e tinha vergonha de perguntar;
• Refatoração de banco de dados sem perder a cabeça ou o emprego!
  
• Migração para PostgreSQL (a partir de Oracle, MySQL, DB2, SQL Server, o que for);
• Versionamento de banco de dados: gerenciando a mudança com responsabilidade!
• Técnicas de auditoria e monitoramento de usuários;
• Desempenho com responsabilidade: descubra o ponto G do PG…
• Casos de sucesso, sim, queremos saber quem está usando o PostgreSQL por aí!
• Casos de insucesso e dicas para evitar entrar em grandes roubadas. Tambem poderia ser: “Eu não disse que esse negócio de banco de dados livre não prestava…” (fala sério, alguém tem que fazer esta um dia)
• Conhecendo um pouco do código fonte do PostgreSQL e funções SPI;
• Ferramentas para modelagem e documentação de DDL para PostgreSQL (tem alguém me devendo essa)
• 10 Coisas que ainda não funcionam bem no PostgreSQL,mas que estão em vias de se resolver (ou não) e como contornar estes problemas;
• Os desafios em ambientes transacionais pesados e com grande volumes de dados;
• PostgreSQL em aplicações científicas. Em 2008 aprovamos uma palestra de banco de dados para dados biológicos que cancelou na última hora, uma pena.
• Modelagem utilizando tipos, vetores, domínios, funções de agragação e outros bichos;
• Consultas recursivas com Common Table Expressions;
• Cálculos complexos com Windowing Functions;
• Stand By rápido e rasteiro.
• A caixa de ferramentas do DBA: consultas e formas de se trabalhar para tornar a vida do DBA mais simples e produtiva;
• Os 12 pecados do desenvolvedor que começa a utilizar o PostgreSQL pela primeira vez;
• PostgreSQL para adminstradores de sistema: montando um servidor seguro, rápido e fácil de administrar;

Bom, estas são apenas algumas sugestões, existem várias outras que não pensei agora. Sugestões? De qualquer forma, estamos muito querendo ver novas caras do PGCon Brasil este ano, agora é só escrever e mandar.

Senhores, eu sei que muitos que estão utilizando o PostgreSQL são novatos, estudantes e entusiastas. Sei que não é de bom tom tratar estas pessoas de forma seca e dura, pois são pessoas que futuramente vão apoiar a comunidade e utilizar o PostgreSQL em cenários mais sérios e coisa e tal. Mas hoje me deu os 5 minutos de fúria.

Vamos escrever melhor gente? Eu seu que não sou uma pessoa que contribui ativamente aqui na lista. Não respondo muita coisa. Mas venhamos e convenhamos, o nível das perguntas (e muitas vezes das
respostas e comentários também) desanima qualquer pessoa letrada que se esforça para se comunicar adequadamente.

Antes de disparar com a metralhadora para todos os lados, eu quero
dizer: entendo que os erros de ortografia e de digitação fazem parte da nossa vida. Eu mesmo cometo erros terríveis no meu blog e nos e-mails. A língua portuguesa é chata mesmo. Quando estou ajudando o
meu filho de 6 anos a fazer a lição de casa eu percebo como as regras
são confusas: G e J, c, ç, ss, z ou c e q, m ou n, r ou rr, e por aí vai. Mas inventaram os corretores ortográficos e eles estão aí para nos livrar da peste, da fome e da danação.

Proponho lançar uma campanha de 5 pontos aqui (a exemplo de zilhões de campanhas semelhantes em trilhões de listas por aí):

1. O nome do banco de dados livre mais avançado do mundo é ‘PostgreSQL’ ou simplesmente ‘postgres’. Sim, você pode escrever sem acentos e sem letras maiúsculas. Pode até abreviar para PG numa lista mais informal como a nossa. Mas não use nenhuma outra forma, ok? É como mandar um cartão de dia dos namorados com o nome da garota escrito errado. Na dúvida repita em voz alta para não errar mais:  postgres, postgres, postgres. Dá um bom mantra, é relaxante, tente novamente: postgres, postgres, postgres…
2. Guarde o miguxes para os seus amigos do tempo do ensino fundamental. Se você escreve ou até fala assim, guarde este segredo terrível para você e aqueles que praticam isso. Não abrevie palavras como se estivesse num chat e principalmente não utilize expressões escritas propositalmente erradas. Conheço muita gente da velha guarda que sente dificuldade em ler menssagens assim. O resultado? Não respondem. Eu não respondo mais e sei de gente muito boa que também não responde.
3. Descrevam o problema! Gente, nós não conhecemos o seu ambiente, não vemos os erros que estão acontecendo na sua tela e não sabemos o que você fez. Nós não vamos adivinhar se você não contar. Dizer simplesmente: “estou com um problema no postgres e nada funciona aqui” pode conter o nome do banco de dados escrito corretamente, pode até fazer um bom uso da língua portuguesa, mas não nos diz nada. Se você se sente apenas frustrado e quer desabafar, recomendo uma boa cerveja, ver desenhos animados na TV ou até mesmo conversar com alguém no IRC. Mas dizer que não funciona e não citar o contexto não vai lhe ajudar.
4. Se o seu chefe/professor mandou você fazer um trabalho com PostgreSQL para ontem e você precisa de alguém que faça uma parte do trabalho para você, a lista será um ótimo lugar para você encontrar um profissional que lhe cobrará um preço justo pelos seus trabalhos. Não, não vamos fazer o trabalho de graça por você. Por favor não peça.
5. Uma boa pergunta é metade do caminho para encontrar a resposta. Se você leu a documentação, pesquisou na Internet, testou e não conseguiu fazer o que você queria, você deve ter uma dúvida. Gaste um tempo na elaboração da pergunta. Pense um pouco.
   • Se você leu um monte de documentações (principalmente a oficial) e não entendeu nada, seu problema é de compreensão de texto. Estude inglês ou português e principalmente leia mais. Um livro por mês seria uma boa meta para você. Mas pelo menos 2 bons livros por ano é o mínimo que um cidadão alfabetizado deveria se habituar a ler. Revistas em quadrinhos são muito legais (eu adoro) mas não contam aqui.
   • Se você testou vários how-tos e receitas de bolo prontas e nada funcionou, vá ler a documentação oficial antes de sair perguntando. Um bom tutorial sempre tem referências. Leia as referências. Ocorre que um tutorial se refere a uma situação específica. Pode não ser o seu caso. Você pode precisar de adaptações. Para quem tem uma boa base de conhecimento (por exemplo, para quem leu a tal da documentação…) o tutorial é muito interessante. Para quem cai de paraquedas, costuma ser um desastre.
   • Se você pesquisou um bocado e leu um bocado e conseguiu evoluir até um certo ponto e depois travou. Você deve ter uma genuína dúvida. Mande um e-mail para nós. Escreva bem, descreva o seu processo e nós lhe ajudaremos. Mas antes de enviar o e-mail, lembre-se que você gastou um tempão para chegar onde está. Se você souber exatamente o que você não está entendendo e souber materializar sua dúvida em forma de um texto, seu problema estará muito próximo da solução. É muito comum se passarem 5 ou 10 e-mails numa lista até que as pessoas entendam precisamente o que você quer saber. Pergunte bem e você terá uma boa resposta. Mais que isso, você será respeitado pelo seu esforço em pesquisar antes e também pela sua capacidade de elaboração de questões relevantes.

Há alguns anos atrás, quando o PostgreSQL começou a ganhar mais visibilidade no Brasil (no lançamento do PostgreSQL 8.0 para ser mais exato), houve uma grande tensão na lista por causa da invasão dos miguxos, analfabetos digitais e até folgados mesmo que caiam diariamente de paraquedas na lista. Eu não acho que espantar esta turma nos ajudará em alguma coisa. Mas se as pessoas vem à lista para aprender alguma coisa, espero aqui estar dando a minha contribuição pedagógica. Sim, eu sou um brasileiro e não desisto nunca!

Bom, apesar de não ter contribuído com a organização, eu acabei aceitando o convite feito no próprio PGCon 2008 de ir para Rondônia. Então eu e o Sr. Euler Taveira fomos de avião para lá. O Sr. Euler, diga-se de passagem virou arroz de festa e está indo a quase todos os PGDays. Só não vai para SC por um motivo simples: vai estar no canadá no PGCon internacional nesta data.

Cada evento traz consigo características próprias: em DF, o Sr. Jair Silva mostrou um pouco do mega ambiente corporativo da Caixa Econômica Federal utilizando PostgreSQl e houve também um longo tutorial sobre replicação com o Sr. Dickson Guedes. Em SP, foram 6 palestras com a grade mais diversificada até o momento. Em RO, foi o maior público até agora. Não tenho os números ainda, mas se juntarmos os dois dias de evento em Porto Velho e Ji Paraná certamente contaremos com algo na casa das 300 pessoas. No RS temos uma renovação nos palestrantes, tendo 3 pessoas que não palestraram em nenhum PGCon Brasil na grade. Por fim, teremos o PGDay SC que ainda não tem a grade fechada, mas é o primeiro a estrear um sistemas de inscrições integrado no próprio site da comunidade.

Enfim, muita coisa boa rolando. O povo do FISL 10 já avisou que quase todas as propostas de palestras sobre banco de dados são para PostgreSQL. Não é muita novidade para nós… ano passado também foi assim. De qualquer forma, eu diria que a comunidade tem realmente se destacado nos últimos tempos.

Meus parabéns a todos os organizadores!

Não achou nenhum link? Tudo o que você quer saber sobre eventos da comunidade brasileira de PostgreSQL está aqui.