• 1ª O DBA deve educar o usuário. O DBA sempre diz o jeito certo de fazer as coisas.
• 2ª Meta medo no cara. Coisas ruins vão acontecer se ele não ouvir o DBA deles.
• 3ª Crie descontentamento. Se eles se recusarem a ouvir as 2 primeiras regras ferra eles, deixa o banco cair.

OBS: em alguns casos, se o cara for muito chato, é OK pular direto para a 3ª regra.

Outra pérola no mesmo programa:

• Qual DR é pior de madrugada?

“Discutir a relação” com a patrôa ou ”Disaster Recovery” ?

O #PGBR2011 foi um marco para mim. Morreu aquele jeito moleque de juntar a turma e ficou claro que a “pegada” da comunidade mudou. A turminha que se conheceu há 10 anos atrás nos FISLs da vida cresceu e tem desafios para lá de cabeludos na mão. Eu mesmo jamais imaginaria que estaria trabalhando com um dos cases mais importantes de Postgres do Brasil há 10 anos atrás. Acho que eu nem imaginava que daria para fazer o que a gente faz com o Postgres hoje naquele tempo. Mas a gente apostou, eu consegui abandonar a minha vida de DBA Oracle e estou feliz da vida me matando de trabalhar com Postgres quase em tempo integral (aka 24/7).

O evento foi num hotel. Não foi numa universidade, não foi num lugar barato. E para a nossa surpresa: fomos nós mesmos que pagamos boa parte da conta: Eu, o Euler, Fabrízio, o Charly, o Coutinho, etc. Nós patrocinamos o evento. Nós pudemos tirar $$ do bolso para fazer o evento acontecer. Para quem não sabe, eu e o Euler Taveira, somos Sócios da Timbira, que está já há uns 2 anos na estrada. A gente nunca teve muita pressa de crescer. Nem no nosso site a gente investiu muito. Na verdade a gente está tendo de expandir para dar conta da demanda. Não, ninguém está ganhando muito dinheiro. Talvez empresas maiores como a Dextra e a 4Linux estejam melhor. Certamente a VMware vai bem. Mas estamos vivendo disso. No caso da Timbira, vivendo só disso. E temos encontrado bons parceiros no caminho. Direta ou indiretamente, estivemos presentes em várias palestras comigo, com o Euler Taveira, com o Dickson Guedes, com o Roberto Mello, com o Fabrízio Mello e tem mais um que logo logo deve estar finalmente assumindo seu lugar junto a Timbira. E tem mais, eu, o Euler e o Guedes (os 3 dos 4 fundadores da Timbira) ganharam prêmios pela nossa atuação na comunidade durante o evento. Não, nenhum de nós fez parte da comissão que elegeu os premiados. Acho que dificilmente vamos encontrar alguém que respira mais Postgres no Brasil do que o Euler Taveira. Não foi por acaso que ele foi nomeado para 4 das 5 categorias do “Prêmio PGBR2011″. É realmente uma honra ter estes caras como colegas de trabalho. Mas eu também estou finalmente dando meus pulinhos. Hoje eu teria tanta coisa para escrever aqui no blog que eu nem sei por onde começar. Preciso de um pouco de tempo para voltar a escrever para valer.

Não é pouca coisa né? Mas este ano foi a primeira vez que mandamos fazer um folder da Timbira. A gente passa tanto tempo trabalhando com Postgres que não tivemos tempo de “aparelhar” a nossa empresa. Sim, temos que melhorar isso. Bom, mas tirando a propaganda toda, (que é a primeira vez que eu cito aqui no blog), a questão é que agora a nossa pegada mudou. Não somos mais moleques. Ninguém mais é. Mesmo o Diogo Biazus com o seu novo visual Punk, sabe que a fase da molecagem passou. Ele também é empresário. E são empresários a maioria dos palestrantes que estiveram no evento. Nem tudo são flores. Eu descobri por exemplo que o Carlos Smanioto, um dos ícones que começou a publicar os primeiros artigos sobre Postgres na SQL Magazine estava com dificuldades alguns meses antes do PGBR2011. Outros dois grandes colegas excepcionais ficaram desempregado recentemente. Eu também tenho minhas dívidas para pagar…. Não estamos vivendo de brisa. Estamos trabalhando muito, errando muito e aprendendo muito. No entanto, me arrisco a dizer que estamos felizes. Não é fácil explicar isso para nossas famílias. Mas é bem verdade. Eu posso dizer que trabalho com o que eu gosto e isso não é para qualquer um.

Mas voltando a provocação do Sr. Fernando Ike. Eu tenho sempre medo do que esse cara diz, pois ele tem a mania de acertar – ele também tem a mania de ser sorteado para alguma coisa em todo evento que vai. Já vi ele ser sorteado 2 vezes num único evento. E essa história de banco de dados virar comodity, já está escrito nas estrelas faz um tempo. Quando você vira especialista numa coisa, não quer que ela deixe de existir, pois você se dedicou por anos a fio para adquirir um bom domínio naquilo. Os bancos da dados relacionais não vão deixar de existir. Mas quem acha que eles vão continuar com o seu “reinado”, como o centro do universo que muito DBA acha que é… já caiu do cavalo. Isso está ruindo mesmo. Claro, isso que não muda tão rápido assim. Ninguém acha que as transações bancárias vão começar a rodar em bases NoSQL. Mas é inútil negar que tem muita informação que não precisa de um banco de dados transacional 100% ACID para cuidar. E os novos desafios estão aí para quem quiser enxergar ou não.

Enquanto a adoção do Postgres cresce no mundo todo e notoriamente no Brasil, um novo movimento surge quebrando paradigmas e a gente vai ter de aprender a conviver com isso. A palestra da VMware estava lá para quem quisesse enxergar. A revolução acontecendo bem na nossa cara. Eu sei que o Ike tem uma visão clara disso. Quando você se afasta e olha mais de longe, consegue ver o mundo girar. Esse negócio de nuvem… tem muita balela e gente querendo vender coisa velha com nome novo. Mas quando eu olho o número de clientes nossos que estão colocando seus software como SaaS, é notavel que as coisas estão mudando. E olha só, a Locaweb estava lá no evento…

É pessoal, eu não sei o próximo PGBR vai rolar ou como ele será. Sei que é bem possível que ele ocorra. Não sei se eu terei tempo para me dedicar a ele como me dediquei em 2011. Nem se as minhas prioridades estarão neste rumo até lá. Mas o mundo está girando… independente de nós sentirmos isso ou não. Os polos magnéticos vão se inverter, uma nova era do gelo vai vir e um novo super continente vai se formar. Precisamos mesmo olhar para fora da caixa. Mas enquanto isso, posso dizer que o Postgres tem me surpreendido muito. Tem se mostrado um grande parceiro, e trabalhar com ele tem sido divertido.

Bom, agora tem um monte de coisas para fazer aqui, até a próxima cervejada pessoal!

OBS: Antes que alguém pergunte… o nome Timbira foi escolhido pelo Euler que tem um blog com esse nome bem antes da “Empresa Timbira nascer”. Ele ajudou muito na tradução da documentação e internacionalização do Postgres. Como ele é Goiano e tem lá uma paixão louca pelo Brasil, eu acho que escolher um nome indigena para a nossa “Empresa Brasileira de Postgres” faz até muito sentido. Claro, é bem engraçado quando as pessoas pedem para repetir o nome da empresa umas 2 ou 3 vezes até entender. Todo mundo espera um buzzword em inglês. Mas depois de um tempo, eu achei o nome tão bacana quanto continuar escrevendo um blog em pt_BR e fazer parte do nosso planeta tupiniquim, . De toda forma, quanto mais masterfucking é o cliente, mais legal é ver a Timbira entrando lá de verde e amarelo…

Fazer um evento num hotel tornou tudo muito mais caro. Foram mais de R$ 16K com aluguel das salas, projetores, sonorização, sala VIP, cofee break e claro, a cervejada. As despesas com hospedagem de palestrantes também foram altas, gastamos uns R$ 8K com isso. Mas o retorno foi incrível. O preço da diária não foi tão alto para quem veio de fora (negociamos isso em abril) e estavam todos lá. Sair para dar um passeio em São Paulo com a turma, dormir até mais tarde ou mesmo ficar de bobeira no saguão com os palestrantes internacionais tomando uma caipirinha. Isso tudo ficou mais fácil. Foi um enorme avanço em relação a 2009. Em 2009 só a organização pode desfrutar do excelente hotel da Unicamp. Sim, o hotel da Unicamp era muito mais agradável. A Unicamp em si é muito mais agradável. O mar de prédios de São Paulo não é algo tão bacana assim. Mesmo tirando a nossa tradicional “foto do Bozo” na piscina, a sensação de estar espremido entre prédios é meio bizarra. Mas o evento se tornou mais acessível para todos. No final, quem mais ganhou foi quem pagou para ir ao evento e pode estar mais próximo dos palestrantes e demais congressistas.

Trazer tanta gente de fora, não foi moleza. O Flávio perdeu a conta de quantas vezes foi até o aeroporto. Além de convidar os Srs. Alvaro Herrera, Bruce Momjian, Dave Page, Greg Smith e Koichi Suzuki, o Sr. Jaime Casanova passou pela chamada de trabalhos e houveram pessoas que saíram de outros países só para vir ao PGBR2011, como o Sr. Joe Abbate que também aproveitou para passear pelo Brasil, claro. Bom, o fato é que o evento novamente chamou a atenção de pessoas de outros países e isso foi algo muito interessante de ver. Tenho de reconhecer que assistir uma palestra em espanhol parece mais difícil que assistir uma palestra em inglês. Acho que a nossa overdose diária de documentação em inglês deve ter algo haver com isso. Vamos ter de repensar nisso no próximo evento.

Houveram alguns problemas menores como erros na impressão dos certificados e o atraso no recebimento dos chaveiros e adesivos. O elefante de pelúcia não ficou uma maravilha, mas se esgotou nos primeiros minutos do evento. O chaveiro ficou muito bacana também. No final acho que ficamos bem. A comida do hotel era realmente muito boa. O almoço não tinha muita variedade mas o peixe deles estava ótimo. A sala VIP era VIP mesmo. Dois bons sofás onde era perfeitamente possível tirar um bom cochilo, uma mesa para quem precisasse terminar uma palestra, fazer uma reunião de negócios ou atender um cliente remoto (sim, isto SEMPRE acontece).

