terça-feira, 6 de fevereiro de 2018

ORA-19909: datafile 1 belongs to an orphan incarnation

Durante a realização de um duplicate from active database, fui notificado que o processo havia falhado durante o recover da base de dados apresentando o erro ORA-19909 conforme detalhamento (case de exemplo) a seguir.


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)
Postagem mais recente Postagem mais antiga Página inicial

0 comentários:

Postar um comentário

Translate

# ACE Program

#Oracle

#Oracle
Disclaimer: The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

#Blog reconhecido

#ARTICULISTA

Marcadores

Postagens populares