sexta-feira, 31 de julho de 2009

CLONE DATABASE

Olá pessoal, tudo certo?!?
Bem eu estava revirando alguns livros e artigos que possuo em minha casa, e me deparei com uma documentação bem antiga, da época em que fiz meus cursos de Oracle Database 8i.
O que me chamou bastante atenção foi no capitulo dedicado a BACKUP e RECOVER, onde tinha um subtitulo de CLONE DATABASE, eis que então que me ocorreu a idéia de fazer um post dedicado a esse momento saudoso. Vamos lá então, espero que gostem.

CLONANDO SEU BANCO DE DADOS

É público e notorio que atualmente na era 11g, e até podemos dizer era GRID CONTROL também, que as estratégias de backup e recover ficaram muito mais simplicadas, pois com alguns poucos clicks, já é possivel ter uma rotina de backup agendada em seu ambiente. Mas ainda ha aqueles que gostam de escrever as boas e velhas linhas de comando, uns como uma forma de não esquecer, uma espécie de exercicio para a memória, outros como forma de aprendizado mesmo, para que numa determinada ocasião quando o ambiente "grafico" lhe faltar, não seja pego 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 assim com ela em mãos batalhar para melhor implementar em seu ambiente, afim 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 deste Post, a CLONAGEM DE BANCO.

CONCEITO: Consiste em um processo onde teremos um ambiente de produção e um suposto ambiente ( o Clone), que será gerado apartir do ambiente principal, se tornando assim bases identicas em termos fisicos (Datafiles e arquivos de dados) e lógicos ( linhas contendo informações sobre seus objetos etc e tal), 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 deste processo, opa!!! mas surgiu uma dúvida : QUANDO DEVO CLONAR MEU BANCO? E QUANTAS VEZES EU POSSO FAZER ISSO?
Interessante, mais a resposta é simples, desde que não gere stress em seu ambiente principal, pois precisaremos de uma cópia deste 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 fisico em disco você tem no seu servidor onde hospedara seu clone.

Muito bem, respondido esse questionamento básico vamos ao processo. Hum!!.Ainda não me convenci da necessidade de Clonagem por esse método, eu posso usar IMPORT e EXPORT?
Sim, claro que pode, este é um outro método de clonagem também, 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áriosm permissões, recompilações de objetos, etc e tal), ou seja um processo mais demorado, se você contar com tempo de sobra pode até executar dessa maneira até mesmo para adquirir um know-how e visão estatisticas de quanto tempo leva um processo e comparar com o outro processo.

Aos olhos dos iniciantes na minha época era meio dificil imaginar um Junior clonando uma base de dados, e eu como todo bom e sábio Junior, não me metia nessas enrrascadas, exceto quando não era em produção. Mas para que fique bem claro para todos os níves, uma tarefa bem executada com respaldo técnico e com uma boa documentação, tem minimas senão nenhuma chance de sair algo errado, por isso 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 a 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 fisico no seu ambiente DESTINO.

c) Tranferir os dados , conjunto de arquivos do seu banco origem ( redo's,control's e datafile's), para o seu ambiente DESTINO, obedecendo a mesma estrutura do ambiente de ORIGEM, isso pode ser feito por meio de FTP, XCOPY, ou até mesmo o 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 a parte de conectividade Oracle, são eles, LISTENER.ORA e TNSNAMES.ORA, para que os mesmos apontem para o seu novo ambiente ( hostname, port, SID e no caso de quem usa DOMINIO o nome correto do novo dominio).
Aos fãs da padronização de ambiente e instalação OFA, os arquivos neste item citados podem ser encontrados no diretório ORACLE_HOME/network/admin.

e) **Atenção**: Alterar o arquivo de inicialização ( init.ora ), para que reflita exatamente em sua parametrização no seu novo ambiente, atente para os seguintes parametros 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 instancia DESTINO. Veremos como proceder a seguir.

g) E por fim inicializar seu novo Ambiente.

COMO RECRIAR 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 é óbviamente muito relevante, pois é no arquivo de controle , como o próprio nome diz, que o Oracle busca as diretrizes do que tem, onde esta e como está, ou seja é o primeiro acesso feito pelo Oracle onde há os ponteiros e "id's", dos seus arquivos que compõem seu Banco de Dados, pois caso você tenha perdido um arquivo de dados como por exemplo algum respectivo 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 até 1 controlfile apenas disponivel para abrir seu ambiente, por isso é super e de extrema importancia manter os CONTROLFILES multiplexados ( dividos em discos distintos) e também sempre estar realizando bancups periódicos do seu controlfile. Há outras maneiras de contornar essa situação de perda de controlfile, não tão ortodoxas mais que servem também em determinadas situações.
- para reinicializar parametros como MAXLOGFILES, MAXDATAFILES,MAXLOGMEMBERS e 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 , é possivel fazer isso por meio de um TRACING (rastreamento) do seu controlfile.
OPA PERAI, MAIS TRACE NÃO É PARA AVALIAR A PERFORMANCE DE BANCO? IDENTIFICAR PROBLEMAS COM QUERYS OU DE PARAMETRIZAÇÕES ?

Correto, os arquivos de trace tem inumeras funcionalidades, por isso temos estruturas próprias para cada tipo de Trace gerado pelo seu Banco de dados, basta nos 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 reciação. Para gerar um trace do seu arquivo de controle, deve ser executado a seguinte instrução :

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Esta 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 este mesmo trace, para esta 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 o 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 á ORADB2, ficando então da seguinte forma:

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 serão Gêmeos Idênticos ou não os seus Bancos, isso a níevl apenas 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 como proceder :

$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 instancia com a opção de RESETLOGS, para que o Oracle redefina os SCN's ( System Change Number) dos arquivos de logs ( redo ). É nesse momento tambem que você pode aproveitar para alterar seus parametros de MAXDATAFILES, MAXLOGMEMBERS etc.

E "Congratulations", você acaba de clonar seu primeiro Banco de dados, curta esse momento, é único, e vale muito a pena realizar, pela razões que eu já descrevi aqui e por outras tantas.
Espero que tenham curtido essa viagem no tempo ( Old School) e que apreciem o material.

Abraço á todos.