Um grande amigo me pediu uma ajuda para identificar um problema em um Data Guard, achei que seria legal compartilhar como fixar o problema do ORA-19909
Vamos ao nosso laboratório
Primary:
DB Name: DUSTOP
Standby:
DB Unique Name: DUTSB
========
Redo apply no standby falhou repentinamente, conforme mostrado no alert.log:
Thu Oct 09 14:40:13 CST 2023
Media Recovery Log < directory >/DUTSB/arch/DUTSB_1_699789524_129430.arc[1]
Thu Oct 10 14:40:26 CST 2023
Media Recovery Waiting for thread 1 sequence 129431 [2]
Thu Oct 10 14:44:34 CST 2023
Redo Shipping Client Connected as PUBLIC
— Connected User is Valid
RFS[4]: Assigned to RFS process 24267
RFS[4]: Identified database type as ‘physical standby’
RFS[4]: Archived Log: ‘< directory >/DUTSB/arch/DUTSB_1_800028335_10.arc’
RFS[4]: Physical Standby in the future of Branch(resetlogs_id) 800028335
RFS[4]: Standby database SCN: 1746:-485073214 Primary branch SCN: 1746:-486307562
RFS[4]: New Archival REDO Branch(resetlogs_id): 800028335 Prior: 699789524
RFS[4]: Archival Activation ID: 0x5a34242d Current: 0x2f28438f
RFS[4]: Effect of primary database OPEN RESETLOGS
RFS[4]: Managed Standby Recovery process is active
New incarnation branch detected in ArchiveLog, filename < directory >/DUTSB/arch/DUTSB_1_800028335_10.arc [3]
Inspection of file changed rdi from 1 to 2
Setting recovery target incarnation to 2
Thu Oct 10 14:44:37 CST 2023
MRP0: Incarnation has changed! Retry recovery…
Thu Oct 10 14:44:37 CST 2023
Errors in file < directory >/DUTSB/admin/bdump/DUTSB_mrp0_20506.trc:
ORA-19906: recovery target incarnation changed during recovery [4]
Recovery interrupted!
Thu Oct 10 14:44:40 CST 2023
Errors in file < directory >/DUTSB/admin/bdump/DUTSB_mrp0_20506.trc:
ORA-19906: recovery target incarnation changed during recovery
Thu Oct 10 14:45:00 CST 2023
Managed Standby Recovery not using Real Time Apply
Warning: Recovery target destination is in a sibling branch
of the controlfile checkpoint. Recovery will only recover
changes to datafiles.
Datafile 1 (ckpscn 7502822792898) is orphaned on incarnation#=1
MRP0: Background Media Recovery terminated with error 19909
Thu Oct 10 14:45:00 CST 2023
Errors in file < directory >/DUTSB/admin/bdump/DUTSB_mrp0_20506.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation [5]
ORA-01110: data file 1: ‘< directory >/DUTSB/data02/system01.dbf’
Thu Oct 10 14:45:00 CST 2023
Errors in file < directory >/DUTSB/admin/bdump/DUTSB_mrp0_20506.trc:
ORA-19909: datafile 1 belongs to an orphan incarnation
Isso ocorre porque o banco de dados standby, por diversos motivos, é aberto com resetlogs e informações que residem no FRA. O RMAN cataloga implicitamente o FRA, fazendo com que as informações sobre esta encarnação de “teste” sejam inseridas no arquivo standby controlfile que esta montado. Portanto existe informação sobre uma nova encarnação.
Para resolver o problema, no standby:
Opção 1:
Redefina a encarnação para a encarnação anterior que corresponda à primária. Por exemplo:
Esta é a encarnação do banco de dados primário:
RMAN> list incarnation of database;
using target database control file instead of recovery catalog
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
——- ——- ——– —————- — ———- ———-
1 1 DUTSOP 791150198 CURRENT 121289826 02-JUN-23
Esta é a encarnação do banco de dados Standby
RMAN> list incarnation of database;
using target database control file instead of recovery catalog
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
——- ——- ——– —————- — ———- ———-
1 1 DUTSB 791150198 PARENT 121289826 02-JUN-23
2 2 DUTSB 791150198 CURRENT 7502821558550 22-AGO-23
No standby, execute:
RMAN> reset database to incarnation 1;
Opção 2:
Limpe as informações FRA associadas aos resetlogs executados no Standby.
1) remover arquivos archivelog e/ou autobackups de controlfile que foram gerados pelo standby quando ele foi ativado (aberto com resetlogs). Deixe apenas os arquivos archivelog recebidos do primário.
2) considere atualizar o arquivo de controlfile do standby com uma cópia do primário para remover informações de encarnação desnecessárias do v$database_incarnation do controlfile do standby
3) inicie a recuperação manual, aplicando o próximo archivelog do primário para confirmar que a recuperação continuará executando.
4) reinicie a recuperação automática no standby
Te vejo em breve em outros artigos.
Fique ligado seguindo no twitter @aontalba and Linkedin.
Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies, or opinions. The information here was edited to be useful for general purpose, specific data, and identifications was removed to allow reach a generic audience and to be useful.”
