Menu de navegação

[Edgar Rombesso RisolaParticipant]

Boa tarde amigos…
Tenho um ambiente de produção e preciso clonar o banco de dados para o ambiente de homologação. IP´s e Hostnames diferentes. Qual a melhor maneira de fazer isso?

PRODUÇÃO:
IP: 192.168.5.10
HOSTNAME: BDPROD

HOMOLOGAÇÃO
IP: 192.168.10.15
HOSTNAME: BDHOM

Ambiente de ambos é Oracle 10g Standard

[José Laurindo ChiappaModerator]

Opa, blz ? Pra gente poder te indicar algo mais concreto e te dar respostas mais focadas, plz nos diga/confirme :

a) vc TEM CERTEZA que é mesmo o database prod ** todinho ** que vc quer ter na máquina HOMO ? Pois em muitos casos as tabelas/índices da aplicação tão concentrados num usuário de banco X, que é o dono dos objetos da aplicação : SE é esse o seu caso E SE o volume é factível, talvez se possa criar um banco Vazio no servidor HOMO e enviar para esse banco apenas um dump, uma “cópia” dos dados desse schema/usuário dono em PROD, via datapump/export

b) estamos supondo aqui vc vc não possui produtos / utilitários que trabalham com clone, seja por parte do storage (exemplo, SnapClone em storages da NetApp) seja por parte da aplicação (exemplo, rapidCLONE para Oracle E-Business Suite)

c) se for realmente o banco Todo que vc quer ter em Homo (porque, digamos, há múltiplos schemas com objetos, ou seja qual for o motivo), o mais indicado necessariamente é o comando de DUPLICATE na ferramenta Oracle RMAN (que é parte integrante do RDBMS Oracle), e em sendo banco 10g nós de cara já sabemos que o procedimento VAI envolver a feitura de um backup em PROD e o restore desse backup no servidor HOMO, já que só no 11g foi introduzido o DUPLICATE ONLINE…
Para que possamos te orientar nesse backup e no posterior restore nos diga :

1) a versão do software RDBMS Oracle instalada nos dois servidores é Rigorosamente a mesma ? Qual é essa versão, Detalhamdamente ?
2) o hardware (ie, qtdade de RAM, processadores, espaço em disco, tipo de I/O, wordsize – ie, se 32 ou 64 bits) é o mesmo nos dois servidores ?
3) o Sistema Operacional é exatamente o mesmo ? Qual é Exatamente esse SO, falando nisso ?
4) os diretórios de destino dos datafiles, controlfiles, logfiles, etc, do database a ser clonado são os mesmos ?
5) vc quer esse backup ONLINE/HOT (ie, com o banco Ativo, e portanto em archive mode) ou OFFLINE/COLD (ie, vc tem janela de indisponibilidade aonde pode baixar o banco PROD durante o backup) ?
6) vc tem espaço em disco para gerar o backup em PROD, e depois em HOMO para copiar os arqs desse backup pra lá ?

Com essas respostas podemos te orientar melhor, mas um overview mais ou menos geral do processo vc acha em http://www.akadia.com/services/ora_duplicate_database_rman.html : no exemplo é em linux, mas o processo geral é mais ou menos o mesmo pra Windows…

[]s

Chiappa

[Edgar Rombesso RisolaParticipant]

Opa..blz…vamos lá…

Tenho o ambiente de produção um Banco de Dados Oracle 10g e uma Aplicação Reports Server e Forms…ambas trabalham juntas me proporcionando uma interface web para a aplicação que gera as informações armazenadas no BD.

Criei do zero o mesmo ambiente em outros dois servidores e a aplicação está rodando normalmente, porém, o banco de dados está vazio, todas informações imputadas no ambiente de produção no dia a dia não constam. Como desejo utilizar este ambiente de homologação para verificar atualizações e possíveis erros na aplicação, o conteúdo do dia-a-dia existente no BD é muito importante para testes reais…logo, quero não o conteúdo de um Schema…e sim todo o banco mesmo…

1 – A versão é rigorosamente a mesma, inclusive os diretórios de instalações. Oracle 10g Standard – Versão 10.2.0.5

SQL> select * from v$version;

BANNER
—————————————————————-
Oracle Database 10g Release 10.2.0.5.0 – 64bit Production
PL/SQL Release 10.2.0.5.0 – Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 – Production
NLSRTL Version 10.2.0.5.0 – Production

