五、索引设计方面的考虑 索引也是一种
DB2对象（一个单独的VSAM数据集），它由一组排好序的键组成，这些键是从相应表中的一个列或多个列抽取出来的。很多
DB2专家声称，只有为表空间建立恰当的索引，才是使得访问该表空间中
DB2数据的应用程序的性能达到最佳、最有效的效果。数年前，在I/T中DASD的成本和空间是更重要的考虑因素。随着技术的发展，通过增加更多的索引（或添加列到已有的索引中）来减少I/O，以及由此消耗的额外磁盘空间，这几年两者之间的权衡已经变得越来越有吸引力。索引所带来的主要性能好处是：
1) 提供指向表中被请求的数据行的直接指针。
2) 如果结果集要求的顺序与索引一致，则可以消除排序。
3) 如果被请求的列都包含在索引项中，则可以避免不得不读数据行的情况。
1. 分区索引
在
DB2 UDB V7中创建分区的表空间时，
DB2根据CREATE INDEX语句的PART子句将数据划分到几个分区上。那样的索引就成为所谓的分区索引，而这种分区的方法就被称为 索引控制的分区（index-controlled partitioning）。对于分区索引，建议选择不大可能改变的键列。如果对那些列进行更新，则可能导致一行从一个分区转移到另一个分区，从而降低了性能。
DB2 V8一个重要的特性是表控制的分区（table-controlled partitioning）。这时，当创建分区的表时，分区的边界由CREATE TABLE语句决定，而不是由CREATE INDEX语句决定。对于索引控制的分区方法，分区的表、分区索引和群集这几个概念之间有点纠缠不清。而在表控制的分区方法中，这三个概念是各自独立的。这种增加的灵活性使您可以考虑更多潜在的设计方案，因而也增加了提高
DB2数据库及其应用程序性能的机会。
2. 何时建立索引
CREATE INDEX语句使用户可以立即建立索引，或者将索引的建立推迟到方便的时候。如果立即建立索引，则需要扫描表空间，这样要花费比较多的时间。通过指定DEFER，则可以推迟索引的创建。
只要有可能，应该在初次装载一个表之前创建其所有索引，因为LOAD实用程序建立索引的效率比CREATE INDEX过程要高。如果需要在一个已有的（并且被填充的）表上创建一个索引，那么可以使用DEFER子句。然后可以在晚些时候使用REBUILD INDEX实用程序，这个实用程序与LOAD实用程序一样，是更为有效的填充索引的方式。
3. PIECESIZE
DB2 UDB V5中引入了一个新特性，这种特性使您可以将一个非分区索引（non-partitioning index，NPI）拆成数块，然后控制将组成索引空间的多个数据集的大小。通过使用这些小块，可以使NPI的索引页散步到多个数据集中。
通过在CREATE或ALTER INDEX语句中指定关键字PIECESIZE，可以确定各块的大小。PIECESIZE的值必须是2的幂，其大小可以介于256KB到64GB之间。对于常规表空间，PIECESIZE的默认值是2GB，对于LARGE表空间，默认值是4GB。如果NPI极有可能显著增长，那么应选择一个更大的值。在为主空间和辅助空间（CREATE INDEX语句的PRIQTY和SECQTY选项）的分配确定值时，也应该留意PIECESIZE的值。
通过使用这个选项，可以促进并行性，从而提高NPI的扫描性能。另一个好处是可以减少在读或更新的处理过程中对I/O的争用。通过指定一个较小的PIECESIZE，可以创建更多的块，从而对块的放置有更多的控制。将这些块放在不同的I/O路径中，可以减少访问NPI所需的SQL操作的争用。
4. 理想的索引
通过检查应用程序中的SQL语句，可以建立一种想象起来很好的索引。
1) 首先，在索引中包括WHERE子句中的所有列，这样，就可以使用索引形成的屏蔽来拒绝结果集中不合格的行。将这些列放在索引的开始部分。这样一来，当对SQL语句进行EXPLAIN时，就可以产生最大的MATCHCOLS值。
2) 接下来，确保索引中这些列有适当的顺序（按照ORDER BY子句），这样可以避免排序。在进行EXPLAIN时，通过检查PLAN_TABLE中所有不同的SORT*列，便可以确认这一点。
3) 最后，如果可能的话，将SELECT中所有的列包括到索引当中，这样就不需要访问表中的行。这样的索引项可以提供所有被请求的数据。这在EXPLAIN中就表现为INDEXONLY = Y。
在很多情况下，实现这一理想的代价太高，也不切实际，甚至是不可能的。对于一个索引中可以包括的列数，以及整个索引项的长度，都有架构上的限制（虽然这些限制已考虑到相当大的索引项长度和灵活性）。而且，也要考虑索引维护的成本。虽然建立理想化的索引可以显著提高查询性能，但是每当对
DB2数据库执行SQL写操作（INSERT、UPDATE 或 DELETE）时，上述理想化的索引都会有负面的影响。因此，您常常可以选择实现只包括在WHERE和ORDER BY子句中引用到的列的索引。
六、并行处理方面的考虑 这些年，
DB2通过实现各种并行处理的方法，已经大大提高了访问数据的性能。为了提高数据密集型只读查询的性能，
DB2 V3引入了查询I/O并行。在这种并行中，
DB2充分利用分区表空间促成的可用I/O带宽。通过这种方法，
DB2可以为单个I/O请求启动多个并发的I/O请求，并在多个数据分区上执行并行I/O处理。这通常可以显著减少I/O bound查询所需的时间，而代价只是稍微增加的CPU时间。
DB2 V4引入了另一种并行技术，这种技术称作查询CP并行。这种方法将并行处理扩展到过程密集型（process-intensive）查询中来。通过这种方法，一条查询可以使
DB2生成多个任务，这些任务被并行地执行，以访问数据。分区表空间最能体现这种并行所带来的性能提高。
DB2 UDB V5引入了sysplex查询并行，进一步扩展了并行处理。CP并行可以在
DB2子系统中为一条查询使用多个任务，而sysplex查询并行这种方法使一个
DB2数据共享组中的所有成员可以一起处理一个查询。对于那些主要是只读形式的I/O密集型和处理器密集型查询，都可以从这种并行中得到好处。
1. 支持并行访问
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语句在一个计划或包中更改这个选项，该语句可以控制专用寄存器中的值。
当一个计划或包与DEGREE(ANY)捆绑在一起，或者CURRENT DEGREE寄存器被设为ANY时，
DB2优化器将考虑对于最有效的顺序计划，并行是否可行。如果并行不可行，那么就选择次好的顺序计划。
2. 限定分区扫描
限定分区扫描允许
DB2将数据扫描限制在一个分区表空间中。根据SQL谓词中的值，
DB2可以判断可能包含SQL语句所请求的表行的最低分区和最高分区，然后将数据扫描限制在这一范围内的分区中。为了使用这种技术，SQL必须提供分区索引的第一个键列上的一个谓词。
3. 并行方面的建议
为了进一步促进并行处理所能带来的性能提高，下面列出了一些需要考虑的事情：
1)尽可能均匀地对表空间分区，因为数据不整齐会对并行度产生影响。一般来说，
DB2根据最大物理分区的大小将表空间分成逻辑上的几块。
2) 为
DB2应用程序的处理分配尽可能多的中央处理器（central processor，CP），以及尽可能多的 I/O 设备和路径。
3) 对于I/O密集型查询，应确保分区的数量与可以访问该表空间的I/O路径的数量一致。
4) 对于处理器密集型查询，应确保分区的数量等于将被分配用来在数据共享组上处理查询的CP的数量。
5) 将用于表空间和索引的分区放在单独的DASD卷中，并且，如果可能的话，要隔开控制单元，以减少I/O争用。
6) 按时执行RUNSTATS实用程序，以获得分区级的统计信息。
7) 监控虚拟缓冲池的阈值和使用情况，确保提供了足够的缓冲池空间来最大化并行度。
七、缓冲池方面的考虑 1. 缓冲池的重要性
很多专家将数据库缓冲池看作
DB2环境中影响性能的最关键的资源。很多
DB2的架构和设计，其基本思想都是尽可能地避免物理I/O。
DB2缓冲池由数个插槽（slot）的连续的内存组成。数据和索引页被从DASD中读出之后，便进入这些插槽，并留在其中，直到
DB2缓冲区管理器确定那些插槽要用于其他数据。应用程序所请求的数据出现在内存中（而不是外面的DASD上）的概率越大，总体性能就越好。实际上，这里的数据被重复使用，因而减少了应用程序对I/O的需要。
是否释放一个缓冲池槽，这是根据最近被使用（LRU）原则来决定的。
DB2维护两个LRU列表，一个用于被随机访问的页，另一个用于被顺序访问的页。这样可以防止大规模的表扫描完全支配缓冲池，并恶劣地影响随机操作。通过使用不同的阈值，
DB2 提供了改善缓冲池性能的灵活性。在
DB2 SQL Reference手册的第2.7.4节中对这些阈值进行了较为详细的讨论。
2. 为缓冲池设置适当的大小
缓冲池大小的指定要取决于可用存储（包括中央存储和扩展存储）的容量。我建议首先分析缓冲池的分配，然后逐渐增加缓冲池的大小，直到通过增加分配的空间已无法增加更多的吞吐量，或者直到MVS换页率已难于接受为止。为实现这一点，要使DASD I/O的数量持续下降，并不断增加VPSIZE，直到换页的成本超出了通过减少I/O所带来的好处为止。
早些时候，GETPAGES的数量被认为可能是对
DB2正在运行的工作量的最好度量。缓冲池的目的是减少I/O（异步读通常表明需要进行预取，从性能角度来看，这样做通常是值得的。另一方面，同步读常常需要对DASD进行随机I/O，因为被请求的页不在缓冲池中）。会计报表显示对应于每个缓冲池的GETPAGES和同步读的数量。一个被普遍接受的ROT声称，如果GETPAGES对同步读的比率小于10:1，那么应该估计对更大缓冲池的需要。
3. 多缓冲池配置
如果操作系统允许为
DB2缓冲池分配相当大的内存，那么使用多缓冲池的配置很可能可以提高特定应用程序或数据库的性能。然而，需要清楚的是，若有了多个缓冲池，那么对这些缓冲池使用效率的监控就变得更加重要。
下面给出了关于分配多个缓冲池的一般建议：
1) 将表空间与和它们相关的索引分放到不同的缓冲池中，以减少索引I/O。
2) 将有不同数据访问模式的数据统一放到不同的缓冲池中。批处理和查询应用程序通常要进行大量的顺序处理，而用于OLTP的数据访问往往更具有随机性。这为利用各种阈值处理缓冲池中某些类型的数据访问提供了一种方法。
3) 为独立的应用程序提供一个单独的缓冲池。这就为紧密监控应用程序的性能问题或测试新的应用程序提供了一种方法。
4) 如果排序的性能在您的环境中很重要，那么需要为工作文件创建一个单独的缓冲池。
5) 对于相对较小但更新频繁的表，通过一个足够大的单独的缓冲池，也许可以同时减少读和写的I/O。
6) 为只读表（小的引用表）提供单独的缓冲池可以提高性能。
八、结束语 考虑周详的数据库设计可以提供巨大的性能收益，但是这必须在应用程序开发过程的早期便开始着手。从早期的
DB2开始，明智的开发人员就已经使用了前面提到的很多准则，这些准则直到现在也仍然成立。但是，
DB2功能的增强、其他领域中硬件和软件技术的变化将影响当前和将来的应用程序，知道这一点至关重要。当数据库性能成为开发过程中的焦点时，您的数据库设计使得为
DB2应用程序提供最佳性能有了更大的可能性。
