oracle 11g 新特性

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 新特性