ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转载]《Oracle 9i&10g 编程艺术》——分区表

[转载]《Oracle 9i&10g 编程艺术》——分区表

原创 Linux操作系统 作者:tolywang 时间:2011-01-21 14:13:57 0 删除 编辑

 

13.1 分区概述
“分而治之”的思想体现。

分区的好处:
1.提高数据的可用性:这点是可以肯定的,要出现问题仅仅可以局限在某个或某几个分区上,不会影响其他的分区数据
2.由于从数据库中取出了大段,相应地减轻了管理的负担:(个人认为也得从两方面来将,因为分区本身的维护也需要成本)
3.改善某些查询的性能:大型数据仓库上使用,在OLTP上不适用,因为OLTP本身就是访问比较少的数据量
4.可以把修改分布到多个单独的分区上,从而减少大容量OLTP系统上的竞争:只有出现大的竞争的时候才会有效

13.1.1 提高可用性
可用性的提高来源于每个分区的独立性。

优化器可以感知到分区的存在。

使用散列分区,我们可以让Oracle随机地(很可能是均匀地)将数据分布到多个分区上。
我们无法控制数据会分布到哪个分区,需要根据生成的散列键值来确定

可用性的两个方面:
1.优化器能够消除分区,这意味着许多用户可能甚至从未注意到某些数据是不可用的。
2.出现错误时的停机时间会减少,因为恢复所需要的工作量会大幅的减少。

13.1.2 减少管理负担
原理:在小对象上执行同样的维护操作从本质上将更为容易、速度更快,而且恢复所需要的资源也更少。

对在线重定义超大的索引(10G)带来的好处是巨大的!!!
所需要的维护空间更小,效率更高。
在线索引重建期间发生的事务修改会更少。

如果在重建过程中出现了问题,分区后重做的内容也会大大的减少。 Good。

也许任务仅仅是:重建最新加入的那个分区的索引。分区有意义。

很有可能因为临时表空间太小无法完成超大表的move维护操作。
因为在move过程中,需要同时保留一份原表的一个副本。即在很短的时间内需要大约两倍的存储空间。

简单的说:利用分区,原先让人畏惧的操作,有时甚至是不可行的操作,会变得像在小数据库中完成的一样。

13.1.3 改善语句性能

1.OLTP系统
在OLTP系统中使用分区,大多情况下不能提高数据访问的性能。不过某些情况下可以减轻管理的负担以及会有更高的可用性。
因为OLTP中都是操作非常小的数据集合,而且在OLTP系统中不会存在对大对象全面扫描的情况发生————如果存在,说明程序设计需要改进。

在OLTP系统中唯一的一种可以提高效率的情况:利用分区来减少竞争,从而提高并发度。
原理:可以利用分区将一个表的修改分布到多个物理分区上。并不是只有一个表段和一个索引段。

在一个OLTP系统最好不要出现并行查询!

2.数据仓库系统
数据仓库和决策支持系统中,分区是非常强大的管理工具,可以加快处理的速度。

对即席查询的辅助支持。如:对要查找的字段进行分区,可以提速。

数据仓库中会频繁的使用到并行查询,并行索引扫描或并行快速全面索引扫描等在此显得非常重要。

OLAP和DSS系统中,分区就意味着很可能会加快处理速度。

13.2 表分区机制
4种分区方法:
1.区间分区
2.散列分区
3.列表分区
4.组合分区

13.2.1 区间分区
“映射”概念。

13.2.2 散列分区
Oracle建议散列分区的个数是2的幂(2、4、8、16),有助于得到最佳的总体分布。这一点非常的重要!!!
Tom的实验很清晰的展示了这个过程。Good.

1.散列分区如何工作。

2.散列分区数使用2的幂

13.2.3 列表分区
9iR1的新特性。

ORA-14323: cannot add partition when DEFAULT partition exists

13.2.4 组合分区
组合分区中,顶层分区机制总是区间分区(注:11g中不是这样了,提供了更多的排列组合方式,得到了非常大的扩展,Oracle很重视分区技术)

分区成为一个逻辑容器,或者是一个指向实际子分区的容器。

