Menu de navegação

[Edgar Rombesso RisolaParticipante]

Possuo um ambiente de produção e preciso clonar o banco de dados para o ambiente de homologação que é em um servidor diferente. Efetuei um Hot Backup Manual com os seguintes procedimentos abaixo, porém não estou conseguindo restaurar. Como proceder a restauração passo a passo?

PRODUÇÃO:
IP: 10.20.253.10
HOSTNAME: BDPROD
Oracle: Database 10g 10.2.0.5 – 64 bits Standard
Instancia:manprod
S.O: Suse Linux Enterprise 10 R2 64 Bits
Estrutura de diretorios: /u1/oradata/manprod_data/

HOMOLOGAÇÃO
IP: 10.21.253.92
HOSTNAME: BDHOM
Oracle: Database 10g 10.2.0.5 – 64 bits Standard
Instancia:manprod
Estrutura de diretorios: /u1/oradata/manprod_data/

Não possui catalogo RMAN
Não possui ASM
Banco em modo archive
FRA não está setada
Backup para disco
Área livre adicional de 500GB disponível na partição

Procedimentos efetuados:

1. VERIFICACAO DO BANCO EM MODO ARCHIVELOG
SELECT LOG_MODE FROM V$DATABASE;
2. – VERIFICACAO DO NAME DO BANCO
SELECT NAME FROM V$DATABASE;
3. – LOCALIZACAO DOS DATAFILES
SELECT NAME FROM V$DATAFILE;
4. – LOCALIZACAO DOS CONTROL FILES
SELECT NAME FROM V$CONTROLFILE;
5. – IDENTIFICACAO DO NUMERO DO LOG CORRENTE
ARCHIVE LOG LIST;
6. – ALTERACAO DO PRIVILEGIO DO BANCO
ALTER DATABASE BEGIN BACKUP;
7. – VERIFICACAO DO ESTADO DOS ARQUIVOS DE BACKUP
SELECT * FROM V$BACKUP;
8. – COPIA FISICA DOS ARQUIVOS
9. – ALTERACAO DO PRIVILEGIO DO BANCO
ALTER DATABASE END BACKUP;
10. – IDENTIFICACAO DO NUMERO DO LOG CORRENTE APOS O BACKUP
ARCHIVE LOG LIST;
11. – FORCAR O ARQUIVAMENTO DO REDO LOG
ALTER SYSTEM SWITCH LOGFILE;
12. – EFETUAR COPIA DOS LOGS IDENTIFICADOS
13. – EFETUAR COPIA DO CONTROL FILE
ALTER DATABASE BACKUP CONTROLFILE TO ‘/u1/clone/controlfileprod.bak’ REUSE;
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS ‘/u1/clone/controlfileprod.txt’;

OBS* Foram copiados 29 arquivos de datafiles e todos archives logs existentes.

Quais os passos necessários para restaurar este backup no outro servidor, sendo que o nome da instancia e a estrutura de diretórios é a mesma da produção???

[José Laurindo ChiappaModerador]

Blz ? Então, não vou ter tempo hábil pra te escrever um passo-a-passo completinho e mastigadinho (nem é nosso escopo aqui) mas penso que vc pode usar o modelo de restore em http://blogs.adobe.com/shwetank/2011/10/19/manual-backuprestore-of-an-oracle-11gr2-database/ : aqui ele exemplifica o restore na mão de um backup manual feito pelo 11g mas pro 10gR2 (que é seu caso) seria basicamente o mesmo…..
Antes de começar vc só terá que :

a. transferir de PROD para HOMO o initfile do banco, pelo que vi na lista vc não o incluiu no seu backup manual

b. vc diz que já tem uma instância manprod no servidor homo, provavelmente já contendo um database também : para que vc possa restaurar um database na íntegra vc tem que parar essa instãncia (prompt de comando servidor HOMO, sqlplus sys/senhadosys as sysdba e pedir um SHUTDOWN IMMEDIATE; e sair com EXIT) e ** remover os Arquivos TODOS ** desse database que a instãncia estava abrindo/mantendo em homo – vc faz uma consulta similar à que fez em PROD e dá um delete/rm em cada arquivo

c. com a instãncia parada E o database completamente removido no servidor HOMO, aí sim vc transfere os arquivos backupeados em PROD para os ** exatos mesmos ** diretórios/sub-diretórios em HOMO

Aí sim é seguir a link e renomear o backup dpo controlfile para o nome/local correto (normalmente em duas cópias – veja na pesquisa que vc fez em PROD quais são as cópias e onde devem estar), mandar um startup mount e fazer o recover, não é nada extremamente difícil não ….

[]s

Chiappa

[Edgar Rombesso RisolaParticipante]

Blz…então…preciso do initfile? pq eu tenho esse init igualzinho no homo…não posso usar o mesmo?
O que fiz…tenho a produção instalada….instalei o homo igual…ou seja…banco já está criado…agora quero restaurar a producao na homologacao…fiz um backup hot…copiei os itens para a produção…só não estou conseguindo restaurar…algo está faltando….

[José Laurindo ChiappaModerador]

Então, o que vc precisa é de um initfile ** totalmente , 100%, completamente Igualzinho ao que está em PROD ** : se vc tem certeza que esse que já está lá em HOMO tá igualzinho OK, pode usar esse, se não tem, copie o de PROD, é isso…

