项目中，客户执行以下语句，出现ORA-600错误，具体如下;
select t1.* from
(select * from A.B where etl_date=20110526) t1
where not exists
(
select * from A.B t2
where etl_date=20110527 and t1.tx_date=t2.tx_date and t1.open_date=t2.open_date and t1.done_no=t2.done_no
)
;
ora-00600: internal error code, arguments:[kcblasm_1],[103],[],[]
通过trace 文件查看call stack.
使用call stack命令，从metalink相关文档中查找符合所发生问题的描述：
在10.2.0.5版本中，所有平台环境下补丁程序P7612454，该补丁是解决hash
join时候，Direct IO最大限制4096，我们从执行计划中可以看出,hash join的build
table表的cardinality非常大，这个是造成该问题的罪魁祸首。解决方案如下：
1、11.2版本解决了上述问题
2、升级补丁P7612454，该补丁替换lib中的kcbl.o文件
3、如果执行计划中是hash join造成的，在会话层中设置"_hash_join_enable"
=false，如果执行计划是hash group by 造成的，设置"_gby_hash_aggregation_
enable"=false
4、修改SQL语句，尽量减少build table的cardinality的值，可以避免该问题的生成
select t1.* from
(select * from A.B where etl_date=20110526) t1
where not exists
(
select * from A.B t2
where etl_date=20110527 and t1.tx_date=t2.tx_date and t1.open_date=t2.open_date and t1.done_no=t2.done_no
)
;
ora-00600: internal error code, arguments:[kcblasm_1],[103],[],[]
通过trace 文件查看call stack.
使用call stack命令，从metalink相关文档中查找符合所发生问题的描述：
在10.2.0.5版本中，所有平台环境下补丁程序P7612454，该补丁是解决hash
join时候，Direct IO最大限制4096，我们从执行计划中可以看出,hash join的build
table表的cardinality非常大，这个是造成该问题的罪魁祸首。解决方案如下：
1、11.2版本解决了上述问题
2、升级补丁P7612454，该补丁替换lib中的kcbl.o文件
3、如果执行计划中是hash join造成的，在会话层中设置"_hash_join_enable"
=false，如果执行计划是hash group by 造成的，设置"_gby_hash_aggregation_
enable"=false
4、修改SQL语句，尽量减少build table的cardinality的值，可以避免该问题的生成
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/354732/viewspace-697070/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
再议hash group by
下一篇：
IBM AIX 无法进行系统备份
请登录后发表评论
登录
全部评论
