Práticas de backup da Velha Escola (Clone Database)

 

Clonando seu banco de dados

É público e notório que atualmente, na era 11G – e até podemos dizer era Grid Control -, as estratégias de backup e de recover ficaram muito mais simplificadas, pois com alguns poucos clicks já é possível ter uma rotina de backup agendada em seu ambiente. Mas ainda há quem goste de escrever as boas e velhas linhas de comando, uns como uma forma de não esquecer, uma espécie de exercício para a memória, outros como forma de aprendizado mesmo, para que numa determinada ocasião, quando o ambiente "gráfico" lhes faltar, não sejam pegos "de calças na mão".

Pois bem, então podemos dizer que atualmente basta você definir uma boa e sólida estratégia de backup, e com ela em mãos batalhar para melhor implementar em seu ambiente, a fim de proporcionar aos seus superiores e ao negócio da sua empresa uma maior disponibilidade e segurança de dados, o que nos dias de hoje é, sem dúvida alguma, a menina dos olhos de muitas empresas.

Bem, tendo dito isso, vamos ao assunto de hoje: a clonagem de banco.
Conceito: consiste em um processo em que teremos um ambiente de produção e um suposto ambiente (o Clone), que será gerado a partir do ambiente principal, tornando-se, assim, bases idênticas em termos físicos (datafiles e arquivos de dados) e lógicos (linhas contendo informações sobre seus objetos etc), ou podemos ainda conceituar como cópia fiel de produção pra uma finalidade qualquer (Teste, Homologação, Desenvolvimento, Laboratório, Stress Test etc).

Então vamos dividir as etapas desse processo. Mas, antes, vou esclarecer uma dúvida bem comum: quando devo clonar meu banco? E quantas vezes posso fazer isso?

A resposta é bem simples: desde que não gere estresse em seu ambiente principal, pois precisaremos de uma cópia desse mesmo ambiente, você pode fazer a qualquer momento; já no que diz respeito a quantas vezes podemos fazer, isso vai depender do quanto de espaço físico em disco você tem no servidor onde hospedará seu clone.

Muito bem, respondido esse questionamento básico, vamos ao processo.

"Humm… ainda não me convenci da necessidade de Clonagem por esse método, eu posso usar import e export?"

Sim, claro que pode, esse é um outro método de clonagem, só que temos que levar em consideração o tempo que seria gasto no preparo do ambiente (criação de banco de dados, estrutura de datafiles e tablespaces, criação de usuários, permissões, recompilações de objetos, etc.), ou seja, um processo mais demorado. Se você contar com tempo de sobra, pode executar dessa maneira, até mesmo para adquirir um know-how e visão estatística de quanto tempo leva um processo e comparar com o outro.

Aos olhos dos iniciantes, na minha época, era meio difícil imaginar um Junior clonando uma base de dados, e eu, como todo bom e sábio Junior, não me metia nessas enrascadas, exceto quando não era em produção. Mas para que fique bem claro para todos os níveis, uma tarefa bem executada com respaldo técnico e com uma boa documentação tem mínimas, senão nenhuma, chances de sair com algo errado, por isso, para aqueles que nunca fizeram isso, eu recomendo, no máximo você vai pecar uma ou duas vezes em uma primeira tentativa até acertar 100%, é pra isso que servem os erros, pra nos ensinar a não errarmos mais.
Bom, filosofias à parte, vamos ao processo.

Step by step do procedimento de clonagem

a) Faça um backup full do seu banco de origem.
b) Verifique se há disponibilidade de espaço físico no seu ambiente destino.

c) Transfira dados, conjunto de arquivos do seu banco origem (redos,controls e datafiles), para o seu ambiente destino, obedecendo à mesma estrutura do ambiente de origem, isso pode ser feito por meio de FTP, XCOPY, ou até mesmo pelo famoso OCOPY, lembrando que uma cópia consistente deve ser feita com seu ambiente em modo offline, ou seja faça um shutdown em seu ambiente origem e realize as cópias, assim você evita que o Oracle esteja usando algum recurso no momento da cópia. Você pode obter as informações do que você deve copiar através das visões V$DATAFILE, V$LOGFILE e V$CONTROLFILE. Com essas informações em mãos, você monta uma espécie de checklist para, ao final do processo, fazer uma verificação se tudo foi copiado conforme a origem.

d) Altere os arquivos relacionados à parte de conectividade Oracle, para que eles apontem para o seu novo ambiente (hostname, port, SID e no caso de quem usa DOMINIO o nome correto do novo domínio). São eles: LISTENER.ORA e TNSNAMES.ORA. Aos fãs da padronização de ambiente e instalação OFA, os arquivos citados neste item podem ser encontrados no diretório ORACLE_HOME/network/admin.

e) Atenção: Altere o arquivo de inicialização ( init.ora ), para que reflita exatamente em sua parametrização no seu novo ambiente; atente para os seguintes parâmetros DB_NAME, CONTROL_FILES,BACKGROUND_DUMP_DEST, USER_DUMP_DEST e LOG_ARCHIVE_DEST.

