分类：
2008-04-13 00:19:57
| 来源：51cto |
|
索引设计考虑事项
索引是一个DB2对象（独立的VSAM数据集），它是从相应表中的一个或更多列中摘录出来的一系列有规则的条目。很多DB2专家主张为一个表空间建立恰当的索引，这也许是将访问DB2数据应用程序的性能最优化的惟一最有效的方法。几年前，在I/T中DASD的成本和空间是一个更重要的考虑因素。随着技术的发展，通过以特大硬盘为代价，加上更多索引（或增加现有索引的列）来减少I/O的折中方法，在这几年里越来越具吸引力。索引主要的性能优势表现在：
为表中被请求的数据行提供直接指针
消除了排序，如果结果集的请求顺序与索引相匹配的话
避免了必须读取数据行，如果被请求的列全部包含在索引条目中的话
分区索引
当在DB2 UDB V7中创建分区表空间时，DB2依照CREATE INDEX语句中的PART子句将分区中的数据进行划分。那个索引则成为所谓的分区索引，这种分区方法被称为受控索引分区。为了对索引进行分区，建议你选择不易改变的关键列。对这些列的更改可能使得一个行从某一分区移动到另外一个分区，从而导致性能下降。
受控表分区是DB2 V8的一个重要的特征。现在，当创建分区表时，分区界限的确定由CREATE TABLE语句代替了原来的CREATE INDEX。在受控索引分区中，分区表的、分区索引和聚簇的概念全都结合在一起。而对于受控表分区，这三个概念是独立的。这就增加了灵活性，允许你去考虑更有潜力的设计方法；并且也因此增加了改善DB2数据库及其应用程序性能的可能性。
构建索引的时机
CREATE INDEX（创建索引）
CREATE INDEX语句使用户具有了这样的能力：立即构建索引，或者将构建推迟到更加方便的时间。如果你立即构建索引，将会对表空间进行扫描，这会占用相当长的时间。通过设定DEFER，你可以推迟索引的构建。
无论什么时候，只要可能，在最初载入一个表之前创建表上的所有索引，因为LOAD实用工具集构建索引比CREATE INDEX过程更加有效。如果你需要在已存在（并且有很多数据）的表上创建一个索引，那么可以使用DEFER语句。稍后，你就可以用REBUILD INDEX实用工具集，它和LOAD实用工具集一样，是一种更加有效的填充索引的方法。
PIECESIZE（片段尺寸）
DB2 UDB V5引进了一个新特征，它给了你一定的灵活性，从而可以将非分区索引（NPI）分解为小段，并且控制组成索引空间的多个数据集的大小。分段的这种用法能够使一个NPI的索引页展开为多个数据集。
片段的尺寸由CREATE或ALTER INDEX语句中的关键字PIECESIZE确定。PIECESIZE的值必然是两个强制值中的一个，其变动范围为最小256KB到最大64GB。常规表空间的默认值为2GB，大的表空间默认值是4GB。如果你的NPI有可能显著增长，那么选择相对较大的表空间。同样，在确定首要和次要的空间分配数值（CREATE INDEX语句的PRIQTY和SECQTY选项）时，记住PIECESIZE的值。
利用这一选项，可以通过发挥并行性来改善NPI的扫描性能。另一个优势是可以减少读取或更新过程中的I/O冲突。通过设定较小的PIECESIZE值，你可以创建更多的片段，因而对片段的位置有更好的控制。将片段置于独立的I/O路径，可以减少了访问NPI所需的SQL操作的冲突。
理想的索引
通过检查一个应用程序中的SQL语句，你可以建立一个假想的完美的索引。
首先，索引所包括的所有列都是WHERE子句，这使得索引的审查可以用于将不合格的行拒于结果集之外。将这些列放在索引的开始。当在SQL语句上执行EXPLAIN时，这会使得MATCHCOLS的价值最大化。
其次，确保索引以适当的顺序含有这些列(依照ORDER BY子句)，从而可以避免进行排序。这可以在执行EXPLAIN时，通过检查PLAN_TABLE的所有不同的SORT*列来验证。
最后，如果可能的话，将所有的列包含在索引的SELECT中，这样就不需要访问表中的行了。索引条目可以提供所有的请求数据。这将在EXPLAIN中以INDEXONLY = Y的方式表现出来。
在很多情况下，实现如此理想的索引的代价太大了，或者说是不切合实际的，甚至是不可能实现的，因为所涉及的列的数量太大了。组成一个索引的列的数目在体系结构方面有限制，并且对于一个索引条目的总长也有限制（尽管这些限制实际上允许相当大的索引条目尺寸和灵活性）。此外，这也是出于索引维护成本的考虑。建立理想的索引可使查询性能获得极大提高，但是对于SQL写入DB2数据库（INSERT、UPDATE或DELETE）就有消极的影响。因此，你应该经常选择实现只包含WHERE和ORDER BY语句中涉及的列的索引。
并行处理的考虑事项
几年来，通过实现了并行处理的各种方法，DB2在数据访问方面的性能获得了改进。为了改进数据密集型只读查询的性能，DB2 V3引进了查询I/O并行机制。在这种类型的并行性中， DB2充分利用了可用的I/O带宽，并使分区表空间中成为可能。利用这种方法，DB2使得一个查询中的多个并发I/O请求可同时进行，并在多个数据分区中执行了并行的I/O处理。这代表性地使得I/O绑定查询所耗费时间的显著降低，同时出现了CPU时间的较小增长。
DB2 V4引入了另外的并行性技术，称为查询CP并行性。该方法将并行处理扩展至处理密集型的查询。用该方法，单个查询可使DB2生成数个任务，并行执行数据访问。对于这种类型的并行性，分区表空间显示出最佳的性能提升。
DB2 UDB V5通过引进综合系统查询并行性，更进一步地扩展了并行处理。当查询CP并行性在DB2子系统中为某个查询使用了多个任务时，该方法使得DB2数据共享群中的所有成员能够处理一个单一的查询。主要为只读形式的I/O密集型和处理密集型查询可以从这种类型的并行性中获益。
并行访问的授权
在DB2环境下使系统获得并行性能力有一定的难度。首先，在DB2子系统级别，并行访问由安装面板DSNTIP4控制。DSNTIP4上的MAX DEGREE 选项决定并行性的最大程度（并行任务的最大数目）。默认值为0，意味着对于DB2可调用的并行性程度没有上限。我建议你估计虚拟存储容量，以及你的z/OS环境限制，还应根据需要调整该参数，因此DB2将不会创建超过你的虚拟存储容量可以应对的并行任务。
通过BIND PLAN和BIND PACKAGE命令的DEGREE选项，你能够控制DB2是否使用并行处理。设定DEGREE(1)阻止并行处理，而DEGREE(ANY)允许并行处理。为了获得进一步的灵活性，动态SQL允许在一个计划或包内更改该选项，通过SET CURRENT DEGREE语句即可实现，SET CURRENT DEGREE语句用于控制某个寄存器中的数值。
当一个计划或包与DEGREE(ANY)绑定，或者CURRENT DEGREE寄存器设定为ANY时，DB2优化器考虑并行性是否是可能的，从而获得最有效的最终计划。如果并行性是不可能的，那么将会选择下一个允许并行性的最有效的最终计划。 |
