遇到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 外加请教大牛老熊（http://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。