自由空间考虑事项

    分配自由空间的主要目的，是为了将数据行保存在相同的物理序列中作为群集索引，这样一来将减少需要重新组织数据的频率。此外，较好的行聚簇将导致更快的读取访问和更快的行插入。但是，自由空间的过度分配又将导致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操作的冲突。