Carlos, se vc tem ** 100% ** de certeza que o comando de RESTORE DATABASE tá restaurando o backup correto (eu particularmente ** tenho uma birra e não confio ** no default do RESTORE sem argumento nenhum, sempre peço um RESTORE DATABASE usando um LABEL específico, e/ou se estou usando controlfile como catálogo depois de restaurar o controlfile manda um list backup e ** REMOVO ** os backups todos que não interessam), que não havia nenhum tipo de standby e/ou de retention setado no RMAN ou coisa assim ** segurando ** a necessidade para o archive que contém essa sequência bem antiga E QUE o controlfile que vc restaurou é o mais recente (E QUE o controlfile apontado pelo spfile/initfile é esse correto, E que ele foi removido certinho do disco), pra mim o que pode estar acontecendo aí é :
a) vc ** NÃO APAGOU ** os archives que tinha em disco na área de archive (o que parece ser o caso, já que vc cita "..deletando todos os arquivos do servidor, SPFILE, PFILE, TEMPFILE, CONTROLFILE, UNDO, SYSTEM, TODOS OS DATAFILES e REDO LOGS" - NÃO VI referência a deleção aos archives -, e por bug/comportamento inadequado o RMAN tentou restaurar um desses archives e esse archive ainda referenciava uma sequência antiga ou b) vc ainda tem catalogado nesse RMAN archives muito antigos (ie, vc *** NÃO PEDIU *** um DELETE EXPIRED antes), e por BUG /comportamento inadequado o RMAN ainda está procurando por esses archives a e b são maaais ou menos parecidos com o que é notado no documento 235973.1 do metalink, grosso modo.... ou c) nada impede que por algum motivo (transação de longa duração, delayed apply, o que for) não tenha havido o checkpoint/aplicação no datafile o redo contido nesse archive antigo, aí a leitura consistente que o RMAN faz voltou, voltou e voltou até esse redo.... O grande detalhe é que, ** se ** o RMAN por causa de algo nesse estilo (transação longa, ou o que for) precisa de algum redo constante no archive X ** E ** consultando o catálogo ele verificar que X já foi backupeado, salvo instrução contrária mesmo que X ainda esteja em disco ele *** NÃO VAI BACKUPEAR X **, ok ? O conceito é, o BACKUP DATABASE PLUS ARCHIVELOG vai te backupear além dos datafiles os archives todos que sejam necessários *** MAS QUE *** ainda não foram backupeados anteriormente, sim sim sim ???? Vc NÃO PODE pensar no jogo de backup criado pelo database plus archivelog como uma unidade autônoma, pois ele *** CONFIA *** que eventuais archives mais antigos eventualmente necessários que constam como catalogados VÃO SIM estar disponíveis, ok ?? ==> EU particularmente desconfio de a) ou b) , ie, o controlfile erradamente referenciando archives velhos que vc não removeu dele (o que configuraria SIM bug/comportamento inadequado), mas até pode ser que c) seja a sua razão... Já que vc está testando, eu diria para vc REFAZER teu teste com um outro banco de testes Atentando-se à questão de deletar o que estiver expired, ter apenas um backup registrado no controlfile (se controlfile é onde tá teu catálogo) ou então especificar DIRETAMENTE o backup que vc quer restaurar, etc, etc... E PLZ *** peça *** um RESTORE PREVIEW pra ver exatamente o que vai ser necessário pra restaurar ok ? Recomendo também que vc inclua na sua rotina antes do backup o seguinte : sql 'alter system switch logfile'; sql 'alter system archive log current'; []s Chiappa
