简介

您是否需要详细分析关键的性能因素，以便控制和调优 DB2 和 DB2 应用程序的性能？您是否需要前瞻性地诊断性能和可用性问题？您是否遇到过 DB2 服务器的操作问题，但又无法使用现有快照确定问题的原因，并希望拥有历史监控数据？

IBM DB2 Performance Expert 是一个能够通过提供在线监控、异常处理以及短期和长期历史监控功能来帮助完成上述所有任务的工具。本系列的 第 1 部分 介绍了 DB2 PE 并举例说明了其组件。第 2 部分 对该产品进行了深入介绍，并演示了各种实际使用场景，例如：

• 确定索引是否会提高性能
• 审查排序性能
• 检查重新组织表的必要性
• 确保具有足够的 DB2 代理来处理工作负载
• 解决锁冲突问题
• 检查来自包缓存的常用 SQL 语句
• 分析缓冲池
• 监控系统运行状况

第 3 部分比较详细地阐述了 Performance Warehouse（PWH），它是 DB2 PE 的组件，用于保存较长一段时间的历史监控数据（长期历史），并提供了数据分析工具，这些数据包括报告、查询和经验法则。在 PWH 中分析数据有助于识别潜在的性能问题或趋势，以及确定改变 DB2 配置值的效果。存储在 PWH 中的数据由 DB2 快照数据、DB2 事件监控数据和 DB2 配置数据组成。

回页首

Performance Warehouse

在监控任何系统的性能时，都应跨较长的几个时间段查看性能数据，这样才能真实了解系统问题。短期监控对于诊断某一即时问题（例如响应时间变长）比较有用，但不对系统变更的长期效果提供洞察，也不能帮助制定未来的容量计划。通过捕获短期性能快照和配置数据，并将其保存到一个长期 Performance Warehouse，DB2 PE 可以满足这种需要。此外，如果必要，DB2 语句事件监视器所捕获的数据也可以保存到 PWH 中。尽管 DB2 PE 的历史数据只保留较短的时间（几小时或几天），但是一旦数据被保存在 PWH 中，这些数据便可在很长的时间内用于报告和趋势分析。

以下是可以通过分析 PWH 中的数据来回答的一些问题：

• 哪些 SQL 语句消耗的 CPU、排序和执行时间最多？
• 执行频率最高的 SQL 语句有哪些？
• 异步读取比率和缓冲池命中率在高峰或正常时间是否总是超过警告和问题阈值？
• 数据库管理器或数据库配置中的变更是否是产生瓶颈（比如排序溢出）的原因？
• 编目缓存和包缓存的大小是否适合于在高峰和正常时间处理工作负载？
• 在使用当前这组索引的情况下，SQL 语句的运行是否正常？

图 1 介绍了 Performance Warehouse 的组件。PWH 由一组控件和驻留在性能数据库中的数据表组成，并且对于通过 DB2 PE 来监控的每一个 DB2 实例都是可用的。数据表中包含了下列活动的实际的长期性能数据：

• 缓冲池活动，包括基于 DB2 快照数据的表空间和表信息
• 基于 DB2 快照数据的数据库活动
• 数据库和数据库管理器配置
• 基于 DB2 语句事件监视器的 SQL 活动

控制表用于保存用于收集、加载和分析数据的定义。

PWH 中包含了一个工作流引擎，它由用于收集和加载数据并用所加载的数据创建报告的过程组成。通过按照您所希望收集和接收报告的时间来安排这些过程，可以自动化这些过程的执行。例如，您可能想在每周一早上获得上一周数据库活动的报告。

此外，PWH 还起着数据仓库的作用。提取、转换和加载（ETL）过程用于将数据收集和加载到 PWH 表中：

• 提取：从短期历史表读取快照和配置数据。从语句事件监视器所写的文件读取 SQL 活动数据。
• 转换：在一段时间内汇总快照数据。将 SQL 活动数据转换成一种关系格式。
• 加载：将快照、配置和 SQL 活动数据插入 PWH 数据表。

报告等分析工具、预定义和用户定义的查询以及经验法则有助于深入分析数据。

回页首

将数据导入 Performance Warehouse

性能数据导入 PWH 的方式有两种：

