Obrigado mais vez chiappa, entendi sim agora o funcionamento do restore, realmente o banco com datafiles com SCN diferentes nao teria jeito, eu pensei que todos estariam no mesmo SCN, mas com a sua explicação percebi pq com backup hot os SCN ficam inconsistentes. Vou fazer tudo que você me recomendou e posto aqui o ocorrido. Mas fiquei ainda com uma dúvida inicial e uma outra que me surgiu agora...Se você pudesse me ajudar agradeceria muito.
Até então, eu só tinha visto cenários de perdaS (falo de perdas de todos) de controlfile com opção de abrir o database no final com "open resetlogs", até o material de backup e recovery do RIcardo Portilho quando se perde todos os controlfiles no final é pedido para abrir o database com open reset logs. Esse cenário (https://www.youtube.com/watch?v=lRxdKs0mKSk) que segui pegando as informações de backup do trace do controlfile e abrindo o database sem a opção de resetlogs isso pra mim então era novidade. A outra duvida nova que me surgiu, foi a seguinte: Quando abro o database sem resetlogs ele nao cria uma nova incarnation? Quando restauro um controlfile sem resetlogs ele continua na mesma incarnation? Você poderia me ajudar a explicar a respeito o que significa um incarnation? Em Terça-feira, 7 de Março de 2017 16:17, "jlchia...@yahoo.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: Vou te responder começando pelos últimos itens : "Outra coisa, posso abrir o database sem a opção de recovery e abrir com resetlogs perdendo dados? Já que o restore funcionou? " ==> como eu disse antes, quando vc faz um backup HOT (ie, com o banco Ativo e Funcionando, o que é seu caso) ** necessariamente ** os datafiles do RDBMS ** vão ** estar inconsistentes entre si : nada impede que o datafile 1 esteja com o SCN 1000, o datafile 2 esteja com SCN anterior, digamos 900, o datafile 3 esteja com SCN 1500, sei lá... OU SEJA, eles estão COMPLETAMENTE INCONSISTENTES entre si, esses SCNs diferentes indicam que os dados nos datafiles foram gravados em PERÍODOS DE TEMPO completamente diferentes - isso é o NORMAL durante o funcionamento do banco Oracle, pois (para propiciar melhor performance) as alterações/inclusões/deleções são feitas em memória primeiro E o fluxo de bytes necessário para atualizar o datafile em disco é gravado no REDO LOG FILE, que depois é archivado.... Assim, se uma informação estava como AAA no bloco em disco de datafile e alguém fez um UPDATE trocando para BBB, para melhor performance o datafile *** NÃO VAI SER GRAVADO IMEDIATAMENTE **, apenas esses bytes BBB (e uns bytezinhos de controle a mais) é que são gravados no redo log file..... No futuro, não sabemos quando mas sempre em background, aos pouquinhos, é que esses bytes de alteração são gravados no datafile, lentamente e aos puoquinhos por vez... Dado que o RESTORE apenas e tão somente restaurou ** OS DATAFILES **, fica ** ULULANTEMENTE ÓBVIO ** que se teu backup é HOT vc NÂO PODE usar só isso, pois podem haver ** SIM ** (e normalmente há mesmo) dados que NÂO FORAM GRAVADOS nos datafiles, né ?? Tá claro ?? Aí #comofaz pra vc abrir um conjunto de datafiles com informações gravadas em períodos de tempo INCOMPATÍVEIS entre si ??? Não faz, essa é a resposta, vc NÂO ABRE CONSISTENTEMENTE esse database SEM aplicar os archives que contém as alterações TODINHAS que não tinham sido ainda gravadas nos datafiles quando do backup... Não é à toa que o manual Oracle chama o backup hot de database também de BACKUP INCONSISTENTE, é por essa razão aí em cima exposta.... É por causa desse mecanismo normal do RDBMS Oracle que para bancos em modo não-archive vc só pode fazer backup com banco fechado, situação em que NECESSARIAMENTE o RDBMS foi ** obrigado ** a baixar pros datafiles em disco as alterações TODINHAS que estavam nos redo log files antes de fechar com sucesso : neste caso SIM, o simples RESTORE já trouxe tudo que precisava pra vc abrir o banco consistentemente.... OBS : apenas para completar a minha resposta (e nunca para casos de utilização normal, em especial NUNCA num banco de produção!!), cito que até há alguns procedimentos para vc "forçar" um banco cujos datafiles não estão "compatíveis" entre si (ie, que foram alterados em períodos totalmente diferentes entre si e portanto possuem SCNs muito maiores ou menores entre si) e cujos archives que contém as alterações necessárias estejam indisponíveis : basicamente vc vai usar o parâmetro "secreto"/interno _ALLOW_RESETLOGS_CORRUPTION=TRUE e abrir com RESETLOGS.... Nem preciso dizer que isso é uma medida TOTALMENTE EMERGENCIAL e DESSESPERADA, que PODE ou Não Funcionar (até porque inclusive tabelas ** INTERNAS **, de Sistema, do database em si, podem estar incompletas/com alterações não-presentes), E que vai ser um festival de tabelas filhas sem pai, dados inválidos e quetais SE esse banco abrir.... "quando se tem um cenário de perda total de controlfiles vc abre o database com a opção resetlogs;" ==> opa, atenção aí : como eu disse antes, o controlfile contém uma informação *** CRUCIAL *** que é o SCN corrente, bem como outras tão cruciais quanto, como a própria lista de arquivos que compõem o database - assim, se vc perder todos os controlfiles (e eu falo NO PLURAL, "os" controlfiles, justamente porque dada a criticidade enorme da informação presente em controlfiles a Oracle via de regra ** DUPLICA ** a informação, mantendo ao menos dois controlfiles ao mesmo tempo, um cópia do outro), vc além de usar o RESETLOGS vc OBVIAMENTE tem que ter um BACKUP QUE CONTENHA os controlfiles, OU então vc pode recriar manualmente o controlfile se vc tiver um script gerado pelo BACKUP CONTROLFILE TO TRACE , seja do próprio banco seja de outro que vc possa adaptar pro banco em questão ... Se vc não tem NADICA DE NADA disso, só o RESETLOGS em si ** não vai ** sincronizar os SCNs nos datafiles nem vai criar nada da informação que havia nos controlfiles perdidos - isso tá longamente explicado em https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:19198234148075 além da Documentação.... "Acho que deve ter sido por algum restore de controle file sem backup que eu fiz, realizei um restore pegando informações do backup controlfile trace. E abri o database sem a opção de open resetlogs;" ==> aí que tá : logo NAS PRIMEIROS msgs questionamos se Realmente o controlfile que vc pegou continha a informação correta, questionamos se vc Casualmente não tinha outros controlfiles anteriores presentes no diretório destino dos controlfiles e assim casualmente tenha havido alguma "sobreposição" por procedimento errado.... Por ISSO que eu sugeri na minha resposta anterior : dado esse cenário estranho antes de pensar em bugs antes de mais nada eu consideraria este último teste como FURADO e faria um novo teste com um dos outros bancos-testes aí do seu ambiente, dessa vez PASSO-A-PASSO cuidadosamente, PESQUISANDO o SCN dos datafiles, dos LOG FILES ** E ** do controlfile no momento do backup, se certificando de ter SWITCH e ARCHIVE CURRENT no script, CONSULTANDO as configs do RMAN via SHOW ALL antes, se CERTIFICANDO de remover os backups desnecessários/expirados do catálogo..... Aí, na hora de testar o RESTORE, ** antes disso ** vc se CERTIFICA 100% que não há NENHUM dos arquivos que compõem um database no diretório-alvo (arquivos que compõem um database = DATAFILES + CONTROLFILES + REDO LOG FILES + ARCHIVED REDO LOG FILES + SPFILE (ou initfile), se for o caso), antes de restaurar depois de ter os arquivos de backup disponíveis no local destino vc pede um PREVIEW , faz o restore ** especificando diretamente ** o backup que vc quer restaurar (via LABEL ou ID ou o que for)..... Tudo no passo-a-passo, no sapatinho, sim sim ??? Apenas SE e SOMENTE assim procedendo ele pedir por um archive inesperado ou coisa assim é que aí sim podemos indicar BUG, sim sim sim ??? []s Chiappa #yiv0591545053 #yiv0591545053 -- #yiv0591545053ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0591545053 #yiv0591545053ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0591545053 #yiv0591545053ygrp-mkp #yiv0591545053hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0591545053 #yiv0591545053ygrp-mkp #yiv0591545053ads {margin-bottom:10px;}#yiv0591545053 #yiv0591545053ygrp-mkp .yiv0591545053ad {padding:0 0;}#yiv0591545053 #yiv0591545053ygrp-mkp .yiv0591545053ad p {margin:0;}#yiv0591545053 #yiv0591545053ygrp-mkp .yiv0591545053ad a {color:#0000ff;text-decoration:none;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ygrp-lc {font-family:Arial;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ygrp-lc #yiv0591545053hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ygrp-lc .yiv0591545053ad {margin-bottom:10px;padding:0 0;}#yiv0591545053 #yiv0591545053actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv0591545053 #yiv0591545053activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv0591545053 #yiv0591545053activity span {font-weight:700;}#yiv0591545053 #yiv0591545053activity span:first-child {text-transform:uppercase;}#yiv0591545053 #yiv0591545053activity span a {color:#5085b6;text-decoration:none;}#yiv0591545053 #yiv0591545053activity span span {color:#ff7900;}#yiv0591545053 #yiv0591545053activity span .yiv0591545053underline {text-decoration:underline;}#yiv0591545053 .yiv0591545053attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv0591545053 .yiv0591545053attach div a {text-decoration:none;}#yiv0591545053 .yiv0591545053attach img {border:none;padding-right:5px;}#yiv0591545053 .yiv0591545053attach label {display:block;margin-bottom:5px;}#yiv0591545053 .yiv0591545053attach label a {text-decoration:none;}#yiv0591545053 blockquote {margin:0 0 0 4px;}#yiv0591545053 .yiv0591545053bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv0591545053 .yiv0591545053bold a {text-decoration:none;}#yiv0591545053 dd.yiv0591545053last p a {font-family:Verdana;font-weight:700;}#yiv0591545053 dd.yiv0591545053last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv0591545053 dd.yiv0591545053last p span.yiv0591545053yshortcuts {margin-right:0;}#yiv0591545053 div.yiv0591545053attach-table div div a {text-decoration:none;}#yiv0591545053 div.yiv0591545053attach-table {width:400px;}#yiv0591545053 div.yiv0591545053file-title a, #yiv0591545053 div.yiv0591545053file-title a:active, #yiv0591545053 div.yiv0591545053file-title a:hover, #yiv0591545053 div.yiv0591545053file-title a:visited {text-decoration:none;}#yiv0591545053 div.yiv0591545053photo-title a, #yiv0591545053 div.yiv0591545053photo-title a:active, #yiv0591545053 div.yiv0591545053photo-title a:hover, #yiv0591545053 div.yiv0591545053photo-title a:visited {text-decoration:none;}#yiv0591545053 div#yiv0591545053ygrp-mlmsg #yiv0591545053ygrp-msg p a span.yiv0591545053yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv0591545053 .yiv0591545053green {color:#628c2a;}#yiv0591545053 .yiv0591545053MsoNormal {margin:0 0 0 0;}#yiv0591545053 o {font-size:0;}#yiv0591545053 #yiv0591545053photos div {float:left;width:72px;}#yiv0591545053 #yiv0591545053photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv0591545053 #yiv0591545053photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv0591545053 #yiv0591545053reco-category {font-size:77%;}#yiv0591545053 #yiv0591545053reco-desc {font-size:77%;}#yiv0591545053 .yiv0591545053replbq {margin:4px;}#yiv0591545053 #yiv0591545053ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv0591545053 #yiv0591545053ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv0591545053 #yiv0591545053ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv0591545053 #yiv0591545053ygrp-mlmsg select, #yiv0591545053 input, #yiv0591545053 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv0591545053 #yiv0591545053ygrp-mlmsg pre, #yiv0591545053 code {font:115% monospace;}#yiv0591545053 #yiv0591545053ygrp-mlmsg * {line-height:1.22em;}#yiv0591545053 #yiv0591545053ygrp-mlmsg #yiv0591545053logo {padding-bottom:10px;}#yiv0591545053 #yiv0591545053ygrp-msg p a {font-family:Verdana;}#yiv0591545053 #yiv0591545053ygrp-msg p#yiv0591545053attach-count span {color:#1E66AE;font-weight:700;}#yiv0591545053 #yiv0591545053ygrp-reco #yiv0591545053reco-head {color:#ff7900;font-weight:700;}#yiv0591545053 #yiv0591545053ygrp-reco {margin-bottom:20px;padding:0px;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ov li a {font-size:130%;text-decoration:none;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv0591545053 #yiv0591545053ygrp-sponsor #yiv0591545053ov ul {margin:0;padding:0 0 0 8px;}#yiv0591545053 #yiv0591545053ygrp-text {font-family:Georgia;}#yiv0591545053 #yiv0591545053ygrp-text p {margin:0 0 1em 0;}#yiv0591545053 #yiv0591545053ygrp-text tt {font-size:120%;}#yiv0591545053 #yiv0591545053ygrp-vital ul li:last-child {border-right:none !important;}#yiv0591545053
