如果自己搞不定可以找诗檀软件专业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