Resolving ORA-752 or ORA-600  During Standby Recovery
(Doc ID 1265884.1)
Last updated on FEBRUARY 14, 2019
Applies to:Oracle Database - Enterprise Edition - Version 10.2.0.1 to 126.96.36.199 [Release 10.2 to 11.2]
Oracle Database - Enterprise Edition - Version 188.8.131.52 to 184.108.40.206 [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-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  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?|