1 ． Interval Partitioning 分區(qū)

11g 新特性 _ 分區(qū)表按時(shí)間自動(dòng)創(chuàng)建，具體見(jiàn)如下示例：

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

通過(guò)如上語(yǔ)句，建立一個(gè)按照月自動(dòng)增加的分區(qū)表，只建了一個(gè)小于 2010 年 1 月 1 日的分區(qū)表，見(jiàn)表結(jié)構(gòu)：

此時(shí)，如果向 TEST_01 表中，插入一個(gè) CJSJ 大于 2010 年 1 月 1 日的數(shù)據(jù)，系統(tǒng)會(huì)自動(dòng)增加一個(gè)相應(yīng)的分區(qū)，如：

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

此時(shí)，查看表結(jié)構(gòu)，會(huì)自動(dòng)增加一個(gè)分區(qū)，

2 ． System Partitioning 分區(qū)

系統(tǒng)分區(qū)，在這個(gè)新的類型中，我們不需要指定任何分區(qū)鍵，數(shù)據(jù)會(huì)進(jìn)入哪個(gè)分區(qū)完全由應(yīng)用程序決定，實(shí)際上也就是由 SQL 來(lái)決定，終于，我們?cè)? Insert 語(yǔ)句中可以指定插入哪個(gè)分區(qū)。

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

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

現(xiàn)在由 SQL 語(yǔ)句來(lái)指定插入哪個(gè)分區(qū)：

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

3 ．執(zhí)行計(jì)劃管理

3.1 執(zhí)行計(jì)劃管理原理

我們知道， SQL 語(yǔ)句的性能很大程度上依賴于 SQL 語(yǔ)句的執(zhí)行計(jì)劃。如果 SQL 語(yǔ)句的執(zhí)行計(jì)劃發(fā)生改變，則 SQL 的性能很有可能發(fā)生大的變化。而 SQL 執(zhí)行計(jì)劃發(fā)生變化的原因有很多種，包括優(yōu)化器版本的變化、統(tǒng)計(jì)信息的變化、優(yōu)化器相關(guān)的各種參數(shù)的變化、添加或刪除了索引、添加或刪除了物化視圖、修改了系統(tǒng)設(shè)置、以及是否應(yīng)用了 10g 引入的 SQL profile 等。

從 11g 開(kāi)始， oracle 引入了 SQL 執(zhí)行計(jì)劃管理（ SQL Plan Management ）這個(gè)新特性，從而可以讓系統(tǒng)自動(dòng)的來(lái)控制 SQL 語(yǔ)句執(zhí)行計(jì)劃的穩(wěn)定性，進(jìn)而防止由于執(zhí)行計(jì)劃發(fā)生變化而導(dǎo)致的性能下降。

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

當(dāng)然， 11g 也支持手工維護(hù) SQL 語(yǔ)句的 plan history ，作為對(duì)自動(dòng)維護(hù) plan history 的功能補(bǔ)充。
但是并不是說(shuō) plan history 里任何的執(zhí)行計(jì)劃都可以拿來(lái)使用。這里需要先介紹一下所謂的執(zhí)行計(jì)劃基準(zhǔn)線（ plan baseline ）這個(gè)概念。 plan baseline 是 plan history 的一個(gè)子集， plan baseline 里面的執(zhí)行計(jì)劃是用來(lái)比較性能好壞的一個(gè)依據(jù)。也就是說(shuō)，憑什么來(lái)判斷是否可以使用一個(gè)新產(chǎn)生的執(zhí)行計(jì)劃呢？就是把該新的執(zhí)行計(jì)劃與 plan baseline 里的計(jì)劃進(jìn)行比較來(lái)判斷。某個(gè) SQL 語(yǔ)句的執(zhí)行計(jì)劃可以屬于 plan history ，但是不一定屬于 plan baseline 。

注意：每個(gè) SQL 語(yǔ)句都會(huì)有它自己的執(zhí)行計(jì)劃歷史以及執(zhí)行計(jì)劃基準(zhǔn)線。

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

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

3.2 執(zhí)行計(jì)劃管理測(cè)試

首先把 optimizer_capture_sql_plan_baselines 參數(shù)設(shè)置為 TRUE;

insert into test_03 select rownum ,object_name from dba_objects;

set autotrace traceonly exp stat;

------------ 備注：在 PLSQL 工具中，打開(kāi)會(huì)報(bào)錯(cuò) : Cannot SET AUTOTRACE ，報(bào)這個(gè)錯(cuò)是由于第三方工具的問(wèn)題，在命令行下沒(méi)問(wèn)題。
此時(shí)我們進(jìn)行查詢
select * from test_03 where id = 200 ; ，見(jiàn)如下圖，屬于全表掃描

待續(xù)。。。。

4 ．虛擬列 -- Virtual Column

Oralce 的虛擬列解決了以前很多需要使用觸發(fā)器或者需要通過(guò)代碼進(jìn)行計(jì)算統(tǒng)計(jì)才能產(chǎn)生的數(shù)據(jù)信息。以前每次對(duì)其他的列進(jìn)行統(tǒng)計(jì)，產(chǎn)生新列的時(shí)候都是采用在 select 語(yǔ)句中通過(guò)統(tǒng)計(jì)計(jì)算增加新列的方法，執(zhí)行效率很低，而且由于使查詢 SQL 語(yǔ)句變得冗長(zhǎng)、復(fù)雜很容易出錯(cuò)。嚴(yán)重的降低了開(kāi)發(fā)效率和程序的執(zhí)行效率。 Oralce 虛擬列的引入解決了這個(gè)問(wèn)題。

Oralce 的虛擬列也有一些問(wèn)題。不能使用 insert into talbe_name values (). 語(yǔ)句，在向含有虛擬列的表中添加數(shù)據(jù)時(shí)，要求 insert 語(yǔ)句的必須把添加的表的列名寫(xiě)出來(lái)。 insert into table_name (list1,list2,...listend) 列名中不能出現(xiàn)虛擬列名，否則會(huì)提示錯(cuò)誤。

oracle 11g 新特性