• 短期历史快照和配置数据的 ETL
• SQL 活动跟踪事件监视器数据的 ETL

短期历史快照和配置数据的 ETL

为了收集短期历史数据，DB2 PE 以用户指定的时间间隔（即记录时间间隔）制作系统活动的定期快照。在默认情况下，该时间间隔设置为 5 分钟，用于收集数据库、缓冲池、表空间、表或配置数据的统计数据，但该值也可以调整为其他值。历史数据存储在性能数据库中，并在以历史模式在任意的在线监视器屏幕上显示数据时使用这些数据。DB2 PE 在历史表中保存历史数据的默认时间为 50 小时；50 小时过后，这些数据便被自动删除。该时间范围可以修改。

捕获的短期历史数据以用户配置的时间间隔，通过 ETL 过程迁移到 PWH 表中。在转换步骤中将汇总这些数据，也就是说将在若干个时间间隔内收集的短期历史数据汇总为一个时间间隔，以减少 PWH 中包含的数据量。最小的汇总时间间隔为 15 分钟。

例如，如果指定每 5 分钟收集一次统计计数器上的短期历史数据，然后在这些历史数据迁移到 PWH 中时将其汇总到 15 分钟组中，那么每一行 PWH 数据将有 3 行短期历史数据。

PWH 汇总方法

收集到的 DB2 快照数据由以下 3 类监视器元素组成：

• 水位标志 监视器元素指示在监视启动后某元素曾达到的最高（最大）或最低（最小）值。
• 测量 监视器元素指示某项的当前值。测量值可能上升和下降。
• 计数器 显示到取样时为止所累积的信息。计数器计算增加的值，比如死锁数。一旦终止或重新启动实例或数据库，计数器便会复位。

在 DB2 PE 将历史数据汇总到 PWH 中时，它会对各监视器元素类型进行不同的处理。

• 对于水位标志，使用最高（最大）或最低（最小）值。
• 对于测量值，计算平均值，因为它们可能随数据库活动的变化而增大或减小。
• 对于计数器值，计算汇总时间间隔上的增量值。

例如，以 5 分钟的时间间隔收集短期历史数据，并以 15 分钟的时间间隔进行汇总，则会看到以下结果：

• 对于水位标志，直到最后 15 分钟时间间隔期间所达到的最高或最低值。
• 对于测量，会在 15 分钟时间间隔内的七八行历史数据上求平均值。
• 对于计数器，为 3 行历史数据中最后一行和第一行值的差。

配置数据（数据库管理器配置和数据库配置数据）汇总到 PWH 与其他元素略有不同，因为这些数据不是水位标志、测量或计数器类型。这些数据是信息元素，并且只要某一值从一个时间间隔变为下一个时间间隔，它们就会迁移到 PHW 中。若配置参数很少变更，那么在相应的 PWH 表中将只有不多的几行。

包含快照和配置数据的 PWH 数据表

汇总后，数据被加载到下列数据表中：

• PWH.BUFFERPOOL 针对缓冲池快照数据
• PWH.TABLESPACE 针对表空间快照数据
• PWH.TABLE 针对表快照数据
• PWH.DATABASE 针对数据库快照数据
• PWH.DBMCFG 针对数据库管理器配置数据
• PWH.DBCFG 针对数据库配置数据

SQL 活动跟踪事件监视数据的 ETL

存储在 Performance Warehouse 中的其他类型的数据是指那些由可以从 DB2 PE 内部运行的语句事件监视器所收集的数据。可以从 Application Summary 面板运行 SQL 活动跟踪，这样将只跟踪一个特定的应用程序，也可以将 SQL 活动跟踪 作为 PWH 中的一个过程来运行，这样可以跟踪一个数据库的所有应用程序或筛选出来的某些应用程序。SQL 活动跟踪 可以预先排定，也可以随需运行。当运行 SQL 活动跟踪 时，DB2 PE 将创建一个语句事件监视器，令其依用户所设置的时间运行，然后终止并将事件跟踪数据从平面文件加载到 PWH 表中。根据请求类型，它也可以生成报告。

包含 SQL 活动跟踪数据的 PWH 数据表