Agora : vc ** seguiu ** os passos que eu indiquei, ie : antes de copiar os arqs pro servidor HOMO, vc PAROU a instância com o mesmo nome da instância de prod, Apagou Completamente os arquivos do database que existia no servidor HOMO ? Isso é CRÍTICO, se vc tá pensando em misturar arquivos vindos de prod com arquivos que já estavam em HOMO, ou reaproveitar essa instãncia que já está em HOMO, ou coisa assim, ESQUECE…

Isso feito, vc TEM CERTEZA que copiou os arquivos que vieram de PROD ** exatamente ** para o mesmo path/mountpoint/sub-diretórios em que eles estavam em PROD ? Eles estão com as mesmas permissões, com o mesmo owner – aí incluindo o initfile, os archives todos, os data files, tudinho ?? É PRA ISSO que vc fez as verificações de 1 a 5 nos procedimentos de backup….

Depois de feita a cópia, vc RENOMEOU o backup de controlfile de controlfileprod.bak para o mesmo nome que tinha antes em Prod ?? SE vc usa em PROD controlfiles duplicados (é uma config comum), talvez vc tenha que fazer cp controlfileprod.bak controlfile01.ctl e depois cp controlfileprod.bak controlfile02.ctl… *** É PARA ISSO **** que vc fez nos passos iniciais do backup uma pesquisa na V$CONTROLFILE , ie, pra saber QUANTOS controlfiles idênticos vc tem que ter, ONDE que eles devem residir…. OK ?

===> Com os passos acima feitos corretamente, vc TEM que ser capaz de fazer o startup mount; com Total Sucesso no sqlplus, sem receber msg de erro…. SE chegou até o mount com sucesso, exatamente QUAL ERRO que dá quando vc tenta fazer o Recover database until cancel using backup controlfile; ????
Dá os detalhes que a gente pode tentar te ajudar mais : NÃO ADIANTA só dizer “não estou conseguindo” se vc não CONFIRMAR que os passos todos foram seguidos rigorosamente E não mostrar a msg exata de erro que está recebendo…

[]s

Chiappa

[Edgar Rombesso RisolaParticipante]

Então jlchiappa…consegui resolver…fiz o recover e depois de vários erros consegui subir o banco e abrir a aplicação… mais ou menos seguiu o seguinte processo até ser arrumado…

1. Realmente o primeiro erro era devido aos datafiles que vieram do PROD estarem com owners diferentes e permissões incorretas também…
2. Corrigido esse problema o backup do controlfile também foi renomeado na pasta correta antes..
3. Depois deste processo a base mountou e abriu mas menos de 1 minuto depois ela teimava em cair..
4. Resolvi com um shutdown e um startup mount e o comando alter system set “_allow_resetlogs_corruption”=true scope=spfile;
5. Depois com comando — create spfile from pfile;
6. Um shutdown novamente e startup mount e alter database open resetlogs;
4. Identifiquei tambem um erro na tablespace do diretório temporario com o erro:

ora-01187 cannot read from file 1 because it failed verification tests

5. O que fiz então foi colocar offline esta tablespace e dar um drop
6. Depois recriei ela com as mesmas propriedades originais e a aplicação subiu e está funcionando normalmente.
7. Outro erro em que cai é que estava mantendo arquivos antigos como você mencionou e misturou com os que vieram do PROD.
8. Quanto ao init e pude utilizar o mesmo sem problemas.

Vlw pelos esclarecimentos jlchiappa

[José Laurindo ChiappaModerador]

Blz ? Fico contente de poder ter ajudado… Sobre as suas issues, vejo que a maioria delas foram erros procedurais (ie, permissões, arqs. com nome impróprio/local incorreto, nada de mais…
Só observo que :

a) “diretório … temporário” Não Existe no RDBMS Oracle, creio que vc deve estar falando sobre TABLESPACE TEMPORARIA, que é composta por ARQUIVOS (não diretórios, mas arquivos) que nem as outras MAS, pelo fato de só conter valores temporários/não-comitados,nunca é necessário se fazer recover dela : cfrme a documentação e sites como http://dbaworkshop.blogspot.com.br/2012/09/how-to-recover-from-loss-of-temporary.html nos avisam, do 10g em diante o Oracle já detecta e recria automaticamente a tablespace temporária se vc montar um banco sem ela, por isso não a incluímos nos procedimentos de cópia… No seu caso, vc ou a copiou erradamente ou (mais Provavel) esqueceu de apagar o(s) tempfile(s) antigos que já estavam no servidor HOMO, imagino…

b) não é padrão, de forma alguma, vc ter que usar “_allow_resetlogs_corruption” pra subir um database : será que foi o fato de vc ter presente no servidor HOMO arquivos da tablespace TEMP que levou o banco a pedir por recuperação ? Pode ser, mas uma outra possibilidade é que talvez os checkpoints do seu banco prod estejam muito demorados/espaçados, e alguma coisinha de redo log ativo não foi arquivado antes do backup ? Da próxima vez, tenta fazer como primeiro passo do seu script um ALTER SYSTEM CHECKPOINT, por via das dúvidas

[]s

Chiappa

[Autor]

Posts