2 – O Hardware do ambiente de homologação é consideravelmente menor e é virtualizado.
Produção: Suse Linux Enterprise 10 64 Bits / 256GB RAM / 600GB de Espaço em disco em Storage podendo aumentar / Oracle 10.2.0.5 x86_x64

3 – SO exatamente o mesmo – Suse Linux Enterprise 10 64 Bits

4 – Todos diretorios de destinos são os mesmos.

5 – HOT

6 – Espaço em disco disponível para gerar o backup full na produção e copiar na homologação.

7 – Nome da instância é a mesma em ambos ambientes.

8 – Só mudam os IP´s e Hostnames.

[José Laurindo ChiappaModerator]

Bom, se vc tem ** ABSOLUTA CERTEZA ** que a sua Aplicação não centraliza os objetos num schema só, aí Realmente fica mais recomendado o clone mesmo…
Muito bem, já que vc tem backup HOT hoje, com certeza vc está rodando em modo ARCHIVE, e vc não diz mas assumo que é um backup RMAN… Já que o Sistema Operacional é rigorosamente o mesmo, E em ambos os locais é 64-bits, E a versão/edição do software RDBMS é 10.2.0.5 STANDARD em ambos, vc não deve ter nenhum problema em restaurar o backup que vc vai tirar em PROD no servidor HOMO.
O clone via RMAN poderia ser feito pelo DUPLICATE, mas já que os diretórios tão iguaizinhos, E que vc diz que o servidor destino é uma máquina virtual (que provavelmente o servidor PROD não pinha/acessa, elas estão em sub-nets diferentes, imagino) , acho que o melhor seria BACKUP em PROD e restore em HOMO.
Em linhas gerais, o procedimento vai ser :

a. gera um BACKUP DATABASE PLUS ARCHIVELOG em produção, gravando em disco, E assegurando-se que no RMAN o AUTOBACKUP de controlfiles está Ativo
b. transfere os arquivos desse backup pro servidor HOMO, via FTP, XCOPY ou o que vc tiver/puder
c. no servidor destino vc sobe em NOMOUNT a instância
d. via RMAN vc restaura o controlfile
e. cataloga no RMAN os arquivos desse backup, com o comando CATALOG START WITH
f. pede o RESTORE do database, e depois o RECOVER

e é isso, http://www.oracledistilled.com/oracle-database/restore-database-to-another-host-using-rman/ é um exemplo… No seu caso, porpem, já que vc não quer/não precisa alterar o PATH de nenhum arquivo, vc simplesmente PULA os RENAMEs/SET NEWNAMEs todos, e já que vc quer ter o novo banco restaurado no último SCN do backup (E, imagino, vc tem TODINHOS os archives necessários em PROD), vc não precisa usar o RECOVER UNTIL scn, mas sim simplesmente o RECOVER UNTIL CANCEl…

[]s

Chiappa

OBS : veja que em monento algum eu falei de IP nem de HOSTNAME – isso porque para o funcionamento DO DATABASE é absolutamente Indiferente tanto o IP quanto o hostname, isso não é usado no funcionamento do database… O que vc vai ter que alterar depois é a CONFIG DE REDE da tua aplicação, para que o TNSNAMES.ORA e os arqs de config da aplicação acessem pelo novo IP ou hostname…

[Edgar Rombesso RisolaParticipant]

Então…sim..é via RMAN o backup e tenho também dump via expdp….via RMAN não tem o catalogo…somente o acesso é via rman target /
O servidor de produção não acessa homologação pois estão em subnets diferentes mesmo…inclusive na produção, o BD e o APP são também subnets diferentes…
Sim…o archivelog está ativado…e o autobackup dos controlfiles tb…

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 5 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/u1/backup/%U’;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u1/backup/snapsi3.cf’;

Tanto o ambiente de produção quanto homologação estão com essas configurações no rman.

Devo então copiar os arquivos que são direcionados ao diretório “/u1/backup” do ambiente de produção e direcionar a copia efetuada também para o mesmo diretório no ambiente de homologação?

Todo esse procedimento via rman? um expdp e impdp não resolveria??

[José Laurindo ChiappaModerator]

