Oracle 11g的新特性分割槽：System Partition

 

Partition分割槽是Oracle一直以來推出的效能、管理最佳化技術。在Oracle資料庫技術體系中，Partition是歸屬在DW（Data Warehouse）體系中，也就是Oracle官方認定的處理大資料策略。

單就Partition技術本身而言，11g是一個重要的版本。一些自動化分割槽技術、增強策略在11g中推出。比如引用分割槽（Reference Partition）、間斷分割槽（Interval Partition）、虛擬列分割槽（Partitioning Virtual Columns）、系統分割槽（System Partition）和擴充組合分割槽（Extended Composite Partitioning）。

本篇目的介紹11g的System Partition特性。

 

1、環境介紹

 

筆者選擇Oracle 11R2作為實驗物件。

 

 

SQL> select * from v$version;

 

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE     11.2.0.1.0     Production

 

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 – Production

 

 

2、System Partition

 

我們在其他的Partition型別中，都會面對一個問題就是分割槽鍵選擇。所謂分割槽Partition，就是將一個資料表段segment拆分為多個儲存段儲存。傳統意義上的Partition停留在定義層面，只要我們在資料表定義的時候確定好分割槽鍵和分割槽策略。之後的使用資料表的過程中，我們其實對分割槽是“透明”的。

如果進行資料表的DML操作和select操作，我們是不需要指定、也無法控制資料記錄插入到哪個分割槽中的。只有一種情況不同，就是修改分割槽鍵。如果修改分割槽鍵，並且修改分割槽鍵會影響到分割槽佈局，這樣的DML操作是不允許的。

11g的System Partition提供了不同選擇。它提供給SQL DML操作者一種選擇，讓可以指定出“希望將資料儲存”在哪個地方。

建立System Partition的過程，也是在定義資料表的過程中需要確定。

 

 

SQL> create table t partition by system (partition p1 tablespace users,

  2  partition p2 tablespace EXAMPLE) as select * from dba_objects where 1=0 ;

 

create table t partition by system (partition p1 tablespace users,

partition p2 tablespace EXAMPLE) as select * from dba_objects where 1=0

 

ORA-14704: 不允許對 SYSTEM 分割槽表執行以下操作: Create table as select

 

 

在system partition中，我們不允許對分割槽進行spilt操作和cats操作。正確的處理方式，如下：

 

 

SQL> create table t

  2  (owner varchar2(100),

  3   object_name varchar2(1000),

  4   object_id number)

  5  partition by system

  6  (partition p1 tablespace users,

  7   partition p2 tablespace example);

 

Table created

 

 

在語句中，我們指定了資料表採用分割槽策略——system策略，設定了兩個分割槽p1和p2，並且指定了兩個分割槽的表空間儲存位置。

注意：這個過程中，我們沒有指定分割槽規則，也就是沒有告訴資料庫當一個資料插入的時候，如何進行資料分堆。

檢查資料字典，確定段結構情況。

 

 

SQL> select segment_name, partition_name, segment_type from dba_segments where owner='SCOTT' and segment_name='T';

 

SEGMENT_NAME         PARTITION_NAME       SEGMENT_TYPE

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

T                    P1                   TABLE PARTITION

T                    P2                   TABLE PARTITION

 

SQL> select partitioning_type from dba_part_tables where owner='SCOTT' and table_name='T';

 

PARTITIONING_TYPE

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

SYSTEM

 

 

分割槽型別，確定為system partition。在system partiton中，也可以建立local index物件。

 

 

SQL> create index idx_t_id on t(object_id) local;

 

Index created

 

SQL> select segment_name, partition_name, segment_type from dba_segments where owner='SCOTT' and segment_name='IDX_T_ID';

 

SEGMENT_NAME         PARTITION_NAME       SEGMENT_TYPE

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

IDX_T_ID             P1                   INDEX PARTITION

IDX_T_ID             P2                   INDEX PARTITION

 

 

3、DML操作與System Partition

 

下面是DML操作，普通Partition在定義資料表的時候，就已經確定資料“分堆”的規則，所以進行資料操作的時候，操作SQL和普通資料表沒有差別。但是，system partition沒有在定義階段確定好規則，所以SQL就必然要制定處理原則。

 

 

SQL> insert into t select owner ,object_name, object_id from t;

 

insert into t select owner ,object_name, object_id from t

 

ORA-14701: 對於按“系統”方法進行分割槽的表, 必須對 DML 使用分割槽副檔名或繫結變數

 

 

我們需要在插入資料表的時候，明確的指定資料插入的位置分割槽。

 

 

 

SQL> insert into t partition(p1) select owner, object_name, object_id from dba_objects where owner in ('SYS','PUBLIC');

 

58673 rows inserted

 

SQL> insert into t partition(p2) select owner, object_name, object_id from dba_objects where owner not in ('SYS','PUBLIC');

 

14130 rows inserted

 

SQL> commit;

Commit complete

 

 

之後，可以看到明顯的分割槽體積變化。

 

 

SQL> select segment_name, partition_name, bytes from dba_segments where owner='SCOTT' and segment_name='IDX_T_ID';

 

SEGMENT_NAME         PARTITION_NAME            BYTES

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

IDX_T_ID             P1                      2097152

IDX_T_ID             P2                       524288

 

 

我們在普通的partition中，如果一個資料表的update操作，涉及到分割槽鍵，並且分割槽鍵的修改會引起資料記錄分割槽所屬位置問題，Oracle是拒絕進行操作的。

建立一個對比試驗資料表t_normal。

 

 

SQL> create table t_normal

  2  (owner varchar2(100),

  3   object_name varchar2(100),

  4   object_id number)

  5  partition by list (owner)

  6  (partition p1 values ('SYS'),

  7   partition p2 values (default));

 

Table created

 

 

SQL> insert into t_normal select owner, object_name, object_id from dba_objects;

 

72806 rows inserted

 

SQL> commit;

Commit complete

 

 

如果修改owner，引起分割槽所屬關係變化，Oracle是拒絕的。

 

 

SQL> update t_normal set owner='SYS' where owner='SCOTT';

 

update t_normal set owner='SYS' where owner='SCOTT'

 

ORA-14402: 更新分割槽關鍵字列將導致分割槽的更改

 

 

這其實就是我們選擇分割槽鍵時候，一定要選擇一個“不變化”的資料取值原因。

但是這個原則對於system partition而言，就不成立了。因為資料放在哪個分割槽裡面，完全是使用者insert過程中輸入確定的，所以這種約束不存在。

 

 

SQL> update t set owner='SYS' where OWNER='SCOTT';

26 rows updated

 

SQL> commit;

Commit complete

 

 

4、結論

 

最後，筆者想聊聊這個特性的用法。在準備這個知識點的時候，筆者一直在思考這個分割槽型別的使用場景。我們使用分割槽的兩個出發點，就是效能優勢和管理優勢。System Partition的最大好處是在於自由，我們可以透過SQL語句控制一條記錄究竟放在哪個分割槽裡面。

個人感覺，這個特性對於管理上的優勢可能比較大。比如，在應用中，我們可以控制資料插入到哪個分割槽中，如果是OLTP系統，就是將負載集中在某個分割槽上。其他分割槽就可以進行日常的運維工作。

那麼，這個特點在沒有System Partition的時候，也是可以實現，就是透過額外的資料列中定義儲存位置。這種方法的缺點是技術部署細節傳匯入業務模型層面。而System Partition就是實現了這個功能。

11g帶給我們很多分割槽特性，就筆者所知，這些特性在實際場景下使用的並不廣泛。相信隨著12c推出，11g大量部署，這些特性會更加廣泛使用。