您所在位置：主题：[转帖]oracle 11g的一些新特性
ilovemountainking
[专家分：3730] 发布于 2007-07-08 00:53:00
简单介绍一下在今年即将发布的Oracle 11g中存储级别的ASM (Automatic Storage Management)的一些新功能。
1. ASM Fast Mirror Resync
在10g的ASM中如果因为某些硬件故障（比如接口线，比如光纤卡，比如电源）导致Diskgroup中的某些磁盘无法正常读取，这些磁盘将处于 offline状态，在offline之后不久ASM就会把这些磁盘从Diskgroup中删除，并且尝试利用冗余的extent来重新在其它磁盘中构建数据，这是一个比较耗时且耗资源的操作。当我们修复了磁盘，再将它们重新加回磁盘组中，又将是另外一次的数据重整操作。如果我们仅仅是例行的维护硬件，因为磁盘中的数据并没有真正的损坏，我们只是将磁盘取出来过一会儿再加回去，那么这样的两次数据重整操作无疑是没有必要的，在11g中ASM的Fast Mirror Resync功能允许我们设置磁盘的repair时间，在repair时间内ASM将不会尝试在磁盘间重新分配extent。
ALTER DISKGROUP dgroup SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';
上述命令可以设置当磁盘组dgroup中的磁盘失效和重新有效之间的时间在3小时内的话，ASM就不会重新构建extent，当磁盘重新有效之后，ASM需要做的只是将这3小时内更改的extent重新同步到刚才失效的这些磁盘中就可以了。
2. ASM Preferred Mirror Read
我们知道在10g中ASM总是会去读取Primary extent，这样做的目的是为了更好的分散IO，但是在某些环境中，一个ASM磁盘组中的磁盘对于某一个特定的节点来说，有些是Local Disk而有些则是Remote Disk，从Remote Disk中读取数据效率会低于Local Disk，但是在10g中我们无法要求从哪组磁盘中读取数据，在11g中新增的ASM_PREFERRED_READ_FAILURE_GROUPS参数帮助我们完成了这个功能。给每个实例设置优先读取的Failure Group就可以了。
3. ASM扩展性的增强
更详细的数据留待11g正式版出来以后再说吧，目前知道的是对于外部冗余（External redundancy），ASM可以最大支持到140PB了，而在10g中这个数字仅仅是35TB。
Partition（分区）一直是Oracle数据库引以为傲的一项技术，正是分区的存在让Oracle高效的处理海量数据成为可能，在即将发布的Oracle 11g中，分区技术在易用性和可扩展性上再次得到了增强。
1. Interval Partitioning
在我曾经的一个项目中，由于数据量的巨大，所以表设计为每一个小时一个分区，数据库管理员日常要做的一件重复而无聊的工作就是每隔一天要生成新的24个分区，用以存储第二天的数据。
而在11g中这项工作可以交由Oracle自动完成了，基于Range和List的Interval Partitioning分区类型登场。
1. CREATE TABLE TB_INTERVAL
2. PARTITION BY RANGE (time_col)
3. INTERVAL(NUMTOYMINTERVAL(1, 'month'))
4. (PARTITION P0 VALUES LESS THAN (TO_DATE('1-1-2007', 'dd-mm-yyyy')));
指定需要Oracle自动创建分区的间隔时间，上面这个例子是1个月，然后至少创建一个基本分区，上面这个例子是在2007-1-1之前的所有数据都在P0分区中，以后每个月的数据都会存放在Oracle自动创建的一个新分区中。
目前还没有更多的资料显示Oracle如何控制每个新分区的属性，比如存放在哪个表空间中，自动创建的数据文件有多大，如果是数据文件是裸设备如何处理，当第一条跨分区的记录插入时实时创建分区效率如何，虽然这些仍然是未知数，但是我们不得不承认这是一个人性化的进步。
2. System Partitioning
又一个人性化的分区类型，系统分区，在这个新的类型中，我们不需要指定任何分区键，数据会进入哪个分区完全由应用程序决定，实际上也就是由SQL来决定，终于，我们在Insert语句中可以指定插入哪个分区了。
假设我们创建了下面这张分区表，注意，没有指定任何分区键：
1. CREATE TABLE systab (c1 integer, c2 integer)
2. PARTITION BY SYSTEM
3. (
4. PARTITION p1 TABLESPACE tbs_1,
5. PARTITION p2 TABLESPACE tbs_2,
6. PARTITION p3 TABLESPACE tbs_3,
7. PARTITION p4 TABLESPACE tbs_4
8. );
现在由SQL语句来指定插入哪个分区：
1. -- 数据插入p1分区
2. INSERT INTO systab PARTITION (p1) VALUES (4,5);
3. -- 数据插入第2个分区，也就是p2分区
4. INSERT INTO systab PARTITION (2) VALUES (7,8);
5. -- 为了实现绑定变量，用pno变量来代替实际分区号，以避免过度解析
6. INSERT INTO systab PARTITION (:pno) VALUES (9,10);
由于System Partitioning的特殊性，所以很明显，这种类型的分区将不支持Partition Split操作，也不支持create table as select操作。
3. More Composite Partitioning
在10g中，我们知道复合分区只支持Range-List和Range-Hash，而在在11g中复合分区的类型大大增加，现在Range，List， Interval都可以作为Top level分区，而Second level则可以是Range，List，Hash，也就是在11g中可以有3*3=9种复合分区，满足更多的业务需求。
4. Virtual Column-Based Partitioning
Virtual Column是11g中的一个新功能，这种列中的数据并不实际存储于磁盘上（我们可以看成是一个类似Function的列），只有当读取的时候才实时计算。暂时不讨论性能问题，这个功能还是比较有意思的。
可以通过这样的语句来创建虚拟列。
1. CREATE TABLE tb_v
2. (col_1 number(6) not null,
3. col_2 number not null,
4. …
5. col_v as (col_1 *( 1+col_2));
虚拟列虽然没有实际的存储空间，但是却可以跟其他普通列一样，创建索引，作为分区键，甚至可以收集统计信息，这是让人感觉有意思的地方，一个实时计算的Function如何创建索引呢？等到11g推出的时候就真相大白了。
1. ASM Fast Mirror Resync
在10g的ASM中如果因为某些硬件故障（比如接口线，比如光纤卡，比如电源）导致Diskgroup中的某些磁盘无法正常读取，这些磁盘将处于 offline状态，在offline之后不久ASM就会把这些磁盘从Diskgroup中删除，并且尝试利用冗余的extent来重新在其它磁盘中构建数据，这是一个比较耗时且耗资源的操作。当我们修复了磁盘，再将它们重新加回磁盘组中，又将是另外一次的数据重整操作。如果我们仅仅是例行的维护硬件，因为磁盘中的数据并没有真正的损坏，我们只是将磁盘取出来过一会儿再加回去，那么这样的两次数据重整操作无疑是没有必要的，在11g中ASM的Fast Mirror Resync功能允许我们设置磁盘的repair时间，在repair时间内ASM将不会尝试在磁盘间重新分配extent。
ALTER DISKGROUP dgroup SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';
上述命令可以设置当磁盘组dgroup中的磁盘失效和重新有效之间的时间在3小时内的话，ASM就不会重新构建extent，当磁盘重新有效之后，ASM需要做的只是将这3小时内更改的extent重新同步到刚才失效的这些磁盘中就可以了。
2. ASM Preferred Mirror Read
我们知道在10g中ASM总是会去读取Primary extent，这样做的目的是为了更好的分散IO，但是在某些环境中，一个ASM磁盘组中的磁盘对于某一个特定的节点来说，有些是Local Disk而有些则是Remote Disk，从Remote Disk中读取数据效率会低于Local Disk，但是在10g中我们无法要求从哪组磁盘中读取数据，在11g中新增的ASM_PREFERRED_READ_FAILURE_GROUPS参数帮助我们完成了这个功能。给每个实例设置优先读取的Failure Group就可以了。
3. ASM扩展性的增强
更详细的数据留待11g正式版出来以后再说吧，目前知道的是对于外部冗余（External redundancy），ASM可以最大支持到140PB了，而在10g中这个数字仅仅是35TB。
Partition（分区）一直是Oracle数据库引以为傲的一项技术，正是分区的存在让Oracle高效的处理海量数据成为可能，在即将发布的Oracle 11g中，分区技术在易用性和可扩展性上再次得到了增强。
1. Interval Partitioning
在我曾经的一个项目中，由于数据量的巨大，所以表设计为每一个小时一个分区，数据库管理员日常要做的一件重复而无聊的工作就是每隔一天要生成新的24个分区，用以存储第二天的数据。
而在11g中这项工作可以交由Oracle自动完成了，基于Range和List的Interval Partitioning分区类型登场。
1. CREATE TABLE TB_INTERVAL
2. PARTITION BY RANGE (time_col)
3. INTERVAL(NUMTOYMINTERVAL(1, 'month'))
4. (PARTITION P0 VALUES LESS THAN (TO_DATE('1-1-2007', 'dd-mm-yyyy')));
指定需要Oracle自动创建分区的间隔时间，上面这个例子是1个月，然后至少创建一个基本分区，上面这个例子是在2007-1-1之前的所有数据都在P0分区中，以后每个月的数据都会存放在Oracle自动创建的一个新分区中。
目前还没有更多的资料显示Oracle如何控制每个新分区的属性，比如存放在哪个表空间中，自动创建的数据文件有多大，如果是数据文件是裸设备如何处理，当第一条跨分区的记录插入时实时创建分区效率如何，虽然这些仍然是未知数，但是我们不得不承认这是一个人性化的进步。
2. System Partitioning
又一个人性化的分区类型，系统分区，在这个新的类型中，我们不需要指定任何分区键，数据会进入哪个分区完全由应用程序决定，实际上也就是由SQL来决定，终于，我们在Insert语句中可以指定插入哪个分区了。
假设我们创建了下面这张分区表，注意，没有指定任何分区键：
1. CREATE TABLE systab (c1 integer, c2 integer)
2. PARTITION BY SYSTEM
3. (
4. PARTITION p1 TABLESPACE tbs_1,
5. PARTITION p2 TABLESPACE tbs_2,
6. PARTITION p3 TABLESPACE tbs_3,
7. PARTITION p4 TABLESPACE tbs_4
8. );
现在由SQL语句来指定插入哪个分区：
1. -- 数据插入p1分区
2. INSERT INTO systab PARTITION (p1) VALUES (4,5);
3. -- 数据插入第2个分区，也就是p2分区
4. INSERT INTO systab PARTITION (2) VALUES (7,8);
5. -- 为了实现绑定变量，用pno变量来代替实际分区号，以避免过度解析
6. INSERT INTO systab PARTITION (:pno) VALUES (9,10);
由于System Partitioning的特殊性，所以很明显，这种类型的分区将不支持Partition Split操作，也不支持create table as select操作。
3. More Composite Partitioning
在10g中，我们知道复合分区只支持Range-List和Range-Hash，而在在11g中复合分区的类型大大增加，现在Range，List， Interval都可以作为Top level分区，而Second level则可以是Range，List，Hash，也就是在11g中可以有3*3=9种复合分区，满足更多的业务需求。
4. Virtual Column-Based Partitioning
Virtual Column是11g中的一个新功能，这种列中的数据并不实际存储于磁盘上（我们可以看成是一个类似Function的列），只有当读取的时候才实时计算。暂时不讨论性能问题，这个功能还是比较有意思的。
可以通过这样的语句来创建虚拟列。
1. CREATE TABLE tb_v
2. (col_1 number(6) not null,
3. col_2 number not null,
4. …
5. col_v as (col_1 *( 1+col_2));
虚拟列虽然没有实际的存储空间，但是却可以跟其他普通列一样，创建索引，作为分区键，甚至可以收集统计信息，这是让人感觉有意思的地方，一个实时计算的Function如何创建索引呢？等到11g推出的时候就真相大白了。