Achei a estrutura vertical do hotel um pouco incômoda. Você tinha que ficar subindo e descendo escadas dos auditórios para o salão de exposições. Os patrocinadores podem não ter gostado muito disso também. Mas acho que não foi algo terrível. Por outro lado, o salão de exposições era bem espaçoso, e conseguiu comportar todos no intervalo para o café sem problemas. E olha que era muuuita gente.

As inscrições foram muito mais tranquilas que em 2009. Mais antecedência, o apoio com atendimento telefônico e um sistema de inscrições mais maduro ajudaram muito. Não que não houvessem problemas. O fato da prefeitura de Porto Alegre não emitir nota fiscal eletrônica, junto com a greve dos correios foi um tiro no pé. Mas o Euler e a Débora estão de parabéns pelo trabalho nesta área.

Então vejamos alguns números:

• Quase R$ 65K de custo no evento, sendo R$ 23K recebido pelas inscrições e o restante de 13 patrocinadores nacionais e internacionais. Este também foi o primeiro ano que não precisamos de ajuda da SPI.
• Mais de 240 pessoas inscritas no evento;
• Mais de 50 propostas de palestras na chamada de trabalhos e um total de 32 palestrantes presentes, fora os Lightning Talks.
• 400 ecobags, 200 chaveiros, 100 squeezes, 100 camisetas, 60 elefantes de pelúcia, 5 banners, 1000 cartazes, 1000 adesivos pequenos e 100 adesivos normais.
• 200 litros de chopp e inúmeras histórias para contar.

Foi muito bom ver todos vocês novamente, eu realmente estava com saudades do pessoal. Até a próxima gente.

• Saiu a lista dos palestrantes do PGBR2011. A grade ainda estamos montando.
• Sim, uma palestra minha foi aprovada (não, eu não faço parte da banca avaliadora), vou falar sobre processos de melhoria de desempenho em ambiente OLTP de alta concorrência. A palestra se chama: “Fazendo uma manada passar debaixo da porta”
• O link onde o site do PGBR está hospedado está com problemas sérios no link. Esperamos que isto esteja normalizado em breve.
• Foi publicada a minha participação no #DatabaseCast sobre PostgreSQL, no Imasters.
• Estamos mandando bala no material promocional. Tirando a sacola, tudo será vendido praticamente a preço de custo. Até agora serão:
•  400 ecobags para o material do evento;
• 100 squeezes em alumínio;
• 100 elefantes de pelúcia;
• 100 camisetas pólo;
• 200 chaveiros;
• 1000 adesivos;
• Um mês antes do evento ocorrer, temos 120 inscritos. Sim, brasileiro deixa tudo para a última hora… então devemos ter um número bem superior até lá.
• Teremos um prêmio para as pessoas que mais se destacaram nos últimos tempos. Estamos organizando isso ainda, mas será uma forma de valorizar aqueles que tem contribuído para o fortalecimento da comunidade brasileira.

O chopp está garantido no final do evento!!!

(ok, vai ter refrigerante também… mas não consegui achar o Guaraná Jesus por aqui)

Pegue uma grande fábrica de software, tipo CMMI 5. Convoque todos os desenvolvedores para uma longa e tediosa reunião, sem direito a comida. Lá pelas tantas, libere uma generosa porção de space cake para todo mundo e veja o que acontece. Vai que a empresa começa a ter um surto criativo….

Na dúvida, é melhor tirar um backup de algumas coisas e cortar o acesso aos servidores de produção por um tempo.

Este ano tudo será diferente…. sim já é. Uma das maiores dificuldades do PGCon Brasil, agora rebatizado como PGBR, é a parte das inscrições. É o tipo de coisa difícil de fazer de forma voluntária. Nas edições anteriores o Euler Taveira e o Diogo Biazus se mataram para fazer as inscrições acontecerem. Bom, a gente continua se matando, mas desta vez temos uma forcinha. Temos algo revolucionário: um número de telefone!!! Ou seja, alguém poderá lhe ouvir, tirar suas dúvidas, falar como nós somos bacanas, ouvir reclamações e passar receitas de bolo pelo telefone. Não, a pessoa que irá atender o telefone não vai lhe ensinar a deixar o seu banco de dados mais rápido…. se a gente faz isso ninguém vai no evento,

Mas não é só isso, o Euler melhorou bastante a 3º versão do sistema de inscrições. As notas fiscais continuarão sendo um problema chato, pois a prefeitura de Porto Alegre – RS ainda não emite nota fiscal eletrônica. Ou seja, ainda vamos ter que continuar mandando pelo correio. Se você não precisa de nota fiscal, pegue o seu boleto, pague, autentique e use-o como comprovante. Dá um trabalhão despachar tudo pelo correio.

Se você pertence a um órgão público, se adiante por favor. Todo mundo sabe o mega trampo que é fazer o processo de empenho. Estamos com todos os documentos em ordem, a ASL (o PostgreSQL-BR é associado a ASL, que é quem nos dá respaldo jurídico e contábil), e já está cadastrada no SICAF. Facilite a sua vida e consulte o SICAF. Sim, o preço da inscrição para governo é mais caro. Também nos custa muito receber o dinheiro da inscrição de um órgão público. E o dinheiro só pode ser utilizado para custear o evento do próximo ano, uma vez que governo só paga depois do evento… e os nossos fornecedores não trabalham assim.

A grande novidade na minha opinião é a inscrição VIP. Todo mundo que se inscreve tem acesso às palestras nos 2 dias, coffe-break e a cervejada que deverá rolar no encerramento. Mas quem puder pagar um pouco mais, já pode incluir o custo do almoço no hotel. As vagas são limitadas, pois o restaurante do hotel não vai comportar todos. Mas para quem optar por isso, vai poder almoçar junto com os palestrantes, patrocinadores e a organização do evento. As vagas são limitadas a 80 pessoas, então corram, pois a maioria dos inscritos até agora optou mesmo pela inscrição VIP.

Bom, por enquanto é só, façam já sua inscrição e o chopp será por nossa conta. Em tempo: há também uma promoção para os 20 primeiros inscritos confirmados no evento. Eles ganharão um elefante de pelúcia do PGBR. Mas acredito que quando você estiver lendo isso, a promoção já tenha acabado. A não ser que o 20 primeiros demorem muito para confirmar (a.k.a. pagar) suas inscrições.

Os palestrantes, a programação e o local estão todos publicados no site do evento. Infelizmente não vou poder estar lá, mas já vi que a grade de palestrantes é excelente e será um evento bem bacana, incluindo um Dojo PL/pgSQL e os já conhecidos Lightning Talks.

Gostaria aqui de parabenizar os palestrantes Dickson Guedes, Diego Rossi, Diogo Biazus, Eduardo Wolak e Fabiano Machado Dias por palestrarem no evento e em especial para o Fabrízio de Royes Mello que é a pessoa que está liderando a organização do evento.

Não esqueçam de mandarem as fotos, publicarem as palestas, ok?

A chamada ficará aberta até o dia 09/09/2011 então não bobeie e mande logo as suas propostas. Este ano serão 4 modalidades diferentes (fora os Lightning Talks): Palestras normais de 50 minutos, tutoriais de 2 horas, hacker talks que podem der de 30 minutos até 2 horas e os painéis acadêmicos que serão expostos no saguão do evento. Tudo explicado no site do evento. Você pode mandar até 5 propostas diferentes para a banca avaliadora (da qual eu não faço parte) escolher.

Eu já estou preparando as minhas propostas, mas segue algumas que eu gostaria de ver lá. Eu sei que tem muita gente que já usa PostgreSQL há um tempão e acha que não teria nada de interessante para falar. Não se intimide, tenho certeza que se você usa o PostgreSQL há mais de um ano, deve se sentir à vontade para falar algum assunto como:

• Postgressssss, lendas urbanas sobre PostgreSQL e um apanhado da sua evolução nas últimas versões;

• Casos de sucesso de quem não tem vergonha de revelar que usa o PostgreSQL em negócios críticos;

• Porquê o PostgreSQL é cada vez mais amante predileta dos DBAs experientes;

• “Meu PostgreSQL não Conecta” e outras coisas que alguém tem de escrever para a gente não repetir novamente na lista…

• Ops, minha base já tem mais de 1TB… ;

• BI, Data Mining, OLAP, PL/R e outros bichos;

• Full Text Search, particularmente como raios se montam Ranks e dicionários personalizados;

• Funções de agregação personalizadas, operadores personalizados, tipos de dados personalizados e o que mais você tiver coragem de inventar;

• Bancos de dados em pesquisas científicas, como em biologia, física e outras ciências ocultas;

• Haks, muitos hacks! Queremos hacks em C, em Perl, Python, SPI, PL/pgSQL etc. Queremos nerds genuínos!!!

• Vou te apresentar a uma tal de libpq…

• Tuning em bases OLTP  com fucking hight concorrência;

• ETL (Extract Transform Load) em ambientes alucinógenos;

• pgbench e outras técnicas para emular a carga da aplicação em ambiente de homologação ou “hum…. então dá para fazer isso antes de sentar a aplicação no cliente?”

• Versionamento de DDL e como controlar do demônio da tasmânia das alterações de estrutura em desenvolvimento e produção sem ir parar no hospital;

• Segurem os trolls, vamos falar sobre sistemas de arquivos, tablespaces e discos de novo….

• Como fazer poesia com SQL e parar de fazer caquinha com PL/você_não_precisa_usar_isto_aqui.

• Técnicas (ok, se você gosta de buzzwords, pode chamar de “design patterns”) de otimização de processos e ajuste de SQL;

• “Rodei o EXPLAIN, e agora?”;

• Magia negra com Window Function;

• CTE, recursividade e como não destruir a memória do seu servidor;

• Localização, codificação de caracteres e coisas que infelizmente você tem de aprender se não quiser sofrer por toda a eternamente com isso;

