数据压缩
DB2提供了压缩表空间或分区内数据的功能。通过指定CREATE TABLESPACE（创建表空间）语句中的 COMPRESS YES（压缩许可）选项，之后在表空间上同时执行LOAD或REORG实用工具集，即可完成该功能。数据的压缩是通过用更短的串来替换频繁出现的字符串实现的。系统还创建了一个字典，包含了原始字节串和它们的替代串之间的映射信息。
一定数量的CPU资源被用于在执行数据存储对其进行压缩，之后，当外部存储设备读取时，数据又被解压缩。然而，数据压缩也能够提供性能方面的好处，因为更多的数据存储在更小的空间内（在DASD上和缓冲池中）；同未经压缩的数据相比，这样可以产生更少的同时读取、更小的I/O等。
接下来是当试图决定是否压缩一个表空间或分区时，需要考虑的一些事情：
行的长度：行越长（尤其是在接近页的尺寸时），压缩的有效性就越低。DB2的行不能够跨页，当一页上有多于一行的情况时，你也许不能获得足够的压缩。
表的尺寸：对于较大的表，压缩具有较好的效果。对于很小的表，压缩字典的大小（8KB到64KB）可能会抵消压缩节省下的所有空间。
数据中的模式：对于一个特定的表空间或分区，数据中重复出现的模式的频率，决定了压缩的效果。含有大量重复字符串的数据能够获得显著的压缩效果。
压缩估计：DB2提供了一个单独的实用工具集，DSN1COMP，它可以用来测定数据压缩将有怎样的效果。想获得有关运行该使用工具的额外信息，请参考DB2实用工具集指南和参考手册。
处理成本：在压缩和解压缩DB2数据时，会消耗一些CPU资源。如果你用IBM的同步数据压缩硬件特征，所消耗的CPU资源将比利用DB2软件仿真程序低得多（当DB2启动时，这决定了硬件压缩特征是否可用）。
更好的字典：当用LOAD使用工具集来建立压缩字典时，DB2用户用最初载入的n行（n取决于你能够压缩的数据量）来决定字典的内容。REORG采用取样技术来建立字典。它不仅使用最初载入的n行，还在实用工具执行UNLOAD（未载入）阶段的剩余时间里继续对数据行采样。
通常情况下，我们推荐你在自己的特定环境下，压缩那些DB2表空间和分区，这将会使你的环境受益；因为在更小的空间内存储更多的数据的性能优势，几乎总是在价值上超过压缩和解压缩数据所消耗的CPU资源。
载入大表
在处理大批量数据时，将数据初始载入表中可能会对系统性能产生挑战。为了在载入过程中实现并行性，你可以手动创建多个LOAD作业，每个分区建一个；或者作为另一个选择，你可以在一个LOAD程序中载入多个分区。每个分区都延伸至I/O子系统，这种方式可以更容易地实现最理想的并行性。
为了使性能最优化，在LOAD语句中指定SORTKEYS参数也很重要。这个参数指示DB2将索引方法传递给内存中的分类程序，而不是将关键字写入或者再次读取DASD上的排序任务文件。SORTKEYS也能够实现载入和分类之间的交迭，因为分类是作为一个独立的任务运行的。
还有一些关于载入大表的额外的建议，如下：
一次LOAD一个表。
如果可能的话，为你预期的任务赋予较高的优先级，来获得最高的消耗时间。
在系统综合体上分配工作。
将二级索引分解为小段，以便获得并行性（见PIECESIZE内的讨论）。
在数据的初始载入过程中，指定LOG NO（用于防止记录日志，它耗费了相当多的资源），在成功载入数据之后运行一个图像复制。
自由空间考虑事项
分配自由空间的主要目的，是为了将数据行保存在相同的物理序列中作为群集索引，这样一来将减少需要重新组织数据的频率。此外，较好的行聚簇将导致更快的读取访问和更快的行插入。但是，自由空间的过度分配又将导致DASD空间的浪费、每一个I/O传输的数据较少、缓冲池的利用效率较低，以及需要扫描更多的页。
表空间和索引中的自由空间分配，由CREATE或ALTER TABLESPACE和CREATE或ALTER INDEX 语句中的PCTFREE和FREEPAGE选项决定。
PCTFREE在载入或者重新组织数据时，为DB2指示表空间或索引中有多大的百分比是闲置的。在插入新的行和索引条目时，DB2将利用那些自由空间。如果没有足够的自由空间在正确的页（即以正确的聚簇序列）上写入行或者索引条目，那么DB2必须将多出来的数据放在另外的页上作为代替。在越来越多的记录放置在物理序列之外的情况下，系统性能将会受到严重影响。
FREEPAGE在载入或者重新组织数据时，为DB2指示一个整页成为自由空间的次数。例如，如果你将FREEPAGE确定为5，在每填满5页的数据之后，DB2将分配一整页的自由空间。如果你的表中的行大于半页，FREEPAGE将是很有用的，因为在这样的情况下，你不能在这一页中插入第二行。
是否在你的表空间内定义自由空间，分配的数量又是多少，这些都主要取决于表空间中表的插入特性（删除活动性居于次要程度）。换句话说，向表中插入行有多大的频率，并且这些行插入的位置是在哪里？根据上述标准，四种主要的类别如下：
只读表：如果在表上不会有任何修正，定义时就可以不分配自由空间。同样，也就不需要运行REORG实用工具集。
随机插入：对于含有相当大数量已有行和相对较少插入行的动作的表，使用默认的PCTFREE（表为5，索引为10）是一个好的起始点。之后，用RUANSTATS来监视数据组织破坏的程度，并且结合你要求的运行REORG的频率，根据需要上调或下调PCTFREE。对于插入活动很频繁的表，你可能需要使用比默认值较高的PCTFREE的值。对于初始为空或只含有极少数行的表（例如，在一个新数据库部署的过程中），你也许需要确定一个非常高的PCTFREE值，并相当频繁地运行REORG，直到表中的行数比较多了。
在表的末端插入：如果表中行的长度不增加，那么就没有必要分配自由空间，因为它们可以加在表的末端。而且既然它们是以物理聚簇序列的形式写入的，REORG也不需要了。但是如果表含有可修改的VARCHAR类型的列，或是如果表是压缩过的，那么行的长度有可能增加，这将使得一行被挤到另外一页上去。通过在表空间上执行RUNSTATS然后核查DB2目录表SYSIBM.SYSTABLEPART的NEARINDREF和FARINDREF列，你就能够确定这些。如果你的表变乱了，那么为表空间设定一个PCTFREE值，并且用RUNSTATS继续监视放错位置的行的数目。根据你观察到的数据和趋势，相应地调整你的REORG的频率和PCTFREE值。通过设定REORG TABLESPACE中的INDREFLIMIT和REPORTONLY选项，你就能够在更新后的DB2表中监视紊乱的数量和速度。
插入一个热点：这是表具有很频繁的插入活动的情况，这种插入活动集中在一个位置（或多个位置），而不是正好处于表的末端。这可能是要应付的最困难的种类。试着增加PCTFREE的数值。如果插入保持在开头的段，行也不是很长，几行可以存储在同一页之内。FREEPAGE是在这种情形下另外的一个考虑。有必要严密监视表变乱有多么快，这样就可以在性能显著下降之前运行REORG。
索引设计考虑事项
索引是一个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优化器考虑并行性是否是可能的，从而获得最有效的最终计划。如果并行性是不可能的，那么将会选择下一个允许并行性的最有效的最终计划。
限制分区扫描
限制分区扫描是允许DB2在分区表空间中限制数据扫描的一种方法。根据SQL谓词的值，DB2能够决定最低和最高的分区，这可能包含了被SQL语句所请求的表的行，之后便将数据扫描限制在分区的范围内。为了使用该技术，SQL必须提供一个在分区索引的第一个关键列上的谓词。
并行性建议
为了使并行处理的性能最优化，需要考虑以下事项：
尽可能均匀地对表空间进行分区，因为并行性程度会受到数据不均匀的影响。DB2通常在最大物理分区的基础上将表空间划分为逻辑片段。
为DB2的应用程序处理分配尽可能多的中央处理器（CP），以及尽可能多的I/O设备和通道。
对于I/O密集型查询，确保分区的数量与可以访问表空间的I/O通道数量相同。
对于处理密集型查询，确保分区的数量与用于跨共享数据群处理查询的CP数量相同。
将表空间和索引的分区放在单独的DASD卷上，并且（如果可能的话）独立控制这些单元以便使I/O冲突最小化。
在规则的基础上执行RUNSTATS实用工具集，以便获得分区级别的统计表。
监视虚拟缓冲池的阈值和使用情况，确信你提供了足够的缓冲池空间来使调用的并行性程度最大化。
缓冲池的考虑事项
缓冲池的重要性
大多数专家认为在DB2环境下，数据库缓冲池是影响性能的最关键的因素。很多DB2的体系结构和设计是基于尽可能多的或实际上避免物理I/O这一概念。
DB2缓冲池由临近存储器的插槽组成。从DASD读入之后，数据和索引页进入这些插槽并且呆在其中，直到DB2缓冲管理器决定这些插槽需要被其他数据占用。被应用程序请求的数据通常存储在存储器内，而不是在外部的DASD，这种情形越经常出现，整体的性能就越好。本质上，数据是被重新利用了，从而使得应用程序需要的I/O数量最小化。
释放缓冲池插槽的决定基于最近最少使用（LRU）法则。DB2维护着两个LRU列表，一个是关于随机访问页的，另一个是关于顺序访问页的。这便阻止了完全占用缓冲池的大表扫描，以及对随机操作的负面影响。通过各种阈值的使用，DB2为你提供了改进缓冲池性能的额外灵活性。关于这些阈值的进一步详细讨论见DB2 SQL参考手册的2.7.4部分。
缓冲池的合适大小
缓冲池尺寸的指定取决于可用的存储量（包括中央部分和扩展部分）。我建议你分析一下缓冲池分配，并且增加它的尺寸直到再也没有由于增加的分配而产生的额外吞吐量，或是MVS分页速率到达不可接受的程度。这将通过逐渐增加的VPSIZE来实现，只要DASD I/Os的数目保持减少，在分页的成本超过减少I/O的收益之前，VPSIZE将持续增加。
在早期，GETPAGES的数量可能是DB2工作量的最好衡量标准。缓冲池的用途是为了使I/O最小化（异步读取通常意味着一次做一个，这是基于性能立场上的一般要求。另一方面，同步读取通常意味着从DASD的随机I/O，因为所请求的页在缓冲池内找不到）。统计报告显示le 每一个缓冲池中的GETPAGES和同步读取的数量。一个被普遍接受的ROT说，如果同步读取的GETPAGES比率小于10:1，那么你应该考虑配置更大缓冲池了。
多缓冲池配置
如果你的操作环境允许为DB2缓存配置容量相当大的存储器，那么多缓冲池配置可以最大限度地为特定的应用程序或数据库提供改善的性能。然而，请注意由于采用多个缓冲池，监视它们的工作效率变得更加重要。
普遍来讲，对配置多缓冲池有如下建议：
将表空间和它们相联系的索引分离到不同的池，以便使索引I/O最小化。
将具有不同数据访问模式的数据分别置于不同的缓冲池中。典型地，批处理和查询应用程序含有大量的连续处理，而OLTP的数据访问在本质上往往比较随机。这就提供了一种方法，来开发不同的阈值以在一个缓冲池适应各种特定类型的数据访问。
为了隔离应用程序，提供一个单独的缓冲池。这就提供了一种方法，来严密监视一个存在运行问题的应用程序，或是测试新的应用程序。
如果分类性能在你的环境下很重要，那么就为共作文件创建一个独立的缓冲池。
对于相对比较小但是更新很快的表，足够大的独立缓冲池可以同时消除读取和书写I/Os。
为只读表（小的、参考表）设立单独的缓冲池也可以提高性能。
总结
经过深思熟虑的数据库设计可以提供重大的性能优势，但是它必须在应用程序的开发过程中尽早开始。上述很多原则，在DB2的早期就已经被明智的开发人员所利用，并且至今仍保持着它们的正确性。然而清楚DB2功能上的进步，以及影响你当前和以后应用程序的其他领域内的硬件和软件技术的变化，同样也是至关紧要的。当数据库性能成为发展过程的一个重要焦点时，你的数据库设计，将使你更有可能为你的DB2应用程序提供最优化的性能。