13.2.5 行移动
为防止数据操作过程中的报错,需要启用行移动特性。
alter table range_example enable row movement;

行移动的开销比正常的update昂贵得多。所以,如果构建的系统会频繁修改分区键,而且这种修改会导致分区移动,这种设计方法是要坚决抵制的。

13.2.6 表分区机制小结
区间分区是最常用的分区形式。

如果不能按自然的区间进行分区,可以使用散列分区。目的是为了提供管理、性能和可用性提升等诸多好处的情况下使用。在where条件中使用完全相等或in子句时,散列分区可以利用分区消除,但是,如果使用区间时,散列分区无法利用分区消除。

如果数据中的一列有一组离散值,而且根据应用使用这一列的方式来看,按这一列分区很有意义(例如可以轻松地利用分区消除)。适合使用列表分区。例如,许多“代码”型属性都很适合应用列表分区。(这次项目中评估后,我打算采用这中分区技术来实现)

如果某些数据逻辑上可以进行区间分区,但是得到的区间分区还是很大,不能有效地管理,就可以使用组合分区。

总体建议:如果按某个属性自然地对数据完成区间分区,就应该使用区间分区,而不是散列分区和列表分区。
因为后者在分区消除方面都不如区间分区好用。

13.3 索引分区
1.随表对索引完成相应的分区————局部分区索引(locally partitioned index),每个表都有一个索引分区,而且只索引该表分区。
2.按区间对索引分区————全局分区索引(globally partitioned index),在此,索引按区间或散列分区,一个索引分区可能指向任何表分区。

对于全局分区索引,要注意,实际上,索引分区数可能不同于表分区数。

全局索引只能按区间或散列分区,索引如果希望有一个列表或组合分区索引,就必须使用局部索引。局部索引会使用与底层相同的机制完成分区。

全局索引的散列分区是在10gR1才有的功能。

13.3.1 局部索引与全局索引

经验如下:
数据仓库   ----采用局部索引
OLTP     ----采用全局索引
这取决于是否需要在索引结构上执行分区消除来维护分区后与分区前有同样的查询响应时间。

局部索引有其自己的特有的性质:支持一个更可用的环境,停机时间更少,因为问题会被隔离到一个区间或数据散列上。

然而全局索引可以指向多个表分区,因此可能会成为一个故障点,对于某些查询来说,一旦全局索引出故障,则所有分区都不可访问。

从维护角度看,局部索引更为灵活。移动一个表分区,只需要重建和维护相关的局部索引分区。
注意全局索引的重建问题的严重性。

Oracle可以利用索引随表进行局部分区这一事实,开发最优的查询计划。而对于全局索引,索引和表分区之间就没有这种关系。

局部索引还有利于分区时间点恢复操作。

全局索引也很重要的,但是在使用之前要评估一下它会带来的影响。

13.3.2 局部索引
两类局部索引
1.局部前缀索引local prefixed index:分区键在索引的前几列上
2.局部非前缀索引local nonprefixed index:这些索引不以分区键作为其列表的前几列,索引可能包含分区键,也可能不包含分区键

如果查询中将索引用作访问表的初始路径,那么从本质来讲,局部前缀索引并不比局部非前缀索引更好。如果查询把"扫描一个索引"作为第一步,那么前缀索引和非前缀索引之间并没有太大的差别。

1.分区消除行为
重点是:要尽可能保证查询包含的谓词允许索引分区消除。
使用前缀局部索引可以保证这一点,使用非前缀索引则不能保证。

还要考虑如何使用索引,如果将索引引用作查询计划中的第一步,那么这两种类型的索引没有多少差别。

2.局部索引和唯一约束
如果想使用一个局部索引来保证这个约束,那么分区键必须包括在约束本身中。Tom认为这是局部索引的最大限制。

Oracle只保证索引分区内部的唯一性,而不能跨分区。
意味着:不能一方面在一个timestamp字段上执行区间分区,而另一方面在ID上有一个主键。Oracle会利用全局索引来保证唯一性。

对分区表中的某个分区做truncate或者move,shrink等,可能会影响到n个全局索引分区,正因为这一点,局部分区索引具有更高的可用性。

13.3.3 全局索引