• Segurança para preguiçosos (ou seja, para todo mundo);

• Técnicas de monitoramento, administração que funcionam e fazem sentido para seres mortais;

• Armadilhas no zoológico das replicações;

• Muito além das configurações do postgresql.conf: personalizando bases, roles , tabelas, tablespaces e até sessões para um ajuste perfeito;

• Eu sei, eu sei…. ACID, blá, blá, blá, Teoria Relacional, etc e tal, mas o C. J. Date diz que bi, bi, bi, bó, bó, bó…. mas eu quero muito ver “Técnicas de NoSQL integradas com PosgreSQL”;

• Backup e o “complexo de Chuck Norris”. (Quem respondeu a pesquisa sobre uso de PostgreSQL sabe do que eu estou falando);

• Técnicas de recuperação de desastres e como é chato ouvir “mas eu já faço assim há 5 anos e nunca deu nenhum problema…”;

• Não entendeu? Vou falar de novo: RECOVER, RECOVER, RECOVER!

• Quer dizer então que para ter um banco de dados é preciso ter um DBA na equipe ou aprender como fazer o trabalho de um?

OBS: Quem sabe este ano o indefectível Osvaldo Kussama não manda uma proposta?

OBS2: Se tiver alguma outra sugestão de palestra que você gostaria de ver no PGBR201, não deixe de deixar um comentário aqui! Vai que alguém gosta da ideia e você acaba tendo uma aula sobre aquele tema que vem lhe assombrando há tempos…

Clonar uma base guardada em file system é simples. Você copia os datafiles, gera um controlfile, edita ele, faz um PITR e pronto. Mas com ASM você não pode fazer isso. Você vai ter de utilizar o nosso amigo DUPLICATE.

Bom eu queria escrever algo detalhado, explicando cada passo, mas a preguiça me impediu. Então vamos apenas mostrar o cenário do exemplo e mandar bala logo:

• Oracle RAC 10.2.0.5 com 2 nós.
• A base a ser clonada é a ‘producao’ com as instâncias ‘producao1′ e ‘producao2′
• A base que vai ser atualizada/criada com os dados da’producao’ é a base’teste’ cin as instâncias ‘teste1′ e ‘teste2′.
• As duas bases tem suas instâncias nos dois servidores, ora1 e ora2 utilizando um SO UNIX like.
• A base ‘produção’ está utilizando o diskgroup ASMGRP01 e ASMGRP02.
• A base ‘teste’ utiliza apenas o diskgroup ASMGRP03
• Estou supondo que a base ‘teste’ já existe, e vai ser atualizada. Se a base não existir, o processo muda. Você não precisa apagar a base antes, mas precisa criar o init e os diretórios nos nós. Não vou abordar estes detalhes aqui.

Preparação

Passo1 - Verificar em quais diskgroups os arquivos da base teste estão

export ORACLE_SID=teste
sqlplus "/ as sysdba"
SELECT name FROM v$datafile;
SELECT * FROM v$logfile;
SELECT VALUE FROM v$parameter
  WHERE name = 'control_files';
EXIT

Passo2 - baixar a base no RAC

srvctl stop database -d teste

Passo3 – Apagar a base no ASM

Tome cuidado aqui. Vamos excluir os arquivos dos  diskgroups observados no passo 1.

export ORACLE_SID=+ASM
asmcmd
cd asmgrp03
rm -r teste
exit

Passo 4 – Editar init

Aqui não estou utilizando SPFILE, pois o 10g tem um bug que ocorre com o SPFILE durante o duplicate no 10g)

cd $ORACLE_HOME/dbs
vi initteste.ora

• Alterar os seguintes parâmetros :

*.control_files                 = '+ASMGRP03'
*.cluster_database              = FALSE

• Verifique o nome do parâmetro UNDO_TABLESPACE. O nome da tablespace deve ser idêntico ao UNDO da produção. No caso deste duplicate, tive de fazer um ajuste, pois o parâmetro do UNDO estava errado no init.
• Configure os parâmetros para alterar o diretório de destino. Neste caso, vamos mandar os datafiles e REDO dos diskgroups ASMGRP01 e ASMGRP02 todos para ASMGRP03:

db_file_name_convert   =
    ('+ASMGRP01/producao','+ASMGRP03/teste',
     '+ASMGRP02/producao','+ASMGRP03/teste',
     '+ASMGRP03/producao','+ASMGRP03/teste')
log_file_name_convert  =
    ('+ASMGRP01/producao','+ASMGRP03/teste',
     '+ASMGRP02/producao','+ASMGRP03/teste',
     '+ASMGRP03/producao','+ASMGRP03/teste')

• Configure o parâmetro para evitar um bug durante o RESETLOGS do DUPLICATE:

_no_recovery_through_resetlogs=TRUE

Passo 5 – Fazer o backup em disco da base de produção

Se já houver um backup recente, pode pular esta etapa. É fundamental que no backup tenha ocorrido um

SQL ‘ALTER SYSTEM archive LOG CURRENT’;

No caso abaixo o

backup database plus archivelog

faz isso implicitamente. Se resolver fazer o backup de outra forma, sembre-se disso.

export ORACLE_SID=producao
rman target / <<EOF
backup database plus archivelog;
exit
EOF

Enfim o DUPLICATE

Passo 6 - Realizar o DUPLICATE com o nohup

É importante rodar isto com o nohup para evitar surpresas. Na verdade no próprio backup também é importante. Então eu crio o script:

export ORACLE_SID=teste
rman TARGET sys/sua_senha@producao NOCATALOG AUXILIARY sys/sua_senha <<EOF
RUN
{
    ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
    DUPLICATE TARGET DATABASE TO teste;
    RELEASE AUXILIARY CHANNEL aux1;
}
EXIT
EOF

e rodo ele com o comando:

nohup atualizaTeste.sh

Verifique o log do nohup.out e veja se está ok.

tail -f nohup.out

Passo 7 –  Verificar o controlfile gerado:

export ORACLE_SID=teste
sqlplus "/ as sysdba" <<EOF
SELECT value
  FROM v$parameter
  WHERE name = 'control_files';
exit
EOF

Passo 8 – Baixar a base

export ORACLE_SID=teste
sqlplus "/ as sysdba" <<EOF
shutdown immediate
exit
EOF

Passo 9 – Editar novamente o init

Colocar o parâmetro ‘control_files’ com o valor encontrado no passo 7.
Colocar o parâmetro ‘cluster_database’ com o valor TRUE.
Copiar o init editado para o nó 2:

scp initteste01.ora ora2:$ORACLE_HOME/dbs/initteste2.ora

Passo 10 – Subir a base no modo NOARCHIVE

export ORACLE_SID=teste
sqlplus "/ as sysdba" <<EOF
startup mount
ALTER database noarchivelog;
ALTER database open;
EOF

Habilitando a base no 2º nó

Se você chegou aqui, parabéns. Eu demorei um tempinho até fazer isso com sucesso pleno. Mas tem um detalhe importante, ao duplicar a base, apenas um nó é duplicado, o outro nó continua inativo.

Passo 11 – Verificar o UNDO

Verifique se o UNDO dos 2 nós estão presentes.

export ORACLE_SID=teste
sqlplus "/ as sysdba" <<EOF
SELECT tablespace_name, status
  FROM dba_tablespaces
  WHERE contents = 'UNDO';
exit
EOF

Se não estiver, criar para o nó 2

Passo 12 – Criar o REDO para o nó 2

Antes verifique como os logs de REDO estão:

SELECT * FROM v$log; -- olhar o tamanho dos logs
SELECT * FROM v$logfile; -- olhar o destino e quantidade dos logs;

Depois crie os logs para a thread 2 segundo as informações encontradas. Neste caso, serão 4 REDOs, de 512M com um membro por grupo utilizando o diskgroup ASMGRP03.

ALTER DATABASE ADD logfile thread 2 ('+asmgrp03') SIZE 512M;
ALTER DATABASE ADD logfile thread 2 ('+asmgrp03') SIZE 512M;
ALTER DATABASE ADD logfile thread 2 ('+asmgrp03') SIZE 512M;
ALTER DATABASE ADD logfile thread 2 ('+asmgrp03') SIZE 512M;

Passo 13 – Habilitar o nó 2

ALTER database enable thread 2;

Passo 14 – baixar a base

shutdown IMMEDIATE

Passo 15 Verificar se a base está cadastrada no cluster

Como a base em geral está sendo atualizada, este problema não ocorre, pois já deverá estar OK. Mas se você estiver criando uma nova, com certeza vai precisar mexer nisso. De qualquer forma, é sempre bom checar.

cd $CRS_HOME/bin/crs_stat

Tem de aparecer algo como:

NAME=ora.teste.db
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE on ora02
 
NAME=ora.teste.teste1.inst
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE on ora01
 
NAME=ora.teste.teste2.inst
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE on ora02

Se não aparecerem as linhas, cadastrar a base no cluster:

srvctl add database -d teste -o $ORACLE_HOME
srvctl add instance -d teste -i  teste1 -n ora01
srvctl add instance -d teste -i  teste2 -n ora02

Legenda:

• -d = nome da base
• -o = local do $ORACLE_HOME
• -I = instância
• -n = mome do servidor onde a instância está.

Passo 16 – Subir a base nos 2 nós pelo cluster

srvctl start database -d teste

Passo 17 – Verificar nos 2 nós

Você pode ignorar alguns erros logo depois do recover, no momento do resetlogs, mas fique atendo a todo o restante.

Na verdade, durante todo o processo é uma boa idéia ir acompanhando o alerta.

E se a base de testes não está no mesmo servidor, não está em RAC e ASM?

Bom, aí meu caro, você vai ter que tomar alguns cuidados adicionais:

Exemplo 1

Ao invés de ficar aqui explicando tudo novamente, vou mostrar 2 exemplos de DUPLICATE de uma base em RAC para uma base de testes sem RAC:

rman TARGET sys/sua_senha@producao NOCATALOG AUXILIARY / <<EOF
run {
allocate auxiliary channel 'dev_0' TYPE 'sbt_tape'
parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,
    ENV=(OB2BARTYPE=Oracle8,
    OB2APPNAME=producao01,
    OB2BARLIST=PRODUCAO_DIARIO)';
send device TYPE 'sbt_tape' 'OB2BARHOSTNAME=ora1';
     DUPLICATE TARGET DATABASE TO teste
	UNTIL TIME "TRUNC(SYSDATE) + 3/24 + 40/1440"
        DB_FILE_NAME_CONVERT = (
		'+ASMGRP01/producao/datafile/', '/u01/oradata/teste/',
		'+ASMGRP01/producao/tempfile/', '/u01/oradata/teste/')
        LOGFILE
            GROUP 1 ('/u01/oradata/teste/redo01.log') SIZE 128M REUSE,
            GROUP 2 ('/u01/oradata/teste/redo02.log') SIZE 128M REUSE,
            GROUP 3 ('/u01/oradata/teste/redo03.log') SIZE 128M REUSE,
	    GROUP 4 ('/u01/oradata/teste/redo04.log') SIZE 128M REUSE;
RELEASE auxiliary channel 'dev_0';
}
EXIT
EOF

Algumas observações:

• Este backup está vindo de uma fita, então estou passando alguns parâmetros específicos para um software de backup, que não vem ao caso aqui. Mas fique atento que sem os dados de um log de backup para fita da sua ferramenta de backup, você não tem como pegar os parâmetros em “params” logo no começo;
• O parâmetro “UNTIL TIME” está ajustado para um horário bem específico, referente à janela de backup da unidade de fitas, e é um horário depois do término do backup normal e antes do horário em que eu rodei um backup dos archives na mão;
• Eu coloquei o DB_FILE_NAME_CONVERT aqui no DUPLICATE e não no INIT. Se estiver configurado este parâmetro no init também, vale o do DUPLICATE.
• O LOGFILE é um dos segredos do sucesso. Ao invés de configurar o LOG_FILE_NAME_CONVERT, eu digo logo como ele tem de ficar. Me poupa o trabalho de arrumar isso depois.
• Você não precisa, mas seria bom remover o tablespace de UNDO do nó 2, que não estará sendo utilizado.

Exemplo 2

Agora vou mostrar um script que utilizo para uma base D-1. Ou seja, uma base que faz o restore do backup da produção todo dia:

export ORACLE_HOME=/opt/app/oracle/product/10.2.0/db_1
export PATH=/usr/local/bin:/bin:/usr/bin:$ORACLE_HOME/bin
export ORACLE_SID=teste
sqlplus "/ as sysdba" <<EOF
shutdown abort
startup nomount
EOF
 
rm -fr /u01/oradata/teste/
 
rman TARGET sys/sua_senha@producao NOCATALOG AUXILIARY sys/sua_senha@teste <<EOF
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS     
    'ENV=(OB2BARTYPE=Oracle8,
     OB2APPNAME=producao1,
     OB2BARLIST=PRODUCAO FULL)';
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
RUN
{
     DUPLICATE TARGET DATABASE TO teste
	UNTIL TIME "TRUNC(SYSDATE) + 2/24 + 50/1440"
        OPEN RESTRICTED
        DB_FILE_NAME_CONVERT = (
		'+ASMGRP01/producao/datafile/', '/u01/oradata/teste/',
		'+ASMGRP02/producao/datafile/', '/u01/oradata/teste/',
		'+ASMGRP01/producao/tempfile/', '/u01/oradata/teste/')
        LOGFILE
            GROUP 1 ('/u01/oradata/teste/redo01.log') SIZE 128M REUSE,
            GROUP 2 ('/u01/oradata/teste/redo02.log') SIZE 128M REUSE,
            GROUP 3 ('/u01/oradata/teste/redo03.log') SIZE 128M REUSE,
	    GROUP 4 ('/u01/oradata/teste/redo04.log') SIZE 128M REUSE;
}
EXIT
EOF

Comentários:

• Este script é uma forma simplificada de um script que fica agendado no crontab e roda toda noite.
• Note que a base abre no modo restrito.

Exemplo 3

Agora um exemplo diferente, um clone de uma base sem ASM e sem RAC. O backup via RMAN é feito toda a noite para disco e utilizamos este backup para o clone. Só que a base de produção e testes estão em servidores diferentes.

Para isso criei um arquivo no servidor de produção para ajudar em ~/script/copia_backup.sh com:

find /u01/backup/producao/ -name 'backup_db_*' -daystart -mtime -1
 -exec rsync -av  \{\} 192.168.0.x:/u01/backup/producao  \;

Este arquivo serve só para copiar o backup da produção para o servidor de teste.

Agora vamos ao script para a atualização da base:

export ORACLE_SID=teste
export ORACLE_SID_ORIGEM=producao
export ORACLE_HOME=/opt/app/oracle/product/10.2.0/db_1
export PATH=$PATH:$ORACLE_HOME/bin
 
sqlplus "/ as sysdba" << EOF
shutdown abort
exit 0
EOF
 
if [ $? -ne 0 ]; then
  echo " ERRO: Banco de dados invalido !"
  exit;
fi
 
echo "Limpando a área de backup"
find /u01/backup/$ORACLE_SID_ORIGEM/ 'backup_db_*' -mtime +2 -exec rm -fv \{\} \;
 
echo "Limpando a área de archive"
find /u01/archive/$ORACLE_SID_ORIGEM/ '*.arc' -mtime +1 -exec rm -fv \{\} \;
 
echo "Backup dos archives"
rman target sys/sua_senha@$ORACLE_SID_ORIGEM <<EOF
backup archivelog all;
exit
EOF
 
echo "Copiando o backup da produção"
ssh 192.168.0.y ~/script/copia_backup.sh
 
