RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 01/10/2017 16:42:19 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script ORA-00283: recovery session canceled due to errors RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed start until change 226605 using backup controlfile ORA-00283: recovery session canceled due to errors ORA-19909: datafile 1 belongs to an orphan incarnation ORA-01110: data file 1: '/u01/app/oracle/oradata/dbtst/system.dbf'
Como a liberação da base era importante para a continuidade dos negócios, verifiquei o incarnation do ambiente produtivo e realizei o reset do incarnation do ambiente auxiliary para a mesma incarnação do produção, conclui o recover e demais etapas necessárias.
DBPROD:
RMAN> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 1 DBPRD 3274873056 CURRENT 1 30-OCT-17
DBTST:
RMAN> list incarnation; using target database control file instead of recovery catalog List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 1 DBPRD 3274873056 PARENT 1 30-OCT-17 2 2 DBPRD 3274873056 ORPHAN 221767 05-NOV-17 4 4 DBPRD 3274873056 ORPHAN 222025 05-NOV-17 3 3 DBPRD 3274873056 CURRENT 222452 05-NOV-17 RMAN> reset database to incarnation 1; database reset to incarnation 1 RMAN> list incarnation of database; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 1 1 DBPRD 3274873056 CURRENT 1 30-OCT-17 2 2 DBPRD 3274873056 ORPHAN 221767 05-NOV-17 4 4 DBPRD 3274873056 ORPHAN 222025 05-NOV-17 3 3 DBPRD 3274873056 ORPHAN 222452 05-NOV-17 <.. recover e demais processos ..>
Na semana seguinte fui notificado da mesma ocorrência, fiz o mesmo procedimento para liberação do ambiente mas também fui analisar o motivo que gerava o erro para resolvê-lo de modo que não fosse necessário uma nova ação manual durante o próximo processo de duplicate.
Examinando o log de alertas do banco (alertlog), podemos constatar a ocorrência de vários "Setting recovery target incarnation to N" as 16:42:14 que represetam as mudanças de incarnation durante o processo de recover.
[oracle@tst1 /]$ vi $ORACLE_BASE/diag/rdbms/dbtst/dbtst/trace/alert_dbtst.log .. .. Tue Jan 10 16:41:29 2017 alter database mount Set as converted control file due to db_unique_name mismatch Changing di2dbun from DBPRD to DBTST Successful mount of redo thread 1, with mount id 3249055801 Database mounted in Exclusive Mode Lost write protection disabled Completed: alter database mount RMAN DUPLICATE: Errors in krbm_getDupCopy Errors in file /u01/app/oracle/diag/rdbms/dbtst/dbtst/trace/dbtst_ora_14094.trc: ORA-19625: error identifying file /u01/app/oracle/oradata/dbtst/system.dbf ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3 RMAN DUPLICATE: Errors in krbm_getDupCopy Errors in file /u01/app/oracle/diag/rdbms/dbtst/dbtst/trace/dbtst_ora_14094.trc: ORA-19625: error identifying file /u01/app/oracle/oradata/dbtst/sysaux.dbf ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3 RMAN DUPLICATE: Errors in krbm_getDupCopy Errors in file /u01/app/oracle/diag/rdbms/dbtst/dbtst/trace/dbtst_ora_14094.trc: ORA-19625: error identifying file /u01/app/oracle/oradata/dbtst/undotbs1.dbf ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3 Tue Jan 10 16:42:14 2017 Setting recovery target incarnation to 2 <======== Setting recovery target incarnation to 2 <======== Setting recovery target incarnation to 3 <======== Setting recovery target incarnation to 3 <======== Tue Jan 10 16:42:14 2017 Switch of datafile 1 complete to datafile copy checkpoint is 226585 Switch of datafile 2 complete to datafile copy checkpoint is 226597 Switch of datafile 3 complete to datafile copy checkpoint is 226594 alter database recover datafile list clear Completed: alter database recover datafile list clear alter database recover datafile list 1 , 2 , 3 Completed: alter database recover datafile list 1 , 2 , 3 alter database recover if needed start until change 226605 using backup controlfile Media Recovery Start Serial Media Recovery started Warning: Recovery target destination is in a sibling branch of the controlfile checkpoint. Recovery will only recover changes to datafiles. Datafile 1 (ckpscn 226585) is orphaned on incarnation#=1 Media Recovery failed with error 19909 ORA-283 signalled during: alter database recover if needed start until change 226605 using backup controlfile
Um pouco antes destas mensagens de mudança de incarnation podemos ver a ocorrência de outros erros juntamente com o nome de um arquivo de rastreamento (.trc). Abrindo o arquivo e pesquisando por incarnation podemos ver que eles ocorreram logo após a leitura de alguns archives pois neles foram identificados mudanças no incarnation deste database em decorrência de outras cargas com open resetlogs (sempre que ocorrer um RESETLOGS uma nova incarnation será gerada).
[oracle@tst1 /]$ vi /u01/app/oracle/diag/rdbms/dbtst/dbtst/trace/dbtst_ora_14094.trc .. .. *** 2017-01-10 16:42:14.546 *** ACTION NAME:(0000023 STARTED124) 2017-01-10 16:42:14.546 New incarnation branch detected in ArchiveLog, filename /oraarchive/DBTST/archivelog/2017_11_05/dbtst_1_1_959263858.arc Inspection of file changed rdi from 1 to 2 New incarnation branch detected in ArchiveLog, filename /oraarchive/DBTST/archivelog/2017_11_05/dbtst_1_1_959265418.arc Inspection of file changed rdi from 2 to 3 New incarnation branch detected in ArchiveLog, filename /oraarchive/DBTST/archivelog/2017_11_05/dbtst_1_1_959264815.arc
Para solucionar o "problema" basta mover/remover os archives indicados (possivelmente já desnecessários) ou apontar a FRA (Fast Recovery Area) para outro destino onde não exitam archives com o mesmo dbid, caso não esteja sendo utilizado a recovery area basta mudar o apontamento do log_archive_dest_1, por exemplo.
Mas por que o processo de recover lê estes archives com outras incarnações?
A partir da versão 11.2.0.3 o comando foi alterado para catalogar todos os arquivos(archives) abaixo do local onde foi configurado a recovery area ou log_archive_dest_N do banco auxiliary, desta forma o "catalog clone start with +DISKGROUP" lê e cataloga todos os arquivos abaixo do diretório que contenham o mesmo DBID da base que está sendo clonada.
Este cenário ocorre normalmente nos casos em que:
FRA está configurada:
*.db_recovery_file_dest='+RECO1'
log_archive_dest_N utilizando LOCATION=+DISKGROUP:
*.log_archive_dest_1='LOCATION=+RECO1'
Para evitar o erro reaponte para outro destino conforme supracitado:
*.db_recovery_file_dest='+RECOC4'
*.log_archive_dest_1='LOCATION=+RECOC4/newdb'
contents of Memory Script:
{
backup as copy reuse
archivelog like "+RECOC4/luz/archivelog/2014_07_18/thread_1_seq_1742.2339.853243229" auxiliary format "+RECOC4/newdb/1_1742_847627148.dbf" ;
catalog clone archivelog "+RECOC4/newdb/1_1742_847627148.dbf"; <======== é catalogado apenas o archive copiado
switch clone datafile all;
}
NOTA:
No cenário de exemplo acima copiei os archives com novas incarnações para dentro do diretório da base DBTST para simular o problema.
[oracle@tst1 /]$ cp /oraarchive/DBPRD/archivelog/2017_11_05/* /oraarchive/DBTST/archivelog/2017_11_05/
e durante o recover:
contents of Memory Script:
{
backup as copy reuse
archivelog like "/oraarchive/DBPRD/archivelog/2017_01_10/o1_mf_1_14_d7bbr54c_.arc" auxiliary format
"/oraarchive/DBTST/archivelog/2017_01_10/o1_mf_1_14_%u_.arc" ;
catalog clone recovery area; <======== catalogando todos os arquivos abaixo da FRA
switch clone datafile all;
}
Referências:
RMAN-11003 ORA-283 ORA-19909 during duplicate database (Doc ID 1913573.1)
Manual Completion of a Failed RMAN Backup based Duplicate (Doc ID 360962.1)
0 comentários:
Postar um comentário