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)列名中不能出现虚拟列名，否则会提示错误。