Então, a questão de não recomendar o export/import, como eu disse antes, é muito mais questão de performance, pois ele vai primeiro extrair via SQL os dados pra depois os inserir num arquivo de dump, que depois de trabsferido no destino vai ser lido novamente, os SQLs vão ser remontados e executados no banco-destino que vai estar vazio – via de regra é mais rápido vc só transferir os arquivos do banco, que NÂO PRECISAM sofrer formatação SQL (é cópia física) – do que fazer todo o trâmite… Por isso, pensando em performance, é que anteriormente eu só indiquei export/import em volume pequeno e preferencialmente se todos os objetos tão num schema só….
E lembro também que esse banco-destino onde vc vai importar o dump file *** TEM *** que ter sido criado manualmente por vc antes, o export/import NÂO O CRIA, sim sim ??? ENtão imho acho mais simples o clone físico, Mas sim, tecnicamente falando se vc já tem o banco-destino já criado vazio (ou se o criar rapidinho com o Assistente apropriado) E os diretórios são todos iguaizinhos nas duas máquinas SIM, vc poderia fazer um export FULL do banco-origem e um import full nesse banco-destino, que ele já criaria as tablespaces, os usuários e seus dados todos : a PERFORMANCE provavelmente seria inferior mas funciona, “resolve” o problema, sim…

de resto : Não, o RMAN ** não tem ** comandos para transferir arquivos entre máquinas, vc é que vai ter que (via FTP prum ftp server que vc tenha acessível e que enxergue as duas máquinas, ou copiando prum HD removível ou pruma fita, enfim, o que vc tiver de recurso) manualmente transferir os arquivos desse backup pro servidor HOMO, sim…. Inclusive, se vc fosse optar pelo datapump, vc Também IA TER QUE, de qualquer maneira, transferir o DUMP FILE gerado lá pro servidor destino…
O diretório lá na máquina-destino é indiferente, mas se for o mesmo que em prod vc poupa o trabalho de fazer o CATALOG START WITH, já que o registro de backups dentro do controlfile vai já estar apontando pro diretório correto…

[]s

Chiappa

[Edgar Rombesso RisolaParticipant]

Então…
O Faço um expdp do banco de produção e um impdp no banco de homologação…só estou na duvida de uma coisa…vc disse que ele iria recriar tablespaces? mas no banco de homologação toda estrutura fisica já existe e está igual ao de produção…algum problema nesse processo?

Se eu fizer via rman…vc tem algum script? digo..pois irei precisar refazer todo o processo ao menos semanalmente…

[José Laurindo ChiappaModerator]

Xo ver se consigo te esclarecer : quando vc faz um export full, além dos CREATE TABLEs/CREATE INDEX/etc pra criar os objetos do database e dos INSERTs com os dados o dump file resultante vai ter ** TAMBÉM ** os CREATEs para a criação dos itens gerais de um database, como TABLESPACES (que, como imagino que vc sabe, é um objeto LÓGICO dentro do database, composto pelos datafiles físicos que estão nos diretórios de dados), DATABASE LINKs, CREATE USERs pra criar os usuários/schemas…. A idéia é, como eu disse, que o database destino, aonde o dump file vai ser importado, está criado mas vazio, então normalmente esses itens gerais todos são necessários estar contidos no dump file para se ter um banco-destino SIMILAR ao banco origem, por isso o export full os bota no dumpfile…
E veja que eu disse *** CRIAR ***, e não recriar : se o seu banco destino não está vazio e portanto já contém TABLESPACEs, DATABASE LINKS, USERS, etc, que podem estar diferentes do que existe em prod, vc tem que APAGAR esses que existem para que o import os possa CRIAR tal como estavam na origem : para tabelas e objetos pertencentes a schemas vc pode usar o parâmetro TABLE_EXISTS_ACTION com a opção de REPLACE que ele já os apaga antes de importar, mas para alguns objetos gerais a nível de banco vc teria que fazer o DROP deles manualmente antes do import…. Não vejo nenhum Impedimento em se fazer isso, mas Necessariamente o TEMPO gasto pra isso se acumula com o resto do tempo gasto pelo import, novamente caímos na questão de PERFORMANCE – Obviamente, só vc sabe se esse overhead todo do export+eventuais drops+import é Significativo pra vc ou não…

Falando disso aliás, fica Evidente também ainda Outra questão que surge quando se usa export/import para refresh frequente : essa ferramenta Não É Incremental, então a cada vez que vc executa um export ele dumpa ** TUDO **, conjunto completo, Não tem Como vc fazer algum tipo de incremental : ESSA é uma vantagem do RMAN, como solução de backup que é vc Pode fazer backups (e RESTOREs, claro) incrementais….

