大家好，我是JiekeXu,江湖人稱“強哥”，青學會MOP技術社區主席，榮獲Oracle ACE Pro稱號，金倉最具價值倡導者KVA，崖山最具價值專家YVP，IvorySQL開源社區專家顧問委員會成員，墨天輪MVP，墨天輪年度“墨力之星”，擁有 Oracle OCP/OCM 認證,MySQL 5.7/8.0 OCP 認證以及金倉KCA、KCP、KCM、KCSM證書，PCA、PCTA、OBCA、OGCA等眾多國產數據庫認證證書,歡迎關注我的微信公眾號“JiekeXu DBA之路”，然后點擊右上方三個點“設為星標”置頂，更多干貨文章才能第一時間推送，謝謝！
前 言
這幾天總是能遇到一些莫名其妙的 Oracle 備庫出現的問題，也許是自己能力和知識面不夠，出現問題沒有找到根因，亦或者是 Oracle 的 BUG，但都沒法求證，本著首先恢復業務的原則，也不能刨根問底，時間也不允許，只能按照目前的經驗處理。最近又遇到一級聯備庫在斷開同步激活成讀寫庫的時候導致其他兩個備庫 MRP 進程中斷無法正常啟動，導致同步中斷，下面來一起看看問題排查過程及解決辦法。
操作過程
如下圖，我們簡單介紹一下這套環境的架構，1 號庫是我們本次操作的級聯 ADG 備庫 RAC 架構，需要將其激活成讀寫模式，然后 2 號庫相當于他的原庫，2 號庫還有一個單機級聯 ADG 3 號庫，2 號庫的源庫是 4 號庫 RAC，業務主庫。
下圖是官網 ADG 架構示意圖：
根據我們上面介紹的架構示意圖，在 2 號庫上斷開主備同步，禁用日志傳輸，在 1 號庫上激活級聯備庫為讀寫庫。
--2 號庫
show parameter arch
show parameter db_file_name_convert
show parameter log_file_name_convert
show parameter standby_file_management
show parameter fal_client
show parameter fal_server
show parameter log_archive
show parameter log_archive_config
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_config string DG_CONFIG=(jieke,jxrtadg,jiekeot)
--禁用日志傳輸及取消DG備庫配置
alter system set log_archive_dest_state_3=defer;
alter system set log_archive_config ='DG_CONFIG=(jieke,jiekeadg)';
這里指的 1 號庫就是我們需要激活為讀寫庫的數據庫，一條命令就搞定！
--1號庫 備庫激活讀寫
srvctl stop database -d jiekeot
sqlplus / as sysdba
startup mount
--alter system set log_archive_dest_state_2=defer;
create restore point flashback_20250901 guarantee flashback database;
select SCN,name from v$restore_point;
--drop restore point flashback_20250901;
--激活為讀寫模式
alter database activate standby database;
select NAME,OPEN_MODE,LOG_MODE,DATABASE_ROLE from gv$database;
--1號庫 RAC節點2
startup
問題現象
如上，操作也算是屬于正常操作流程，一時半會看不出有何問題，但過了一會兒，2 號庫和 3 號庫的 MRP 進程不存在了，出現了告警。立馬登錄 2 號庫(生產庫的備庫)查看，alert 日志如下：
2025-09-01T15:59:59.316300+08:00
TT00 (PID:20443): Error ORA-235 occurred during an un-locked control file <--可忽略
TT00 (PID:20443): transaction. This error can be ignored. The control
TT00 (PID:20443): file transaction will be retried.
2025-09-01T15:59:59.341296+08:00
TT02 (PID:24613): Cannot find SRL for T-1.S-2
2025-09-01T15:59:59.379866+08:00
rfs (PID:78114): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:2463801)
2025-09-01T15:59:59.873310+08:00
**ORA-205：**從 Oracle 12c 開始，控制文件事務得到了增強。在掃描特定的控制文件段（controlfile section）之前，我們不再需要請求控制文件隊列。這樣做的目的是最大限度地減少鎖定問題（locking issues），并提升性能與可擴展性（scalability）。由于這一變更，當某個控制文件段正被另一個進程修改時，讀取該控制文件段的進程有時可能會遇到 ORA-235 錯誤。出現這種情況時，讀取進程會直接重新讀取該段。您可以安全地忽略此錯誤信息，它并非實際問題。無法通過設置任何事件或初始化參數在數據庫層面抑制（suppress）這類錯誤。原因在于，盡管這些錯誤無害，但它們能反映出控制文件上的并發情況，且有助于排查與控制文件 I/O 緩慢等相關的問題 —— 因此，開發團隊專門新增了這一增強功能。最佳做法是修改所有監控腳本，讓其忽略或排除此錯誤。由于這是符合設計預期的正常行為，且這些錯誤僅為提示性信息（informational），因此完全可以忽略。接著往下看日志。
Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78114.trc:
ORA-00316: log 15 of thread 1, type 0 in header is not log file <---有 Bug 37555741 會出現這種情況
ORA-00312: online log 15 thread 1: '/data/jieke/fra/jiekedg/onlinelog/o1_mf_15_kz74bht7_.log'
2025-09-01T16:00:01.191910+08:00
Clearing online log 16 of thread 1 sequence number 0
2025-09-01T16:00:01.313156+08:00
rfs (PID:78515): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is ARCH (PID:900202)
rfs (PID:78515): New archival redo branch: 1210694362 current: 1129114545
2025-09-01T16:00:01.330323+08:00
rfs (PID:78526): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is ASYNC (PID:900208)
rfs (PID:78526): New archival redo branch: 1210694362 current: 1129114545
rfs (PID:78526): Primary database is in MAXIMUM PERFORMANCE mode
2025-09-01T16:00:01.436794+08:00
rfs (PID:78540): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:899936)
第一個錯誤 ORA-00316, type 0 in header is not log file 聯機日志已損壞或為舊版本，這里什么也沒做，怎么會有這個錯誤呢？當時沒想通，事后查 MOS 說可能是 Bug 37555741 - Enhance the ORA-316 error message with more description and solutions (Doc ID 37555741.8) ，在新發布的 23ai 版本 23.9.0.25.07 DBRU 中修復了，但我這里不是 bug，下文有詳細說明。接著往下看：
2025-09-01T16:00:01.596280+08:00 rfs (PID:78515): Selected LNO:27 for T-2.S-1 dbid 657075540 branch 1210694362 2025-09-01T16:00:01.655925+08:00 rfs (PID:78526): No SRLs available for T-2 2025-09-01T16:00:01.693947+08:00 rfs (PID:78515): A new recovery destination branch has been registered <--已注冊新的恢復目標分支 rfs (PID:78515): Standby in the future of new recovery destination branch(resetlogs_id) 1210694362 rfs (PID:78515): Incomplete Recovery SCN:0x00000000ad6c46ef <--完成恢復并 Resetlogs rfs (PID:78515): Resetlogs SCN:0x00000000ad65f284 rfs (PID:78515): SBPS:0x00000000ad65f281 rfs (PID:78515): Flashback database to SCN:0x00000000ad65f281 (-1385827711) to follow new branch <--閃回數據庫到指定的 SCN rfs (PID:78515): New Archival REDO Branch(resetlogs_id): 1210694362 Prior: 1129114545 rfs (PID:78515): Archival Activation ID: 0x381cb7fa Current: 0x37d48dcf rfs (PID:78515): Effect of primary database OPEN RESETLOGS <---主庫 OPEN RESETLOGS 的效果 rfs (PID:78515): Managed Standby Recovery process is active <--MRP0還是 active 2025-09-01T16:00:01.909730+08:00 PR00 (PID:73250): MRP0: Incarnation has changed! Retry recovery... <--MRP0出現Incarnation 分身 2025-09-01T16:00:01.909992+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_pr00_73250.trc: ORA-19906: recovery target incarnation changed during recovery <--恢復過程中恢復目標 incarnation 發生了變化 PR00 (PID:73250): Managed Standby Recovery not using Real Time Apply 2025-09-01T16:00:02.178418+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78540.trc: ORA-00316: log 16 of thread 1, type 0 in header is not log file ORA-00312: online log 16 thread 1: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_16_kz74ckbv_.log' 2025-09-01T16:00:02.178507+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78540.trc: ORA-00316: log 16 of thread 1, type 0 in header is not log file ORA-00312: online log 16 thread 1: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_16_kz74ckbv_.log' 2025-09-01T16:00:02.835458+08:00 TT02 (PID:24613): Cannot find SRL for T-1.S-435988 2025-09-01T16:00:03.616687+08:00 Recovery interrupted! 2025-09-01T16:00:04.548867+08:00 Clearing online log 25 of thread 2 sequence number 0 2025-09-01T16:00:05.195481+08:00 Recovered data files to a consistent state at change 123168755979 Stopping change tracking 2025-09-01T16:00:05.215300+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_pr00_73250.trc: ORA-19906: recovery target incarnation changed during recovery <--恢復過程中恢復目標 incarnation 發生了變化 2025-09-01T16:00:05.908878+08:00 TT02 (PID:24613): Cannot find SRL for T-1.S-0 2025-09-01T16:00:05.929365+08:00 Started logmerger process 2025-09-01T16:00:05.931772+08:00 TT02 (PID:24613): Cannot find SRL for T-1.S-435988 2025-09-01T16:00:05.942115+08:00 IM on ADG: End of Empty Journal PR00 (PID:79396): Managed Standby Recovery starting 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 123168755979) is orphaned on incarnation#=5 <--數據文件1（ckpscn 123168755979）在化身#=5時成為孤立文件 PR00 (PID:79396): MRP0: Detected orphaned datafiles! <--MRP0：檢測到孤立的數據文件! 2025-09-01T16:00:06.033747+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_pr00_79396.trc: ORA-19909: datafile 1 belongs to an orphan incarnation <--數據文件1屬于一個孤立的化身 ORA-01110: data file 1: '/data/jieke/datafile/system.378.1128999715' PR00 (PID:79396): Managed Standby Recovery not using Real Time Apply Stopping change tracking 2025-09-01T16:00:06.170633+08:00 Recovery Slave PR00 previously exited with exception 19909 2025-09-01T16:00:06.170873+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_mrp0_72231.trc: ORA-19909: datafile 1 belongs to an orphan incarnation <--數據文件1屬于一個孤立的化身，Oracle 僅報告遇到的第一個數據文件問題（文件#1）。此時所有數據文件都屬于一個孤立的實例 ORA-01110: data file 1: '/data/jieke/datafile/system.378.1128999715'
通常情況下，當備庫 resetlogs 打開后會出現這種情況。由于各種原因，備庫是以 resetlogs 模式打開的，且相關信息駐留在 FRA 中。RMAN 會隱式地對 FRA 進行編目，從而導致有關此實例的信息被插入到已裝載的備用控制文件中，因此，存在有關新實例的信息。 接下來的日志基本上都是“ORA-00316”和“ORA-00312”的關于 redo 文件頭損壞的錯誤，省略部分無關信息。
2025-09-01T16:00:07.046914+08:00 Clearing online log 26 of thread 2 sequence number 0 2025-09-01T16:00:08.178531+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78540.trc: ORA-00316: log 26 of thread 2, type 0 in header is not log file ORA-00312: online log 26 thread 2: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_26_kz74j9k5_.log' 2025-09-01T16:00:08.178585+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78114.trc: ORA-00316: log 26 of thread 2, type 0 in header is not log file ORA-00312: online log 26 thread 2: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_26_kz74j9k5_.log' 2025-09-01T16:00:08.571603+08:00 rfs (PID:78515): Opened log for T-1.S-435984 dbid 657075540 branch 1129114545 2025-09-01T16:00:08.813186+08:00 rfs (PID:78515): Archived Log entry 1371162 added for B-1129114545.T-1.S-435984 ID 0x37d48dcf LAD:2 2025-09-01T16:00:08.944878+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78540.trc: ORA-00316: log 26 of thread 2, type 0 in header is not log file ORA-00312: online log 26 thread 2: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_26_kz74j9k5_.log' 2025-09-01T16:00:16.394238+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_6383.trc: ORA-00316: log 14 of thread 1, type 0 in header is not log file ORA-00312: online log 14 thread 1: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_14_kz749cd6_.log' 2025-09-01T16:00:16.412872+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_85016.trc: ORA-00316: log 14 of thread 1, type 0 in header is not log file ORA-00312: online log 14 thread 1: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_14_kz749cd6_.log' 2025-09-01T16:00:17.235144+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekedg/jieke/trace/jieke_rfs_78114.trc: ORA-00316: log 14 of thread 1, type 0 in header is not log file ORA-00312: online log 14 thread 1: '/data/jieke/fra/jiekeDG/onlinelog/o1_mf_14_kz749cd6_.log' 2025-09-01T16:00:17.398664+08:00 rfs (PID:23835): Opened log for T-1.S-435985 dbid 657075540 branch 1129114545 2025-09-01T16:00:17.659551+08:00 rfs (PID:8672): Opened log for T-2.S-440963 dbid 657075540 branch 1129114545
問題解決
由于也是生產環境，需要優先恢復同步，啟動 MRP0 進程，然后再查原因，所以解決辦法就是去還原到原來的 incarnation，在以前 duplicate 的時候也遇到過類似的情況，處理也比較簡單。 然后分別登錄主備庫 Rman，查看化身 incarnation，status 列顯示當前化身的狀態，化身狀態一般有如下三種：
ORPHAN- 孤兒化身CURRENT- 數據庫的當前化身PARENT- 當前化身的父母
如上圖，數據庫的 incarnation 化身 1 從 SCN 1 開始，一直持續到 SCN 1000，然后到 SCN 2000。假設在化身 1的 SCN 2000 時，執行了一次時間點恢復到 SCN 1000，然后使用 RESETLOGS 選項打開數據庫。化身 2 現在從 SCN 1000 開始，一直持續到 SCN 3000。在這個例子中，化身 1 是化身 2 的父化身。
假設在化身 2 中的 SCN 3000，您執行了到 SCN 2000 的時間點恢復，并使用 RESETLOGS 選項打開了數據庫。在這種情況下，化身 2 是化身 3 的父化身。化身 1 是化身 3 的祖先。
當數據庫中發生 DBPITR 或閃回數據庫時，根據當前版本的不同，一個SCN（系統變更號）可以引用多個時間點。例如，圖中的 SCN 1500 可以引用版本 1 或版本 2 中的一個 SCN。
您可以使用 RESET DATABASE TO INCARNATION 命令來指定在特定數據庫版本的參照系中解釋 SCN。當您使用FLASHBACK、RESTORE 或 RECOVER 返回至非當前數據庫版本的某個 SCN 時，需要使用 RESET DATABASE TO INCARNATION 命令。但是，如“在恢復目錄中重置數據庫版本”所述，RMAN 在執行 FLASHBACK 時會自動執行RESET DATABASE TO INCARNATION 命令。
所以我們通過 rman reset database 設置一下就好，但這次執行 reset 卻報錯了，說已經存在于控制文件中無法刪除，無奈還是提緊急變更，重啟數據庫到 mount 后 reset database 得到恢復。
--主庫 select * from v$database_incarnation;
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 JIEKEXU 657075540 PARENT 1 2013-08-24 11:37:30
2 2 JIEKEXU 657075540 PARENT 925702 2016-10-27 10:24:22
3 3 JIEKEXU 657075540 PARENT 1682404406 2019-08-24 12:12:47
4 4 JIEKEXU 657075540 ORPHAN 71803922170 2023-02-07 16:31:34
5 5 JIEKEXU 657075540 CURRENT 72450305224 2023-02-18 10:55:45
備庫和級聯備庫操作如下：
--級聯備庫和備庫操作
SQL> shu immediate
SQL> startup mount
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 JIEKEXU 657075540 PARENT 1 2013-08-24 11:37:30
2 2 JIEKEXU 657075540 PARENT 925702 2016-10-27 10:24:22
3 3 JIEKEXU 657075540 PARENT 1682404406 2019-08-24 12:12:47
4 4 JIEKEXU 657075540 ORPHAN 71803922170 2023-02-07 16:31:34
5 5 JIEKEXU 657075540 PARENT 72450305224 2023-02-18 10:55:45
6 6 JIEKEXU 657075540 ORPHAN 77904788037 2023-07-15 11:19:45
7 7 JIEKEXU 657075540 CURRENT 123168223876 2025-09-01 15:59:22
RMAN> reset database to incarnation 5;
RMAN> list incarnation;
RMAN> sql'alter database open';
問題原因
事后通過排查 alert 日志發現，是由于要激活的這個備庫上的 ARCn 進程將歸檔日志文件（包含實例變更）發送到他現在配置的備庫，備庫又配置了級聯備庫，級聯備庫能夠識別備庫上的實例變更，并停止MRP0進程，導致這兩個備庫均出現中斷。下面來根據時間點看看日志內容就清楚了,通過查看 alert 日志 2025-09-01 15:59:22 執行激活讀寫命令，然后接著數據庫自己執行了 resetlogs 命令，恢復到 SCN 123168223875 time 09/01/2025 15:52:15時。
2025-09-01T15:58:49.980265+08:00 Created guaranteed restore point FLASHBACK_20250901 2025-09-01T15:59:22.048193+08:00 alter database activate standby database 2025-09-01T15:59:22.048238+08:00 ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE [Process Id: 2463823] (jiekeot1) 2025-09-01T15:59:22.056741+08:00 .... (PID:2463823): Begin: SRL archival .... (PID:2463823): End: SRL archival RESETLOGS after incomplete recovery UNTIL CHANGE 123168223875 time 09/01/2025 15:52:15 NET (PID:2463823): Disable RFS client [kcrlc.c:1526]
然后就出現了開頭日志中的錯誤，這個時候我們激活的這個 1 號庫就是讀寫模式的主庫了，但他的配置中還有 DG 配置信息沒有清除，導致歸檔日志傳到了 2 號庫。如下，log_archive_dest_2 配置的是 2 號庫地址且配置為ONLINE_LOGFILES,PRIMARY_ROLE，所以當變為讀寫庫時日志就傳遞到 2 號庫，3 號庫是正常的級聯備庫，所以歸檔日志也就傳到了 3 號庫，1 號庫的激活過程 resetlogs 等操作就傳到了這兩個庫，導致 MRP 發生化身，MRP0 進程全部掛掉。
SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=jiekedg LGWR ASYNC VA
LID_FOR=(ONLINE_LOGFILES,PRIMA
RY_ROLE) DB_UNIQUE_NAME=jiekeDG
SQL> show parameter log_archive_dest_state_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string ENABLE
SQL> ! tnsping jiekeDG
TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 11-SEP-2025 17:36:31
Copyright (c) 1997, 2024, Oracle. All rights reserved.
Used parameter files:
/u01/app/oracle/product/19.0.0/dbhome_1/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.132.132)(PORT = 11522)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = jiekedg)))
OK (0 msec)
這里大概說一下log_archive_dest_2 VALID_FOR=(redo_log_type,database_role) 參數格式：
-
可用日志文件類型：online_logfile,standby_logfile, all_logfiles
-
可用的角色類型：primary_role, standby_role, all_roles
說明如下：
(1)redo_log_type 關鍵字表明該目的地產生歸檔的 redo 日志類型
- online_logfile：目的地只歸檔聯機redo日志
- standby_logfile：目的地只歸檔standbyredo日志
- all_logfiles：目的地既歸檔聯機redo日志，也歸檔standby redo日志
(2)database_role 表明該目的地產生歸檔的數據庫角色
- primary_role：只有數據庫是主庫時，該目的地才會產生歸檔
- standby_role：只有數據庫是備庫時，該目的地才會產生歸檔
- all_role：當數據庫不論是主庫還是備庫時，該目的地都會產生歸檔
其他參數可以查看官方文檔或我之前寫的一篇DG參數詳解，[爆肝一萬字終于把 Oracle Data Guard 核心參數搞明白了]（https://mp.weixin.qq.com/s/m1S-ElWOYf_h2kcrre5HNA）。然后查看 alert 日志在 2025-09-03 09:07:35 時分，log_archive_dest_state_2 才被重置成 defer，清理掉了備庫配置，所以之前都是一直在傳遞歸檔日志的。
ALTER SYSTEM SET log_archive_config='' SCOPE=BOTH; 2025-09-03T09:06:31.116758+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekeot/jiekeot1/trace/jiekeot1_ppa7_2475002.trc: ORA-16057: Data Guard 配置中沒有服務器 2025-09-03T09:06:31.116795+08:00 NET (PID:2475002): krsg_check_connection: Error 16057 connecting to standby 'jiekedg' 2025-09-03T09:06:31.276741+08:00 Errors in file /u01/app/oracle/diag/rdbms/jiekeot/jiekeot1/trace/jiekeot1_ppa7_2475002.trc: ORA-16057: Data Guard 配置中沒有服務器 NET (PID:2475002): krsg_check_connection: Error 16057 connecting to standby 'jiekedg' 2025-09-03T09:07:35.594029+08:00 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 2025-09-03T09:07:57.366605+08:00 ALTER SYSTEM SET fal_server='' SCOPE=BOTH;
然而另外一套也是同樣的操作卻沒有發生這樣的問題，排查后發現 log_archive_dest_2 雖然配置了備庫的地址，但是 tnsping 發現不通，日志沒傳遞過去，也就避免了這樣的事情發生。
log_archive_dest_2 string service=edstd ASYNC valid_for
=(online_logfiles,primary_role
) compression=enable db_unique
_name=edstd
SQL> ! tnsping edstd
TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 11-SEP-2025 17:38:19
Copyright (c) 1997, 2024, Oracle. All rights reserved.
Used parameter files:
/u01/app/oracle/product/19.0.0/dbhome_1/network/admin/sqlnet.ora
TNS-03505: Failed to resolve name
事后總結
細節決定成敗,當任何細小的環節被忽略就會導致出錯的概率增大，進而影響我們的判斷，當在發生這種事情的時候，應該需要規劃更具體的步驟，比如清理要激活的庫的控制文件自動備份，FRA 里的閃回日志以及應用完的歸檔日志，再者修改此庫的關于 DG 的一些參數配置，防止變成主庫后傳遞歸檔日志到其他相關的主備庫或級聯庫造成 incarnation 分身，MRP 進程中斷無法繼續同步數據。
--查看控制文件自動備份位置，進而刪除
RMAN> show all;
-- 關閉閃回 清理歸檔日志
SQL> alter database flashback off;
--清理DG相關配置
SQL> alter system reset log_archive_dest_2 SCOPE=BOTH;;
SQL> alter system set log_archive_dest_2='' SCOPE=BOTH;;
SQL> alter system set log_archive_dest_state_2=‘defer’ SCOPE=BOTH;；
SQL> alter system set log_archive_config='' SCOPE=BOTH;
SQL> alter system set fal_server='' SCOPE=BOTH;
參考文章
ORA-19906 and ORA-19909 at standby site (Doc ID 1509932.1) MRP0 Process on Cascading Standby Database Is Stppped After Converting to Snapshot Standby By ORA-19909 ORA-1110 (Doc ID 2654140.1) https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-data-repair-concepts.html#GUID-9942AC94-A35D-4A06-9A45-A5A43B82B23D https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/managing-recovery-catalog.html#GUID-304B2237-0921-422F-A084-D83E7B5C8D2B
全文完，希望可以幫到正在閱讀的你，如果覺得有幫助，可以分享給你身邊的朋友，同事，你關心誰就分享給誰，一起學習共同進步~~~
歡迎關注我的公眾號【JiekeXu DBA之路】，一起學習新知識！
——————————————————————————
公眾號：JiekeXu DBA之路
墨天輪：http://m.sunline.cc/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
騰訊云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————
