Email: service@parnassusdata.com 7 x 24 online support!
ORA-00600: 内部错误代码, 参数:[3020] 错误解析
ORA-00600: 内部错误代码, 参数:[3020]
ORA-00600[3020]也被称为STUCK RECOVERY, 一般的原因是当一个数据块在被recovery恢复过程中,发现要APPLY到该块上的redo重做日志验证这个块的内容时,与ORACLE的算法不匹配,即认证redo与data block之间不一致,此时就需要报错,否则ORACLE不能在糊涂账上继续写糊涂账。
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
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 |