Re: [oracle_br] Desaster Recovery
Chiappa, tudo bem?Estou reabrindo a thread pq fiquei ainda com algumas dúvidas, poderia me ajudar? Analisando o seu procedimento, notei o seguinte: Ckp SCN dos seus datafiles: 15092588 Ckp SCN do seu controlfile: 15092616 Ckp SCN do seu ultimo archivelog: 15092622 (SCN -1) = 15092621 Algumas perguntas: a) Quando você diz: "o truque é que se eu pedir RECOVER sem informar SCN, ele vai tentar restaurar até o SCN do controlfile, SCN esse que estava no redo online, que ** nunca ** é backupeado no HOT..." Se o SCN do controlfile é o SCN que estava no Redo que nunca é backupeado, pq o SCN do seu Arhivelog 15092621 é maior que o SCN do seu controlfile 15092616 ? b) Analisei o seu list backup antes do restore do controlfile, e o list backup após o restore do controlfile e notei o seguinte: No primeiro list backup (antes de vc realizar o cenário de restore/recovery) aparece o SCN do archivelog que vc utiliza na recuperação "recover database until scn 15092621" BS Key Size Device Type Elapsed Time Completion Time--- -- --- ---7 9.50K DISK 00:00:00 15-MAR-17 BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20170315T185107 Piece Name: /home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2017_03_15/o1_mf_a_TAG20170315T185107_ddmftcjj_.bkp List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time --- -- - -- - 1 667 15092582 15-MAR-17 15092622 15-MAR-17 Mas após o restore do controlfile quando você envia o list backup, apenas aparecem o backup set 3, 4 e 5. O meu questionamento aqui é o seguinte: Em um cenário do mundo real, quando se tem um crash desse tipo e você não realizou um list backup anterior, no qual foi mostrado o backup set de número 7 com o último archivelog, no momento que você restaura o controlfile, como você sabe que aquele backup do archivelog existe se o mesmo não apareceu no segundo list backup após o restore do controlfile? Em Segunda-feira, 20 de Março de 2017 22:53, "Carlos Eduardo carloseduard...@yahoo.com [oracle_br]" escreveu: Mais uma vez, meu muito obrigado, Chiappa. Obrigado pelas dicas e pelos conselhos, sao muito bem vindos. Irei sim, realizar cenários de restore/recover mais complexos, como por exemplo: 1 - Fazer um restore de um backup antigo de uma semana atrás, como vc mesmo propos. 2- Backupear um database em um hostname e restaurar em um outros host com file systems divergentes ou de file system para ASM e vice versa. 3 - Restaurar/recover de um backup que se tenha perdido de um determinado archive de SCN x antes que o mesmo tenha sido backupeado. etc E qualquer dúvida posto aqui para você me ajudar, Obrigado :) Em Segunda-feira, 20 de Março de 2017 10:24, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Blz... Agora é partir pros criar cenários mais complexos (como fazer um backup + restore de backup mais antigo que vc tiver, restore envolvendo backups incrementais - com e sem Block Changing Track -, diferenciais e cumulativos), recover point-in-time recover E em paralelo a isso se não o fez vc VAI começar a levantar as rotinas de backup que possui hoje para tentar restores de testes - Apenas e Tão Somente assim, NA Prática, ie, tentando restaurar num servidor não-prod algum backup de PROD é que vc vai descobrir os erros operacionais e de processo, tipo, backups que neguim não manteve registro do DBID, que não tem em mãos a sequência ** EXATA ** dos archives porque antes do backup database rolou um backup delete input dos archives necessários, que por qualquer motivo algum dos datafiles tá com um SCN ** extremamente antigo ** registrado nele e ninguém sabia), backups antigos que estão na fita há um LONGO tempo sem ser usado - não é incomum a fita 'grudar' e/ou ficar ressecada e quebradiça se ficar enrolada no cartucho há longuíssimo tempo, parada, e coisas assimAté por isso em várias Empresas por onde passei que eram da área Financeira e que tinham SLAs muito exatamente precisos sobre Recuperabilidade, bem como Multas imensamente impossíveis se não os cumprir, além de vc ter *** MAIS *** de uma Cópia de cada backup em fitas diferentes (a regra repito é backup, se vc tem um só vc NÂO TEM NENHUM, na verdade) , era comum o Rodízio, tipo : a cada x meses vc voltava o backup, depois esses arquivos restaurados iam pra Outra fita com a fita Original voltando ao pool de uso Quantos ciclos de reuso a fita aguenta confiavelmente antes de ser descartada, qual esse intervalo e questões assim são Específicas pra cada ambiente/hardware, não dá pra generalizar, mas vc TEM que se assegurar que Existe algo assim... Garanto que quando vc for mesmo fazer os restores+recovers reais para testar é bem capaz de vc vai achar falhas do tipo, e sempre é melhor vc achar isso agora do que quan
Re: [oracle_br] Desaster Recovery
Mais uma vez, meu muito obrigado, Chiappa.
Obrigado pelas dicas e pelos conselhos, sao muito bem vindos. Irei sim,
realizar cenários de restore/recover mais complexos, como por exemplo:
1 - Fazer um restore de um backup antigo de uma semana atrás, como vc mesmo
propos.
2- Backupear um database em um hostname e restaurar em um outros host com file
systems divergentes ou de file system para ASM e vice versa.
3 - Restaurar/recover de um backup que se tenha perdido de um determinado
archive de SCN x antes que o mesmo tenha sido backupeado.
etc
E qualquer dúvida posto aqui para você me ajudar, Obrigado :)
Em Segunda-feira, 20 de Março de 2017 10:24, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Blz... Agora é partir pros criar cenários mais complexos (como fazer um
backup + restore de backup mais antigo que vc tiver, restore envolvendo backups
incrementais - com e sem Block Changing Track -, diferenciais e cumulativos),
recover point-in-time recover
E em paralelo a isso se não o fez vc VAI começar a levantar as rotinas de
backup que possui hoje para tentar restores de testes - Apenas e Tão Somente
assim, NA Prática, ie, tentando restaurar num servidor não-prod algum backup de
PROD é que vc vai descobrir os erros operacionais e de processo, tipo, backups
que neguim não manteve registro do DBID, que não tem em mãos a sequência **
EXATA ** dos archives porque antes do backup database rolou um backup delete
input dos archives necessários, que por qualquer motivo algum dos datafiles tá
com um SCN ** extremamente antigo ** registrado nele e ninguém sabia), backups
antigos que estão na fita há um LONGO tempo sem ser usado - não é incomum a
fita 'grudar' e/ou ficar ressecada e quebradiça se ficar enrolada no cartucho
há longuíssimo tempo, parada, e coisas assimAté por isso em várias Empresas
por onde passei que eram da área Financeira e que tinham SLAs muito exatamente
precisos sobre Recuperabilidade, bem como Multas imensamente impossíveis se não
os cumprir, além de vc ter *** MAIS *** de uma Cópia de cada backup em fitas
diferentes (a regra repito é backup, se vc tem um só vc NÂO TEM NENHUM, na
verdade) , era comum o Rodízio, tipo : a cada x meses vc voltava o backup,
depois esses arquivos restaurados iam pra Outra fita com a fita Original
voltando ao pool de uso Quantos ciclos de reuso a fita aguenta
confiavelmente antes de ser descartada, qual esse intervalo e questões assim
são Específicas pra cada ambiente/hardware, não dá pra generalizar, mas vc TEM
que se assegurar que Existe algo assim...
Garanto que quando vc for mesmo fazer os restores+recovers reais para testar
é bem capaz de vc vai achar falhas do tipo, e sempre é melhor vc achar isso
agora do que quando tiver um diretor gritando na sua orelha que precisa porque
precisa recuperar os dados do ano passado pra fazer não-sei-qual relatório
importante, ou mesmo numa hora de crise total ie disaster recover
[]s
Chiappa #yiv5316083694 #yiv5316083694 -- #yiv5316083694ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5316083694
#yiv5316083694ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5316083694
#yiv5316083694ygrp-mkp #yiv5316083694hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv5316083694 #yiv5316083694ygrp-mkp #yiv5316083694ads
{margin-bottom:10px;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad
{padding:0 0;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad p
{margin:0;}#yiv5316083694 #yiv5316083694ygrp-mkp .yiv5316083694ad a
{color:#ff;text-decoration:none;}#yiv5316083694 #yiv5316083694ygrp-sponsor
#yiv5316083694ygrp-lc {font-family:Arial;}#yiv5316083694
#yiv5316083694ygrp-sponsor #yiv5316083694ygrp-lc #yiv5316083694hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5316083694
#yiv5316083694ygrp-sponsor #yiv5316083694ygrp-lc .yiv5316083694ad
{margin-bottom:10px;padding:0 0;}#yiv5316083694 #yiv5316083694actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5316083694
#yiv5316083694activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5316083694
#yiv5316083694activity span {font-weight:700;}#yiv5316083694
#yiv5316083694activity span:first-child
{text-transform:uppercase;}#yiv5316083694 #yiv5316083694activity span a
{color:#5085b6;text-decoration:none;}#yiv5316083694 #yiv5316083694activity span
span {color:#ff7900;}#yiv5316083694 #yiv5316083694activity span
.yiv5316083694underline {text-decoration:underline;}#yiv5316083694
.yiv5316083694attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv5316083694 .yiv5316083694attach div a
{text-decoration:none;}#yiv5316083694 .yiv5316083694attach img
{border:none;padding-right:5px;}#yiv5316083694 .yiv5316083694attach label
{display:block;margin-bottom:5px;}#yiv5316083694 .yiv5316083694attach label a
{text-decoration
Re: [oracle_br] Desaster Recovery
Blz... Agora é partir pros criar cenários mais complexos (como fazer um backup + restore de backup mais antigo que vc tiver, restore envolvendo backups incrementais - com e sem Block Changing Track -, diferenciais e cumulativos), recover point-in-time recover E em paralelo a isso se não o fez vc VAI começar a levantar as rotinas de backup que possui hoje para tentar restores de testes - Apenas e Tão Somente assim, NA Prática, ie, tentando restaurar num servidor não-prod algum backup de PROD é que vc vai descobrir os erros operacionais e de processo, tipo, backups que neguim não manteve registro do DBID, que não tem em mãos a sequência ** EXATA ** dos archives porque antes do backup database rolou um backup delete input dos archives necessários, que por qualquer motivo algum dos datafiles tá com um SCN ** extremamente antigo ** registrado nele e ninguém sabia), backups antigos que estão na fita há um LONGO tempo sem ser usado - não é incomum a fita 'grudar' e/ou ficar ressecada e quebradiça se ficar enrolada no cartucho há longuíssimo tempo, parada, e coisas assimAté por isso em várias Empresas por onde passei que eram da área Financeira e que tinham SLAs muito exatamente precisos sobre Recuperabilidade, bem como Multas imensamente impossíveis se não os cumprir, além de vc ter *** MAIS *** de uma Cópia de cada backup em fitas diferentes (a regra repito é backup, se vc tem um só vc NÂO TEM NENHUM, na verdade) , era comum o Rodízio, tipo : a cada x meses vc voltava o backup, depois esses arquivos restaurados iam pra Outra fita com a fita Original voltando ao pool de uso Quantos ciclos de reuso a fita aguenta confiavelmente antes de ser descartada, qual esse intervalo e questões assim são Específicas pra cada ambiente/hardware, não dá pra generalizar, mas vc TEM que se assegurar que Existe algo assim... Garanto que quando vc for mesmo fazer os restores+recovers reais para testar é bem capaz de vc vai achar falhas do tipo, e sempre é melhor vc achar isso agora do que quando tiver um diretor gritando na sua orelha que precisa porque precisa recuperar os dados do ano passado pra fazer não-sei-qual relatório importante, ou mesmo numa hora de crise total ie disaster recover []s Chiappa
Re: [oracle_br] Desaster Recovery
Descuylpe a demora para responder Chiappa, agora sim convegui resolver,
obrigado.Só precisei setar o SCN -1 do ultimo archivelog e foi.:)
Em Quinta-feira, 16 de Março de 2017 14:41, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Aproveitei e usei o mesmo texto como um post no meu blog pessoal, vide
https://jlc1967.wordpress.com/2017/03/16/demonstracao-de-restore-de-backup-hotonlineinconsistente-na-mesma-maquina/
[]s
Chiappa #yiv3133981602 #yiv3133981602 -- #yiv3133981602ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3133981602
#yiv3133981602ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3133981602
#yiv3133981602ygrp-mkp #yiv3133981602hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv3133981602 #yiv3133981602ygrp-mkp #yiv3133981602ads
{margin-bottom:10px;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad
{padding:0 0;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad p
{margin:0;}#yiv3133981602 #yiv3133981602ygrp-mkp .yiv3133981602ad a
{color:#ff;text-decoration:none;}#yiv3133981602 #yiv3133981602ygrp-sponsor
#yiv3133981602ygrp-lc {font-family:Arial;}#yiv3133981602
#yiv3133981602ygrp-sponsor #yiv3133981602ygrp-lc #yiv3133981602hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3133981602
#yiv3133981602ygrp-sponsor #yiv3133981602ygrp-lc .yiv3133981602ad
{margin-bottom:10px;padding:0 0;}#yiv3133981602 #yiv3133981602actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3133981602
#yiv3133981602activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3133981602
#yiv3133981602activity span {font-weight:700;}#yiv3133981602
#yiv3133981602activity span:first-child
{text-transform:uppercase;}#yiv3133981602 #yiv3133981602activity span a
{color:#5085b6;text-decoration:none;}#yiv3133981602 #yiv3133981602activity span
span {color:#ff7900;}#yiv3133981602 #yiv3133981602activity span
.yiv3133981602underline {text-decoration:underline;}#yiv3133981602
.yiv3133981602attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv3133981602 .yiv3133981602attach div a
{text-decoration:none;}#yiv3133981602 .yiv3133981602attach img
{border:none;padding-right:5px;}#yiv3133981602 .yiv3133981602attach label
{display:block;margin-bottom:5px;}#yiv3133981602 .yiv3133981602attach label a
{text-decoration:none;}#yiv3133981602 blockquote {margin:0 0 0
4px;}#yiv3133981602 .yiv3133981602bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3133981602
.yiv3133981602bold a {text-decoration:none;}#yiv3133981602 dd.yiv3133981602last
p a {font-family:Verdana;font-weight:700;}#yiv3133981602 dd.yiv3133981602last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3133981602
dd.yiv3133981602last p span.yiv3133981602yshortcuts
{margin-right:0;}#yiv3133981602 div.yiv3133981602attach-table div div a
{text-decoration:none;}#yiv3133981602 div.yiv3133981602attach-table
{width:400px;}#yiv3133981602 div.yiv3133981602file-title a, #yiv3133981602
div.yiv3133981602file-title a:active, #yiv3133981602
div.yiv3133981602file-title a:hover, #yiv3133981602 div.yiv3133981602file-title
a:visited {text-decoration:none;}#yiv3133981602 div.yiv3133981602photo-title a,
#yiv3133981602 div.yiv3133981602photo-title a:active, #yiv3133981602
div.yiv3133981602photo-title a:hover, #yiv3133981602
div.yiv3133981602photo-title a:visited {text-decoration:none;}#yiv3133981602
div#yiv3133981602ygrp-mlmsg #yiv3133981602ygrp-msg p a
span.yiv3133981602yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3133981602
.yiv3133981602green {color:#628c2a;}#yiv3133981602 .yiv3133981602MsoNormal
{margin:0 0 0 0;}#yiv3133981602 o {font-size:0;}#yiv3133981602
#yiv3133981602photos div {float:left;width:72px;}#yiv3133981602
#yiv3133981602photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv3133981602
#yiv3133981602photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3133981602
#yiv3133981602reco-category {font-size:77%;}#yiv3133981602
#yiv3133981602reco-desc {font-size:77%;}#yiv3133981602 .yiv3133981602replbq
{margin:4px;}#yiv3133981602 #yiv3133981602ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv3133981602 #yiv3133981602ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv3133981602
#yiv3133981602ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv3133981602
#yiv3133981602ygrp-mlmsg select, #yiv3133981602 input, #yiv3133981602 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv3133981602
#yiv3133981602ygrp-mlmsg pre, #yiv3133981602 code {font:115%
monospace;}#yiv3133981602 #yiv3133981602ygrp-mlmsg *
{line-height:1.22em;}#yiv3133981602 #yiv3133981602ygrp-mlmsg #yiv3133981602logo
{padding-bottom:10px;}#yiv3133981602 #yiv3133981602ygr
Re: [oracle_br] Desaster Recovery
Aproveitei e usei o mesmo texto como um post no meu blog pessoal, vide https://jlc1967.wordpress.com/2017/03/16/demonstracao-de-restore-de-backup-hotonlineinconsistente-na-mesma-maquina/ https://jlc1967.wordpress.com/2017/03/16/demonstracao-de-restore-de-backup-hotonlineinconsistente-na-mesma-maquina/ []s Chiappa
Re: [oracle_br] Desaster Recovery
Ops : eu tinha feito um exemplo step-by-step das consultas que queremos ver, bem como de um backup e restore no mesmo servidor (que é o teste que vc está fazendo) mas ficou muito grande o texto : baixei em http://pastebin.com/W0A1w5AL http://pastebin.com/W0A1w5AL veja lá... []s Chiappa
Re: [oracle_br] Desaster Recovery
Carlos,
Acho que fiz a conta errada :-):
List of Archived Logs in backup set 25 Thrd Seq Low SCN Low Time
Next SCN Next Time --- -- - -- - 1
72 2797947 15-MAR-17 2798016 15-MAR-17
Tenta o recover until scn 2798015.
Antigamente, o backup database plus archivelog all não pegava todos os
archives necessários para fazer um recover, então eu sempre fazia primeiro um
"backup database", depois um "sql 'alter system archive log current'" e um
backup archivelog all.
Mas acho que esse problema foi resolvido na 11g.
O "until sequence" talvez tenha que ser até a sequencia 73 em vez de 72 :-).
Atc,Luis Freitas
On Wednesday, March 15, 2017 4:21 PM, "carloseduard...@yahoo.com
[oracle_br]" wrote:
O que deu a entender eh o seguinte:
Meus datafiles, após o restore, estão em um SCN 2797971.
O meu ultimo archive log disponivel possui o SCN 2798015 (next SCN - 1). E
quando executo um recover, ele diz que eu preciso restaurar os meus datafiles
de um SCN anterior ao 2797947.
Portanto, o ultimo backupset nao seria o ideal para recuperar o database?
EU sempre fiz restore/recover inumeras vezes, mas esse cenario especifico estou
tendo dificuldades para resolver.
Em Quarta-feira, 15 de Março de 2017 16:07, "carloseduard...@yahoo.com"
escreveu:
Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o
estado da sequence antes da realização do backup, a localização dos backup sets
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado.
Inclusive no restore database, ele mostra que o backup que está sendo
restaurado foi o que realizei no exemplo, informando o backup set do dia 15,
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido,
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro
da politica de retenção guardado.
Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
FILE# STATUS REC CHECKPOINT_CHANGE#-- --- ---
-- 1 ONLINE 2797971 3 ONLINE 2797971 4 ONLINE 2797971
5 ONLINE 2797971 6 ONLINE 2797971 7 ONLINE 2797971
RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1:
SID=12 device type=DISKRMAN-00571:
===RMAN-00569:
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571:
===RMAN-03002: failure
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be
restored from backup older than SCN 2797947
Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com
[oracle_br]" escreveu:
Pessoal, o backup que fiz, foi um backup HOT, com o database em estado
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o
database estava em shutdown, ate pq foram deletados todos os datafiles do banco
e consequentemente a instance estava em shutdown na hora do restore/recovery.
Mas que o backup foi realizado com o database aberto, backup HOT.
Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
"
se entendi direito, você fez um backup 'cold'
"
==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas
internas em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER
de um database que já está íntegro, sim
Se não for COLD, eu reforço também a necessidade de vc consultar
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW
antes da coisa real, sim...
[]s
Chiappa
#yiv7468412983 #yiv7468412983 -- #yiv7468412983ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7468412983
#yiv7468412983ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7468412983
#yiv7468412983ygrp-mkp #yiv7468412983hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv7468412983 #yiv7468412983ygrp-mkp #yiv7468412983ads
{margin-bottom:10px;}#yiv7468412983 #yiv7468412983ygrp-mkp .yiv7468412983ad
{padding:0 0;}#yiv7468412983 #yiv7468412983ygrp-mkp .yiv7468412983ad p
{margin:0;}#yiv746841
Re: [oracle_br] Desaster Recovery
O que deu a entender eh o seguinte:
Meus datafiles, após o restore, estão em um SCN 2797971.
O meu ultimo archive log disponivel possui o SCN 2798015 (next SCN - 1). E
quando executo um recover, ele diz que eu preciso restaurar os meus datafiles
de um SCN anterior ao 2797947.
Portanto, o ultimo backupset nao seria o ideal para recuperar o database?
EU sempre fiz restore/recover inumeras vezes, mas esse cenario especifico estou
tendo dificuldades para resolver.
Em Quarta-feira, 15 de Março de 2017 16:07, "carloseduard...@yahoo.com"
escreveu:
Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o
estado da sequence antes da realização do backup, a localização dos backup sets
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado.
Inclusive no restore database, ele mostra que o backup que está sendo
restaurado foi o que realizei no exemplo, informando o backup set do dia 15,
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido,
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro
da politica de retenção guardado.
Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
FILE# STATUS REC CHECKPOINT_CHANGE#-- --- ---
-- 1 ONLINE 2797971 3 ONLINE 2797971 4 ONLINE 2797971
5 ONLINE 2797971 6 ONLINE 2797971 7 ONLINE 2797971
RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1:
SID=12 device type=DISKRMAN-00571:
===RMAN-00569:
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571:
===RMAN-03002: failure
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be
restored from backup older than SCN 2797947
Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com
[oracle_br]" escreveu:
Pessoal, o backup que fiz, foi um backup HOT, com o database em estado
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o
database estava em shutdown, ate pq foram deletados todos os datafiles do banco
e consequentemente a instance estava em shutdown na hora do restore/recovery.
Mas que o backup foi realizado com o database aberto, backup HOT.
Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
"
se entendi direito, você fez um backup 'cold'
"
==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas
internas em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER
de um database que já está íntegro, sim
Se não for COLD, eu reforço também a necessidade de vc consultar
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW
antes da coisa real, sim...
[]s
Chiappa
#yiv1968297007 -- #yiv1968297007ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1968297007
#yiv1968297007ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1968297007
#yiv1968297007ygrp-mkp #yiv1968297007hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1968297007 #yiv1968297007ygrp-mkp #yiv1968297007ads
{margin-bottom:10px;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad
{padding:0 0;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad p
{margin:0;}#yiv1968297007 #yiv1968297007ygrp-mkp .yiv1968297007ad a
{color:#ff;text-decoration:none;}#yiv1968297007 #yiv1968297007ygrp-sponsor
#yiv1968297007ygrp-lc {font-family:Arial;}#yiv1968297007
#yiv1968297007ygrp-sponsor #yiv1968297007ygrp-lc #yiv1968297007hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1968297007
#yiv1968297007ygrp-sponsor #yiv1968297007ygrp-lc .yiv1968297007ad
{margin-bottom:10px;padding:0 0;}#yiv1968297007 #yiv1968297007actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1968297007
#yiv1968297007activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1968297007
#yiv1968297007activity span {font-weight:700;}#yiv1968297007
#yiv1968297007activity span:first-child
{text-transform:uppercase;}#yiv1968297007 #yiv196829700
Re: [oracle_br] Desaster Recovery
Chiappa, respondendo seus questionamentos...
EM relação aos SCN/sequence do database, passei as informações necessárias, o
estado da sequence antes da realização do backup, a localização dos backup sets
dos datafiles, controlfiles e archives, informações do SCN e das sequences dos
bakups dos datafiles e dos archives logs. Está tudo listado no cenário passado.
Inclusive no restore database, ele mostra que o backup que está sendo
restaurado foi o que realizei no exemplo, informando o backup set do dia 15,
que eh o comportamento padrao sempre pegar o ultimo backup full como voce mesmo
ja sabe.
Em relação da deletar backups anteriores, vc vai me desculpar, mas eu descordo
de vc nesse ponto. Se por acaso, um backup set mais novo estivesse corrompido,
eu nao poderia voltar um backup mais antigo, pelo simples fato de eu ter
deletado os backups atenreiores, portanto eu prefiro deixar todo backup dentro
da politica de retenção guardado.
Luis Freitas:
SQL> select file#, status, recover, checkpoint_change# from v$datafile_header;
FILE# STATUS REC CHECKPOINT_CHANGE#-- --- ---
-- 1 ONLINE 2797971 3 ONLINE 2797971 4 ONLINE 2797971
5 ONLINE 2797971 6 ONLINE 2797971 7 ONLINE 2797971
RMAN> recover database until sequence 72 thread 1;
Starting recover at 15-MAR-17allocated channel: ORA_DISK_1channel ORA_DISK_1:
SID=12 device type=DISKRMAN-00571:
===RMAN-00569:
=== ERROR MESSAGE STACK FOLLOWS ===RMAN-00571:
===RMAN-03002: failure
of recover command at 03/15/2017 16:06:50RMAN-06556: datafile 1 must be
restored from backup older than SCN 2797947
Em Quarta-feira, 15 de Março de 2017 15:00, "carloseduard...@yahoo.com
[oracle_br]" escreveu:
Pessoal, o backup que fiz, foi um backup HOT, com o database em estado
OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o
database estava em shutdown, ate pq foram deletados todos os datafiles do banco
e consequentemente a instance estava em shutdown na hora do restore/recovery.
Mas que o backup foi realizado com o database aberto, backup HOT.
Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
"
se entendi direito, você fez um backup 'cold'
"
==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas
internas em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER
de um database que já está íntegro, sim
Se não for COLD, eu reforço também a necessidade de vc consultar
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW
antes da coisa real, sim...
[]s
Chiappa
#yiv9671287422 #yiv9671287422 -- #yiv9671287422ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9671287422
#yiv9671287422ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9671287422
#yiv9671287422ygrp-mkp #yiv9671287422hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv9671287422 #yiv9671287422ygrp-mkp #yiv9671287422ads
{margin-bottom:10px;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad
{padding:0 0;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad p
{margin:0;}#yiv9671287422 #yiv9671287422ygrp-mkp .yiv9671287422ad a
{color:#ff;text-decoration:none;}#yiv9671287422 #yiv9671287422ygrp-sponsor
#yiv9671287422ygrp-lc {font-family:Arial;}#yiv9671287422
#yiv9671287422ygrp-sponsor #yiv9671287422ygrp-lc #yiv9671287422hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9671287422
#yiv9671287422ygrp-sponsor #yiv9671287422ygrp-lc .yiv9671287422ad
{margin-bottom:10px;padding:0 0;}#yiv9671287422 #yiv9671287422actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9671287422
#yiv9671287422activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9671287422
#yiv9671287422activity span {font-weight:700;}#yiv9671287422
#yiv9671287422activity span:first-child
{text-transform:uppercase;}#yiv9671287422 #yiv9671287422activity span a
{color:#5085b6;text-decoration:none;}#yiv9671287422 #yiv9671287422activity span
span {color:#ff7900;}#yiv9671287422 #yiv9671287422activity span
.yiv9671287422underline {text-decoration:underline;}#yiv9671287422
.yiv9671287422attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv9671287422 .yiv9671287422attach div a
{text-decoration:none;}#yiv9671287422 .yiv9671287422attach img
{border:none;padding-right:5px;}#yiv9671287422 .yiv9671287422attach label
{display:block;margin-botto
Re: [oracle_br] Desaster Recovery
Pessoal, o backup que fiz, foi um backup HOT, com o database em estado OPEN, ok?
O que quis dizer com INSTANCE em SHUTDOWN, eh que na hora do restore/recovery o
database estava em shutdown, ate pq foram deletados todos os datafiles do banco
e consequentemente a instance estava em shutdown na hora do restore/recovery.
Mas que o backup foi realizado com o database aberto, backup HOT.
Em Quarta-feira, 15 de Março de 2017 13:12, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
"
se entendi direito, você fez um backup 'cold'
"
==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e
feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles
TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas
internas em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER
de um database que já está íntegro, sim
Se não for COLD, eu reforço também a necessidade de vc consultar
V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode
ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW
antes da coisa real, sim...
[]s
Chiappa #yiv199977 #yiv199977 -- #yiv199977ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv199977
#yiv199977ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv199977
#yiv199977ygrp-mkp #yiv199977hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv199977 #yiv199977ygrp-mkp #yiv199977ads
{margin-bottom:10px;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad
{padding:0 0;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad p
{margin:0;}#yiv199977 #yiv199977ygrp-mkp .yiv199977ad a
{color:#ff;text-decoration:none;}#yiv199977 #yiv199977ygrp-sponsor
#yiv199977ygrp-lc {font-family:Arial;}#yiv199977
#yiv199977ygrp-sponsor #yiv199977ygrp-lc #yiv199977hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv199977
#yiv199977ygrp-sponsor #yiv199977ygrp-lc .yiv199977ad
{margin-bottom:10px;padding:0 0;}#yiv199977 #yiv199977actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv199977
#yiv199977activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv199977
#yiv199977activity span {font-weight:700;}#yiv199977
#yiv199977activity span:first-child
{text-transform:uppercase;}#yiv199977 #yiv199977activity span a
{color:#5085b6;text-decoration:none;}#yiv199977 #yiv199977activity span
span {color:#ff7900;}#yiv199977 #yiv199977activity span
.yiv199977underline {text-decoration:underline;}#yiv199977
.yiv199977attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv199977 .yiv199977attach div a
{text-decoration:none;}#yiv199977 .yiv199977attach img
{border:none;padding-right:5px;}#yiv199977 .yiv199977attach label
{display:block;margin-bottom:5px;}#yiv199977 .yiv199977attach label a
{text-decoration:none;}#yiv199977 blockquote {margin:0 0 0
4px;}#yiv199977 .yiv199977bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv199977
.yiv199977bold a {text-decoration:none;}#yiv199977 dd.yiv199977last
p a {font-family:Verdana;font-weight:700;}#yiv199977 dd.yiv199977last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv199977
dd.yiv199977last p span.yiv199977yshortcuts
{margin-right:0;}#yiv199977 div.yiv199977attach-table div div a
{text-decoration:none;}#yiv199977 div.yiv199977attach-table
{width:400px;}#yiv199977 div.yiv199977file-title a, #yiv199977
div.yiv199977file-title a:active, #yiv199977
div.yiv199977file-title a:hover, #yiv199977 div.yiv199977file-title
a:visited {text-decoration:none;}#yiv199977 div.yiv199977photo-title a,
#yiv199977 div.yiv199977photo-title a:active, #yiv199977
div.yiv199977photo-title a:hover, #yiv199977
div.yiv199977photo-title a:visited {text-decoration:none;}#yiv199977
div#yiv199977ygrp-mlmsg #yiv199977ygrp-msg p a
span.yiv199977yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv199977
.yiv199977green {color:#628c2a;}#yiv199977 .yiv199977MsoNormal
{margin:0 0 0 0;}#yiv199977 o {font-size:0;}#yiv199977
#yiv199977photos div {float:left;width:72px;}#yiv199977
#yiv199977photos div div {border:1px solid
#66;height:62px;overflow:hidden;width:62px;}#yiv199977
#yiv199977photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv199977
#yiv199977reco-category {font-size:77%;}#yiv199977
#yiv199977reco-desc {font-size:77%;}#yiv199977
Re: [oracle_br] Desaster Recovery
" se entendi direito, você fez um backup 'cold' " ==> yep, essa foi a minha primeira pergunta também : logicamente se é COLD e feito com SHUTDOWN normal/immediate, vc tem 100% de certeza que os datafiles TODOS estão sincronizados/compatíveis com o controlfile E com as tabelas internas em termos de SCN - não faz o MENOR dos MENORES sentidos pedir RECOVER de um database que já está íntegro, sim Se não for COLD, eu reforço também a necessidade de vc consultar V$DATAFILE/HEADER/REDO LOGs, sim Também um VALIDATE DATABASE; no RMAN pode ser legal, para estarmos Certos que o backup será possível, um RESTORE PREVIEW antes da coisa real, sim... []s Chiappa
Re: [oracle_br] Desaster Recovery
Carlos,
Bom dia,
a) Se eu mando o "RECOVER DATABASE" o RDBMS nao deveria recuperar até onde
seria possível?
Sim, mas pelos logs que você mandou, o até onde possível é o scn 2798016,
que é onde parou o ultimo archivelog mencionado no backup na sequencia 72.
b) Mesmo informando o SCN que o controlfile me diz que eu possuo, o database
também nao recupera, por qual motivo isso está acontecendo?
O database recuperou até onde encontrou archived logs, usando as informações
do controlfile e do fast recovery area. Mas como foi feito o restore do
controlfile, o Oracle não assume que este archive log é o ultimo, você precisa
especificar até onde vai fazer o recover, você pode tentar:
recover database until scn 2798015; (O next do ultimo archivelog -1 )recover
database until log sequence 72 thread 1;
Ou mesmorecover database until cancel; (Seguido de um cancel, este ultimo
antigamente não tinha no RMAN, era preciso rodar no SQLPLUS)
E depois deve ser possível abrir o banco, mas ele deve exigir um resetlogs. Da
forma como está acredito que você consiga abrir o banco mesmo sem fazer o
recover, veja a resposta do "c".
c) Estou fazendo algum procedimento errado? Alguém poderia ajudar?
Bom, o que tem de errado nesse procedimento é que, se entendi direito, você fez
um backup "cold", o que normalmente não temos em uma situação de desastre, pois
os backups de produção são usualmente "hot".
Acho que você também não viu a ultima sequencia de archive log, que está em um
backupset separado, pois está tentando fazer o "recover" até a sequencia 71. A
sequencia 71 termina no scn 2797947, sendo que os datafiles no ultimo backup
estão já neste scn.
Com um backup cold, deve ser possível abrir o banco logo após o "restore
database", sem nem ser preciso fazer o "recover".
Tendo restaurado o controlfile e os datafiles, você pode confirmar isso abrindo
o SQLPLUS com o banco em "mount" e verificando a v$datafile_header, a coluna
status vai te indicar se falta algum arquivo, a coluna "recover" indica os
datafiles que estão inconsistentes e precisam de mais "recover". Quando todos
os datafiles estão com o mesmo numero na "checkpoint_change#" é possível abrir
o banco, mesmo que você não tenha aplicado todos os archives que possui.
Talvez haja uma forma de ver isso dentro do RMAN, mas eu não conheço.
Atc,Luis Freitas
From: "angelo angelolis...@gmail.com [oracle_br]"
To: oracle_br@yahoogrupos.com.br
Sent: Wednesday, March 15, 2017 10:34 AM
Subject: Re: [oracle_br] Desaster Recovery
Bom dia,
As vezes pode virar uma bateção de cabeça, ainda mais se o ambiente não estiver
previamente documentado...
Principalmente com relação ao DBID do banco. Guarda bem esse numero, porque vc
ainda vai precisar dele um dia
Passei por uma situação tosca outro dia, em que um tablespace nao era
backupeado, na configuração do rman estava excluido de proposito.
Mas na hora do restore, em outra maquina não retornava porque havia
referencia a ele, na listagem dos datafiles fazia uma referencia ao que não
tinha
Era uma emergência, precisava fazer uma correção em um sistema que o usuário
tinha feito uns lançamentos errados, então era uma copia do banco de produção.
E pra completar, as pastas onde estavam os arquivos originais não eram as
mesmas no servidor ( era um outro servidor ), ter que sair adaptando com set
newname datafile.. E na pressa, até lembrar que existia o comando "recover
database skip tablespace fulano,beltrano,... until sequence (ou scn) etc."
Pode tentar também com recover database until cancel.
Carlos, vou propor um outro desafio para treinar o restore, depois que vc
vencer este: => formata a maquina, reinstala o Oracle, zerado e tenta voltar
esse backup ai de novo..
Depois de praticar alguma vezes backup e restore, fica parecendo uma receita de
bolo, que muda pouco, dependendo da situação.
On 15 March 2017 at 03:39, Carlos Eduardo carloseduard...@yahoo.com [oracle_br]
wrote:
Cenário: Desastre e Recovery, COM BACKUP, SEM CATALOGO, INSTANCE
SHUTDOWN.Enterprise Edition 12.1.0.2 Linux 64
SQL> archive log listDatabase log mode Archive ModeAutomatic archival
EnabledArchive destination /u01/app/archivelog2Oldest online log
sequence 67Next log sequence to archive 70Current log sequence 70
a) PASSO 1 - BACKUPEAR TODOS OS ARQUIVOS DO DATABASE
run{alter system archive log current; backup database plus archivelog delete
input;}
Starting backup at 15-MAR-17using channel ORA_DISK_1channel ORA_DISK_1:
starting full datafile backup setchannel ORA_DISK_1: specifying datafile(s) in
backup setinput datafile file number=1 name=/u01/app/oracle/oradata/
TERRA1/datafile/o1_mf_system_ dbz6nx14_.dbfinput datafile file number=3
name=/u01/app/oracle/oradata/ TERRA1/datafile/o1_mf_sysaux_ dbz6m573_.dbf
Re: [oracle_br] Desaster Recovery
Bom dia,
As vezes pode virar uma bateção de cabeça, ainda mais se o ambiente não
estiver previamente documentado...
Principalmente com relação ao *DBID do banco. *Guarda bem esse numero,
porque vc ainda vai precisar dele um dia
Passei por uma situação tosca outro dia, em que um tablespace nao era
backupeado, na configuração do rman estava excluido de proposito.
Mas na hora do restore, em outra maquina não retornava porque havia
referencia a ele, na listagem dos datafiles fazia uma referencia ao que não
tinha
Era uma emergência, precisava fazer uma correção em um sistema que o
usuário tinha feito uns lançamentos errados, então era uma copia do banco
de produção.
E pra completar, as pastas onde estavam os arquivos originais não eram as
mesmas no servidor ( era um outro servidor ), ter que sair adaptando com
set newname datafile..
E na pressa, até lembrar que existia o comando "recover database skip
tablespace fulano,beltrano,... until sequence (ou scn) etc."
Pode tentar também com recover database until cancel.
Carlos, vou propor um outro desafio para treinar o restore, depois que vc
vencer este: => formata a maquina, reinstala o Oracle, zerado e tenta
voltar esse backup ai de novo..
Depois de praticar alguma vezes backup e restore, fica parecendo uma
receita de bolo, que muda pouco, dependendo da situação.
On 15 March 2017 at 03:39, Carlos Eduardo carloseduard...@yahoo.com
[oracle_br] wrote:
>
>
> Cenário: Desastre e Recovery, COM BACKUP, SEM CATALOGO, INSTANCE SHUTDOWN.
> Enterprise Edition 12.1.0.2 Linux 64
>
> SQL> archive log list
> Database log mode Archive Mode
> Automatic archival Enabled
> Archive destination /u01/app/archivelog2
> Oldest online log sequence 67
> Next log sequence to archive 70
> Current log sequence 70
>
>
> a) PASSO 1 - BACKUPEAR TODOS OS ARQUIVOS DO DATABASE
>
> run
> {alter system archive log current;
> backup database plus archivelog delete input;
> }
>
> Starting backup at 15-MAR-17
> using channel ORA_DISK_1
> channel ORA_DISK_1: starting full datafile backup set
> channel ORA_DISK_1: specifying datafile(s) in backup set
> input datafile file number=1 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_system_dbz6nx14_.dbf
> input datafile file number=3 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_sysaux_dbz6m573_.dbf
> input datafile file number=5 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_new_user_dcchkvk9_.dbf
> input datafile file number=4 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_undotbs1_dcczlbll_.dbf
> input datafile file number=6 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_tbs_user_dccnlhxy_.dbf
> input datafile file number=7 name=/u01/app/oracle/oradata/
> TERRA1/datafile/o1_mf_new_user_dcchkvnx_.dbf
> channel ORA_DISK_1: starting piece 1 at 15-MAR-17
> channel ORA_DISK_1: finished piece 1 at 15-MAR-17
> piece handle=/u01/app/oracle/fast_recovery_area/TERRA1/
> backupset/2017_03_15/o1_mf_nnndf_TAG20170315T021022_ddkm6036_.bkp
> tag=TAG20170315T021022 comment=NONE
> channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45
> Finished backup at 15-MAR-17
>
> Starting backup at 15-MAR-17
> current log archived
> using channel ORA_DISK_1
> channel ORA_DISK_1: starting archived log backup set
> channel ORA_DISK_1: specifying archived log(s) in backup set
> input archived log thread=1 sequence=72 RECID=133 STAMP=938657529
> channel ORA_DISK_1: starting piece 1 at 15-MAR-17
> channel ORA_DISK_1: finished piece 1 at 15-MAR-17
> piece handle=/u01/app/oracle/fast_recovery_area/TERRA1/
> backupset/2017_03_15/o1_mf_a_TAG20170315T021210_ddkm9bgq_.bkp
> tag=TAG20170315T021210 comment=NONE
> channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
> channel ORA_DISK_1: deleting archived log(s)
> archived log file name=/u01/app/archivelog/arc_1_72_936747113.arc
> RECID=133 STAMP=938657529
> Finished backup at 15-MAR-17
>
> Starting Control File and SPFILE Autobackup at 15-MAR-17
> piece handle=/u01/backup/controlfile/control_file_c-2182710439-20170315-00.ctl
> comment=NONE
> Finished Control File and SPFILE Autobackup at 15-MAR-17
>
>
> 2) rm -rf em todos os datafiles, controlfiles, redo logs, spfile e init.
>
>
> 3) Restaurando o spfile
>
> RMAN> set dbid=2182710439 <(21)%208271-0439>
>
> executing command: SET DBID
>
> RMAN> startup nomount;
>
> startup failed: ORA-01078: failure in processing system parameters
> LRM-00109: could not open parameter file '/u01/app/oracle/product/12.1.
> 0.2/db_1/dbs/initTERRA1.ora'
>
> starting Oracle instance without parameter file for retrieval of spfile
> Oracle instance started
>
> Total System Global Area1073741824 bytes
>
> Fixed Size 2932632 bytes
> Variable Size281018472 bytes
> Database Buffers 784334848 bytes
> Redo Buffers 5455872 bytes
>
> RMAN> set dbid=2182710439 <(21)%208271-0439>
>
> executing command: SET DBID
>
> RMAN> restore
