ORA-10567: Redo is inconsistent with data block | ORA-00600 ORA-10564 ORA-01110 ORA-10560

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: [3020] 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: [3020], [100], [106520704], [106520704], [], [], [], [], [], [], [], []
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.

How to Restore Oracle Database ( Controlfile, Datafile, Archivelog ) via RMAN from Tape 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

On Standby

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.

 

 

Do you want to learn Oracle Database for Beginners, then read the following articles.

Oracle Tutorial | Oracle Database Tutorials for Beginners ( Junior Oracle DBA )

 

About Mehmet Salih Deveci

I am Founder of SysDBASoft IT and IT Tutorial and Certified Expert about Oracle & SQL Server database, Goldengate, Exadata Machine, Oracle Database Appliance administrator with 10+years experience.I have OCA, OCP, OCE RAC Expert Certificates I have worked 100+ Banking, Insurance, Finance, Telco and etc. clients as a Consultant, Insource or Outsource.I have done 200+ Operations in this clients such as Exadata Installation & PoC & Migration & Upgrade, Oracle & SQL Server Database Upgrade, Oracle RAC Installation, SQL Server AlwaysOn Installation, Database Migration, Disaster Recovery, Backup Restore, Performance Tuning, Periodic Healthchecks.I have done 2000+ Table replication with Goldengate or SQL Server Replication tool for DWH Databases in many clients.If you need Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS Consultancy and Training you can send my email adress [email protected].-                                                                                                                                                                                                                                                 -Oracle DBA, SQL Server DBA, APPS DBA,  Exadata, Goldengate, EBS ve linux Danışmanlık ve Eğitim için  [email protected] a mail atabilirsiniz.

Leave a Reply

Your email address will not be published. Required fields are marked *