分区表空间,也称为Partition Tablespace,这类表空间只能定义一个表,表空间被通过定义分区(Partition)来划分成多个称为分区的若干部分,每一个分区都对应一个单独的物理VSAM数据集。分区表空间的设计通过将大型的表中的数据分布在不同的物理磁盘设备上,来增强数据的可用性。
有两类的分区表空间:大型(LARGE)和非大型(non-LARGE)。定义为LARGE的表空间允许每个PARTITION大小可以达到4GB,进而允许一个表空间可以容纳超过64GB大小的数据。
分区表空间的分区个数,通过参数NUMPARTS指定,来表示表空间内包含多少个分区。目前在DB2 V8 版本,可以支持最多定义4096个分区。
每个分区的最大容量,通过参数DSSIZE来指定,有效的DSSIZE值分为:1GB(1 gigabyte)、2GB(2 gigabyte)、4GB(4 gigabyte)、8GB(8 gigabyte)、16GB(16 gigabyte)、32GB(32 gigabyte)、64GB(64 gigabyte)。
当用户定义的DSSIZE大于4GB时,需要运行在具有DFSMS 1.5版本基础上的系统环境中,表空间的数据集必须和定义为扩展格式和扩展寻址能力的DFSMS数据集相关联。创建大于4GB的数据集需要使用DFSMS扩展寻址功能。IBM用扩展寻址启动(EA-enabled)这个术语来定义能够支持扩展寻址能力的数据库。
分区表空间定义的PARTITION的个数依赖于页面的大小及DSSIZE参数的设置。整个分区表空间的大小依赖于定义的PARTITION个数总和及DSSIZE参数的设置。页面大小影响表空间的大小是因为它决定了一个分区表空间允许定义的PARTITION个数。
表2.1中整理了页面大小、DSSIZE、分区个数及表空间的关系。从表格中可以看出,对于非扩展寻址的数据库系统,最大允许的表空间为16TB,对于支持扩展寻址的数据库系统,最大允许的表空间为128TB。
表2.1 分区表空间
类 型 | 页面大小 | DSSIZE | Partition个数 | Tablespace大小 |
Non-EA | 4KB | 4GB | 4096 | 16TB |
EA | 4KB | 1GB | 4096 | 4TB |
EA | 4KB | 2GB | 4096 | 8TB |
EA | 4KB | 4GB | 4096 | 16TB |
EA | 4KB | 8GB | 2048 | 16TB |
EA | 4KB | 16GB | 1024 | 16TB |
EA | 4KB | 32GB | 512 | 16TB |
EA | 4KB | 64GB | 256 | 16TB |
EA | 8KB | 1GB | 4096 | 4TB |
EA | 8KB | 2GB | 4096 | 8TB |
EA | 8KB | 4GB | 4096 | 16TB |
EA | 8KB | 8GB | 4096 | 32TB |
续表
类 型 | 页面大小 | DSSIZE | Partition个数 | Tablespace大小 |
EA | 8KB | 16GB | 2048 | 32TB |
EA | 8KB | 32GB | 1024 | 32TB |
EA | 8KB | 64GB | 512 | 32TB |
EA | 16KB | 1GB | 4096 | 4TB |
EA | 16KB | 2GB | 4096 | 8TB |
EA | 16KB | 4GB | 4096 | 16TB |
EA | 16KB | 8GB | 4096 | 32TB |
EA | 16KB | 16GB | 4096 | 64TB |
EA | 16KB | 32GB | 2048 | 64TB |
EA | 16KB | 64GB | 1024 | 64TB |
EA | 32KB | 1GB | 4096 | 4TB |
EA | 32KB | 2GB | 4096 | 8TB |
EA | 32KB | 4GB | 4096 | 16TB |
EA | 32KB | 8GB | 4096 | 32TB |
EA | 32KB | 16GB | 4096 | 64TB |
EA | 32KB | 32GB | 4096 | 128TB |
EA | 32KB | 64GB | 2048 | 128TB |
使用分区表空间的优点在于:
(1)每个分区可以指定不同的Storage Group,以区分不同物理存储介质。
(2)每个分区被放在不同的DASD卷上,这将提高访问效率。
(3)分区表空间是唯一可以容纳大于64GB数据的表空间。64GB是简单表和分段表空间最大容量。一个分区表空间可以容纳到16TB的数据(4096个分区,每个分区容纳4GB的数据,4096×4=16TB)。一个支持扩展寻址的分区表空间可以容纳大到128TB的数据(2048个分区,每个分区容纳64GB的数据,2048×64=128TB)。
(4)可以在分区一级上使用启动和停止命令,通过停止一个指定的分区,其他分区仍然可以使用,这样就提高了可用性。
(5)每一个分区都相对独立,对外的访问和操作都可以视为单独的对象,查询的I/O、CPU使多个引擎可以同时并行访问不同的分区,这通常会减少运行的时间,分区可以通过消除磁盘竞争使并行得到最优效率。
(6)对分区表空间的扫描可以跳过查询谓词中排除的分区,在表空间扫描时跳过分区可以提高整个查询的性能。
(7)可以通过建立聚簇索引(Cluster Index)减少对数据的竞争。例如,如果表空间按部门分区,则每个部门的数据被放置在一个单独的分区文件上。每个部门在一个离散的物理数据集中,因而由于多个部门共存在一个页面上引起的部门间的访问竞争就减少了。注意,如果定义了非分区索引,非分区索引的数据仍然有竞争存在。因为非分区索引是有顺序的,如果用户在分区表上定义非分区索引,则分区级上的独立性所带来的数据库工具并行操作的好处将丧失。
(8)DB2 会为分区表空间的每一个分区创建一个单独的压缩字典。多个字典将会有更高压缩率。
(9)可以在分区表空间的分区一级上执行REORG、COPY和RECOVER等工具。这样工具执行的效率和并行度会大大提高,且在运行这些工具时由于分区的独立性和资源串行从而进一步增加了分区的可用性。这样对于系统维护和故障处理来说,在分区级别而不是整个表空间级别上处理,从效率和影响范围来说都要小得多。
(10)在DB2 V8版本后,对于表空间级别的锁也下放到分区一级,增大了数据更新的并发性。
使用分区表空间的缺点在于:
(1)每一个分区表空间只能定义一张表,这也不能说是缺点,仅是一个限制。
(2)每一个分区对应的物理数据集大小在定义时就已经确定,如果定义分区内存储的数据超过分区数据集定义的最大值,该物理数据集不会自动扩展,DB2 会报一个资源不可用的信息给用户,该分区标志为不可用。
(3)在创建分区索引前,作为插入表中数据依据的关键字的值的范围应当是一致的、稳定的。为了定义一个分区,值的范围必须在分区索引中通过编码来定义。这个范围应当能够根据应用使用数据时的访问需求将数据分布在各个分区上。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23577591/viewspace-689653/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23577591/viewspace-689653/