SQL 活动跟踪数据加载到下列数据表中：

• PWH.EVM_HEADER 针对事件监视器、数据库和实例信息
• PWH.EVM_CONNECTION_HEADER 针对各应用程序的连接信息
• PWH.EVM_STMT_IDENTIFIER 针对语句信息，如包、 创建者或游标
• PWH.EVM_STMT_TEXTS 针对语句文本数据
• PWH.EVM_STMT_SUMMARY 针对摘要信息，如准备、警告、错误或执行
• PWH.EVM_STMT_OPERATIONS 针对语句操作

回页首

使用 Performance Warehouse 过程和创建报告

过程用于收集报告数据（CRD）、将这些数据加载到 PWH 表中和创建报告。过程最多由三步（CRD、加载、报告）组成。在执行过程时并非所有步骤都有必要执行。例如，若想创建数据库活动报告，并且因为数据已经从短期历史表迁移到 PWH 表中，所以只执行报告步骤。

过程被组织在过程组中。现有的过程组 Public 中包含了过程模板，用户可以随需或按计划将其复制到自己的过程组中，并进行配置和执行。图 2 所示为 Performance Warehouse 过程屏幕。在该树中可以看到 Public 组中的过程模板列表和 pedemo 组中所复制的过程列表。SQL 活动摘要报告 过程由三步（CRD、加载、报告）组成，各步可以单独配置。

对于创建缓冲池和数据库活动报告的过程来说，只有报告步骤可用。若要配置报告步骤，请指定下列参数：

• 数据库名
• 过滤条件，如缓冲池名、表空间名、表名
• 报告时间间隔
• 对于 DPF 环境：分区编号或 global，这意味着数据在所有分区上进行汇总。

对于创建 SQL 活动报告的过程来说，这三个步骤都是可用的。若要配置这些步骤，请指定下列参数：

• 数据库名
• 过滤条件，如应用程序标识、应用程序名称或授权标识
• 事件监视器运行耗费的时间
• 事件监视器文件的最大文件长度
• 对于 DPF 环境：分区编号

以下几节内容详细描述了这些报告：

• 数据库活动报告
• 缓冲池活动报告
• SQL 活动报告

数据库活动报告

数据库活动报告中包含了 DB2 数据库快照 API 所提供的监视器元素，但它们是随着时间的推移逐渐收集并汇总的，因此可以查看系统整体的长期行为。这些类型的报告对于趋势分析和未来的容量计划非常重要。

数据库活动报告对于在测试环境中记录新的或变更的应用程序很有用。例如，可以在一系列测试周期内收集性能数据，保存每一周期的数据，并在以后对这些数据进行比较。可以将测试结果与后来的生产结果进行对比，通过这种方式来验证所作的预测并针对将来作出改进。若在所使用的严格测试过程中可以在每一测试开始前将环境重置回“零状态”，则 PWH 数据在验证某一测试的重复结果中可能非常有价值。

数据库活动报告由报告块 组成，每一块报告一组不同的监视器元素。数据库活动报告有 19 个报告块：

• Configuration
• Overview
• SQL statistics
• Row statistics
• Sorts
• Hash joins
• Internal DB Statistics / Counts - Logging
• Internal DB Statistics / Counts - Locking
• Internal DB Statistics / Counts - Catalog Cache
• Internal DB Statistics / Counts - Package Cache
• Internal DB Statistics / Counts - Shared Workspace
• Internal DB Statistics / Counts - Private Workspace
• Bufferpools / IO Statistics - Non-bufferred I/O Activity
• Bufferpools / IO Statistics - Data section
• Bufferpools / IO Statistics - Index section
• Bufferpools / IO Statistics - Times
• Bufferpools / IO Statistics - Extended Storage Section
• Bufferpools / IO Statistics - Page Cleaner Section
• Applications

图 3 所示为某示例数据库活动报告的 Overview 和 SQL statisics 报告块。

缓冲池活动报告

缓冲池报告的布局和格式类似于上节所述的数据库活动报告，每一部分信息都存放在报告块中，其中包含了特定元素组的汇总快照数据。缓冲池报告块有：

• Buffer pool
• Tables pace
• Table

SQL 活动报告

