最近，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提示的方法，问题得到解决。后续需要处理的问题是，制定合适的归档备份清理策略。
