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

Passo2 – baixar a base no RAC

Passo3 – Apagar a base no ASM

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

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)

  • Alterar os seguintes parâmetros :

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

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

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

No caso abaixo o

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

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:

e rodo ele com o comando:

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

Passo 7 –  Verificar o controlfile gerado:

Passo 8 – Baixar a base

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:

Passo 10 – Subir a base no modo NOARCHIVE

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.

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:

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.

Passo 13 – Habilitar o nó 2

ALTER database enable thread 2;

Passo 14 – baixar a base

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.

Tem de aparecer algo como:

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

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

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:

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:

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:

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:

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

 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *