How Changing the COMPATIBLE Parameter Fixed ORA-600 Errors on Oracle Standby

The environment consisted of a single‑instance Oracle 11.2.0.4 database running on Windows with a primary and a standby server. After the primary experienced high load, a standby was added for disaster recovery and read‑write separation. System‑maintenance staff later deleted several large files, including archive log files, which later caused the standby to stall on logs 17620 and 17621.

Initial investigation involved querying the archived log view to confirm the presence of the two logs:

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

The log files existed, but their sizes were abnormal (1 KB vs. 2662 KB). Further checks showed the primary had already shipped the logs to the standby, yet the standby could not apply them:

-- Max sequence numbers
select max(sequence#) from v$archived_log;  -- primary
select max(sequence#) from v$archived_log;  -- standby

Querying the gap view revealed a missing range: select * from v$archive_gap; Result:

THREAD#  LOW_SEQUENCE#  HIGH_SEQUENCE#
1        17620           17621

The managed‑standby view showed the standby waiting for the gap:

select process, status, sequence# from v$managed_standby;

Result highlighted a WAIT_FOR_GAP 17620 entry, confirming the standby could not apply those logs.

Examining the trace files produced an ORA‑00600 error and a clear message that the write buffer failed:

ORA-00600: internal error, arguments: [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

The underlying cause was identified as a mismatch in the compatible initialization parameter between primary and standby. Although the parameter had never been changed before, the trace indicated incompatibility:

This happens due to Unmatched compatibility setup on the primary and the standby.
The value of compatible parameter in primary and standby is different.

To verify, an attempt to manually register the missing archive log on the standby produced a version‑mismatch error:

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

The fix involved aligning the compatible parameter on the standby with the primary (11.2.0.4) and restarting the standby:

ALTER SYSTEM SET compatible='11.2.0.4' SCOPE=SPFILE;

After setting the parameter, the standby was shut down, recovered, and restarted:

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 the previously stuck archive logs being applied successfully:

Parallel Media Recovery started with 8 slaves
Waiting for all non‑current ORLs to be archived...
All non‑current ORLs have been archived.
Media Recovery Log /opt/oracle/archivedlog/1_17620_964956507.dbf
Media Recovery Log /opt/oracle/archivedlog/1_17621_964956507.dbf
Media Recovery Log /opt/oracle/archivedlog/1_17622_964956507.dbf
...

With the logs applied, the standby resumed normal archive‑log shipping and data synchronization, confirming that the COMPATIBLE parameter mismatch was the root cause of the ORA‑600 errors.