【Oracle数据恢复】ORA-00600[3020]错误解析

ORA-00600[3020]也被称为STUCK RECOVERY，一般的原因是当一个数据块在被recovery恢复过程中，发现要APPLY到该块上的redo重做日志验证这个块的内容时，与ORACLE的算法不匹配，即认证redo与data block之间不一致，此时就需要报错，否则ORACLE不能在糊涂账上继续写糊涂账。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线： 13764045638 QQ号:47079569 邮箱：[email protected]

ORA-00600[3020]这个报错的相关argument在9.2中的含义是：

Arg [a] Block DBA
Arg [b] Redo Thread
Arg [c] Redo RBA Seq
Arg [d] Redo RBA Block No
Arg [e] Redo RBA Offset.

在ORACLE 10.1中的含义是：

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

这个报错的模块属于内核并行内存恢复，其具体影响是可能导致实例在前滚时报错从而导致打开数据库OPEN Database失败。

解决方案：使用recover命令时多个可能都会导致该错误，最常见的可能是数据文件没有被正常restore 到磁盘，或者restore是不完全的。因此，首先保证整个备份被有效restore出来了，这个restore 一定要在recover database之前完成。

如果确认restore是完整的，但是问题仍存在，则考虑再次从backup restore然后做一个基于时间点POINT-IN-TIME的恢复，这个时间点应当早于ORA-600[3020]错误所指向的时间点。

举例来说如下面的命令：

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

当然这个错误也可能由于丢失更新lost update而造成。

在常规操作过程中，块的更新和写是在包括一系列的数据文件、重做日志文件和归档日志文件中的。这些文件中任意一个的丢失写都可能是ORA-00600[3020]的原因。因此也建议全面检查发生问题的操作系统和磁盘硬件。

如果是丢失写的情况，那么可以尝试从更老的备份中restore，并尝试恢复和前滚。

必要的诊断信息基本都包含在alert.log和一些trace中了，例如负责实施前滚的进程的trace和SMON的trace。

ORA-600 [3020]相关的一些bug列表：

NB	Bug	Fixed	Description
	9847338		Session hang after applying the patch for Bug 9587912 which causes ORA-600 [3020]
+	13467683	11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 12.1.0.0	Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368
	12831782	11.2.0.2.BP11, 11.2.0.3.BP01, 12.1.0.0	ORA-600 [3020] / ORA-333 Recovery of datafile or async transport do not read mirror if there is a stale block
	12582839	11.2.0.3, 12.1.0.0	ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace
	11689702	11.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.0	ORA-600 [3020] during recovery after datafile RESIZE (to smaller size)
	10329146	11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.0	Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
	10218814	11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.0	ORA-600 [3020] during recovery / on standby
+	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.0	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.0	ORA-600 / corruption possible during shutdown in RAC
	10094823	11.2.0.2.4, 11.2.0.2.BP09, 11.2.0.3, 12.1.0.0	Block change tracking on physical standby can cause data loss
	10071193	11.2.0.2.BP02, 11.2.0.3, 12.1.0.0	Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded
	9587912	11.2.0.2, 12.1.0.0	ORA-600 [3020] in datafile that went offline/online in a RAC instance
	8774868	11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0	OERI[3020] reinstating primary
+	8769473	11.2.0.2, 12.1.0.0	ORA-600 [kcbzib_5] on multi block read in RAC. Invalid lock in RAC. ORA-600 [3020] in Recovery
P	8635179	10.2.0.5, 11.2.0.2, 12.1.0.0	Solaris: directio may be disabled for RAC file access. Corruption / Lost Write
+	8597106	11.2.0.1.BP06, 11.2.0.2, 12.1.0.0	Lost Write in ASM when normal redundancy is used
P	12330911	12.1	EXADATA LSI firmware for lost writes
+	10425010	11.2.0.3, 12.1	Stale data blocks may be returned by Exadata FlashCache
	8826708	10.2.0.5, 11.2.0.2	ORA-600 [3020] for block type 0x3a (58) during recovery for block restored by RMAN backup
	11684626	11.2.0.1	ORA-600 [3020] on standby involving “BRR” redo when db_lost_write_protect is enabled
	8230457	10.2.0.4.1, 10.2.0.5, 11.1.0.7.1, 11.2.0.1	Physical standby media recovery gets OERI[krr_media_12]
