一个完整的日常维护规范可以帮助 DBA 理顺每天需要的操作，以便更好的监控和维护数据库，保证数据库的正常、安全、高效运行，防止一些错误重复发生。
由于DB2使用CBO作为数据库的优化器，数据库对象的状态信息对数据库使用合理的 ACCESS PLAN至关重要。DB2 优化器使用目录统计信息来确定任何给定查询的最佳访问方案。如果有关表或索引的统计信息已过时或者不完整，则会导致优化器选择不是最佳的方案，并且会降低 执行查询的速度。当数据库里某个表中的记录变化量很大时，需要在表上做REORG操作来优化数据库性能
一、完整的REORG表的过程
值得注意的是，针对数据库对象的大量操作，如反复地删除表，存储过程，会引起系统表中数据的频繁改变，在这种情况下，也要考虑对系统表进行REORG操作。一个完整的REORG表的过程应该是由下面的步骤组成的：
RUNSTATS ->?? REORGCHK ->?? REORG ->?? RUNSTATS -> BIND或REBIND
注： 执行下面命令前要先连接数据库
1 RUNSTATS
?? 由于在第二步中REORGCHK时可以对指定的表进行RUNSTATS操作(在REORGCHK时指定UPDATE STATISTICS)，所以第一步事实上是可以省略的。
2 REORGCHK
?? 在对表数据进行许多更改之后，逻辑上连续的数据可能会位于不连续的物理数据页上，在许多插入操作创建了溢出记录时尤其如此。按这种方式组织数据时，数据库管理器必须执行其他读操作才能访问顺序数据。另外，在删除大量行后，也需要执行其他的读操作。
表重组操作会整理数据碎片来减少浪费的空间，并对行进行重新排序以合并溢出记录，从而加快数据访问速度并最终提高查询性能。还可以指定根据特定索引来重新排序数据，以便查询时通过最少次数据读取操作就可以访问数据。
下列任何因素都可能指示用户应该重组表：
1）自上次重组表之后，对该表进行了大量的插入、更新和删除活动 。
2）对于使用具有高集群率的索引的查询，其性能发生了明显变化 。
3）在执行 RUNSTATS 命令以刷新统计信息后，性能没有得到改善。
4）REORGCHK 命令指示需要重组表（注意：在某些情况下，REORGCHK 总是建议重组表，即使在执行了重组后也是如此）。例如，如果使用 32KB 页大小，并且平均记录长度为 15 字节且每页最多包含 253 条记录，则每页具有 32700- (15 x 253)=28905 个未使用字节。这意味着大约 88% 的页面是可用空间。用户应分析 REORGCHK 的建议并针对执行重组所需的成本平衡利益。
5）db.tb_reorg_req（需要重组）运行状况指示器处于 ATTENTION 状态。此运行状况指示器的集合详细信息描述通过重组可获得好处的表和索引的列表。
REORGCHK 命令返回有关数据组织的统计信息，并且可以建议您是否需要重组特定表。然而，定期或在特定时间对目录统计信息表运行特定查询可以提供性能历史记录，该记录使用户可以发现可能具有更广性能隐含的趋势。
DB2 V9.1 引入了自动重组功能，可以对表和索引进行自动重组。自动重组通过使用 REORGCHK 公式来确定何时需要对表进行重组。它会定期评估已经更新了统计信息的表，以便了解是否需要重组。
REORGCHK命令的语法如下：
.?????????????????????????? -UPDATE STATISTICS--.
>>-REORGCHK--+--------------------+----------------------------->
???????????????????????? '-CURRENT STATISTICS-'
??????????? .-ON TABLE USER-----------------.
>--+-------------------------------+---------------------------><
??????????? '-ON--+-SCHEMA--schema-name---+-'
??????????????????? | .-USER-------. |??
??????????????????? '-TABLE--+-SYSTEM-----+-'??
?????????????????????? +-ALL--------+??
?????????????????????? '- table-name-'
下面我们来看一下各个选项的含义：
UPDATE STATISTICS：更新表的统计数据，根据该统计数据判断是否需要重组表。
CURRENT STATISTICS：根据当前表统计数据判断是否需要重组表。
TABLE table_name：对单个表进行分析。
TABLE ALL：对数据库所有的表进行分析。
TABLE SYSTEM：对系统表进行分析。
TABLE USER：对当前用户模式下的所有表进行分析。
如果数据库中数据量比较大，在生产系统上要考虑REORGCHK的执行时间可能较长，需安排在非交易时间执行。
可以分为对系统表和用户表两部分分别进行REORGCHK：
1) 针对系统表进行REORGCHK
db2 reorgchk update statistics on table system
使用UPDATE STATISTICS参数指定数据库首先执行RUNSTATS命令。
2) 针对用户表进行REORGCHK
db2 reorgchk update statistics on table user
REORGCHK是根据统计公式计算表是否需要重整。对于每个表有3个统计公式，对索引有3个统计公式(版本8开始有5个公式)，如果公式计算结果该表需重整，在输出的REORG字段中相应值为*，否则为-。
reorgchk 所使用的度量的考虑因素包括：（当查看 reorgchk 工具的输出时，找到用于表的 F1、F2 和 F3 这几列，以及用于索引的 F4、F5、F6、F7 和 F8 这几列。如果这些列中的任何一列有星号 (*)，则说明当前的表和/或索引超出了阈值。）
F1: 属于溢出记录的行所占的百分比。当这个百分比大于 5% 时，在输出的 F1 列中将有一个星号 (*)。
F2: 数据页中使用了的空间所占的百分比。当这个百分比小于 70% 时，在输出的 F2 列上将有一个星号 (*)。
F3: 其中含有包含某些记录的数据的页所占的百分比。当这个百分比小于 80% 时，在输出的 F3 列上将有一个星号 (*)。
F4: 群集率，即表中与索引具有相同顺序的行所占的百分比。当这个百分比小于 80% 时，那么在输出的F4 列上将有一个星号 (*)。
F5: 在每个索引页上用于索引键的空间所占的百分比。当这个百分比小于 50% 时，在输出的 F5 列上将有一个星号 (*)。
F6: 可以存储在每个索引级的键的数目。当这个数字小于 100 时，在输出的 F6 列上将有一个星号 (*)。
F7: 在一个页中被标记为 deleted 的记录 ID（键）所占的百分比。当这个百分比大于 20% 时，在输出的 F7 列上将有一个星号 (*)。
F8: 索引中空叶子页所占的百分比。当这个百分比大于 20% 时，在输出的 F8 列上将有一个星号 (*)。
下面是执行的部分结果
db2 reorgchk update statistics on table user
执行 RUNSTATS ....
表统计信息
