Eu penso que vc está pecando no Conceito aqui : o CONTROLFILE guarda apenas a 
lista/localização dos arquivos que compõem o database e algumas informações 
gerais, como por SCN (um número de controle interno do banco), além de servir 
de repositório para o RMAn se não estiver sendo usado um catalog... Assim, 
quando vc diz "...restaurei o controlfile a partir do backup do dia anterior e 
não tinha essa tabela lá..." isso ABSOLUTAMENTE não faz o menor sentido, o 
CONTROLFILE *** não ** guarda informações sobre objetos internos, okdoc ? Isso 
é guardado na tablespace SYSTEM do database...

 Pelo que entendi, o que aconteceu foi que vc restaurou o controlfile da hora 
do backup (que continha o número de controle/SCN x), mas os datafiles (que 
também mantém essa info nos seus cabeçalhos) estavam com um SCN mais adiantado 
, x+n, : aí, quando vc pediu o RECOVER DATABASE sem especificar até quando 
recuperar, E vc estava em modo de archive ainda na ocasião E vc tinha todos os 
archives, o recover localizou o archive referente ao SCN x do controlfile, o 
aplicou, localizou o próximo, o aplicou, assim por diante, até chegar ao SCN 
x+n marcado nos datafiles...

 Para vc simular um cenário de perda de dados, faz assim : agora que o banco 
está em noarchive, tira um novo backup CONSISTENT via RMAN (com banco em 
MOUNT), registrando o fato do db estar em noarchive, e só depois disso cria uma 
nova tabela, insere e comita uns dados... Depois para simular um crash vc apaga 
um datafile qualquer (provavelmente antes pedindo um SHUTDOWN ABORT e 
rebootando o servidor).... Aí vc vai ver que vc vai ter que voltar o backup, e 
o recover que fará depois disso vai reconhecer que o banco está em noarchive, 
então não terá redo a aplicar, só ira recuperar até o SCN da hora que foi feito 
o backup : a sua transação feita depois do backup tirado vai sumir....

 []s

   Chiappa

Responder a