How to Fix ORA-600 Errors Stalling Oracle Standby Log Apply

A single‑instance Oracle 11.2.0.4 database running on Windows was configured with a standby for disaster recovery and read/write separation. After some archive logs were manually deleted, the standby stopped applying logs and reported ORA‑600 errors at sequence numbers 17620 and 17621.

The DBA first inspected the archived log view:

select name, sequence#, thread#, fal, applied, archived from v$archived_log where sequence#>17600;

Both log files existed, but their sizes differed (1 KB vs 2662 KB). Checking the gap and managed standby status revealed the gap:

select * from v$archive_gap;
-- Result shows THREAD# 1, LOW_SEQUENCE# 17620, HIGH_SEQUENCE# 17621

select process, status, sequence# from v$managed_standby;
-- Shows MRP0 WAIT_FOR_GAP 17620 among other ARCH CONNECTED rows

The trace files ( orclstd_rfs_32611.trc, orclstd_rfs_32613.trc) contained the internal error:

ORA-00600: internal error, parameters: [2730], [331], [1], [5], [17620], [17620], [512], [512]
Exception 600 received while writing lno 5 thread 1 seq 17620
krsb_stream_write: Error 600 while attempting to write buffer

Investigation pointed to an incompatibility of the compatible initialization parameter between primary and standby. Attempting to manually register the missing log file produced:

alter database register logfile '/opt/oracle/archivelog/1_17620_964956507.dbf';
ORA-00331: log version 11.2.0.4 is not compatible with Oracle version 11.2.0.0
ORA-00334

Resolution involved aligning the parameter on the standby:

alter system set compatible='11.2.0.4' scope=spfile;

After shutting down the standby, the DBA restarted it and ran the recovery commands:

alter database recover managed standby database cancel;
shutdown immediate;
startup mount;
alter database open;
alter database recover managed standby database using current logfile disconnect from session;

Post‑restart logs showed successful application of the previously stuck archive logs (17620, 17621, 17622), confirming that the compatibility mismatch was the root cause and that the standby is now synchronized with the primary.