I got ” ORA-10567: Redo is inconsistent with data block | ORA-00600 ORA-10564 ORA-01110 ORA-10560 ” error in Oracle database during the MRP process shutdown in Standby Side.
ORA-10567: Redo is inconsistent with data block
Details of error are as follows.
2021-04-03T20:48:14.055178+03:00 ERROR: ORA-00600: internal error code, arguments:  recovery detected a data block with invalid SCN. This could be caused by a lost write on the primary; do NOT attempt to bypass this error by copying blocks or datafiles from the primary database to the standby database because that would propagate the lost write from the primary to the standby. Errors in file /u01/app/oracle/diag/rdbms/MSDBdg/MSDBDG1/trace/MSDBDG1_pr05_82440.trc (incident=61993): ORA-00600: internal error code, arguments: , , , , , , , , , , ,  ORA-10567: Redo is inconsistent with data block (file# 100, block# 106520704, file offset is 1478492160 bytes) ORA-10564: tablespace TEST_TBS ORA-01110: data file 100: '+DATA/MSDBDG/DATAFILE/TEST_TBS.4555.1065371261' ORA-10560: block type '58' Incident details in: /u01/app/oracle/diag/rdbms/MSDBdg/MSDBDG1/incident/incdir_61993/MSDBDG1_pr05_82440_i61993.trc 2021-04-03T20:48:15.178798+03:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************
ORA-00600 ORA-10564 ORA-01110 ORA-10560
This ORA-00600 ORA-10564 ORA-01110 ORA-10560 errors are related with the stuck recovery and corrupted datafile in the Standby. This error occurs when redo cannot be applied to a block because the scn of the block, when read from disk, is NOT the scn that we expect.
To solve this error, you need to restore the related datafile(s) of tablespace from Backup. You can use the following post to learn how to restore datafile from backup.
If the affected file belongs to SYSTEM or UNDO tablespace you should restore the database from backup and do point in time recovery to just before the problem log is applied.
If the affected file belongs to SYSAUX, this is the ONLY file affected and it is offline then a better option than point in time recovery of the whole database would be to create a NEW database and then use Transportable Tablespace feature to plug in all other tablespaces.
Another point worth noting: if SYSAUX is ONLINE but contains corrupt blocks, then before considering restore and recovery, use the SQL in point 3 below to identify the affected object and raise a call with Oracle Support Services to ask if it is possible to drop and recreate the object.
Restore the Problematic datafile from the primary database to Standby.
Option 1:- For 11g and above Version . Restore datafile from a fresh backup from primary
a>On Standby stop managed recovery
SQL>Alter database recover managed standby database cancel ; (If database is open read only mount it later)
b> On Primary take a backup of the datafile involved.
rman> Connect target / rman> Backup datafile <fileno> format '<Path>/%U_corrupt' ;
Scp the backuppiece to standby
c> On Standby in mount stage
rman target / Catalog backuppiece '<name and path of the backuppiece>' ; Rman> restore datafile <fileno>;
Option 2:- From 12c Onward you can use also restore datafile from Service
Stop the Manged recovery on Standby
Rman> Alter database recover managed standby database cancel ; Rman> restore datafile <fileno> from service <Primary service name> ;
The above command would restore datafile involved over network to standby using primary service name.
Once done start the managed recovery again.
501 views last month, 5 views today