Para automatizar via script, basicamente é colocar os comandos necessários num arquivo .CMD, com os CONFIGURE antes e os comandos efetivos de backup em blocos RUN {} , e na hora de chamar o RMAN vc icnlui o parâmetro CMDFILE=nomedoseuarquivo.CMD, é basicamente isso : tenta aí e eventuais probs nos mostra como está o seu script que a gente tenta palpitar em cima ….

[]s

Chiappa

[José Laurindo ChiappaModerator]

Opa, blz ? Eu obtive um ambiente teste aqui e vou te Exemplificar mais ou menos como seria os scripts que vc vai ter que implementar para ter automatizado o backup e o restore, mas ** nem preciso dizer ** que :

a) isto é só uma PROVA DE CONCEITO, de forma ALGUMA vc pode fazer um copy/paste disto em produção : entre outras coisas,esta rotina mega-simplória NÂO prevê backup incremental, NÃO gera arquivos com nomes diferentes a cada execução, Não prevê casos onde os backups dos archives esteja em outro local E/ou archives anteriores tenham sido removidos….

b) assumi aqui que o servidor HOMO/destino já está com o software do RDBMS Oracle corretamente instalado e configurado, com as vars de ambiente necessárias, tudo certinho, ** E ** (IMPORTANTE!!) assumi que nenhum parâmetro de hardware (por exemplo, tamanho da RAM a ser usada no banco, número de processos, etc) precise ser alterado com o hardware “menor” que vc diz que tem na VM que vai ser homo…

c) o IP e o hostname diferente, como eu disse antes, só influenciam para configurações gerais ** FORA DO BANCO **, como arquivos TNSNAMES.ORA, LISTENER do banco, etc – o banco em si é COMPLETAMENTE IMUNE a mudanças do tipo… Não coloquei essas alterações no script pois isso vc faz uma vez só…

d) pra agilizar aqui, já que meu banco é Enterprise Edition, vc verá que estabeleci paralelismo – iirc no Standard Edition, capadinho e restrito que é, vc não deve ter isso, ajuste….

Isso claro, segue o exemplo :

=> na máquina “PROD”, veja como criei os scripts de backup :

[oracle@localhost oracle]$ cat backup_full.sh
export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/db11204
export ORACLE_SID=orcl
export PATH=$ORACLE_HOME/bin:$PATH
rman target=/ nocatalog log=backup_full.log cmdfile=backup_full.cmd

[oracle@localhost oracle]$ cat backup_full.cmd
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO “/media/sf_jlchiappa/bkp/ctl_%F”;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 3;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT “/media/sf_jlchiappa/bkp/bkp_full_%u_%s_%p” MAXPIECESIZE 2048 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
run {
backup database plus archivelog;
}
exit;

===> Vou executar manualmente mas OBVIAMENTE, para Automatizar vc Iria rodar esses scripts dentro do CRON, do AT ou coisa do tipo, claro :

[oracle@localhost oracle]$ /oracle/backup_full.sh

RMAN> 2> 3> 4> 5> 6> 7> 8> 9>

===> em outra janela , consulto o andamento – aproveito para verificar o DBID do banco PROD, que vai ser usado no RESTORE :

[oracle@localhost oracle]$ cat backup_full.log

Recovery Manager: Release 11.2.0.4.0 – Production on Fri Jul 1 11:33:31 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

connected to target database: ORCL (DBID=1229390655)
using target database control file instead of recovery catalog

….
Starting backup at 01-JUL-16
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/home/oracle/app/oracle/oradata/orcl/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at 01-JUL-16
channel ORA_DISK_2: starting full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/home/oracle/app/oracle/oradata/orcl/system01.dbf
input datafile file number=00007 name=/home/oracle/cr_data_01.dbf
input datafile file number=00006 name=/home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf
channel ORA_DISK_2: starting piece 1 at 01-JUL-16
channel ORA_DISK_3: starting full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00003 name=/home/oracle/app/oracle/oradata/orcl/undotbs01.dbf
input datafile file number=00004 name=/home/oracle/app/oracle/oradata/orcl/users01.dbf
input datafile file number=00005 name=/home/oracle/app/oracle/oradata/orcl/example01.dbf
channel ORA_DISK_3: starting piece 1 at 01-JUL-16
……. blablanla, segue até o final, e quando acabou o backup de banco, Sozinho ele vai fazer o AUTOBACKUP :

