遇到ORA-00600：internal error code,arguments:[kcblasm_1],[103],[],[],[],[]报错的解决办法

昨日客户在10.2.0.5上通过dblink采集另外一套10.2.0.5的数据时遇到了这个报错

ora-00600：internal error code,arguments:[kcblasm_1],[103],[],[],[],[]

查看mos，ora-600 [kcblasm_1] in 10.2.0.5. [id 1133845.1]

只给出了解决的方法：

to quickest way to the solution of this problem is to apply psu 10.2.0.5.4, patch 12419392 or later.
all alternative solutions forthis problem are listed below:
o upgrade the database to 11.2.

or
o apply 10.2.0.5.4 patch set update (patch 12419392) or later psus where bug is fixed.
the available psus are mentioned in"10.2.0.5 patch set updates - list of fixes in each psu" (document 1337394.1)

or
o apply interim patch 7612454 on topof 10.2.0.5 (10.2.0.5.0-10.2.0.5.3):
o for unix / linux platforms apply patch 7612454 available fordownload on mos.
o for windows platforms apply patch 3 or higher.
please check document 342443.1 forlatest patches available forwindows on topof 10.2.0.5.

但是没有给具体的原因，由于是在线没有可操控的关机时间来打小补丁或则进行打psu，所以mos给的建议现在用不上。查看trace文件，发现都是一些sql语句引起（为了保障客户资料，不贴出sql），都是一些单表的group by操作的sql，继续google 外加请教大牛老熊（https://www.laoxiong.net/），猜测该问题是由于oracle 10g中group by操作引用了新的算法导致，从10g开始group by操作将默认以hash group by的形式进行以取代以往的sort group by，当hash group by操作数据量比较大的时候就会引发该ora-600的报错，为了验证该推论是否正确，做了以下测试：

1、在报错的数据库上先执行了一次报错的sql，确定是否每次都会报错（由于数据量没改变，应该每次都会报错），记录实际的执行计划，确定确实是采用的hash group by的方式

2、在同一个会话内设置alter session set "_gby_hash_aggregation_enabled"=false; 该参数为false的情况下将不采用hash group by而会选择以往的sort group by

3、再次运行报错的sql，运行成功，查看执行计划，确定是sort group by

通过上面的测试，基本上可以确定问题的所在，具体的解决方法归纳下：

方法一：升级系统，打相应的psu或则小补丁

方法二：修改sql

方法三：设置_gby_hash_aggregation_enabled为false，其中设置方法有：

1、 系统或则会话级设置通过alter system或则alter session

2、为语句添加hint /*+ opt_param(‘_gby_hash_aggregation_enabled’,'false’)

另外说明：

hash join也可能会引起该ora-600的错误，当由于hash join引起该错误的时候，可以在会话级通过设置__hash_join_enable为false或则在语句上添加hint的方式来处理，建议不要在system级别关闭hash join。