ORA-00600 [2662]错误解决过程
数据库版本：7.3.2
背景：
客户那边数据库突然出现一个current日志文件坏了 ，导致数据库crash了 ，然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数 ，做了不完全恢复后强行将数据库打开 。可是打开数据库后发现只能用internal用户连接进去 ，别的用户连接都报错 ，错误信息如下：
ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []
查询不了任何应用的表 ，应用也没法使用 ，于是想尝试全库的exp出来然后重新imp进去建库 ，结果发现exp数据也不成功 ，也是报同样的ORA-600的错误 ，用户当时数据没有任何的备份过 ，只能想办法尽量打开数据库 ，导出数据了 。
处理过程：
先检查了600错误产生的trace文件：
*** SESSION ID:(7.15) 2004.11.23.23.28.16.824
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []
Current SQL statement for this session:
SELECT * FROM "WHSB"."SB_BSBF"
得到的信息有限 ，只能看到是严重内部错误 ，剩下的都是内存堆栈的一堆信息 ，于是查找了一下这个错误的具体相关信息 。
ORA-600 [2662] "Block SCN is ahead of Current SCN" ，说明当前数据库的数据块的SCN早于当前的SCN ，主要是和存储在UGA变量中的dependent SCN进行比较 ，如果当前的SCN小于它 ，数据库就会产生这个ORA-600 [2662]的错误了 。这个错误一共有五个参数 ，分别代表不同的含义 ，
ORA-600 [2662] [a] [b] [c] [d] [e]
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.
我们分析错误中的提示 ，它的参数b=431267754,d=431272752,表明当前的SCN确实是小于dependent SCN ，所以产生了这个600的错误 。
通过查阅文档 ，发现这个错误的产生原因主要有以下几条：
l 使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
l 硬件错误引起数据库没法写控制文件和重做日志文件
l 错误的部分恢复数据库
l 恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
l 数据库crash后设置了_DISABLE_LOGGING隐含参数
l 在并行服务器环境中DLM存在问题
仔细对比了一下 ，发现问题可能是由于第一条产生的 ，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后 ，虽然强制性的打开数据库 ，但是数据库本身存在了corruption ，仍然存在严重的问题 。
于是想到使用ADJUST_SCN事件来调整当前的SCN ，使其大于dependent SCN ，然后保证数据库可以全库的导出 ，然后重建数据库导入数据 。
用internal用户登陆数据库后 ，连接别的用户 ，还是失败报错 ，执行：
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
然后尝试连接别的用户 ，连接成功 。
最后exp整个数据库 ，重建数据库后导入数据 ，整个数据库恢复成功！
通过这个实例 ，我们可以看到 ，尽量的不要去使用那些隐含参数 ，这些参数是oracle所不推荐使用的 ，也不是万能的！如果使用了可能会存在一些遗留的问题 ，如果非要使用 ，建议使用后一定要exp/imp重建建立数据库 。
数据库版本：7.3.2
背景：
客户那边数据库突然出现一个current日志文件坏了 ，导致数据库crash了 ，然后现场工程师使用_ALLOW_RESETLOGS_CORRUPTION = TRUE这个隐含参数 ，做了不完全恢复后强行将数据库打开 。可是打开数据库后发现只能用internal用户连接进去 ，别的用户连接都报错 ，错误信息如下：
ORA-00600: internal error code, arguments: [2662], [0], [431267936], [0], [431273216], [0], [], []
查询不了任何应用的表 ，应用也没法使用 ，于是想尝试全库的exp出来然后重新imp进去建库 ，结果发现exp数据也不成功 ，也是报同样的ORA-600的错误 ，用户当时数据没有任何的备份过 ，只能想办法尽量打开数据库 ，导出数据了 。
处理过程：
先检查了600错误产生的trace文件：
*** SESSION ID:(7.15) 2004.11.23.23.28.16.824
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2662], [0], [431267754], [0], [431272752], [0], [], []
Current SQL statement for this session:
SELECT * FROM "WHSB"."SB_BSBF"
得到的信息有限 ，只能看到是严重内部错误 ，剩下的都是内存堆栈的一堆信息 ，于是查找了一下这个错误的具体相关信息 。
ORA-600 [2662] "Block SCN is ahead of Current SCN" ，说明当前数据库的数据块的SCN早于当前的SCN ，主要是和存储在UGA变量中的dependent SCN进行比较 ，如果当前的SCN小于它 ，数据库就会产生这个ORA-600 [2662]的错误了 。这个错误一共有五个参数 ，分别代表不同的含义 ，
ORA-600 [2662] [a] [b] [c] [d] [e]
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.
我们分析错误中的提示 ，它的参数b=431267754,d=431272752,表明当前的SCN确实是小于dependent SCN ，所以产生了这个600的错误 。
通过查阅文档 ，发现这个错误的产生原因主要有以下几条：
l 使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库
l 硬件错误引起数据库没法写控制文件和重做日志文件
l 错误的部分恢复数据库
l 恢复了控制文件但是没有使用recover database using backup controlfile进行恢复
l 数据库crash后设置了_DISABLE_LOGGING隐含参数
l 在并行服务器环境中DLM存在问题
仔细对比了一下 ，发现问题可能是由于第一条产生的 ，由于设置了_ALLOW_RESETLOGS_CORRUPTION这个隐含参数后 ，虽然强制性的打开数据库 ，但是数据库本身存在了corruption ，仍然存在严重的问题 。
于是想到使用ADJUST_SCN事件来调整当前的SCN ，使其大于dependent SCN ，然后保证数据库可以全库的导出 ，然后重建数据库导入数据 。
用internal用户登陆数据库后 ，连接别的用户 ，还是失败报错 ，执行：
alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';
然后尝试连接别的用户 ，连接成功 。
最后exp整个数据库 ，重建数据库后导入数据 ，整个数据库恢复成功！
通过这个实例 ，我们可以看到 ，尽量的不要去使用那些隐含参数 ，这些参数是oracle所不推荐使用的 ，也不是万能的！如果使用了可能会存在一些遗留的问题 ，如果非要使用 ，建议使用后一定要exp/imp重建建立数据库 。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10294527/viewspace-122298/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/10294527/viewspace-122298/
扫一扫
1734
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