全局索引只有一类,就是:前缀全局索引。

全局索引的一个需求:最高分区必须有一个值为MAXVALUE的分区上界。确保底层表中的所有行都能放在这个索引中。

应用全局索引的场景:
1.数据仓库和全局索引
原先的数据仓库系统中很抵制使用全局索引。

数据仓库意味着:大量数据的录入、大量数据的删除
滑动窗口(sliding window)来完成上面的工作:删除表中最旧的分区,并为新加载的数据增加一个新分区。

8i及以前版本数据仓库系统都会避免使用全局索引,原因是:全局索引缺乏可用性。大多数分区操作都会使全局索引无效,除非重建全局索引,否则无法使用,这会严重地影响可用性。

新的方法:数据滑动窗口(sliding window of data
如何绕过全局索引的影响。
(1)滑动窗口和索引
滑动窗口过程如下:
1.去除老数据:删除数据,或与一个空表交换
2.加载新数据并建立索引:在一个“工作表”中加载新数据
3.关联新数据:“工作表”中的数据与分区表的一个空分区交换

通过简单的数据字典更新实现的滑动过程,速度超快。

这种方法好处:能非常快的完成任务
缺点:索引会失效,在重新创建索引过程中,对应用有很大的冲击,而且重新创建全局索引的时间会非常的长,而且会使用非常多的资源。

(2)“活动”全局索引维护
在9i版本之后,可以使用update global indexes子句来维护全局索引。
这个特性对于需要提供数据连续访问的系统来说是必行之举!

原理:牺牲分区操作的速度,换取100%的数据可用性。
如果系统不允许有停机时间,那么只能使用这个技术来保障。

需要权衡的地方:在整个过程中,因为要维护全局索引,所以会带来大量的开销(insert、delete)。
注意对redo和undo产生的评估,可能的话需要提前进行调整。

2.OLTP和全局索引
OLTP特点:频繁地出现许多小的读写事务。首要要求是:快速的获得所需行的数据。
具体特点总结罗列如下:
1)快速访问,速度至上,快速得到所需的数据行
2)数据完整性要求高
3)可用性要求高
4)OLTP不适合并行查询
5)必须使用到索引分区消除
6)需要适当的提供索引,以便利用某些字段上的全局索引

13.4 再论分区和性能
数据仓库中使用分区利多害少!
OLTP系统中使用分区害多利少!因为OLTP类型的系统获取的数据量很少。

OLTP使用分区仅有的一些好处:
1.高度并发环境中数据修改有利,分区可以提供显著的好处。
2.大数量的可管理性。
3.大数量的可用性。
4.需要在SQL语句中使用分区键,显示的指定去哪个分区找数据,可以提高性能。

必须使用order by语句来保证数据的有序性。
group by也不会执行排序! order by是无可替代的!

13.5 审计和段空间压缩
大环境对数据库的审计需求越来越重。

实现审计数据的保存需求时往往会使用到分区技术。

审计跟踪信表空间建议:
1.一个当前在线的读写表空间:不会被压缩,只向其中插入信息。
2.一个只读表空间:包含“当前这一年”的审计跟踪信息分区,采用压缩格式。每个月的月初,置这个表空间为可读写,向这个表空间中移入上个月的审计信息,并进行压缩,再使之成为只读表空间,并完成备份
3.用于去年、前年等的一系列表空间。都是只读的。

采用这种方式可以很容易的实现“净化”(删除一个分区)的目的。

13.6 小结
分区是扩展数据库中大对象的有效途径。大对象可以被分成更小、更可管理的部分。

性能扩展   ---- 系统的最终用户关心这一点。
可用性扩展  ---- 系统所有者关心这点,因为停机时间就意味着金钱损失。
管理扩展   ---- 维护DBA重视这一点。

OLTP中使用分区技术不太合适。

分区可能会提高某些类型查询的性能,但是这些常用的OLAP/DSS查询类型通常不会在OLTP系统中使用。

不能想当然的把分区和“性能提升”联系到一起。

法律方面的原因,审计需求可能很重,所以不可回避的需要用到分区技术。

http://space.itpub.net/519536/viewspace-613449    

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/35489/viewspace-684433/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13471962