Home » RDBMS Server » Backup & Recovery » managed recovery - redo is inconsistent with data block
managed recovery - redo is inconsistent with data block [message #161503] Sun, 05 March 2006 20:36 Go to next message
skodman
Messages: 10
Registered: March 2005
Location: Auckland
Junior Member
Hi all

Here is the situation. I have primary db in town A and standby in town b. Standby runs in managed recovery mode. Database version is 10GR2.

couple a days ago sysadmin restarted the server where stdby db was running, without properly shutting down the standby database and closing redo log apply service first. Now after mounting the database i am getting this error:

ORA-00600: internal error code, arguments: [3020], [2], [137], [8388745], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 137)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 2: 'O:\ORADATA\ABCD\UNDOTBS01.DBF'
ORA-10560: block type 'KTU SMU HEADER BLOCK'


Restarting the redo log apply service didn't help to clear the error. What is my best course of action to get rid of the error and make logs properly apply to standby

regards
skodman
Re: managed recovery - redo is inconsistent with data block [message #161551 is a reply to message #161503] Mon, 06 March 2006 00:39 Go to previous message
alexzeng
Messages: 133
Registered: August 2005
Location: alexzeng.wordpress.com
Senior Member
Please refer this article: https://metalink.oracle.com/metalink/plsql/f?p=130:14:2019257725183951363::::p14_database_id,p14_docid,p14_show_header,p14_show_help, p14_black_frame,p14_font:NOT,30866.1,1,0,1,helvetica

Also post here, FYI
------------------------------------------------------------------
Subject: ORA-600 [3020] "Stuck Recovery"
Doc ID: Note:30866.1 Type: REFERENCE
Last Revision Date: 09-JAN-2006 Status: PUBLISHED


Note: For additional ORA-600 related information please read Note 146580.1

PURPOSE:
This article discusses the internal error "ORA-600 [3020]", what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.

ERROR:
ORA-600 [3020] [a] [b] [c] [d] [e]

VERSIONS:
version 6.0 to 10.1

DESCRIPTION:

This is called a 'STUCK RECOVERY'.

There is an inconsistency between the information stored in the redo
and the information stored in a database block being recovered.

ARGUMENTS:

For Oracle 9.2 and earlier:
Arg [a] Block DBA
Arg [b] Redo Thread
Arg [c] Redo RBA Seq
Arg [d] Redo RBA Block No
Arg [e] Redo RBA Offset.

For Oracle 10.1
Arg [a] Absolute file number of the datafile.
Arg [b] Block number
Arg [c] Block DBA

FUNCTIONALITY:
kernel cache recovery parallel

IMPACT:
INSTANCE FAILURE during recovery.

SUGGESTIONS:

There have been cases of receiving this error when RECOVER has
been issued, but either some datafiles were not restored to disk,
or the restoration has not finished.

Therefore, ensure that the entire backup has been restored and that
the restore has finished PRIOR to issuing a RECOVER database command.

If problems continue, consider restoring from a backup and doing a
point-in-time recovery to a time PRIOR to the one implied by
the ORA-600[3020] error.

Example:

SQL> recover database until time 'YYYY-MON-DD:HH:MI:SS';

This error can also be caused by a lost update.

During normal operations, block updates/writes are being performed to
a number of files including database datafiles, redo log files,
archived redo log files etc.

This error can be reported if any of these updates are lost for some
reason.

Therefore, thoroughly check your operating system and disk hardware.

In the case of a lost update, restore an old copy of the datafile and
attempt to recover and roll forward again.

If the Known Issues section below does not help in terms of identifying
a solution, please submit the trace files and alert.log to Oracle
Support Services for further analysis.

Known Issues:

Bug# 4594917 See Note 4594917.8
Write IO error can cause incorrect file header checkpoint information
Fixed: 9.2.0.8, 10.2.0.2, 11

Bug# 4594912 See Note 4594912.8
Incorrect checkpoint possible in datafile headers
Fixed: 9.2.0.8, 10.1.0.2

Bug# 4453449 See Note 4453449.8
OERI:3020 / corruption errors from multiple FLASHBACK DATABASE
Fixed: 10.2.0.2, 11

Bug# 3762714 See Note 3762714.8
ALTER DATABASE RECOVER MANAGED STANDBY fails with OERI[3020]
Fixed: 9.2.0.7, 10.1.0.4, 10.2.0.1

Bug# 3635331 See Note 3635331.8
Stuck recovery (OERI:3020) / ORA-1172 on startup after a crash
Fixed: 9.2.0.6, 10.1.0.4

Bug# 3535712 See Note 3535712.8
OERI[3020] / ORA-10567 from RAC with standby in max performance mode
Fixed: 9.2.0.6, 10.1.0.4

Bug# 3397181 See Note 3397181.8
ALTER SYSTEM KILL SESSION of recovery slave causes stuck recovery
Fixed: 9.2.0.5, 10.1.0.3, 10.2.0.1

Bug# 2322620 See Note 2322620.8
OERI:3020 possible on recovery of LOB DATA
Fixed: 9.2.0.1

Bug# 656370 P+ See Note 656370.8
AlphaNT only: Corrupt Redo (zeroed byte) OERI:3020
Fixed: 7.3.3.4, 7.3.4.0, 8.0.3.0



------------------------------------------------------------------
Alex zeng |Skype me: hans9zeng
Previous Topic: Restore tablespace to another server via RMAN to a point in time
Next Topic: rman
Goto Forum:
  


Current Time: Fri Apr 19 07:19:17 CDT 2024