歡迎進入Oracle社區論壇，與200萬技術人員互動交流 >>進入 前不久，曾經接手一個性能調優案例：這是一個報表系統，其基礎數據主要存儲于三張表中。表的大小已經很大了，最大一張接近100G。在生成報表時需要長時間才能返回結果，一些online查詢甚至經常timeou

歡迎進入Oracle社區論壇，與200萬技術人員互動交流 >>進入

前不久，曾經接手一個性能調優案例：這是一個報表系統，其基礎數據主要存儲于三張表中。表的大小已經很大了，最大一張接近100G。在生成報表時需要長時間才能返回結果，一些online查詢甚至經常timeout。表中存儲的是2萬多個公司的數據，報表的生成也是以公司為單位的，因此，這一調優方案的思路比較明確：將表按公司分區。但是，這中間卻存在一些麻煩：每個公司的數據并不是均衡的。其中近200家公司屬于VIP用戶，他們的數據量最大，每個公司差不多是十幾萬到幾十萬的數據量，其總量占了全部數據的30%左右;而其它非VIP用戶的數據基本上每個都在1萬以內。而我們的主要目標就是要優先保證VIP用戶獲取到最佳的性能(由于其數據量，當前最大的性能問題恰恰就出在這些VIP用戶上)。因此，我們提出了2中分區方案：

基于Company Id的Hash分區;

基于Company Id的List分區;

但是，這兩種方案各有優缺點：

對于Hash分區，分區的大小更加均衡，因而性能也更加均衡。但是，可能出現一些無法控制的極端現象：Hash分區僅僅是對Company Id使用Hash函數進行分組，它能做到每個分區分配基本相當數量的Company Id，但是每個Company Id對應的數據量并不考慮在內，因此可能出現某些分區集中的都是VIP數據或者都是非VIP數據，造成分區過大或過小;另外一個缺點就是我們很難直接干預某個公司的性能。例如，可能有某個非VIP用戶成為了VIP用戶，其數據量激增，它又正好處于一個大的分區上，這時，我們很難將其從這個分區剝離出來，除非它所在分區正好出在一個即將分裂的分區上。

對于List分區，VIP用戶的性能能夠得到保證。我們可以將每個VIP用戶單獨存儲在一個分區上，但是，不可能將非VIP用戶單獨存儲開(不僅增加維護難度，且增加整個表的大小)，只能將非VIP用戶存儲在幾個分區上。但是這樣還是造成DDL語句非常復雜，并且非VIP的分區很大(每個都在10G左右，而VIP分區最大才200M)。

由于List分區更加接近我們的優化目的，最終還是采用了List分區。

其實，期間我們曾經考慮過使用復合分區。在10g中(我們的生產庫是10g)，僅支持2種復合分區：Range-List和Range-Hash。我們的解決方案是：為表增加一個數字類型的ID字段，VIP用戶對應的數字大于100,000，非VIP用戶的ID小于100,000。每個VIP用戶被單獨放置在一個Range分區中，所有非VIP用戶被放置在一個Range分區中，然后再對非VIP分區通過Hash劃分子分區。這樣，即能保證VIP用戶的性能，也能均衡非VIP用戶的性能。但是，由于這種方案需要增加一個非業務的字段，以及其它一些原因，最終被否決了。

到11g中，Oracle的分區策略更加靈活了。首先，11g支持更多方式的組合分區，除10g支持的兩種之外，還支持Range-Range、List-Range、List-List、List-Hash的組合分區策略。對于我們上述這個案例，就可以通過List-Hash的組合分區來解決。以下就是一個List-Hash分區的演示：

SQL代碼

SQL> create table par_test

2 partition by list (owner)

3 subpartition by hash (owner)

4 store in (example)

5 (partition p1 values ('SYS'), 6 partition p2 values ('PUBLIC'),

7 partition def values (default)

8 subpartitions 4

9 )

10 as select * from dba_objects

11 /

Table created.

SQL> analyze table par_test compute statistics;

Table analyzed. SQL> select partition_name, subpartition_name, num_rows, blocks from dba_tab_subpartitions

2 where table_name = 'PAR_TEST';

PARTITION_NAME SUBPARTITION_NAME NUM_ROWS BLOCKS

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

P2 SYS_SUBP154 26604 434

DEF SYS_SUBP158 4529 70

DEF SYS_SUBP157 2783 45

DEF SYS_SUBP156 2422 39

DEF SYS_SUBP155 2854 47

P1 SYS_SUBP153 29770 437

6 rows selected.

順便再提一下11g新增的其他分區策略。

針對Range Partition，11g有了一種更加靈活的方式：Interval Partition。例如，我們一些分區表是依賴于時間做的范圍分區：每個月的數據存放到一個分區中。隨著數據的增長，還需要有一個作業來增加新的分區以滿足上述策略。而在11g中，通過Interval Parition，就無需這中人為的維護作業了，Oracle會為新的數據自動增加分區：

SQL代碼

SQL> create table par_test2 (a number, b date)

2 partition by range (b)

3 interval (numtoyminterval(1,'MONTH'))

4 store in (example)

5 (

6 partition values less than (to_date('2009-09-01','yyyy-mm-dd'))

7 )

8 ;

Table created. SQL> insert into par_test2 values(1, sysdate); 1 row created.

SQL> commit;

Commit complete. SQL> select partition_name, high_value from dba_tab_partitions

2 where table_name = 'PAR_TEST2';

PARTITION_NAME HIGH_VALUE

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

SYS_P164 TO_DATE(' 2009-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA ' SQL> insert into par_test2 values(1, to_date('2009-10-01','yyyy-mm-dd')); 1 row created.

SQL> commit;

Commit complete. SQL> select partition_name, high_value from dba_tab_partitions

2 where table_name = 'PAR_TEST2';

PARTITION_NAME HIGH_VALUE

[1] [2]

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com