channel ORA_DISK_1: finished piece 1 at 01-JUL-16
piece handle=/media/sf_jlchiappa/bkp/bkp_full_1jr9jop7_51_1 tag=TAG20160701T114023 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 01-JUL-16

Starting Control File and SPFILE Autobackup at 01-JUL-16
piece handle=/media/sf_jlchiappa/bkp/ctl_c-1229390655-20160701-00 comment=NONE
Finished Control File and SPFILE Autobackup at 01-JUL-16

Recovery Manager complete.
[oracle@localhost oracle]$

================> no servidor HOMO, com os arquivos já transferidos (via FTP no meu caso, mas aí vc teria que usar o recurso que tivesse, como por exemplo transferir prum internet disk, prum HD externo, o que for), E com as variáveis de ambiente corretas, E com os diretórios todos Iguaizinhos :

=> veja que os arqs de backup estão OK :

[oracle@localhost oracle]$ ls -ltr /media/sf_jlchiappa/bkp
total 4602263
-rwxrwx— 1 root vboxsf 703777792 Jul 1 11:34 bkp_full_1er9joce_46_1
-rwxrwx— 1 root vboxsf 770240512 Jul 1 11:35 bkp_full_1cr9joce_44_1
-rwxrwx— 1 root vboxsf 27738112 Jul 1 11:35 bkp_full_1fr9jof3_47_1
-rwxrwx— 1 root vboxsf 771342336 Jul 1 11:35 bkp_full_1dr9joce_45_1
-rwxrwx— 1 root vboxsf 349364224 Jul 1 11:38 bkp_full_1ir9jofb_50_1
-rwxrwx— 1 root vboxsf 918798336 Jul 1 11:39 bkp_full_1hr9jofb_49_1
-rwxrwx— 1 root vboxsf 1161248768 Jul 1 11:40 bkp_full_1gr9jofb_48_1
-rwxrwx— 1 root vboxsf 81408 Jul 1 11:40 bkp_full_1jr9jop7_51_1
-rwxrwx— 1 root vboxsf 10125312 Jul 1 11:40 ctl_c-1229390655-20160701-00
[oracle@localhost oracle]$

=> veja os scripts presentes :

[oracle@localhost oracle]$ cat restore_spfile.sh
export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/db11204
export ORACLE_SID=orcl
export PATH=$ORACLE_HOME/bin:$PATH
rman target=/ nocatalog log=restore_spfile.log cmdfile=restore_spfile.cmd

[oracle@localhost oracle]$ cat restore_spfile.cmd
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO “/media/sf_jlchiappa/bkp/ctl_%F”;
SET DBID 1229390655;
startup nomount;
RUN {
RESTORE SPFILE FROM AUTOBACKUP;
}
exit;

[oracle@localhost oracle]$

==> posso portanto restaurar o spfile – Repito, executo aqui o script manualmente, mas no seu caso seria via CRON ou similar :

[oracle@localhost oracle]$ /oracle/restore_spfile.sh

=> após o script ter executado :

[oracle@localhost oracle]$ cat restore_spfile.log

Recovery Manager: Release 11.2.0.4.0 – Production on Fri Jul 1 13:54:34 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

connected to target database: DUMMY (not mounted)
using target database control file instead of recovery catalog
…
Starting restore at 01-JUL-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

channel ORA_DISK_1: looking for AUTOBACKUP on day: 20160701
channel ORA_DISK_1: AUTOBACKUP found: /media/sf_jlchiappa/bkp/ctl_c-1229390655-20160701-00
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /media/sf_jlchiappa/bkp/ctl_c-1229390655-20160701-00
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 01-JUL-16

Recovery Manager complete.

==> maravilha, veja os scripts de restore do controlfile (que, como eu tenho o SPFILE ok, vão ser restaurados pro path indicado nos parãmetros correspondentes) :

[oracle@localhost oracle]$ cat restore_controlfile.sh
export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/db11204
export ORACLE_SID=orcl
export PATH=$ORACLE_HOME/bin:$PATH
rman target=/ nocatalog log=restore_controlfile.log cmdfile=restore_controlfile.cmd

[oracle@localhost oracle]$ cat restore_controlfile.cmd
SET DBID 1229390655;
shutdown immediate;
startup nomount;
RUN {
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO “/media/sf_jlchiappa/bkp/ctl_%F”;
RESTORE CONTROLFILE FROM AUTOBACKUP;
}
exit;

==> executo :

