My Oracle Support Banner

Resolving ORA-752 or ORA-600 [3020] During Standby Recovery (Doc ID 1265884.1)

Last updated on FEBRUARY 14, 2019

Applies to:

Oracle Database - Enterprise Edition - Version to [Release 10.2 to 11.2]
Oracle Database - Enterprise Edition - Version to [Release 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.


Standby Redo Apply can terminate due to a failure of redo-data consistency checks, a problem called stuck recovery. Stuck recovery can occur when an underlying operating system or storage system loses a write issued by the Primary or Standby database during normal operation. Because there is an inconsistency between the information stored in the redo and the information stored in a database block being recovered, the database signals an internal error when applying the redo.

ORA-00600: internal error code, arguments: [3020], [2885689059], [1], [419819],[26750], [808], [], []
ORA-10567: Redo is inconsistent with data block (file# 1, block# 419819)
ORA-10564: tablespace <tablespace_name> 
ORA-01110: data file ’/<path>/<datafile_name>.dbf’




To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document
 Determining the Extent of Corruption
 Determining Root Cause
 What actions can be taken when an ORA-752 lost write error is signalled?
 What action can be taken when an ORA-600 [3020] is signaled?
 Protecting Against Lost Writes
 Steps to recover from bug 11674485
 Detection – how do we know “Lost write at the Primary” detected at the standby is a false positive?

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.