数据架构师：DB2 数据仓库性能，第 1 部分：把 OLTP 调优技能转换为对基于 DB2 的业务智能化系统的有效性能管理

核心提示： 编目统计信息是否丰富也很重要（DB2 对数据库中的数据了解越全面，查询的性能就可能越好），数据架构师：DB2 数据仓库性能，第 1 部分：把 OLTP 调优技能转换为对基于 DB2 的业务智能化系统的有效性能管理(5)，所以应该收集您能够收集的所有信息：关于索引和表的统计信息，尽可能多的列的基数

编目统计信息是否丰富也很重要（DB2 对数据库中的数据了解越全面，查询的性能就可能越好），所以应该收集您能够收集的所有信息：关于索引和表的统计信息，尽可能多的列的基数和分布信息。请记住，RUNSTATS 收集的信息越多，它消耗的 CPU 时间就越多；因此，如果处理能力不足，可能需要把列统计信息生成限制在查询谓词中使用（或很可能使用）的列。

利用索引。对于支持 OLTP 应用程序的数据库，人们在为表创建索引方面往往非常保守，这有一个很合理的原因：在表上定义的每个索引都会增加每个 INSERT 和 DELETE 操作的成本（如果更新的列是索引键的组成部分，UPDATE 操作的成本也会增加）。

在 BI 环境中，数据获取（而不是数据更改）操作的性能往往更重要；因此，与 OLTP 数据库相比，在数据仓库数据库中创建更多索引通常是有意义的。但是，也不要为数据仓库表创建过多的索引，否则定期的 ETL 数据更新过程可能无法及时完成（这会导致数据仓库向查询 “开放” 的时间推迟，有时候会让用户不满）。

在 OLTP 环境中，我一般会把每个表的平均索引数量限制在四或五个。对于 BI 系统中的数据库，我觉得每个表八到十个索引更合适，但是我不会一开始就创建这么多索引。相反，我会先为每个表创建五或六个索引，如果以后发现需要减少某些查询的运行时间，那么可以定义更多索引。

明智地使用聚簇。数据聚簇（表行的物理次序）在数据仓库中是个重要的问题，因为常常会大批地获取行（而不是像典型的 OLTP 系统那样获取小结果集）。在连续获取大量行时，引用的局部化（所需的行在目标表中的物理位置相互接近）会对运行时间产生显著的影响。应该尽可能精确地预测用户希望查询的东西 —— 具有给定的客户 ID 的所有行？关于给定的产品的所有行？某一日期范围内的所有行？

如果两个或更多聚簇键对于某个表都是有意义的，那么可以考虑使用 DB2 9 for LUW 的多维聚簇 (MDC) 特性。大型机 DB2 管理员可以使用 DB2 for z/OS V8 中提供的表分区改进来实现多维聚簇，具体地说，按一个键进行数据分区，然后按另一个键对分区中的行进行聚簇。

接下来要考虑查询

现在，已经设置了 DB2 系统和数据库，为良好的数据仓库性能奠定了基础。然后，用户要执行他们的查询和报告请求，他们很可能会发现一部分查询的运行时间比期望的要长。现在怎么办呢？现在，要分析这些查询，找到让它们运行得更快的方法。我将在下一期中分享一些有用的经验。