如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
目的：
这篇文章讨论的是内部错误“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，然后保证数据库可以全库的导出，然后重建数据库导入数据。
Leave a Reply