oracle之_gby_hash_aggregation_enabled

 

前几天，给一客户把Oracle由原来的Oracle9i升级到Oracle10g。

升级后发现生成树形导航图页面报异常，打不开了。

原来是由于自身程序问题+Oracle10.2.1版本BUG，导致此问题的出现。

因为我们的树形导航图是从数据库中取值，由于是多级树形图，每一级树形图，查询长度相同的ID来排列在同一层上。

由于Oracle9i查询数据时，若不使用排序语句，则默认按照插入顺序取出数据。而我们的树形图恰好是依顺序插入的。而恰好查询数据时就没有使用排序语句。

当升级到Oracle10g时，Oracle查出的数据，若不使用排序语句，那么就按照系统内部的排序方式排序而非按照插入顺序排序。这样应用程序就不干了。所以就报出了异常。

现在的情况是，由于应用程序代码已封装好，去改应用程序基本是不可能的，唯一可能的就修改数据库配置。

最后终于找到一参考资料：执行以下命令后，问题消失。

alter system set "_gby_hash_aggregation_enabled"=false;

 

参考资料内容如下：

--------------------------------------------------------------------------

这样改变的原因就是：oracle在使用hash排序的时候，如果hash表数据大到某个阀值，会出现严重的表空间升级【bug】

 

alter session set "_gby_hash_aggregation_enabled"=false;

这样的修改主要事用于修改oracle内部决定的排序方式，以下是一个例子：

 

 

SQL> create table test as select *from dba_objects;

 

表已创建。

 

SQL> set autotrace traceonly exp

SQL> select object_type,count(*) from test group by object_type;

 

执行计划

----------------------------------------------------------

Plan hash value: 1435881708

 

---------------------------------------------------------------------------

| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |

---------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |      | 43683 |   469K|   167   (6)| 00:00:03 |

|   1 | HASH GROUP BY     |      | 43683 |   469K|   167   (6)| 00:00:03 |

|   2 |   TABLE ACCESS FULL| TEST | 43683 |   469K|   161   (2)| 00:00:02 |

SQL> set autotrace off;

 

SQL> alter system set "_gby_hash_aggregation_enabled"=false;

 

系统已更改。

 

SQL> set autotrace traceonly exp

 

SQL> select object_type,count(*) from test group by object_type;

 

执行计划

----------------------------------------------------------

Plan hash value: 2603667166

 

---------------------------------------------------------------------------

| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |

---------------------------------------------------------------------------

|   0 | SELECT STATEMENT   |      | 43683 |   469K|   167   (6)| 00:00:03 |

|   1 | SORT GROUP BY     |      | 43683 |   469K|   167   (6)| 00:00:03 |

|   2 |   TABLE ACCESS FULL| TEST | 43683 |   469K|   161   (2)| 00:00:02 |

 

 

可以从红色部分可以看出，以及有原来的hash的方式修改为 sort的group by 方式。

这样的修改可能带来的原因就是可能sql的运行时间会比较久，对结果不会产生影响。

 

注：出现这样的问题主要是因为大表的hash排序问题。