ORA-00600: internal error code, arguments:[3020] stuck recovery

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

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

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ORA-00600: internal error code, arguments:[3020]

适用于：

Enterprise Manager for Oracle Database – 版本10.1.0.2 到 12.1.0.2.0 [Release 10.1 to 12.1]
Oracle Database – Enterprise Edition – 版本 9.0.1.4 到 12.1.0.2 [Release 9.0.1 to 12.1]
Oracle Database – Personal Edition – 版本 9.2.0.1 到12.1.0.2 [Release 9.2 to 12.1]
本文信息适用于任何平台。
*** 16-Apr-2014检查相关性***

症状

在做恢复时，恢复过程可能会失败，生成ORA-600 [3020]错误信息

ORA-00600: internal error code, arguments: [3020], [2885689059], [1], [419819],[26750], [808], [], []
ORA-10567: Redo is inconsistent with data block (file# %s, block# %xxxx)
ORA-10564: tablespace
ORA-01110: data file %s

原因

由于失败的一致性检查，称为stuck recovery的问题，恢复停止。当底层操作系统或存储系统失去正常操作期间由数据库发出的写，就可能出现stuck recovery。在重做中储存的信息和存储在被恢复的数据库块中的信息之间有不一致性。

在应用重做时，数据库发出一个内部错误。这个问题可以通过Oracle数据库的错误造成的，或可能是因为I / O问题（硬件或O / S相关的问题）

还有一个与RDBMS ORA-600 [3020]相关的已知EMC问题，其中的根本原因是在OS /硬件水平。

在修复的性质上EMC的详情（Symmetrix微码的问题）
ID: emc230687
Domain: EMC1
Solution Class: 3.X Compatibility

解决方案

当媒体恢复遇到问题时，警报日志可能表明如果它被允许破坏导致了问题的数据块，恢复可以继续。警报日志包含有关块的信息：它的块类型，块地址，它属于表空间，等等。对于包含用户数据的块，警报日志也可能报告数据对象号。

在这种情况下，如果数据库被允许标记问题块为corrupt，恢复可以进行。然而，这种反应是不总是可取的。例如，如果该块是在SYSTEM表空间的重要块，将块标记为corrupt最终会阻止你打开恢复的数据库。另外要考虑恢复问题是否是分离的。如果这个问题后紧随许多在重做流中的其他问题，那么你可能需要使用RESETLOGS选项打开数据库。

对于包含用户数据的块，通常可以查询数据库找出哪些对象或表拥有此块。如果数据库未打开，那么你应该能打开只读的数据库，即使要恢复整个数据库备份。下面的例子取消恢复并打开只读：

CANCEL
ALTER DATABASE OPEN READ ONLY;

从alert.log错误信息中，我们可以发现dataifle及其相应的块号。即使对于包含用户数据的块，警报日志也能报告数据对象号。由此我们可以得到对象的信息。

SQL>SELECT SEGMENT_NAME FROM DBA_EXTENTS WHERE FILE_ID= &file_number
AND &BLOCK_NUMBER BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS-1;

— 其中File_number是错误消息中的数据文件号，Block_Number是错误消息中的块号。

如果我们在alert.log中得到数据对象号，则我们就可以通过发出此查询确定所有者，对象名和对象类型：

SQL>SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = &Object_number;

— 其中object_number是错误信息中的object_id。

要确定恢复问题是否是独立的，我们可以运行诊断试验恢复diagnostic trial recovery，这将扫描问题的重做流，但实际上对被恢复的数据库不作任何更改。如果试验发现任何恢复问题，则在alert_SID.log中报告。你可以使用RECOVER … TEST语句来调用试验恢复。参见Note 283262.1 Trial Recovery

注：如果问题不是孤立的或它属于SYSTEM表空间，则最好使用RESETLOGS选项打开数据库。
如果块相对不重要，如属于索引表空间或者问题是独立的，那么最好损坏块。如果你决定允许恢复继续，尽管块损坏，使用ALLOW n CORRUPTION运行RECOVER命令，其中n是允许的损坏块数。

要允许恢复损坏块：

1. 确保满足一切正常恢复的前提条件。

2. 运行RECOVER命令，允许单个损坏，对每个损坏进行必要的重复。例如：

SQL>RECOVER DATABASE ALLOW 1 CORRUPTION;

注：ALLOW integer CORRUPTION子句允许你在日志文件损坏的事件中指定允许恢复继续时可以同时容忍损坏的块数。

当你在试验恢复过程中使用这一子句（即与TEST子句一并），整数能超过1。当在正常的恢复过程中使用这一子句，整数不能超过1。

在10gR2中及以下版本，限制是允许在恢复阶段中，在允许1损坏（allow 1 corruption）中仅指定1块，但是从11gR1其，此限制被删除，恢复时的allow <n> corruption可以指定n值，其中n是使用恢复数据库test时在trail恢复过程中发现的被损坏块数。

Example : SQL> Recover database allow 10 corruption ;

参考

NOTE:283262.1 – Trial Recovery