解决ORACLE报ora-600[2662]错误： 数据块的SCN大于当前的SCN

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

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

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

目的：

这篇文章讨论的是内部错误“ora-600[2662]”的含义和解决办法，只能对下列版本有指导作用。

报错：

格式：ora-600[2662][a][b][c][d][e]

版本：6.0到12.1

描述：

数据块的SCN大于当前的SCN。

主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了。

参数：

Arg [a] Current SCN WRAP

Arg [b] Current SCN BASE

Arg [c] dependent SCN WRAP

Arg [d] dependent SCN BASE

Arg [e] Where present this is the DBA where the dependent SCN came from.

功能：

redo日志文件管理和IO缓存管理

影响：

实例崩溃

可能发生物理错误

建议：

不同的情况下都可能产生ORA-600[2662]错误：

可能在启动数据库时发生。

如果你没有使用并行服务器，那么检查两个实例是否是启动的同一个数据库。

检查SMON的跟踪文件和警告日志文件。

检查SCN的差异，参数d-参数b

如果SCN非常接近，可以试着关闭重启几次。

在某些情况下，SCN在数据库打开是会增长。

如果下面的信息没法帮你定位问题，请提交trace文件和alert.log文件给ORACLE 支持人员进一步分析问题。

两种类型的错误

类型1：

4/5个参数形式

数据块的SCN早于当前的SCN。

类型2：

1个参数形式（7.2.3之前的版本才会发生）

类型1

如果SCN来自最近或当前的SCN，那么DBA保存为0。如果它来自uodo$，因为回滚段是
不可用，DBA保存为undo段号，它看起来像是0号文件的块。如果SCN来自redo日志（即
块编号== 0的变化的数），那么DBA是块0相关的数据文件。如果它是从另一个数据库的分布式事务则DBA是DBAINF（）。如果它来自TX锁定那么DBA是USN<<16 +插槽。

类型2

日志块总和校验

开始分析：

1、这个报错是发生在数据库工作过程中或者在启动数据库时；

2、参数d和参数b的差异

3、如果是5个参数

把DBA转换成文件号块号

是否是一个数据字典对象（文件号等于1）

4、当前SQL语句（看trace）

指向的是哪个表？

上一步找出的对象和这里指向的表是否是同一个？

注意这点：可能和DBA无关，问题的真正原因（blockdump）

进一步分析：

（1）查看trace文件：

可能是正常的用户trace文件，也可能是smon的trace文件

（2）查看’buffer’

oracle7 dump文件里的“buffer dba”

oracle8或Oracle9 dump文件里的”buffer tsn”

这有助于你找到产生2662错误真正源头。

这个错误的可能原因：

1.使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库

2.硬件错误引起数据库没法写控制文件和重做日志文件

3.错误的部分恢复数据库

4.恢复了控制文件但是没有使用recover database using backup controlfile进行恢复

5.数据库crash后设置了_DISABLE_LOGGING隐含参数

6.在并行服务器环境中DLM存在问题

7、一个BUG

解决：

（1）如果SCN号差异很小，可以尝试多重启几次数据库，每次重启SCN号会有一定的增长，当dscn=scn时就能打开数据库了

（2）使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN，然后保证数据库可以全库的导出，然后重建数据库导入数据。