Problema com Restores e Incarnations

Era um processo rotineiro de clonagem do banco de produção para o desenvolvimento. Não havia o que errar, o processo já estava no sangue e o fazia instintivamente. Até que essa semana fui surpreendido com um ORA-01180 – can not create datafile 1.

Refiz então o processo esperando que fosse só um erro ao acaso, voodoo talvez. Mas não, novamente o 01180. Apaguei os datafiles todos que eu tinha e refiz o processo. Mesmo problema. Notei que, assim que o RESTORE era executado uma nova incarnation era criada, o que é errado, já que a incarnation só deveria ser criada após o recover.

Tentei mudar para a incarnation original (reset database to incarnation 1) e refiz o restore. Sucesso. Ou, pelo menos, aparentemente sucesso.

Prossegui com o processo e bati em uma nova parede: erro no recover: ORA-19909: datafile 1 belongs to an orphan incarnation.

Ou seja, o restore criava uma nova incarnation assim que era executado e alternava para ela. Dava erro ORA-01180 e não restaurava. Ao mudar a incarnation na mão o restore concluía, porém os archivelogs não podiam ser aplicados.

Pesquisa daqui e dali. Cheguei a criar um SR no MOS. Até que achamos esse post do ucraniano Oleksandr Denysenko que relatava um problema similar, cuja solução não se aplicava a nossa situação. Porém, ele indicava uma entrada no suporte da Oracle a respeito de “Common Causes for RMAN-06023 and RMAN-06026”. Eu não havia tido esses erros, porém decidimos ler a entrada e, surpreendentemente, lá havia um parágrafo que explicava, enfim, o meu problema:

New incarnation added due to implicit resync

This is isssue is only relevant if a Flash | Fast Recovery Area (FRA) is being used.

If 1 or more restore and recovery attempts have been done for this database and the database has been opened with RESETLOGS,
than there might be archived redologs generated for this new incarnation of the database.

During the RMAN recovery-phase, RMAN will do an catalog of all the files in the FRA, and will catalog the new archived redologs aswell.
As they belong to another incarnation, the incarnation will be added (if not there) and will be marked as CURRENT.
The recovery will than look for archived redologs of a different incarnation than intended, as the CURRENT incarnation belongs to a prior RESETLOGS-operation

The best option is to remove all the old files from the FRA eg. flashbacklogs, archivelogs, backupsets, datafiles etc.
belonging to an incarnation of a prior attempt.

Então seguimos o conselho da entrada. Apagamos todos os datafiles novamente, todos os archivelogs e backupsets que estavam no servidor, e tentamos fazer o restore a partir de um backup novo e intocado. Sucesso. Prosseguimos para o recover. Sucesso!

Ou seja, o problema se deu com mais de um restore e recover sendo executados antes de o banco ser aberto com OPEN RESETLOGS.

Então, se alguém enfrentar esse mesmo problema, de incarnations sendo criadas assim que é executado o restore e que não é possível criar datafiles sem mudança de incarnation, muito provavelmente está enfrentando o mesmo problema que enfrentei. Boa sorte!