SQL 活动报告包含 DB2 语句事件监视器所捕获的关于运行在数据库上的应用程序的信息。SQL 活动跟踪报告 以应用程序执行 SQL 活动的顺序列出 SQL 活动。SQL 活动摘要报告 包含每个应用程序的每个语句的摘要信息：

• Total number of executions
• Total execution time
• Total sort time
• Number of warnings and errors
• Total number of rows read from table
• Total number of rows changed in table
• Total preparation time
• 等等

该摘要信息使用户能够确定应用程序中的关键 SQL 语句。

若应用程序执行静态 SQL 语句，则 SQL 活动报告同样显示它们，以及摘要或操作信息。

图 4 所示为某示例 SQL 活动摘要报告 的一部分。第一个表列出了每条语句的摘要信息。利用报告中的超链接，可以钻取每条语句的细节，包括每条执行语句的语句文本和操作信息。

回页首

使用 Performance Warehouse 查询

查询用于分析 PWH 中数据的不同方面。这些查询是标准的 SQL select 语句，它们基于 PWH 表执行。可以使用预定义的查询或使用标准的 SQL 自己创建查询。DB2 PE 在查询生成器中提供了一个列辅助特性，因此用户可以从一个列表中选择表和列。若用户并不是对所有的 PWH 表都非常熟悉，则该特性便会派上用场，但这并不是说必须使用该特性。如果使用 SQL 比较顺手，则可手工编写查询。PWH 查询的一个非常精妙的特性是将变量插入查询的能力，用户可以在运行时对变量进行替代。

与过程类似，查询是在查询组中组织的。现有查询组 Public 包含所有预定义的查询。可以直接从该 Public 组执行查询，但若想在执行前更改某一查询，则必须将该查询复制到自己的查询组中，然后再更改和执行它。用户自己的查询也是在自己的查询组中定义的。

图 5 给出了预定义的查询列表。预定义的查询分为三个不同的组：

• 问题查询：这些查询只返回超过重要性能计数器阈值的行，例如缓冲池命中率不到 90% 的行。名称以 DB2 PM.Buffer pool、DB2 PM.DATABASE、DB2 PM.TABLE space 打头的预定义查询属于这一组。
• 报告查询：这些查询返回包含在 PWH 表中的不同方面的数据。可以使用这些查询定义自己的报告。名称以 DB2 PM.Report 打头的预定义查询属于这一组。
• 高命中率查询：这些查询对已经存储了 DB2 语句事件监视器所收集的数据的 PWH 表进行操作。它们返回高命中率 SQL 语句，例如耗用排序时间最多的语句。名称以 DB2 PM.SQL Activity 打头的预定义查询属于这一组。

图 6 给出了所执行的预定义问题查询的示例查询结果。该查询只返回命中率低于 90% 的缓冲池。此外，它还返回命中率低时的时间间隔。可以在浏览器中打开该查询结果，也可以将它们保存起来供以后分析使用。

下面几节将介绍可能比较有用的一些查询。它们不属于预定义查询。它们举例说明了可以从 PWH 表获得的不同类型的信息。

• 说明哪些表空间使用哪些缓冲池
• 随时间的推移将数据库配置值与监视器元素关联起来
• 识别日志使用趋势
• 比较 AVG_APPLS 和缓冲池命中率

说明哪些表空间使用哪些缓冲池

下面的查询 清单 1 说明了哪些表空间使用哪些缓冲池。可以从课程的系统编目中得到该清单，但若用在这两个表（例如缓冲池命中率）中同样可用的快照数据扩展该查询，则可全面了解表空间和缓冲池中的活动。结果可能会将某一表空间分配给不同的缓冲池。

SELECT DISTINCT
T1.DB_NAME
, T1.BP_NAME
, T2.TABLESPACE_NAME
FROM PWH.BUFFERPOOL T1
, PWH.TABLESPACE T2
WHERE T1.BUFFERPOOL_ID = T2.TABLESPACE_CUR_POOL_ID
AND T1.DB_NAME = T2.DB_NAME
AND T1.MEMBER_ID = T2.MEMBER_ID
AND T1.INTERVAL_TO = T2.INTERVAL_TO
AND T1.INTERVAL_FROM = T2.INTERVAL_FROM

