Restore no RMAN falha com "ORA-01180: can not create datafile 1"

Depois de um tempo ausente, volto com este probleminha que já aconteceu comigo duas vezes.
Pediram-me para que eu restaurasse um banco de dados para criação de uma base de testes (ainda bem) e no momento da restauração algo assim aconteceu:

creating datafile No=1 name=/....../o1_mf_system_5n2w3nky_.dbf
released channel: t1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 09/05/2010 09:34:12
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '/....../o1_mf_system_5n2w3nky_.dbf'


Segundo o METALINK, isso acontece porque "O Rman acha que não tem backups pra restaurar, então ele recria os arquivos para aplicar os archives. No entanto isso não funciona para a tablespace SYSTEM". De fato é verdade. Quando tentamos restaurar os demais arquivos dá certo, só não para a SYSTEM.


Bom, no metalink ele diz que quando você executa um LIST BACKUP diz que existem backups disponíveis. O problema é que existem entradas duplicadas no controlfile, duas incarnações com o mesmo reset SCN:

DB Key	Inc Key	DB Name	DB ID	STATUS	Reset SCN	Reset Time
1	1	ORCL	3441889539	PARENT	1	20-NOV-07
3 (*)	3	ORCL	3441889539	CURRENT	2388963095	30-APR-08
2 (*)	2	ORCL	3441889539	PARENT	2388963095	26-APR-08

A única forma de isso acontecer é se o controlfile foi restaurado de um backup frio via sistema operacional e então outro resetlogs foi executado, gerando o mesmo SCN.


Todos os backups pertencentes a ambas as incarnações (2 e 3) se tornam ao mesmo tempo backups órfãos e atuais.


O metalink informa que isso é um BUG (Bug 5844752).


Mas existe também outra condição que pode resultar neste problema (no meu caso). Quando há um RESETLOGS gerando uma nova incarnação (daí são criados alguns arquivos físicos, etc) e é executado um "RESET DATABASE TO INCARNATION X" para voltar a incarnação anterior (por motivos ainda desconhecidos). Então a incarnação nova (criada com o resetlogs) fica ORPHAN (órfã) gerando o mesmo problema.


Usando a mesma tabela acima como exemplo, o resultado fica mais ou menos assim:

DB Key	Inc Key	DB Name	DB ID	STATUS	Reset SCN	Reset Time
1	1	ORCL	3441889539	CURRENT	1	20-NOV-07
2	2	ORCL	3441889539	ORPHAN	2388963095	30-APR-08

Desta forma o erro acontece na hora da restauração.




O problema é você precisar restaurar esse backup e ele estar nestas condições, por isso é importante saber se está tudo em ordem (incarnações anteriores PARENT e a última CURRENT) antes de realizar os backups para que não aconteçam problemas durante a restauração.


Para os dois casos similares a recriação do controlfile, recatalogação dos backups e restore pode funcionar. Isso para contornar o problema em caso de tentativa de restauração do backup.


O procedimento é:
1. Restaurar o controlfile primeiramente;
2. Gerar um script de recriação do controlfile (backup controlfile to trace;)
3. Recriar o controlfile;
4. Recatalogar os backups;
5. Executar a restauração;
6. Rezar.


Para corrigir o problema na base atual (para que os backups fiquem OK) você pode apenas executar um "RESET DATABASE TO INCARNATION X" voltando para última incarnação (que estava ORPHAN). Recriar o controlfile também deve solucionar o problema, mas é interessante analisar o caso e, preferencialmente, realizar um backup para executar um método ou o outro. Comigo, no caso da incarnação ORPHAN, corrigi o problema apenas executando um "RESET DATABASE TO INCARNATION". Após isso executei um backup e um restore sem problemas.


UPDATE 11/07/2011:


Passei por um problema desse aí galera, mais uma vez, semana passada. No entanto eu percebo que esse problema pode acontecer em situações diferentes e nem sempre vai ter uma explicação bem concreta sobre o caso.


Um amigo que trabalha comigo estava tentando restaurar uma base em outro servidor. Copiou o backup e na hora de restaurar o erro era diferente.
O RMAN dizia que não existia backups daqueles datafiles, apesar de estar listando no RMAN normalmente:


RMAN-06023: no backup or copy of datafile 1 found to restore


Achávamos que era por causa do NFS (estávamos testando restaurar pelo NFS por conta do pouco espaço em disco local), mas mesmo copiando dava o mesmo erro.


Decidi então listar as incarnações novamente no servidor onde o backup estava sendo restaurado pra ver o que tinha lá. Apareceram 3 incarnações:


PARENT         12-FEV-2008
PARENT         23-OUT-2010
CURRENT      01-JUL-2011


Em produção apareciam só as duas primeiras:


PARENT ...
CURRENT ...


Ninguém realizou resetlogs algum no servidor antes de ser tentado restaurar essa base de dados e muito menos em produção.


Restauramos o controlfile novamente e listamos as incarnações. Apareceu igual como produção. Após recatalogarmos os arquivos de backup, para registrar inclusive os backups de archives, e apareceu a bendita incarnação fantasma de 01-JUL-2011. Sem explicação resolvemos executando um RESET DATABASE TO INCARNATION X (anterior a de 01-JUL) e o backup foi restaurado sem problemas. Alguma coisinha errada tava informando ao banco de dados esse suposto "resetlogs" mesmo sem ter sido executado em produção.


Até mais.