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排序問題。