随时间的推移将 DB CFG 值与监视器元素关联起来

下面的查询 清单 2 说明如何将特定的监视器元素（在本例中为与排序相关的元素）与相应的数据库或数据库管理器配置值（在本例中为 SORTHEAP ）关联在一起。该方法对于评估趋势和了解更改某一配置值后的结果非常有价值。请注意，PWH 存储 DB 和 DBM CFG 值，但某值发生变化时只插入一行。这些表都将配置值作为表中的一列。PWH.DBCFG 和 PWH.DBMCFG 表中的 INTERVAL_TO 列中包含的时间与其他 PWH 表中的 INTERVAL_TO 列包含的时间不同。这就是我们在下面的例子中使用附加谓词的原因。在比较配置值与统计值的查询中始终都应包含该谓词。

SELECT
T1.INTERVAL_FROM AS DB_INTERVAL_FROM
, T1.INTERVAL_TO as DB_INTERVAL_TO
, T2.INTERVAL_TO as DBCFG_INTERVAL_TO
, T1.DB_NAME
, T1.TOTAL_SORT_TIME
, T1.SORT_OVERFLOWS
, T1.ACTIVE_SORTS
, T2.SORTHEAP as DBCFG_SORTHEAP
FROM PWH.DBASE T1
LEFT OUTER JOIN PWH.DBCFG T2
ON
T2.INTERVAL_TO < T1.INTERVAL_TO and T2.INTERVAL_TO >= T1.INTERVAL_FROM
AND T1.DB_NAME = T2.DB_NAME
AND T1.MEMBER_ID = T2.MEMBER_ID
WHERE
T2.DB_NAME = ':db_name'
AND DATE(T1.INTERVAL_TO) BETWEEN ':from_date' AND ':to_date'
ORDER BY T1.DB_NAME

识别日志使用趋势

下面 清单 3 中的查询将报告一些日志和日志空间使用监视器元素，以及当前正在执行的应用程序数，它允许用户输入一个数据范围。用户也许能够跟踪日志的增长过程，或者在二次日志分配中寻找增长，这可能指示数据库中一些即将出现的空间问题。对于任何查询，若发现有什么异常，可以随时运行附加报告或查询，以深入了解更多信息。

SELECT
INTERVAL_TO
, DB_NAME
, TOTAL_LOG_USED
, TOTAL_LOG_AVAILABLE
, TOT_LOG_USED_TOP
, SEC_LOGS_ALLOCATED
, SEC_LOG_USED_TOP
, APPLS_IN_DB2 FROM PWH.DBASE
WHERE DB_NAME = ':db_name'
AND DATE(INTERVAL_TO) BETWEEN ':from_date' AND ':to_date'

比较 AVG_APPLS 和缓冲池命中率

下面的查询 清单 4 将显示 AVG_APPLS 配置参数、当前连接到数据库的应用程序数和该数据库的缓冲池命中率之间的相关性。若使用多个缓冲池，可能要从 PWH.BUFFERPOOL 表取得缓冲池命中率和缓冲池名称。SQL 优化器使用 AVG_APPLS 参数来帮助估算这些缓冲池中有多大比例可能会在运行时可供所选择的存取方案使用。该参数值较高可能会影响优化器在缓冲池使用中对比较保守的存取方案的选择。APPLS_CUR_CONS 值可以帮助调整 AVG_APPLS 配置参数。POOL_HIT_RATIO 值显示更改缓冲池命中率的 AVG_APPLS 后的效果。若 AVG_APPLS 参数调整得好，但缓冲池命中率降低，可以考虑调整缓冲池，比如增大缓冲池。

SELECT
T1.INTERVAL_FROM AS DB_INTERVAL_FROM
, T1.INTERVAL_TO as DB_INTERVAL_TO
, T2.INTERVAL_TO as DBCFG_INTERVAL_TO
, T1.DB_NAME
, T1.POOL_HIT_RATIO
, T1.APPLS_CUR_CONS 
, T2.AVG_APPLS AS DBCFG_AVG_APPLS
FROM PWH.DBASE T1
LEFT OUTER JOIN PWH.DBCFG T2
ON T2.INTERVAL_TO < T1.INTERVAL_TO and T2.INTERVAL_TO >= T1.INTERVAL_FROM
AND T1.DB_NAME = T2.DB_NAME
AND T1.MEMBER_ID = T2.MEMBER_ID
WHERE T2.DB_NAME = ':DB_NAME'
AND DATE(T1.INTERVAL_TO) BETWEEN ':from_date' AND ':to_date'
ORDER BY T1.DB_NAME

