最近，Oracle數據庫維護中遇到一個常見的問題場景：oracle dataguard災備，源端數據庫在做大批量數據變更時，主端
產生大量歸檔，而源端和目標端的歸檔空間比較小，未到達oracle備份週期歸檔未及時清理，源端歸檔空間先滿，繼而目標
端歸檔空間100%；當源端和目標端的歸檔部分清理後，目標端再次啓動dataguard的日誌同步進程時，mrp進程無法啓動不
報錯，但是，目標庫的alert告警日誌有報錯ORA-00600 [2619]，相關分析處理過程如下。
目標庫的告警日誌提示：
Wed Feb 15 14:11:31 2012
Streams CAPTURE CP01 for DOWNSTREAM_CAPTURE with pid=46, OS id=15497 stopped
Errors in file /oraxolt4db/oraadm/diag/rdbms/xonlt4pr/XONLT4/trace/XONLT4_cp01_15497.trc:
ORA-01280: Fatal LogMiner Error.
Errors in file /oraxolt4db/oraadm/diag/rdbms/xonlt4pr/XONLT4/trace/XONLT4_ms00_15503.trc:
ORA-00600: internal error code, arguments: [2619], [13608], [], [], [], [], [], [], [], [], [], []
LOGMINER: session#=52 (DOWNSTREAM_CAPTURE), reader MS00 pid=48 OS id=15503 sid=11 stopped
Errors in file /oraxolt4db/oraadm/diag/rdbms/xonlt4pr/XONLT4/trace/XONLT4_ms00_15503.trc:
ORA-00600: internal error code, arguments: [2619], [13608], [], [], [], [], [], [], [], [], [], []
LogMiner process death detected
LOGMINER: session#=52 (DOWNSTREAM_CAPTURE), preparer MS02 pid=50 OS id=15507 sid=393 stoppedLOGMINER: session#=52 (DOWNSTREAM_CAPTURE), builder MS01 pid=49 OS id=15505 sid=200 stopped
Sweep [inc][88385]: completed
Sweep [inc2][88385]: completed
根據報錯提示ORA-00600 [2619]，查看oracle mos官網，有文檔Doc ID 1422085.1與之匹配，查看該文檔的原因描述
與我們遇到的完全一樣。按mos的說法是源端和目標端的13608號歸檔不一致導致，調查源端和目標端的13608號歸檔，發現
源端爲678kb，而目標端的13608號歸檔爲478MB，應該是源端歸檔空間滿13608號歸檔寫不下去，而目標端還沒滿，導致
mrp進程恢復到13608號歸檔時發現源端和目標端不一致而停止繼續應用歸檔日誌。
MOS原文：
CAUSE
ORA-600[2619] is raised due to an invalid next_change# detected in archive log.
This is caused by the archive log disk space ran out size, causing that archive log not fully written on disk.
MOS提供的方法是，將源端13608號歸檔覆蓋目標端13608號歸檔，直接啓動Mrp進程即可，但是需要注意，需要源端和目標端的日誌格式相同。
MOS原文：
SOLUTION
1. Resolve the disk space problem where archive log stored on Standby/Downstream site to make sure that there is no space issue.
2. Copy the problem archive log from the primary site and replace the one on the standby, before and after sequence# where got ORA-600 from source database, then restart recovery.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
3. Start the capture process.
按mos提示的方法，問題得到解決。後續需要處理的問題是，制定合適的歸檔備份清理策略。