[oracle@localhost oracle]$ /oracle/restore_controlfile.sh
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> [oracle@localhost oracle]$

[oracle@localhost oracle]$ cat restore_controlfile.log
…
database name (or database unique name) used for search: ORCL
channel ORA_DISK_1: AUTOBACKUP /oracle/orcl/flash_recovery_area/ORCL/autobackup/2016_03_11/o1_mf_s_906211876_cg5wpn4f_.bkp found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20160701
channel ORA_DISK_1: AUTOBACKUP found: /media/sf_jlchiappa/bkp/ctl_c-1229390655-20160701-00
channel ORA_DISK_1: restoring control file from AUTOBACKUP /media/sf_jlchiappa/bkp/ctl_c-1229390655-20160701-00
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=/home/oracle/app/oracle/oradata/orcl/control01.ctl
output file name=/home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl
Finished restore at 01-JUL-16

Recovery Manager complete.

==> veja que RESTAUROU DIREITINHO :

[oracle@localhost oracle]$ find /home/oracle -name *control*.ctl -ls
229496 9824 -rw-rw—- 1 oracle oracle 10043392 Jul 1 14:08 /home/oracle/app/oracle/oradata/orcl/control01.ctl
753756 9824 -rw-rw—- 1 oracle oracle 10043392 Jul 1 14:08 /home/oracle/app/oracle/flash_recovery_area/orcl/control02.ctl
[oracle@localhost oracle]$

[oracle@localhost oracle]$ find /home/oracle -name *spfile*.ora -ls
789454 16 -rw-rw—- 1 oracle oracle 14848 Jul 1 14:08 /home/oracle/app/oracle/product/11.2.0/db11204/dbs/spfileorcl.ora
[oracle@localhost oracle]$

=> Veja os scripts do RESTORE e RECOVER do banco :

[oracle@localhost oracle]$ cat restore_full.sh
export ORACLE_HOME=/home/oracle/app/oracle/product/11.2.0/db11204
export ORACLE_SID=orcl
export PATH=$ORACLE_HOME/bin:$PATH
rman target=/ nocatalog log=restore_full.log cmdfile=restore_full.cmd

[oracle@localhost oracle]$ cat restore_full.cmd
shutdown immediate;
SET DBID 1229390655;
startup mount;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO “/media/sf_jlchiappa/bkp/ctl_%F”;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 3;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT “/media/sf_jlchiappa/bkp/bkp_full_%u_%s_%p” MAXPIECESIZE 2048 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
run {
restore database;
recover database;
}
exit;

[oracle@localhost oracle]$

==> Agora é só restaurar completamente :

[oracle@localhost oracle]$ /oracle/restore_full.sh

=> uma vez restaurado, só falta reabrir com resetlogs : podia ter colocado isso no script mas vou fazer manualmente :

[oracle@localhost oracle]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 1 14:24:44 2016

Copyright (c) 1982, 2013, Oracle. All rights reserved.

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 456146944 bytes
Fixed Size 1365292 bytes
Variable Size 343935700 bytes
Database Buffers 104857600 bytes
Redo Buffers 5988352 bytes
Database mounted.

SQL> alter database open resetlogs;

Database altered.

SQL>

[]s

Chiappa

[Edgar Rombesso RisolaParticipant]

blz…vou tentar adequar ao meu ambiente…
agora…tentei assim…fiz um expdp full e tentei um impdp na homologação…mas durante a importação ele gerou erros nos objetos dizendo que já existiam…não tem como importar somente o conteudo das tabelas???

[José Laurindo ChiappaModerator]

Bem, se as limitações do datapump (principalmente o fato dele não ter nenhuma possibilidade de incremental, além da performance em si) não te incomedam ok : para que ele não tente recriar a estrutura que já existe, vc usa o parâmetro TABLE_EXISTS_ACTION, veja http://arvindasdba.blogspot.com.br/2014/10/impdp-tableexistsaction-append-replace.html (e a documentação) para refs – com ele vc pode indicar pro datapump apagar os dados que já existiam (opção TRUNCATE) ou para ele Dropar as tabelas que já existem, que serão portanto criadas novamente com a estrutura que veio da produção…. Isso resolve a sua pergunta, ie, como “importar somente o conteúdo”, ok ?

