解决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,然后保证数据库可以全库的导出,然后重建数据库导入数据。

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号