+	7680907	10.2.0.5, 11.1.0.7.1, 11.2.0.1	ORA-600 [kclexpandlock_2] in LMS / instance crash. Incorrect locks in RAC. ORA-600 [3020] in recovery
	4637668	10.2.0.3, 11.1.0.6	IMU transactions can produce out-of-order redo (OERI [3020] on recovery)
	4594917	9.2.0.8, 10.2.0.2, 11.1.0.6	Write IO error can cause incorrect file header checkpoint information
	4453449	10.2.0.2, 11.1.0.6	OERI:3020 / corruption errors from multiple FLASHBACK DATABASE
	7197445	10.2.0.4.1, 10.2.0.5	Standby Recovery session cancelled due to ORA-600 [3020] “CHANGE IN FUTURE OF BLOCK”
	5610267	10.2.0.5	MRP terminated by ORA-600[krr_media_12] / OERI:3020 after flashback
	3762714	9.2.0.7, 10.1.0.4, 10.2.0.1	ALTER DATABASE RECOVER MANAGED STANDBY fails with OERI[3020]
	3560209	10.2.0.1	OERI[3020] stuck recovery under RAC
	3397181	9.2.0.5, 10.1.0.3, 10.2.0.1	ALTER SYSTEM KILL SESSION of recovery slave causes stuck recovery
*	3381950	10.2.0.1	Backups from RAC DB before Data Guard Failover cannot be used
	3535712	9.2.0.6, 10.1.0.4	OERI[3020] / ORA-10567 from RAC with standby in max performance mode
	4594912	9.2.0.8, 10.1.0.2	Incorrect checkpoint possible in datafile headers
	3635331	9.2.0.6, 10.1.0.4	Stuck recovery (OERI:3020) / ORA-1172 on startup after a crash
	2322620	9.2.0.1	OERI:3020 possible on recovery of LOB DATA
P+	656370	7.3.3.4, 7.3.4.0, 8.0.3.0	AlphaNT only: Corrupt Redo (zeroed byte) OERI:3020

Posted

November 19, 2012

mac

Tags:

Comments

One response to “【Oracle数据恢复】ORA-00600[3020]错误解析”

Ask_Maclean_liu_Oracle

November 24, 2013

Bug 10209232 ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write inASMDescriptionBlocks can be misplaced in ASM after using a wrong extent map to write blocksduring rebalance. The Blocks intended to write may not be written.Those blocks become stale blocks (Lost Write).Misplaced Blocks================The blocks are written to wrong locations and those blocks become misplacedwith wrong rdba producing ORA-1578 and dbverify may report the misplacedblocks as follow:DBVERIFY – Verification starting : FILE = +GROUP1/data_1.269.586785881Page 8195 is marked corruptCorrupt block relative dba: 0x06c02003 (file 27, block 8195)Bad header found during dbv:Data in bad block:type: 6 format: 2 rdba: 0x06c01a03 <– Content is for a different blocklast change scn: 0x08e4.371d0fa4 seq: 0x2 flg: 0x04spare1: 0x0 spare2: 0x0 spare3: 0x0consistency value in tail: 0x0fa40602check value in block header: 0x7965computed block checksum: 0x0 <— Checksum is okLOST WRITE / LOST IO====================Blocks intended to write may not be written. Those blocks become stale blocks.A media recovery of these blocks may produce ORA-600 [3020].As there is lost IO this may also produce several inconsistencies with errors:ORA-8103, ORA-1410ORA-600 [kdsgrp1], ORA-1499 by Analyze validate structure cascadeORA-600 [25027]ORA-600 [4553]Run dbms_diskgroup.checkfile to identify mirror discrepancies when ASMdisk group normal redundancy is used.If there is a Standby database and if 11g parameter DB_LOST_WRITE_PROTECT is setin the PRIMARY database, a recovery in the Standby may fail with messages:STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASELOST A DISK WRITE OF BLOCK , FILE

Reply