Porém, imho só importar os dados/o conteúdo eu acho que ** NÂO VAI SER SUFICIENTE ** : a não ser vc tenha um banco que nunca muda (acho difícil), o caso é que fatalmente, CEDO OU TARDE vc VAI ter alterações estruturais no database PROD, seja nas suas tablespaces (vão ser adicionados novos datafiles, por exemplo), ou vc vai ter alterações de constraints, triggers, etc, etc : para que as estruturas alteradas sejam criadas no banco-destino como estão em prod, vc ANTES DE IMPORTAR ** TEM ** que zerar o banco-destino, ie, eliminar as tablespaces, usuários, triggers a nível de banco, database links, sinônimos…. Como eu disse antes e Repito, o import de um dump file gerado com a opção FULL serve para vc CRIAR OS DADOS E ESTRUTURAS como estavam em Produção mas ** sem nenhum tipo de incrementação, ele SUPÕE como certo que o banco-destino está Zerado….

[]s

Chiappa

[Edgar Rombesso RisolaParticipant]

Sim…com certeza a estrutura muda…ela e alterada quando aplico patches ja concebidos para essas alterações…e que aplicando estes mesmos na homologação, igualam os ambientes em suas estruturas…sendo que o que fica realmente diferentes são os dados armazenados nas tabelas pois a produção efetuas atendimentos diarios…a homologação não…e esses dados que desejo importar…não preciso me preocupar com a estrutura…so preciso mesmo dos dados…

[José Laurindo ChiappaModerator]

Veja lá : para assumir que as estruturas são sempre as mesmas , vc teria que ter ** absoluta e completa ** CERTEZA de que todas as alterações estruturais feitas em PROD são através dos tais patches ** E QUE ** nunca de forma nenhuma um patch é “esquecido” de ser aplicado em homo… Por exemplo, digamos que a alteração foi adicionar um novo datafile na tablespace X para que tenhamos mais espaço para os dados – OBVIAMENTE, se essa adição não for feita Também em HOMO na hora que o import for trazer os dados a tablespace não vai ter o espaço/tamanho necessário e os INSERTs simplesmente VÂO FALHAR…. Sim sim ?? Idem para alterações ou criações de sinônimos, database links e objetos do tipo que não contém dados em si e por si mas podem ser Exigidos para o correto funcionamento dos INSERTs contidos no dump file… SE vc não estiver 100% certo disso, aí como eu disse o procedimento é dropar TUDO que possa ser usado pela aplicação (ie, tablespaces, datafiles, usuários, dblinks, sinônimos, etc) e deixar i import os recosntruir como estavam em PROD, com a info presente dentro do export full…

Já ** SE ** vc tem Absoluta e Completa Certeza que as alterações/inclusões havidas na estrutura lógica e física do banco PROD estão 100% presentes também em HOMO, aí, como eu disse, é simplesmente pedir pro import ** apagar ** os dados que já existem antes de extrair e executar os INSERTs com dados presentes no dump file , isso se faz com o parâmetro que te indiquei na resposta anterior – vc pode especificar TRUNCATE, que implica que o import vai apagar apenas os dados (o que seria a opção, se vc tem 100% de certeza que não há NENHUMA diferença nas colunas/constraints/etc das tabelas), OU pode pedir REPLACE no parâmetro, que instrui o import a Dropar e fazer novamente o CREATE TABLE de cada tabela antes de trazer os dados… COmo preferir…

[]s

Chiappa

[José Laurindo ChiappaModerator]

Inclusive, imho essa é uma vantagem da opção de se restaurar um backup físico no servidor HOMO : como em um backup físico estamos copiando os arquivos de conteúdo gerais do database (NÂO É só os arquivos de dados, é tudo : nesses arquivos que o RMAN copia estão além dos dados a lista de tablespaces, de usuários, de db links, de sinônimos, tudo de tudo) absolutamente NÂO TEM COMO vc “esquecer” um DDL, uma alteração de estrutura, nem nada assim – vc vai estar trazendo o banco INTEIRINHO,inclusive com objetos/estruturas internas, e não apenas os dados e as estruturas usadas pelos usuários de banco que é o que o export+import faz…

[]s

Chiappa

[Edgar Rombesso RisolaParticipant]

sim…tenho certeza que a estrutura e a mesma pois pois os patchs só são aplicados em produção depois de aplicados na homologação e testados….
Então eu poderia utilizar a opção replace que ele iria dropar uma constraint por exemplo e recria-la e fazer o import do conteúdo das tabelas?? e como seria um exemplo deste comando para um import full de banco??

[Author]

Posts