PGBR2011 – Inscrições abertas!

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, :-P

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.

PGDay RS no dia 19 de agosto de 2011

O pessoal de RS se mexeu e mais um PGDay RS estará ocorrendo este ano. Será no dia 19 de agosto (sexta-feira) em Porto Alegre.

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?

PGBR2011 – Chamada de trabalhos

Nesta semana foi aberta a Chamada de Trabalhos do PGBR2011.

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…

Clonando bases no ORACLE RAC 10G

Eu sempre fui fã do backup feito na mão. Gosto de ter controle do processo, adaptar um script para demandas específicas etc e tal. Mas quando utilizamos o Oracle RAC, em geral estamos utilizando o ASM e neste caso, a unica forma de se fazer backup físico é pelo RMAN.

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

SQLALTER 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:

  1. Você vai rodar o duplicate no servidor onde está a base de testes. Então precisa configurar o tnsnames.ora para a produção neste servidor. Configure para se conectar em um nó apenas.
  2. Você vai ter que tomar mais cuidado ainda no FILE_NAME_CONVERT.
  3. Você vai ter de criar os logs de REDO no próprio comando DUPLICATE.
  4. Você provavelmente vai pegar o backup da fita, então pegue a string de conexão do backup, mas altere o canal (channel em inglês) para auxiliar.
  5. Você vai poder apagar o tablespace UNDO do nó 2 que você não vai precisar.
  6. Você vai ter de tomar um mega cuidado com os archives. Quando o DUPLICATE roda com a produção e testes no mesmo servidor, nós configuramos o archive_dest da base teste igual ao da base de produção e não nos preocupamos mais com isso. Agora estão em servidores diferentes…

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" &lt;&lt;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

 

PGCasts

 

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.