echo "Limpando a base $ORACLE_SID"
rm -Rfv /u01/oradata/${ORACLE_SID}/*.dbf
 
echo "Subindo a base $ORACLE_SID no modo NOMOUNT"
sqlplus  "/ as sysdba" << EOF
startup nomount;
exit
EOF
 
echo "Iniciando o DUPLICATE"
rman target 'sys/sua_senha@$ORACLE_SID_ORIGEM' auxiliary / <<EOF
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
    '/u01/backup/$ORACLE_SID_ORIGEM/backup_db_%U_%T' MAXPIECESIZE 8192 M;
run {
  allocate auxiliary channel dsk11 device type disk;
  duplicate target database to $INSTANCE_NAME until time "sysdate - 12/24";
  release auxiliary channel dsk11;
}
exit
EOF
 
sqlplus  "/ as sysdba" << EOF
shutdown immediate;
startup mount;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;
exit
EOF

Comentários:

• A troca de chaves SSH foi realizada para podermos rodar comandos SSH sem senha;
• O backup via RMAN tem de ser copiado do servidor de produção para o servidor de teste para exatamente o mesmo diretório.
• Sempre cuidado com os archives. Fazemos um backup via RMAN dos archives e copiamos ele junto antes de iniciar o DUPLICATE;
• Colocamos a base no modo noarchive, algumas pessoas fazem isso em bases de testes.

Referências

• Backup and Recovery Advanced User’s Guide – Cap 13: Creating and Updating Duplicate Databases with RMAN
• Backup and Recovery Reference – DUPLICATE

O Sr. Dickson Guedes resurgiu das cinzas em grande estilo e com um projeto muito bacana. O pgcasts é um screencast, ou seja, áudio e vídeo com uma demonstração de como fazer alguma coisa no PostgreSQL. Ver a tela dele fazendo enquanto vai comentando, é muito mais simples do que ler um artigo enorme num blog como o meu…. assuntos que eu levaria páginas para abordar ele mostra como fazer na prática com 20 a 30 minutos de screencast.

Muito bacana, eu recomendo. Até hoje (02/05/11) são 3 episódios e ele vem mantendo a média de um novo screencast por semana:

1. Instalando PostgreSQL 9.0
2. Trabalhando com datas no PostgreSQL
3. Alterando colunas de tipos conflitantes

Divirtam-se.

Para quem não sabe, o PGBR2011 (nome novo para o PGCon Brasil) está à pleno vapor e em sua 4ª edição estamos novamente dando um bom salto de qualidade. Vejamos algumas novidades:

5 Palestrantes internacionais Confirmados

• Álvaro Herrera (Chile)
• Bruce Momjian (EUA)
• Dave Page (Inglaterra)
• Greg Smith (EUA)
• Koichi Suziki (Japão)

Todos eles são desenvolvedores do PostgreSQL e tem grandes contribuições para a comunidade.

O evento será realizado no conforto do Hotel Century Paulista, em São Paulo

Os detalhes do local já estão acertados. A decisão de fazer o evento num hotel deverá ajudar bastante quem vem de longe. Você poderá se hospedar no mesmo local do evento. Assim as pessoas gastam menos com deslocamento e perdem menos tempo. Para quem for se hospedar, confira os preços especiais para quem for participar do evento. Recomendo fazer a sua reserva o quanto antes para evitar surpresas na última hora.

Para quem mora em São Paulo, também será uma grande vantagem, o local fica a apenas algumas quadras da estação Brigadeiro do metrô. Se você preferir vir de carro até o local, há um estacionamento com preço fechado para participantes do evento.

Serão 3 salas simultâneas que juntas comportam 470 pessoas, uma sala de apoio, um salão de exposições e um local para o famoso coffee break à tarde. Estamos esperando um público de 400 pessoas nos 2 dias do evento, que cairão numa 5ª e 6ª feira, diferente das edições anteriores. Notem que na 4ª, haverá um feriado.

Participe

Você pode ajudar:

1. Venha ao evento. Sua presença é o mais importante para nós. As inscrições deverão abrir em agosto. Como sempre, quem se inscrever com antecedência, vai poder aproveitar um preço especial.
2. Mande uma proposta de palestra. A chamada de trabalhos será aberta em meados de junho ou julho, fique atento.
3. Divulgue o evento:
   • Se você tem um blog, um site, pode divulgar um banner do evento ou falar sobre ele.
   • Se você utiliza o Twitter, fale sobre o evento e utilize a hash tag #PGBR2011.
   • Se você participa de alguma lista de discussão por e-mail, informe as pessoas sobre o evento. Não esqueça das boas maneiras e coloque um [off-topic] no assunto.
   • Se você estuda numa faculdade, estaremos fazendo alguns cartazes sobre o evento que você poderá afixar no mural.
4. Se você trabalha numa empresa de TI ou utiliza muito o PostgreSQL no seu trabalho, considere a possibilidade da sua empresa patrocinar o evento.
5. Se você gostaria de dar sugestões ou ajudar na organização do evento, entre na lista da comunidade.

Bom, vale a pena ler o artigo. Você verá que nos comentários o PostgreSQL começa a aparecer, e com boas avaliações. Mais interessante ainda é que o Thomas ignora ao máximo o PostgreSQL nos comentários. Claro, ele não é estúpido, não seria inteligente nem diplomático da parte dele. O máximo que ele chega a citar é que a Oracle tem o XE, que quem conhece sabe que é algo limitado e certamente foi lançado (a exemplo do que fez a MicroSoft e IBM) para retardar o avanço dos bancos de dados livres.

O post é de 2001 e os comentários perduram até 2010. De qualquer forma, fica claro, que os mesmos argumentos que ele utiliza para mostrar a superioridade do Oracle, serviriam para o PostgreSQL…. vale a pena ler.

Comparison between Oracle and Others

Bom, vou mostrar aqui um alguns exemplos de SQLs que tive que desenvolver recentemente. Alguns foram feitos para ajudar a equipe de desenvolvimento, outros para resolverem problemas de performance e tem um que foi feito por solicitação dos  sysadmins. Na verdade, eu deveria mesmo é organizar estes scripts de uma forma lógica, mas são coisas realmente simples para merecerem tanto coidado…

Então chega de blá, blá, blá e vamos a eles:

• Conversão de NOT IN em NOT EXISTS numa carga de dados. É muito comum você precisar carregar periodicamente uma tabela com os dados de uma outra. Isso ocorre muito na integração entre sistemas. Eu sei, eu sei, usar visões materializadas pode ser um processo bem mais inteligente. Infelizmente nem sempre estas decisões estão na nossa mão. Vejamos o caso:

INSERT INTO tabela2
    SELECT * FROM tabela1 t1
        WHERE campo_pk NOT IN(SELECT campo_pk FROM tabela_origem);

Você tem de carregar a tabela2, com os dados da tabela1 sem repetir os dados que já estejam lá. Utilizar o NOT IN é bem intuitivo, mas quando a tabela2 é grande, se torna um pesadelo, pois a subconsulta uma vez para cada registro na tabela1 e não consegue utilizar índices para isso. Um verdadeiro pesadelo. Então vamos a solução clássica:

INSERT INTO tabela2
    SELECT * FROM tabela1 t1
        WHERE NOT EXISTS (SELECT NULL FROM tabela2 t2 WHERE t2.campo_pk = t1.campo_pk );

• Pegar apenas o primeiro e o último nome de um campo com nome completo:

SELECT
        SUBSTR(nome,0,INSTR(TRIM(nome),' ')) primeiro_nome
        SUBSTR(nome,INSTR(TRIM(nome),' ',-1) + 1) ultimo_nome,
    FROM tabela_cadastro;

• Limpar caracteres inválidos de telefones. Sim, tem muita gente que gosta de armazenar telefones, CEP, RG, CPF com caracteres não numéricos. Não é o correto, mas muita gente faz. Então, para fazer uma limpeza, vamos utilizar um pouco de expressões regulares, que são pouco exploradas por muitos DBAs e até mesmo desenvolvedores:

SELECT SUBSTR(LTRIM(regexp_replace(telefone,'[^0-9]'),0),0,10) fone_tratado
    FROM tabela_cadastro;

• Selecionar apenas e-mails válidos. Eu sei, a validação deveria ser feita na carga dos dados, mas nem sempre acontece. Aqui, mais um caso clássico de uso de expressões regulares:

SELECT TRIM(email) email
    FROM tabela_cadastro
    WHERE REGEXP_LIKE (TRIM(email),'^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$','i');

• Agora uma forma de saber se o número de sessões num nó do Oracle RAC estão relativamente bem balanceadas. Aqui estou utilizando funções de janelas (que já abordamos aqui antes, mas com o Postgres), algo muito bacana, utilizado exaustivamente em consultas complexas com BI:

SELECT
        i.instance_name,
        l.sessions_current,
        ROUND(l.sessions_current * COUNT(l.inst_id) OVER () / SUM(l.sessions_current) OVER (),2) var
    FROM gv$license l, gv$instance i
    WHERE l.inst_id = i.inst_id;

Aqui, um valor entre digamos 0,9 e 1,1 para o campo VAR significa que o nó está relativamente bem balanceado. Esta consulta foi utilizada para uma ferramenta de monitoramento do Oracle RAC.

OBS: Os scripts aqui foram escritos e testados em Oracle 10g e 11g, sorry.

Aí o que o DBA faz? Pega a senha do usuário numa listinha “cuidadosamente” guardada e roda o script em questão. Então, pare e pense: qual é o problema nisso?

• Você tem que guardar a senha dos usuários da base. Isso vai lhe levar a uma das seguintes situações:
  • Você vai colocar senhas fáceis (como o mesmo nome do usuário ou a mesma senha para todos usuários), o que representa uma brecha de segurança;
  • Você vai anotar num papel, txt ou algo do tipo todas as senhas. E esse papel, txt, etc não vai estar guardado num cofre, pois você precisa disso com frequência. Nova falha de segurança.
  • Você vai criar um banco de dados para guardar as senhas… e ter mais uma base para administrar, gênio.
  • Você vai deixar o próprio desenvolvedor/fornecedor rodar o script para você. Tá louco? Jamais faça isso num ambiente de produção!!!
• Você vai ter que conceder permissões para este usuário além do necessário. Se precisa criar uma tabela, precisa conceder permissão de CREATE TABLE. Precisa criar uma sequência? CREATE VIEW. E por aí vai. Não é raro o DBA usar logo uma daquelas mega permissões como DBA, RESOURCE, etc. Afinal, perder tempo com segurança é coisa de DBA chato, certo?

Ok, você é um DBA esperto… muitos anos de praia, já sabe que existem outras alternativas:

• Rodar o script como DBA, mas antes abrir o script num editor e sair colocando o nome do esquema antes do nome do objeto. Isso dá certo, mas dá muito trabalho. Não é algo que se possa automatizar sem cometer alguns erros. Acredite, há casos em que isso pode levar horas e está sujeito a muitos erros.
• Você pode pegar a senha criptografada em DBA_USERS, alterar a senha do usuário, rodar o script e depois voltar a senha original. É também uma forma de bloquear o acesso deste usuário enquanto você está atualizando os objetos. Claro que idealmente um usuário dono de objetos não deveria nunca ser utilizado para acesso pela aplicação… mas não é o que os desenvolvedores tem a mania de fazer. Por mim esse usuário não deveria sequer ter permissão para se conectar na base. Eu realmente não acho esta uma solução elegante, e você precisa manter o usuário com um monte de privilégios desnecessários da mesma forma que antes. Já vi também pessoas colocando permissões de DBA enquanto rodam o script e depois que terminam removem a permissão. Não, não é uma boa idéia. Você também tem de anotar com cuidado a senha criptografada para alterar a senha de volta para a original qualquer caracter bizarro que você erre, já era. Por fim você  tem conhecer o impacto de alterar a senha, mesmo que provisóriamente. Experimenta por exemplo trocar a senha do usuário APPS no EBS para ver o que acontece…

Então qual é o procedimento que 10 entre 10 DBAs experientes utilizam? Simples:

ALTER SESSION SET current_schema=foo;

Simples assim. O esquema padrão passa a ser foo. Todos os objetos criados, alterados e apagados serão neste esquema.

Mas calma, existem alguns problemas sim: alguns comandos não trabalham bem com outro CURRENT_SCHEMA. Um deles é a criação de DB Links. Não é possível criar um DB Link para outro esquema, você tem de estar realmente conectado com o usuário em questão para criar este DB Link. Claro que você não cria DB Links no ambiente de produção com frequência (pela sua sanidade mental, eu espero que não). DB Links públicos não tem esse problema, é claro. Outro problema é a criação de JOBs com o DBMS_JOB. Você pode utilizar o DBMS_IJOB, para contornar este problema ou pelo bem da humanidade migrar para o Scheduler.

Bom, de qualquer forma é sempre obrigação do DBA revisar os scripts, verificar os parâmetros de Storage, etc.

OBS: Este post é dedicado a um DBA velho de guerra que ainda guarda velhos hábitos dos tempos que era desenvolvedor e insiste em me trazer mais problemas do que soluções.

OBS2: No PostgreSQL existe uma não conformidade com o padrão SQL (você pode trabalhar no padrão se quiser, mas não vejo vantagem) que permite que os usuários e os esquemas não sejam diretamente relacionados.  Então esta cultura ruim do Oracle não é tão comum entre os desenvolvedores/DBAs do PostgreSQL. Além disso o PostgreSQL tem o SEARCH_PATH que é mais refinado que o CURRENT_SCHEMA, e os comandos DDL permitem a troca do dono de qualquer objeto (que não seja um objeto de sistema, claro).

• ATUALIZAÇÃO (em 16/02/2011):

Para aqueles que ainda precisam utilizar o DBMS_JOB e precisam criar JOBs para outro usuário, segue uma dica de como fazer, utilizando o DBMS_IJOB.SUBMIT. O DBMS_IJOB.REMOVE é fácil de utilizar, mas para criar um novo JOB, você vai precisar passar todos os parâmetros, como em:

DECLARE
    job_num NUMBER;
    nlsvar varchar2(4000);
    envvar raw(32);
BEGIN
    SELECT nls_env,misc_env
        INTO nlsvar,envvar
        FROM dba_jobs
        WHERE
            rownum<2 AND
            nls_env IS NOT NULL AND
            misc_env IS NOT NULL;
    SELECT MAX(job)+1
        INTO job_num
        FROM dba_jobs;
    sys.dbms_ijob.submit(         job=>job_num,
        luser=>'MEU_USUARIO',
        puser=>'MEU_USUARIO',
        cuser=>'MEU_USUARIO',
        what=>'meu_usuario.roda_procedure_xyz;',
        next_date=>TRUNC(SYSDATE),
        INTERVAL=>'TRUNC(SYSDATE) + 1',
        broken=>FALSE,
        nlsenv=>nlsvar,
        env=>envvar);
    dbms_output.put_line(job_num);
END;
/
COMMIT;

Já aqueles que desejam criar um DB LINK privado, a única alternativa é recorrer ao DBMS_SYS_SQL, que assim como o DBMS_IJOB não está na documentação oficial:

DECLARE
    uid NUMBER;
    sqltext varchar2(1000) := 'CREATE DATABASE LINK test_dblink
CONNECT TO dblink_user IDENTIFIED BY dblink_user_password
USING ''nome_da_base_no_tnsnames''';
    myint INTEGER;
BEGIN
    SELECT user_id INTO uid FROM all_users WHERE username LIKE 'SCOTT';
    myint:=sys.dbms_sys_sql.open_cursor();
    sys.dbms_sys_sql.parse_as_user(myint,sqltext,dbms_sql.native,UID);
    sys.dbms_sys_sql.close_cursor(myint);
END;
/

Note que você pode utilizar o DBMS_SYS_SQL para rodar qualquer comando SQL como outro usuário. No exemplo, estamos utilizando o usuário SCOTT.

Para facilitar este trabalho criei o pequeno script abaixo que cria dois arquivos, um para desabilitar os JOBs e outro para habilitar novamente. Outro erro comum é desabilitar os JOBs e depois não saber quais estavam ativos antes, na hora de habilita-los.

Um último adendo, aqui eu estou utilizando o DBMS_IJOB (que não está bem documentado, mas permite trabalhar com jobs de outros usuários) e o DBMS_SCHEDULER para aqueles que utilizam este recurso introduzido no 10g.

sqlplus -s / AS sysdba <<EOF
SET heading off
SET trimspool ON
SET term off
SET echo off
SET feed off
 
SPOOL 'jobs_to_broken.sql'
SELECT 'EXEC dbms_ijob.broken(' || job || ',TRUE);' 
    FROM dba_jobs 
    WHERE broken = 'N';
 
SELECT 'EXEC dbms_scheduler.disable (''' || owner || '.' || job_name || ''');' 
    FROM dba_scheduler_jobs 
    WHERE enabled = 'TRUE'
    ORDER BY owner, job_name;
 
SPOOL OFF
SPOOL 'jobs_to_run.sql'
SELECT 'EXEC dbms_ijob.broken(' || job || ',FALSE);' 
    FROM dba_jobs 
    WHERE broken = 'N';
 
SELECT 'EXEC dbms_scheduler.enable (''' || owner || '.' || job_name || ''');' 
    FROM dba_scheduler_jobs 
    WHERE enabled = 'TRUE'
    ORDER BY owner, job_name;
SPOOL OFF
-- rodar '@jobs_to_broken' para desabilitar os JOBs'
-- rodar '@jobs_to_run' para restaurar os JOBs
EOF

Bom, resumindo a história, eu precisei lançar mão das novas funções de janela, incorporadas na versão 8.4 do PostgreSQL. Para exemplificar aqui, vou utilizar uma base de exemplo conhecida de todos, o PAGILA. Eu tentei o DELLSTORE, mas os dados não apareceram tão bem distribuídos para efeito de visualização.

Bom, depois de criar uma base e importar os dados do PAGILA, eu criei uma visão para facilitar a minha vida e simplificar a análise, deixando de lado detalhes desnecessários:

CREATE OR REPLACE VIEW sales_pgday AS
    SELECT
        f.title,
        c.name AS category,
        SUM(p.amount) AS total_sales
        FROM
            (((((payment p JOIN rental r ON ((p.rental_id = r.rental_id)))
                JOIN inventory i ON ((r.inventory_id = i.inventory_id)))
                JOIN film f ON ((i.film_id = f.film_id)))
                JOIN film_category fc ON ((f.film_id = fc.film_id)))
                JOIN category c ON ((fc.category_id = c.category_id)))
        GROUP BY c.name, f.title
    ;

Com um select você verá os dados mais ou menos assim:

           title            |  category   | total_sales
-----------------------------+-------------+-------------
 AMADEUS HOLY                | Action      |       33.79
 AMERICAN CIRCUS             | Action      |      167.78
 ANTITRUST TOMATOES          | Action      |       37.90
 BAREFOOT MANCHURIAN         | Action      |       66.82
 BERETS AGENT                | Action      |       78.78
 BRIDE INTRIGUE              | Action      |       21.81
 BULL SHAWSHANK              | Action      |       21.84
 CADDYSHACK JEDI             | Action      |       51.84
 CAMPUS REMEMBER             | Action      |       90.81
 CASUALTIES ENCINO           | Action      |       72.91
 CELEBRITY HORN              | Action      |       32.76
 CLUELESS BUCKET             | Action      |      112.75
 CROW GREASE                 | Action      |       18.88
 DANCES NONE                 | Action      |       31.86
 DARKO DORADO                | Action      |       82.89
 DARN FORRESTER              | Action      |       93.82
 DEVIL DESIRE                | Action      |       83.85
 DRAGON SQUAD                | Action      |       27.89
 DREAM PICKUP                | Action      |       81.78
 DRIFTER COMMANDMENTS        | Action      |      141.76
...

O primeiro passo para calcular a curva ABC sobre as vendas de cada filme, para cada categoria de filme (os filmes mais vendidos e os menos vendidos em cada categoria) é calcular o total de vendas. Uma vez que queremos os 20% mais vendidos e os 20% menos vendidos, precisamos do total (100%) para calcular a porcentagem:

SELECT category, SUM(total_sales)
    FROM sales_pgday
    GROUP BY category;

E assim teremos:

  category   |   sum
-------------+---------
 Action      | 4375.85
 Animation   | 4656.30
 Children    | 3655.55
 Classics    | 3639.59
 Comedy      | 4383.58
 Documentary | 4217.52
 Drama       | 4587.39
 Family      | 4226.07
 Foreign     | 4270.67
 Games       | 4281.33
 Horror      | 3722.54
 Music       | 3417.72
 New         | 4361.57
 Sci-Fi      | 4756.98
 Sports      | 5314.21
 Travel      | 3549.64
(16 linhas)

Agora vejamos uma função de janela em ação aqui. Ainda não é a que vamos utilizar, é apenas um exemplo:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (ORDER BY total_sales DESC) AS rank
FROM sales_pgday;

Agora vejamos o resultado:

            title            |  category   | total_sales | rank
-----------------------------+-------------+-------------+------
 TELEGRAPH VOYAGE            | Music       |      231.73 |    1
 WIFE TURN                   | Documentary |      223.69 |    2
 ZORRO ARK                   | Comedy      |      214.69 |    3
 GOODFELLAS SALUTE           | Sci-Fi      |      209.69 |    4
 SATURDAY LAMBS              | Sports      |      204.72 |    5
 TITANS JERK                 | Sci-Fi      |      201.71 |    6
 TORQUE BOUND                | Drama       |      198.72 |    7
 HARRY IDAHO                 | Drama       |      195.70 |    8
 INNOCENT USUAL              | Foreign     |      191.74 |    9
 HUSTLER PARTY               | Comedy      |      190.78 |   10
 PELICAN COMFORTS            | Documentary |      188.74 |   11
 CAT CONEHEADS               | Comedy      |      181.70 |   12
 ENEMY ODDS                  | Music       |      180.71 |   13
 BUCKET BROTHERHOOD          | Travel      |      180.66 |   14
 RANGE MOONWALKER            | Family      |      179.73 |   15
 MASSACRE USUAL              | Games       |      179.70 |   16
 VIDEOTAPE ARSENIC           | Games       |      178.71 |   17
 DOGMA FAMILY                | Animation   |      178.70 |   18
 APACHE DIVINE               | Family      |      178.69 |   19
 VELVET TERMINATOR           | Comedy      |      177.74 |   20
...

Agora vamos olhar com calma os dados (tirei aqui apenas as 20 primeiras linhas) e a parte do SELECT que diz:

rank() OVER (ORDER BY total_sales DESC) AS rank

Veja, o campo está utilizando a função RANK, sobre uma janela de dados ordenados pelo total de vendas. O campo RANK simplesmente diz qual é mais significativo, sobre a amostra (OVER) determinada. Agora queremos saber quais são os mais vendidos por categoria. O curioso é que ao invés de utilizar o GROUP BY que afetaria todas as colunas, vamos utilizar o PARTITION BY dentro da definição da janela, assim, isto afetará apenas a nossa última coluna:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (PARTITION BY category ORDER BY total_sales DESC) AS rank
FROM sales_pgday;

Assim teremos:

            title            |  category   | total_sales | rank
-----------------------------+-------------+-------------+------
 FOOL MOCKINGBIRD            | Action      |      175.77 |    1
 AMERICAN CIRCUS             | Action      |      167.78 |    2
 STAGECOACH ARMAGEDDON       | Action      |      154.74 |    3
 EASY GLADIATOR              | Action      |      150.77 |    4
 MINDS TRUMAN                | Action      |      149.80 |    5
 KISSING DOLLS               | Action      |      147.80 |    6
 TRIP NEWTON                 | Action      |      145.72 |    7
 DRIFTER COMMANDMENTS        | Action      |      141.76 |    8
 SUSPECTS QUILLS             | Action      |      133.70 |    9
 WATERFRONT DELIVERANCE      | Action      |      121.83 |   10
...
 DRAGON SQUAD                | Action      |       27.89 |   56
 BULL SHAWSHANK              | Action      |       21.84 |   57
 BRIDE INTRIGUE              | Action      |       21.81 |   58
 CROW GREASE                 | Action      |       18.88 |   59
 LAWRENCE LOVE               | Action      |       15.87 |   60
 MONTEZUMA COMMAND           | Action      |       11.91 |   61
 DOGMA FAMILY                | Animation   |      178.70 |    1
 SUNRISE LEAGUE              | Animation   |      170.76 |    2
 TITANIC BOONDOCK            | Animation   |      154.77 |    3
 FORRESTER COMANCHEROS       | Animation   |      146.73 |    4
 FALCON VOLUME               | Animation   |      127.77 |    5
...

Notem que agora o rank é realizado para cada categoria, o rank é ordenado pelas vendas. Vale a pena executar o SQL no seu computador para verificar os dados com mais calma.

Bom, mas eu quero saber dos 20% mais vendidos. O problema aqui é que você precisaria ir somando o total de vendas de cada produto até chegar em 20% do total. Ocorre que você pode utilizar as funções de agregação como SUM, COUNT e outras junto com a sua janela. Vejamos como isso funciona:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (PARTITION BY category ORDER BY total_sales DESC) AS rank,
    SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS SUM
FROM sales_pgday;

E teremos os seguintes dados:

            title            |  category   | total_sales | rank |   sum
-----------------------------+-------------+-------------+------+---------
 FOOL MOCKINGBIRD            | Action      |      175.77 |    1 |  175.77
 AMERICAN CIRCUS             | Action      |      167.78 |    2 |  343.55
 STAGECOACH ARMAGEDDON       | Action      |      154.74 |    3 |  498.29
 EASY GLADIATOR              | Action      |      150.77 |    4 |  649.06
 MINDS TRUMAN                | Action      |      149.80 |    5 |  798.86
 KISSING DOLLS               | Action      |      147.80 |    6 |  946.66
 TRIP NEWTON                 | Action      |      145.72 |    7 | 1092.38
 DRIFTER COMMANDMENTS        | Action      |      141.76 |    8 | 1234.14
 SUSPECTS QUILLS             | Action      |      133.70 |    9 | 1367.84
 WATERFRONT DELIVERANCE      | Action      |      121.83 |   10 | 1489.67
 TRUMAN CRAZY                | Action      |      121.77 |   11 | 1611.44
 CLUELESS BUCKET             | Action      |      112.75 |   12 | 1724.19
 SOUTH WAIT                  | Action      |      107.78 |   13 | 1831.97
 DARN FORRESTER              | Action      |       93.82 |   14 | 1925.79
 CAMPUS REMEMBER             | Action      |       90.81 |   15 | 2016.60
 FORREST SONS                | Action      |       87.82 |   16 | 2104.42
 DEVIL DESIRE                | Action      |       83.85 |   17 | 2188.27
 DARKO DORADO                | Action      |       82.89 |   18 | 2271.16
 DREAM PICKUP                | Action      |       81.78 |   19 | 2352.94
 WEREWOLF LOLA               | Action      |       78.86 |   20 | 2431.80
...
 REAR TRADING                | Action      |       32.83 |   52 | 4163.15
 CELEBRITY HORN              | Action      |       32.76 |   53 | 4195.91
 DANCES NONE                 | Action      |       31.86 |   54 | 4227.77
 SIDE ARK                    | Action      |       29.88 |   55 | 4257.65
 DRAGON SQUAD                | Action      |       27.89 |   56 | 4285.54
 BULL SHAWSHANK              | Action      |       21.84 |   57 | 4307.38
 BRIDE INTRIGUE              | Action      |       21.81 |   58 | 4329.19
 CROW GREASE                 | Action      |       18.88 |   59 | 4348.07
 LAWRENCE LOVE               | Action      |       15.87 |   60 | 4363.94
 MONTEZUMA COMMAND           | Action      |       11.91 |   61 | 4375.85
 DOGMA FAMILY                | Animation   |      178.70 |    1 |  178.70
 SUNRISE LEAGUE              | Animation   |      170.76 |    2 |  349.46
 TITANIC BOONDOCK            | Animation   |      154.77 |    3 |  504.23
 FORRESTER COMANCHEROS       | Animation   |      146.73 |    4 |  650.96
 FALCON VOLUME               | Animation   |      127.77 |    5 |  778.73
 MISSION ZOOLANDER           | Animation   |      126.82 |    6 |  905.55
 DOORS PRESIDENT             | Animation   |      123.81 |    7 | 1029.36
 SLEEPLESS MONSOON           | Animation   |      121.80 |    8 | 1151.16
 THIEF PELICAN               | Animation   |      117.81 |    9 | 1268.97
 HORN WORKING                | Animation   |      112.76 |   10 | 1381.73
...

Note que o valor da soma (SUM) vai acumulando registro a registro até que uma nova categoria apareça. Isto é uma coisa muito difícil de se fazer com SQL puro, você não consegue fazer cálculos com base nos registros anteriores.

Agora nós podemos juntar esta última consulta com a primeira para calcular a porcentagem de vendas sobre o total da categoria. Vamos colocar cada uma das consultas como uma entrada em FROM:

SELECT
    sales.category,
    title,
    somatorio,
    total,
    (somatorio / total) * 100 AS porcentagem
    FROM
        (SELECT
            category,
            SUM(total_sales) total
          FROM sales_pgday
          GROUP BY category) AS tot,
        (SELECT
            title,
            category,
            SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS somatorio
          FROM sales_pgday) sales
    WHERE tot.category = sales.category;

O resultado será:

  category   |            title            | somatorio |  total  |       porcentagem
-------------+-----------------------------+-----------+---------+--------------------------
 Action      | FOOL MOCKINGBIRD            |    175.77 | 4375.85 |   4.01681958933692882500
 Action      | AMERICAN CIRCUS             |    343.55 | 4375.85 |   7.85104608247540477900
 Action      | STAGECOACH ARMAGEDDON       |    498.29 | 4375.85 |  11.38727332975307654500
 Action      | EASY GLADIATOR              |    649.06 | 4375.85 |  14.83277534650410777300
 Action      | MINDS TRUMAN                |    798.86 | 4375.85 |  18.25611024143880617500
 Action      | KISSING DOLLS               |    946.66 | 4375.85 |  21.63373973056663276800
 Action      | TRIP NEWTON                 |   1092.38 | 4375.85 |  24.96383559765531268200
 Action      | DRIFTER COMMANDMENTS        |   1234.14 | 4375.85 |  28.20343476124638641600
 Action      | SUSPECTS QUILLS             |   1367.84 | 4375.85 |  31.25884113943576676500
 Action      | WATERFRONT DELIVERANCE      |   1489.67 | 4375.85 |  34.04298593416136293500
 Action      | TRUMAN CRAZY                |   1611.44 | 4375.85 |  36.82575956671275295100
 Action      | CLUELESS BUCKET             |   1724.19 | 4375.85 |  39.40240181907515111300
 Action      | SOUTH WAIT                  |   1831.97 | 4375.85 |  41.86546613800747283400
 Action      | DARN FORRESTER              |   1925.79 | 4375.85 |  44.00950672440782933600
 Action      | CAMPUS REMEMBER             |   2016.60 | 4375.85 |  46.08476067506884376700
...
 Action      | REAR TRADING                |   4163.15 | 4375.85 |  95.13923009243918324400
 Action      | CELEBRITY HORN              |   4195.91 | 4375.85 |  95.88788463955574345600
 Action      | DANCES NONE                 |   4227.77 | 4375.85 |  96.61597175405921135300
 Action      | SIDE ARK                    |   4257.65 | 4375.85 |  97.29881051681387616100
 Action      | DRAGON SQUAD                |   4285.54 | 4375.85 |  97.93617240079070352000
 Action      | BULL SHAWSHANK              |   4307.38 | 4375.85 |  98.43527543220174366100
 Action      | BRIDE INTRIGUE              |   4329.19 | 4375.85 |  98.93369288252568072500
 Action      | CROW GREASE                 |   4348.07 | 4375.85 |  99.36515191334255059000
 Action      | LAWRENCE LOVE               |   4363.94 | 4375.85 |  99.72782430842007838500
 Action      | MONTEZUMA COMMAND           |   4375.85 | 4375.85 | 100.00000000000000000000
 Animation   | DOGMA FAMILY                |    178.70 | 4656.30 |   3.83781113759852243200
 Animation   | SUNRISE LEAGUE              |    349.46 | 4656.30 |   7.50510061636922019600
 Animation   | TITANIC BOONDOCK            |    504.23 | 4656.30 |  10.82898438674484032400
 Animation   | FORRESTER COMANCHEROS       |    650.96 | 4656.30 |  13.98019887034770096400
 Animation   | FALCON VOLUME               |    778.73 | 4656.30 |  16.72422309559091982900
 Animation   | MISSION ZOOLANDER           |    905.55 | 4656.30 |  19.44784485535725790900
 Animation   | DOORS PRESIDENT             |   1029.36 | 4656.30 |  22.10682301398105792200
 Animation   | SLEEPLESS MONSOON           |   1151.16 | 4656.30 |  24.72263385091166806300
...

O resultado é a porcentagem do total de vendas sendo acumulado até 100% e depois começando novamente para outra categoria. Com isso fica fácil atribuir A para os 20% mais significativos, B para os próximos 60% e C para os 20% menos significativos. Aqui, irei utilizar uma função CASE, que embora ocupe um bom espaço no nosso SQL é algo bastante trivial:

SELECT
    sales.category,
    title,
    TRUNC((somatorio / total) * 100) AS porcentagem,
    CASE
        WHEN (somatorio / total) <= 0.2 THEN 'A'
        WHEN (somatorio / total) > 0.2  AND  (somatorio / total) <= 0.8 THEN 'B'
        ELSE 'C' END AS curva_abc
    FROM
        (SELECT
            category,
            SUM(total_sales) total
          FROM sales_pgday
          GROUP BY category) AS tot,
        (SELECT
            title,
            category,
            SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS somatorio
          FROM sales_pgday) sales
    WHERE tot.category = sales.category;

E finalmente temos a nossa curva ABC:

  category   |            title            | porcentagem | curva_abc
-------------+-----------------------------+-------------+-----------
 Action      | FOOL MOCKINGBIRD            |           4 | A
 Action      | AMERICAN CIRCUS             |           7 | A
 Action      | STAGECOACH ARMAGEDDON       |          11 | A
 Action      | EASY GLADIATOR              |          14 | A
 Action      | MINDS TRUMAN                |          18 | A
 Action      | KISSING DOLLS               |          21 | B
 Action      | TRIP NEWTON                 |          24 | B
 Action      | DRIFTER COMMANDMENTS        |          28 | B
 Action      | SUSPECTS QUILLS             |          31 | B
 Action      | WATERFRONT DELIVERANCE      |          34 | B
 Action      | TRUMAN CRAZY                |          36 | B
...
 Action      | EXCITEMENT EVE              |          69 | B
 Action      | BAREFOOT MANCHURIAN         |          70 | B
 Action      | HANDICAP BOONDOCK           |          72 | B
 Action      | PARK CITIZEN                |          73 | B
 Action      | UPRISING UPTOWN             |          74 | B
 Action      | MOCKINGBIRD HOLLYWOOD       |          76 | B
 Action      | PATRIOT ROMAN               |          77 | B
 Action      | GRAIL FRANKENSTEIN          |          78 | B
 Action      | SHRUNK DIVINE               |          79 | B
 Action      | CADDYSHACK JEDI             |          81 | C
 Action      | GOSFORD DONNIE              |          82 | C
 Action      | ENTRAPMENT SATISFACTION     |          83 | C
 Action      | SPEAKEASY DATE              |          84 | C
 Action      | MIDNIGHT WESTWARD           |          85 | C
 Action      | FANTASY TROOPERS            |          86 | C
 Action      | WOMEN DORADO                |          87 | C
...
 Action      | DRAGON SQUAD                |          97 | C
 Action      | BULL SHAWSHANK              |          98 | C
 Action      | BRIDE INTRIGUE              |          98 | C
 Action      | CROW GREASE                 |          99 | C
 Action      | LAWRENCE LOVE               |          99 | C
 Action      | MONTEZUMA COMMAND           |         100 | C
 Animation   | DOGMA FAMILY                |           3 | A
 Animation   | SUNRISE LEAGUE              |           7 | A
 Animation   | TITANIC BOONDOCK            |          10 | A
 Animation   | FORRESTER COMANCHEROS       |          13 | A
 Animation   | FALCON VOLUME               |          16 | A
 Animation   | MISSION ZOOLANDER           |          19 | A
 Animation   | DOORS PRESIDENT             |          22 | B
 Animation   | SLEEPLESS MONSOON           |          24 | B
 Animation   | THIEF PELICAN               |          27 | B
 Animation   | HORN WORKING                |          29 | B
 Animation   | GANGS PRIDE                 |          32 | B
...

É claro que existem N coisas que você pode fazer com funções de janela. A documentação possui algumas explicações sobre este recurso e também uma lista com várias funções que você pode testar com a sua base, aproveitando como ponto de partida os exemplos mostrados aqui.

Boa diversão!

Isso exige um pouco de reflexão. E como faz tempo que eu não faço isso por aqui, lá vai…

Bom, quem acompanha o blog aqui está careca de saber que em 2009 eu fui uma das pessoas que colaborou na organização da “III Conferência Brasileira de PostgreSQL“, também conhecida como PGCon Brasil 2009. Bom a organização de um evento deste porte não é nem de perto algo como a organização de um FISL. Mas não é nada simples. Quando você cobra R$ 100,00 pora alguém entrar num evento, tem que fazer este investimento voltar para a pessoa. É um compromisso que você assume. Não pode pisar na bola.

Para quem não sabe, existem 3 tipos de eventos que se encaixam aqui no Brasil:

• O PG Metting, que seria algo como um Happy Hour com uma palestra e um convite para tomar uma cerveja depois. Em São Francisco, CA, o povo do PostgreSQL se encontra toda  na 3ª quinta-feira de cada mês. É algo que São Paulo, Brasília, Porto Alegre, Fortaleza, teriam todas as condições de fazer. Basta achar um local e criar a tradição. Tenho muita vontade de criar algo deste tipo aqui em São Paulo, mas não pode ser no dia do meu rodízio, hehehe.
• O PGDay, que é um dia de palestras em um evento em geral direcionado para novatos. Assim como o PG Metting, pode ser organizado com custo zero, sem cobrar ingresso e sem patrocínio. Se tiver patrocínio, ótimo, mas não é preciso. Já foram vários PGDays com muito sucesso até agora. No ano passado tivemos: Brasília, São Paulo-SP, Porto Velho-RO, Ji-Paraná-RO, Porto Alegre-RS e ainda Florianópolis-SC. Este ano foram Ilheus-BA, Manaus-AM e São Paulo-SP, mas ainda deverá acontecer um no Rio de Janeiro-RJ. Vejam que não é pouca coisa. A simplicidade na organização e o aproveitamento de palestrantes locais é a chave do sucesso. E é a porta de entrada para novos colaboradores na comunidade.
• O PGBR, antes era chamado de PGCon Brasil, mas atendendo ao pedido do Dan Languile, trocamos o nome. Questões internas, não vale a pena discutir e não é nenhum problema para nós. É o grande evento da comunidade nacional e tem tudo para ser referência em toda a América do Sul e é também um dos maiores eventos de usuários de PostgreSQL do mundo. Ele não é voltado para novatos, é voltado para quem já trabalha ou esta avaliando seriamente a possibilidade de trabalhar com o PostgreSQL. Aqui o nível das palestras vai de intermediário para avançado, passando por uma sala reservada aos Hackers onde o nível é para quem quer fazer coisas realmente divertidas.

<mimimi mode ON>
No ano passado a organização do PGCon Brasil 2009 tomou muito do meu tempo assim como o tempo de muitos outros como o Euler Taveira, Diogo Biazus, Leonardo Cezar, Fernando Ike, Marcelo Costa, a equipe da 4Linux e muitos outros mais. Mas houve algo curioso em 2009, que não houve nas outras 2 edições do evento em 2007 e 2008: pouca repercussão. Antes de depois do evento, vi pouca divulgação, comentários, posts em blogs, fotos, etc. E o mais estranho é que o evento deve defeitos mas não se pode dizer que foi pior que os anteriores, então o que aconteceu? Eu não sei exatamente o que aconteceu, só posso especular aqui. Uma pista é o que houve com muitos organizadores este ano: eu, Euler, Fike e Diogo, nos afastamos um pouco da comunidade. E isto teve um peso forte. Mas nós temos trabalhado juntos há alguns anos, o que houve? Bom, quando começamos, o PostgreSQL era quase um hobby para alguns de nós, hoje começa a ser meio de vida. Isso acontece em várias comunidades, eu vi isso claramente aqui no PSL-ABCD. Veja que por outro lado, este anos foram 3 palestrantes brasileiros no PGCon 2010, lá no Canadá! O nível tem crescido, e o nosso tempo disponível está indo para o ralo. De toda forma, depois de ralar muito, ver uma repercussão baixa após o PGCon 2009 também me desanimou um pouco.
<mimimi mode off>

O que aprendemos no passado

• A burocracia é nosso inimigo número 1. Projeto de captação, contratos de patrocínio, notas fiscais, as inscrições, notas de empenho, prestação de contas, etc, etc, etc. Conseguir tirar esta parte burocrática da frente é uma meta que pode mudar tudo. A burocracia é o nosso maior inimigo. Ele nos leva ao próximo ponto:
• As inscrições não podem ser realizadas pela comunidade. Receber dinheiro dá muito trabalho e fazer isso do jeito certo dá um absurdo de trabalho. Se tivéssemos patrocinadores em abundância, seria muito, mas muito mais fácil não cobrar nada. Não se trata apenas de ter um bom sistema para fazer as inscrições (coisa que o Euler fez do zero), não se trata apenas de ter banco, nota, recibo, documentação, etc. Se trata de ter alguém que atenda a meleca do telefone o tempo todo e resolva as dúvidas, encaminhe os processos bizarros de alguns órgãos públicos e suas notas de empenho from hell.
• Patrocínio em troca de serviços é um bom negócio. Ao invés de receber dinheiro, receber o serviço. Foi assim com os brindes (canecas, pins, chaveiros, etc), com o credenciamento e com o Coffee Break. Tira uma boa parte da carga de burocracia e preocupação das nossas costas.
• Começar a organização com pelo menos um ano antes e adiantar ao máximo as coisas no começo, garante que o evento saia, pois:
  • Reservar auditório com menos de 6 meses de antecedência é quase impossível, com 12 meses também não é tão fácil assim;
  • Ter o plano de captação pronto, com local e data definidos com mais de 6 meses de antecedência torna possível conseguir patrocínio. Com isso na mão, muitas portas vão bater na sua cara, mas outras vão se abrir. Sem isso, só na base da amizade mesmo, nem pense em órgãos públicos;
  • Os palestrantes internacionais precisam se agendar com muita antecedência e comprar passagens adiantado sai bem mais barato;
  • Com local, data e plano de captação prontos com um ano de antecedência, você tem tempo de se dedicar aos zilhões de detalhes que vão surgir nos 6 meses que antecedem o evento;
  • As inscrições tem de abrir cedo, para você começar a ter dinheiro em caixa cedo.
• O valor das incrições tem de cobrir pelo menos os dois maiores custos do evento: a locação dos auditórios e o coffee-break.
• Receber dinheiro de patrocinadores estrangeiros é um inferno. Então peça a eles que ajudem no pagamento de viagens de palestrantes internacionais;

Que venha o PGBR 2011!

Bom, e porquê o PGBR 2010 não deu certo? De certo não vale a pena entrar nesta questão. Pessoas, trabalharam muito para tentar organizar o evento mas isso não foi sificiente. A única coisa realmente óbivia é que a organização começou muito tarde. Mas de fato houveram pessoas que trabalharam bastante e imagino o quanto elas estejam frustradas agora. Muito mais do que aqueles que já aguardavam com expectativa o evento deste ano.

Agora é hora de pensar em 2011 e nos PGMettings e PGDays que podemos fazer em breve. Não temos tempo para ficar se remoendo mais, já estamos em cima da hora para começar o PGBR 2011. O mercado de PostgreSQL está crescendo, com o 9.0 está aparecendo um novo Standby em cada esquina. Vamos que vamos gente, que atrás vem muita gente!

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;