f) Você vai precisar recriar o arquivo de controle (CONTROLFILE), caso queira mudar o nome da instância DESTINO. Veremos como proceder em seguida.

g) E, por fim, inicialize seu novo ambiente.

Como criar seu ControlFile

Os motivos pelos quais devemos recriar o controlfile são:

  • para alterar o nome do banco de dados
  • quando todos os arquivos de controle se perderem: esse motivo é, obviamente, muito relevante, pois é no arquivo de controle, como o próprio nome diz, que o Oracle busca as diretrizes do que tem, de onde está e de como está, ou seja é o primeiro acesso feito pelo Oracle onde há os ponteiros e "ids", dos seus arquivos que compõem seu Banco de Dados. Caso você tenha perdido um arquivo de dados, como algum referente a Tablespace, basta que você coloque o mesmo em modo OFFLINE e seu banco abrirá. Note que, neste caso, foi um arquivo de dados perdido e não um ControlFile. Para efeito de informações, o Oracle suporta apenas um ControlFile disponível para abrir seu ambiente, por isso é de extrema importância manter os ControlFiles multiplexados (divididos em discos distintos), e também sempre realizar backups periódicos do seu ControlFile. Há outras maneiras de contornar essa situação de perda de ControlFile, não tão ortodoxas, mas que servem também em determinadas situações.
  • para reinicializar parâmetros como MAXLOGFILES, MAXDATAFILES,MAXLOGMEMBERS etc.

Vejamos então como proceder para a recriação dos arquivos de Controle. É importante ter o conhecimento estrutural de seu ambiente para saber exatamente onde estão os arquivos, quais os nomes etc. É possível fazer isso por meio de um tracing do seu controlfile. 

"Opa, peraí, mas trace não é para avaliar a performance do banco? Para identificar problemas com querys ou de parametrizações?"

Correto. Os arquivos de trace têm inúmeras funcionalidades, por isso temos estruturas próprias para cada tipo de trace gerado pelo seu banco de dados; basta lembrar dos diretórios UDUMP, BDUMP, CDUMP etc, cada um tem sua finalidade em armazenar arquivos de trace gerados por razões distintas e segregadas.

Bom, voltemos ao nosso processo de reiniciação. Para gerar um trace do seu arquivo de controle, deve ser executada a seguinte instrução:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Essa opção irá gerar, dentro do diretório USER_DUMP_DEST, um arquivo com a nomenclatura padrão de trace, contendo as informações do seu ambiente.

Podemos também gerar esse mesmo trace, para essa mesma finalidade, só que determinando um nome especifico para ele, até para efeitos de melhor identificação, basta que coloquemos a seguinte instrução:

ALTER DATABASE BACKUP CONTROLFILE TO 'CAMINHO DETERMINADO';

Bom, feito isso, nosso arquivo de trace contendo o nosso backup ficará com a seguinte cara:

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORADB" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/redo/oradb/redo01.log'  SIZE 50M,
  GROUP 2 '/redo/oradb/redo02.log'  SIZE 50M,
  GROUP 3 '/redo/oradb/redo03.log'  SIZE 50M
DATAFILE
  '/oradata/oradb/system01.dbf',
  '/oradata/oradb/undotbs01.dbf',
  '/oradata/oradb/sysaux01.dbf',
  '/oradata/oradb/users01.dbf',
  '/oradata/oradb/example01.dbf'
CHARACTER SET WE8ISO8859P1
;

É aqui que entra uma pequena intervenção, caso seja necessário recriar o ambiente destino com um nome diferente do seu ambiente de origem, pois onde se lê REUSE DATABASE "ORADB" devemos colocar SET DATABASE "ORADB2". Com isso, recriaremos o próximo banco com o SID igual a ORADB2, ficando assim:

CREATE CONTROLFILE SET DATABASE "ORADB2" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/redo/oradb2/redo01.log'  SIZE 50M,
  GROUP 2 '/redo/oradb2/redo02.log'  SIZE 50M,
  GROUP 3 '/redo/oradb2/redo03.log'  SIZE 50M
DATAFILE
  '/oradata/oradb2/system01.dbf',
  '/oradata/oradb2/undotbs01.dbf',
  '/oradata/oradb2/sysaux01.dbf',
  '/oradata/oradb2/users01.dbf',
  '/oradata/oradb2/example01.dbf'
CHARACTER SET WE8ISO8859P1
;

Note a sutil diferença em ambos, é apenas uma palavra que irá determinar se os seus bancos serão Gêmeos Idênticos ou não, isso apenas em nível de nomenclatura.

Feitas as modificações em seu arquivo de trace, você precisa criar o arquivo de controle com a sua instância em modo NOMOUNT, veja abaixo:

$sqlplus "/as sysdba"
SQL>startup nomount
SQL>@controlfile_ORADB2.sql
SQL>alter database open resetlogs;

Uma vez criado o arquivo de controle, você deve abrir sua instância com a opção de ResetLogs, para que o Oracle redefina os SCN’ (System Change Number) dos arquivos de logs (redo ). É nesse momento também que você pode aproveitar para alterar seus parâmetros de MAXDATAFILES, MAXLOGMEMBERS etc