1 ． Interval Partitioning 分區

11g 新特性 _ 分區表按時間自動創建，具體見如下示例：

CREATE TABLE test_01
(
id number ,
cjsj date
)
PARTITION BY RANGE (cjsj)
INTERVAL (NUMTOYMINTERVAL( 1 , 'month' )) ----- 這里的 1 表示增加的間隔，表示每一個月作為一個分區；這里的 month 表示間隔是月，還有另外一個參數； year
(
PARTITION P0 VALUES LESS THAN (TO_DATE( '2010-01-01' , 'yyyy-mm-dd' ))
);

通過如上語句，建立一個按照月自動增加的分區表，只建了一個小于 2010 年 1 月 1 日的分區表，見表結構：

此時，如果向 TEST_01 表中，插入一個 CJSJ 大于 2010 年 1 月 1 日的數據，系統會自動增加一個相應的分區，如：

insert into test_01 values ( 1 ,to_date( '20100103' , 'yyyy-mm-dd' ));
commit ;

此時，查看表結構，會自動增加一個分區，

2 ． System Partitioning 分區

系統分區，在這個新的類型中，我們不需要指定任何分區鍵，數據會進入哪個分區完全由應用程序決定，實際上也就是由 SQL 來決定，終于，我們在 Insert 語句中可以指定插入哪個分區。

CREATE TABLE test_02
( id number ,
cjsj date )
PARTITION BY SYSTEM
(
PARTITION p1 TABLESPACE users,
PARTITION p2 TABLESPACE users01,
PARTITION p3 TABLESPACE users02
);

--- 這里很奇怪的事情是，表屬性中，并未顯示出來分區特性，建截圖：

現在由 SQL 語句來指定插入哪個分區：

-- 數據插入 p1 分區
INSERT INTO test_02 PARTITION (p1) VALUES ( 1 , sysdate );
commit ;
select * from test_02 PARTITION (p1)

3 ．執行計劃管理

3.1 執行計劃管理原理

我們知道， SQL 語句的性能很大程度上依賴于 SQL 語句的執行計劃。如果 SQL 語句的執行計劃發生改變，則 SQL 的性能很有可能發生大的變化。而 SQL 執行計劃發生變化的原因有很多種，包括優化器版本的變化、統計信息的變化、優化器相關的各種參數的變化、添加或刪除了索引、添加或刪除了物化視圖、修改了系統設置、以及是否應用了 10g 引入的 SQL profile 等。

從 11g 開始， oracle 引入了 SQL 執行計劃管理（ SQL Plan Management ）這個新特性，從而可以讓系統自動的來控制 SQL 語句執行計劃的穩定性，進而防止由于執行計劃發生變化而導致的性能下降。

通過啟用該特性，某條語句如果產生了一個新的執行計劃，只有在它的性能比原來的執行計劃好的情況下，才會被使用。
為了實現執行計劃管理，優化器會為所有執行次數超過一次的 SQL 語句維護該 SQL 語句的每個執行計劃的歷史列表（ plan history ）。優化器通過維護一個語句執行的日志條目（ statement log ）來識別該 SQL 語句是否為第二次執行。一旦優化器認出某條 SQL 語句為第二次執行，則優化器將該語句所生成的所有不同的執行計劃插入到 plan history 的相關表里，而 plan history 里包含了優化器能夠用于重新生成執行計劃的所有信息，這些信息包括 SQL 文本、存儲大綱、綁定變量以及解析環境（比如 optimizer_mode 之類影響優化器解析 SQL 語句的參數）等。

當然， 11g 也支持手工維護 SQL 語句的 plan history ，作為對自動維護 plan history 的功能補充。
但是并不是說 plan history 里任何的執行計劃都可以拿來使用。這里需要先介紹一下所謂的執行計劃基準線（ plan baseline ）這個概念。 plan baseline 是 plan history 的一個子集， plan baseline 里面的執行計劃是用來比較性能好壞的一個依據。也就是說，憑什么來判斷是否可以使用一個新產生的執行計劃呢？就是把該新的執行計劃與 plan baseline 里的計劃進行比較來判斷。某個 SQL 語句的執行計劃可以屬于 plan history ，但是不一定屬于 plan baseline 。

注意：每個 SQL 語句都會有它自己的執行計劃歷史以及執行計劃基準線。

那么某個 SQL 語句的執行計劃是如何進入執行計劃歷史，乃至執行計劃基準線的呢？
有兩種方法可以將 SQL 語句的執行計劃納入到執行計劃管理體系中去：
1) 將初始化參數： OPTIMIZER_CAPTURE_PLAN_BASELINES 設置為 true ，則會自動的捕獲 SQL 的執行計劃。該參數缺省為 false 。設置為 true 以后，當某條 SQL 語句第一次執行時，該 SQL 語句的 plan history 是空的，顯然該 SQL 語句的 plan baseline 也是空的。那么當該 SQL 第二次再次執行時，優化器會自動將該 SQL 語句以及相關的執行計劃放入 plan history ，同時也會放入到 plan baseline 里。這就構成了最初的 plan baseline ，也就是說最初進入 plan history 的執行計劃會直接自動進入 plan baseline 里。那么當你做了某些修改，比如添加了一個索引等，然后第三次執行該同樣的 SQL 語句，則會產生另外一個不同的執行計劃，這時新的執行計劃會自動進入 plan history ，但是不會自動進入 plan baseline 。是否使用該新的執行計劃，則要把該新的執行計劃與 plan baseline 里現存的第二次執行 SQL 時的執行計劃進行比較，如果新的執行計劃成本更低，則會使用新的執行計劃，否則使用 plan baseline 里的執行計劃。

2) 使用 dbms_spm 包手工處理，這可以讓你手工管理 SQL plan baseline 。使用該包，你可以直接將 SQL 的執行計劃從 shared pool 里加載到 plan baseline 里，也可以使用 dbms_spm 包將已經存在的 SQL Tuning Set 加載到 plan baseline 里。同時， dbms_spm 可以讓你把 plan history 里的執行計劃加入到 plan baseline 里。反之，你也可以使用該包將 plan baseline 里的執行計劃移出去。

3.2 執行計劃管理測試

首先把 optimizer_capture_sql_plan_baselines 參數設置為 TRUE;

insert into test_03 select rownum ,object_name from dba_objects;

set autotrace traceonly exp stat;

------------ 備注：在 PLSQL 工具中，打開會報錯 : Cannot SET AUTOTRACE ，報這個錯是由于第三方工具的問題，在命令行下沒問題。
此時我們進行查詢
select * from test_03 where id = 200 ; ，見如下圖，屬于全表掃描

待續。。。。

4 ．虛擬列 -- Virtual Column

Oralce 的虛擬列解決了以前很多需要使用觸發器或者需要通過代碼進行計算統計才能產生的數據信息。以前每次對其他的列進行統計，產生新列的時候都是采用在 select 語句中通過統計計算增加新列的方法，執行效率很低，而且由于使查詢 SQL 語句變得冗長、復雜很容易出錯。嚴重的降低了開發效率和程序的執行效率。 Oralce 虛擬列的引入解決了這個問題。

Oralce 的虛擬列也有一些問題。不能使用 insert into talbe_name values (). 語句，在向含有虛擬列的表中添加數據時，要求 insert 語句的必須把添加的表的列名寫出來。 insert into table_name (list1,list2,...listend) 列名中不能出現虛擬列名，否則會提示錯誤。

oracle 11g 新特性