回页首

使用 Performance Warehouse 经验法则分析

经验法则（ROT）功能提供一种非常有效的方式来分析长期数据以及向用户提供系统调优方法建议。一旦长期数据存入 PWH 表，就可以使用预定义的 ROT 或定义自己的 ROT 来分析 PWH 中的数据。

一条 ROT 由一个比例或百分比、警告和问题阈值的计算公式以及一条在超过警告或问题阈值时应采取的措施建议组成。ROT 功能组织在集群中。预定义的 ROT 功能组织在缓冲池、数据库、表空间和 SQL 活动集群中。ROT 分析可以通过使用整个集群（这意味着在该集群中定义的所有 ROT 都将用于分析 PWH 中的数据 ）或使用某一集群中的一个 ROT 来启动。

下面的列表给出了预定义的集群中所提供的预定义 ROT 功能。

• 缓冲池
  • 命中率（数据和/或索引）
  • 异步读取比率/写比率
• 数据库
  • 目录/包缓存命中率
  • 所读行与所选行
  • 排序溢出
  • 关闭的文件
• 表空间
  • 异步读取比率/写比率
• SQL 活动
  • 最多的 CPU 时间
  • 最多的执行时间
  • 最多的排序时间
  • 最频繁使用的语句

与过程和查询类似，ROT 集群组织在 ROT 组中。现有 ROT 组 Public 包含了所有的预定义 ROT 集群。可以直接从 Public 组执行某一集群中的 ROT，但若要在执行之前更改 ROT，则必须先将该 ROT 复制到自己的 ROT 组中，然后再更改和执行它。自己的 ROT 也是在自己的 ROT 组中定义的。

图 7 所示为启动 PWH 数据的 ROT 分析后所显示的示例 ROT 结果矩阵。本例使用了缓冲池集群。对于 PWH.BUFFERPOOL 表中的每一条记录，结果矩阵都指示计算的比例是否出现警告或问题。

从该结果矩阵可以钻取行列细节。图 8 所示为选择的时间戳的行细节。若选择一个 ROT Name（下图突出显示的部分），则可以在经验法则细节 中看到该值的计算过程、其实际值和系统更改建议。

回页首

结束语

Performance Warehouse 保存的历史监控数据由较长时间的（长期历史） DB2 快照数据、DB2 事件监控数据和配置数据组成。它提供了用于分析报告、查询和经验法则等数据的功能。分析 PWH 中的数据有助于识别潜在的性能问题或趋势，或确定更改某一 DB2 配置值后的结果。总之，PWH 中的长期数据及其分析功能对于前瞻性地改进 DB2 UDB 系统的未来行为和性能是非常重要的。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• DB2 Performance Expert Homepage 介绍了 DB2 Performance Expert V2.1。
  
  
• DB2 Performance Expert for Multiplatforms V2（IBM 红皮书，2005 年 1 月）提供了 DB2 Performance Expert tool for Multiplatforms 的使用指导原则。
  
  

关于作者

Ute Baumbach 是 IBM 德国实验室的一名软件开发人员，也是 DB2 Performance Expert 开发团队的一员。此外，Ute 还负责提供客户支持，帮助客户设置和使用 DB2 Performance Expert，以充分发挥该产品的优势。她是一名 IBM 认证的数据库管理员，也是一名经过认证的 DB2 UDB 应用程序开发人员。

为本文评分

评论

回页首

内容

• 简介
• Performance Warehouse
• 将数据导入 Performance Warehouse
• 使用 Performance Warehouse 过程和创建报告
• 使用 Performance Warehouse 查询
• 使用 Performance Warehouse 经验法则分析
• 结束语
• 参考资料
• 关于作者
• 建议