使用 db2mon 收集和报告性能监视器数据
db2mon 是一组 Db2® 命令行处理器 (CLP) 脚本，这些脚本使用 Db2 轻量级内存中监视接口 来收集特定时间段的监视数据。
db2mon.sh shell 脚本提供数据收集和分析的采样。 此脚本还会检查是否满足 db2mon 的先决条件。
轻量级内存中监视接口是指以“MON_GET”开头的内置例程，例如，“MON_GET_DATABASE”。 该主题的其余部分将这些例程统称为 MON_GET 函数或作为 MON_GET 数据返回的数据。
MON_GET 函数返回从数据库激活时开始起的数据增量。 通过收集不同时间的测量结果并计算差异来确定数据库活动。 db2mon 脚本收集信息并处理通过使用存储过程自动完成的计算。
准备工作
db2mon CLP 脚本需要与数据库的连接。 db2mon.sql 还要求数据库具有用户临时表空间。 许多系统已有用户临时表空间。 如果数据库没有用户临时表空间，那么可以使用
CREATE TABLESPACE 语句创建一个：
DB2 CREATE USER TEMPORARY TABLESPACE myTempTbsp要使 db2mon.sql 和 db2mon_export.sql 正确收集监视数据，必须使用下列数据库配置参数在数据库级别启用监视：
- MON_ACT_METRICS 必须至少设置为 BASE（缺省值）。
- MON_REQ_METRICS 必须至少设置为 BASE。 其缺省值为 EXTENDED，它提供有关表和索引的完整监视器信息，并且是 db2mon 的理想设置。
如果您正在以脱机方式运行 db2mon ，那么您必须具有创建永久表和索引的权限。
关于本任务
您可以选择两种方式来使用 db2mon 收集和分析性能监视器数据：
- 联机
- db2mon 最常以联机方式运行，在此方式下，它会运行至完成，并在其监视的系统上生成有关标准输出的报告。 该报告包含用于在指标中查找变化值和列示输出的所有
SQL。 db2mon.sh 自动连接到数据库，创建用户临时表空间和小型专用缓冲池（用于尽量减少对系统的影响），运行 db2mon.sql，然后断开连接。 您可以通过两种方式来运行联机方式：
- 通过使用 db2mon.sh
- 通过使用现有连接
- 脱机
- 已为导出、导入和报告生成提供了单独的 SQL 文件。 如果受监视系统对性能敏感，您可使用导出脚本来收集性能数据，并将其传输到另一个系统以进行导入和报告。
在脱机方式下生成的报告（通过运行 db2mon_report.sql）比联机方式（通过运行 db2mon.sql）生成的报告短。 脱机方式报告较短，因为它没有已声明临时表 (DGTT) 声明和变化量计算。
以下文件作为 db2mon 的一部分提供，并且位于 ~/sqllib/samples/perf 下的实例目录中：
- db2mon.sh
- db2mon.sql（db2monBefore.sql、db2monInterval.sql 和 db2monAfter.sql 的合并形式）
- db2mon_import.sql
- db2mon_export.sql
- db2mon_report.sql
db2mon 检查用户临时表空间以及 MON_ACT_METRICS 和 MON_REQ_METRICS 的最小必需值。 此检查的结果将在报告的“先决条件”部分中报告。
过程
遵循以下步骤以使用 db2mon 收集和报告性能监视器数据：
结果
该报告包含许多有用的查询，大致分为以下几个部分：
- 时间点数据（例如，当前正在运行的 SQL、实用程序和锁定等待），它们是在时间间隔的开始和结束收集的。
- 累积数据，它们是在整个时间间隔内测量的。
- 在各个分层级别（例如，数据库级别、表空间级别、缓冲池级别、表级别、查询级别和连接级别）收集的数据。
- 针对不同部署类型收集的数据 (示例包括标准 Db2 ESE ， Db2 pureScale和 Db2 with BLU)。
- 环境信息（例如，数据库和实例配置、注册表变量、 CPU 计数和使用情况以及内存使用情况）。
示例
样本输出以逐渐详细的顺序提供，高级部分显示在最前，稍后是较精细的详细信息。 通过高级部分大致了解数据库的性能，然后使用该信息来确定要检查哪些详细部分以获取更深入的洞察。
报告中的大多数表都比以下输出宽。 为了便于阅读，此处的某些表已进行修剪。 在某些情况下，输出将拆分并换行。
- 使用“Throughput metrics at database level”部分确定由系统完成的工作。
====================================== Throughput metrics at database level ====================================== select min(ts_delta) ts_delta, member, decimal((sum(act_completed_total) / float(min(ts_delta))), 10, 1) as act TS_DELTA MEMBER ACT_PER_S CMT_PER_S RB_PER_S DDLCK_PER_S SEL_P_S UID_P_S ROWS_INS_P_S -------- ------ --------- --------- ---------- ------------ --------- ---------- ------------ 35 0 22629.7 2361.1 0.0 0.0 13089.6 9540.0 4364.0 35 1 24331.0 2525.0 0.0 0.0 14064.1 10266.8 4638.2 35 2 27331.5 2842.1 0.0 0.0 15804.4 11527.1 5204.6 35 3 25674.2 2682.0 0.0 0.0 14859.5 10814.6 4878.8 4 record(s) selected.以上输出显示四个成员以及表中显示的其他指标，每个成员每秒大约完成 2400 个事务 (CMT_PER_S) 或 25,000 个 SQL 语句 (ACT_PER_S)。 这些事务和语句是在 35 秒时间段测量的 (TS_DELTA)。 收集数据的过程有时可能会略微延长计划时间间隔。 在此情况下，计划时间间隔为 30 秒。
报告中出现缩写名很常见：- ACT_PER_S：每秒活动数
- CMT_PER_S：每秒落实数
- RB_PER_S：每秒回滚数
- DDLCK_PER_S：每秒死锁数
- SEL_P_S：每秒 SELECT 语句数
- UID_P_S：每秒 UPDATE/INSERT/DELETE 语句数
- ROWS_INS_P_S：每秒插入的行数
- 使用“Time breakdown at database level”部分确定数据库的处理时间。
===================================================== Time breakdown at database level (wait + processing) ===================================================== select member, integer(sum(total_rqst_time)) as total_rqst_tm, decimal(sum(total_compile_time) / float(sum MEMBER TOTAL_RQST_TM PCT_COMPILE PCT_SECTION PCT_SORT PCT_COL PCT_COL_SYNOP PCT_COMMIT PCT_RBACK PCT_CONN ------ ------------- ----------- ----------- -------- ------- ------------- ---------- --------- -------- 0 1035374 0.04 78.59 0.74 0.00 0.00 9.38 0.00 0.10 1 438810 0.01 75.85 1.02 0.00 0.00 15.15 0.00 0.12 2 492605 0.01 74.57 1.06 0.00 0.00 16.66 0.00 0.09 3 482646 0.01 76.32 1.04 0.00 0.00 14.73 0.00 0.11 4 record(s) selected.PCT_SECTION 包括 SQL 语句的处理和等待时间。
在此示例中，最多时间消耗在处理部分 (PCT_SECTION) 上，其次消耗在落实处理 (PCT_COMMIT) 上。 此模式是正常的。
事务系统上编译时间 (PCT_COMPILE) 超过 0.15（或 15%）时可能表示应用程序正在使用字面值而不是参数标记。
- “Wait times at database level”部分报告数据库消耗在等待上的时间。 评估性能运行状况时，“Wait times at database level”部分通常是最重要的顶级信息。
============================== Wait times at database level ============================== select w.member, integer(sum(total_rqst_time)) as total_rqst_tm, integer(sum(total_wait_time)) as total_wait MEMBER TOTAL_RQST_TM TOTAL_WAIT_TM PCT_RQST_WAIT PCT_LOCK PCT_GLB_LOCK PCT_LTCH PCT_LG_DSK PCT_RCLM PCT_CF ------ ------------- ------------- ------------- -------- ------------ -------- ---------- -------- ------ 0 1035374 732450 70.74 1.31 0.57 0.89 4.28 1.07 56.26 1 438810 291659 66.46 2.29 1.51 0.57 8.03 1.91 46.21 2 492605 320535 65.06 1.50 1.13 0.92 9.37 1.67 44.36 3 482646 319718 66.24 1.39 0.86 1.05 7.74 1.87 46.23 4 record(s) se1ected.在此示例中，每个成员消耗在每个请求 ( PCT_RQST_WAIT) 上的等待时间百分比大约为 67%。 此等待时间大部分消耗在集群高速缓存工具 (CF) 通信 (PCT_CF) 上，其次消耗在日志写入 (PCT_LG_DST) 和锁定等待 (PCT_LOCK) 上。
- 您可以使用报告中的各个部分来确定使用最多数据库处理时间的语句。
报告的各个部分显示程序包高速缓存中的语句数据，这意味着在监视时间间隔内完成运行的语句。 监视完成时仍在运行的语句将显示在报告开头的时间点部分中。
报告将列示按总活动时间排列的前 100 个语句，并以表的形式显示不同视图，焦点放在基本指标、等待时间，排序和 I/O 之类的视图上。
将 "数据库级别的等待时间" 部分 (来自示例 3) 与此示例中的 "按执行时间列出的排名靠前的 SQL 语句" 部分进行比较，以确定是否由于下列任一原因导致了高等待时间:- 几个语句
- 影响所有语句的系统范围的问题
“Top SQL statements by execution time”部分显示原始 CPU 使用情况。
来自报告的输出（续）：====================================== Top SQL statements by execution time ====================================== select member, integer(num_exec_with_metrics) as num_exec, coord_stmt_exec_time, decimal(coord_stmt_exec_time / double(num_exec_with_metrics), 10, 2) as avg_coord_exec_time, decimal( (coord_stmt_exec_time / double(... MEMBER NUM_EXEC COORD_STMT_EXEC_TIME AVG_COORD_EXEC_TIME PCT_COORD_STMT_EXEC_TIME TOTAL_CPU_TIME ... ------ -------- -------------------- ------------------- ------------------------ -------------- ... 0 61729 301979 4.89 15.09 29928189 ... 3 69026 150782 2.18 7.53 33255990 ... 2 72832 148618 2.04 7.42 34689087 ... 1 64562 137670 2.13 6.88 3121S907 ... 0 124839 112563 0.90 5.62 4468845 ... 0 124833 111863 0.89 5.59 3686860 ... 0 124836 58906 0.46 2.91 2807094 ... 0 11350 57011 5.02 2.84 1997313 ... 2 147141 46613 0.31 2.33 4830165 ... 3 138286 45568 0.32 2.27 4618735 ... 3 138285 40548 0.29 2.02 5767918 ... 2 147137 39975 0.27 1.99 6031554 ... 1 131525 39818 0.30 1.99 4457211 ...... AVG_CPU_TIME PCT_WAIT_TIME AVG_SECT_TIME AVG_COL_TIME STMT_TEXT ... ------------ ------------- ------------- ------------ ---------------------------------------------- ... 484 53.67 4.89 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 481 40.93 2.18 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 476 36.56 2.04 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 483 41.59 2.13 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDE ... 35 89.65 0.90 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 29 90.54 0.89 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 22 85.45 0.46 0.00 Insert into ORDER_LINE va1ues (?, ?, ?, ?, ?, ... 175 93.18 5.02 0.00 Update ORDER_LINE set OL_DELIVERY_D = ? where ... 32 84.75 0.31 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 33 85.28 0.32 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS ... 41 83.84 0.29 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 40 82.78 0.27 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ ... 33 86.20 0.30 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIS 13 record(s) selected.“Wait time breakdown”部分显示因为等待例如（但不限于）磁盘、锁存器和锁定的资源而未在运行的语句。
来自报告的输出（续）：============================================================== Wait time breakdown for top SQL statements by execution time ============================================================== select member, decimal((total_act_wait_time / double(total_act_time)) * 100, 5, 2) as pct_wait, decimal((log_disk_wait_time / double(total_act_time)) * 100, 5, 2) as pct_lg_dsk, decimal((log_buffer_wait... MEMBER PCT_WAIT PCT_LG_DSK PCT_LG_BUF PCT_LOCK PCT_GL_LK PCT_LTCH PCT_RCLM PCT_CF PCT_PFTCH PCT_DIAG ... ------ -------- ---------- ---------- -------- --------- -------- -------- ------- --------- -------- ... 0 53.67 0.00 0.00 2.37 0.36 2.34 0.00 47.55 0.00 0.00 ... 3 40.93 0.00 0.00 2.29 1.02 2.57 0.00 30.97 0.00 0.00 ... 2 36.56 0.00 0.00 1.42 0.65 1.88 0.00 29.37 0.00 0.00 ... 1 41.59 0.00 0.00 5.04 3.21 1.05 0.00 31.96 0.00 0.00 ... 0 89.65 0.16 0.00 0.00 0.00 0.07 0.35 89.06 0.00 0.00 ... 0 90.54 0.00 0.00 2.32 2.29 0.00 3.59 75.30 0.00 0.00 ... 0 85.45 4.61 0.00 0.00 0.00 0.71 3.77 75.19 0.00 0.00 ... 0 93.18 0.00 0.00 0.00 0.00 0.02 0.05 88.41 0.00 0.00 ... 2 84.75 0.00 0.00 5.16 5.12 0.00 4.94 63.97 0.00 0.00 ... 3 85.28 0.00 0.00 0.23 0.19 0.00 7.03 67.87 0.00 0.00 ... 3 83.84 0.19 0.00 0.00 0.00 0.01 1.50 82.12 0.00 0.00 ... 2 82.78 0.20 0.00 0.00 0.00 0.01 0.71 81.85 0.00 0.00 ... 1 86.20 0.00 0.00 0.00 0.33 0.00 4.85 70.23 0.00 0.00 ... 1 83.34 0.22 0.00 0.00 0.00 0.00 0.90 82.20 0.00 0.00 ...... PCT_POOL_RD PCT_DIR_WR PCT_DIR_RD STMT_TEXT ... ----------- ---------- ---------- ----------------------------------------------------------------- ... 1.40 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 5.06 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 3.87 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 3.52 0.00 0.00 Se1ect Count(Distinct S_I_ID) from STOCK, ORDER_LINE where (S_W_I ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 9.27 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.49 0.00 0.00 Insert into ORDER_LINE va1ues (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ... 4.67 0.00 0.00 Update ORDER_LINE set OL_DELIVERY_D = ? where OL_W_ID = ? and OL_ ... 10.32 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 10.12 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE ... 10.76 0.00 0.00 Se1ect S_QUANTITY, S_DIST_01, S_DIST_02, S_DIST_03, S_DIST_04, S_ ... 0.00 0.00 0.00 Update STOCK set S_QUANTITY = ?, S_YTD = ?, S_ORDER_CNT = ?, S_RE 14 record(s) selected.提示: "语句和计划标识" 部分显示前 100 个语句中每个语句的 EXECUTABLE_ID。 您可以将 EXECUTABLE_ID 与 MON_GET_PKG_CACHE_STMT 函数配合使用，以获取这些语句中的任一项的存取方案。 通过使用以下命令，您还可以使用 EXECUTABLE_ID 来确定说明计划：db2 "call explain_from_section(x'<executable id>','M',NULL,0,'<current user>',?,?,?,?,?)"“Top SQL statements by execution time, aggregated by PLANID”部分与“Top SQL statement by execution time”部分类似。 字面值不同（但具有相同 PLANID 散列值）的所有语句将汇总以显示总成本。 事务应用程序使用字面值来驱动许多 SQL 语句时，此信息很有用。
“IO statistics per statement”部分显示前 100 个 SQL 语句的缓冲池活动。
来自报告的输出（续）：========================================================== IO statistics per stmt - top statements by execution time ========================================================== select member, integer(num_exec_with_metrics) num_exec, decimal(pool_data_l_reads/double(num_exec_with_metrics), 16,1) as avg_d_lrd, decimal(pool_data_p_reads/double(num_exec_with_metrics), 10,1) ... MEMBER NUM_EXEC AVG_D_LRD AVG_D_PRD AVG_I_LRD AVG_I_PRD AVG_TD_PRD AVG_TI_PRD ... ------ ----------- ---------- ---------- ---------- ---------- ----------- ----------- ... 0 61729 0.0 0.0 607.4 0.1 0.0 0.0 ... 3 69026 0.0 0.0 607.4 0.4 0.0 0.0 ... 2 72832 0.0 0.0 607.3 0.2 0.0 0.0 ... 1 64562 0.0 0.0 607.3 0.2 0.0 0.0 ... 0 124839 2.0 0.0 4.0 0.0 0.0 0.0 ... 0 124833 1.1 0.1 3.0 0.0 0.0 0.0 ... 0 124836 1.0 0.0 4.1 0.0 0.0 0.0 ... 0 11350 20.3 0.4 4.1 0.0 0.0 0.0 ... 2 147141 1.1 0.1 3.0 0.0 0.0 0.0 ... 3 138286 1.1 0.1 3.0 0.0 0.0 0.0 ... 3 138285 2.0 0.0 4.0 0.0 0.0 0.0 ... 2 147137 2.0 0.0 4.0 0.0 0.0 0.0 ... 1 131525 1.1 0.1 3.0 0.0 0.0 0.0 ... 1 131523 2.0 0.0 4.0 0.0 0.0 0.0 ... 0 124837 0.0 0.0 2.0 0.0 0.0 0.0 ... 0 11343 0.0 0.0 4.1 0.0 0.0 0.0 ... 2 147135 1.0 0.0 4.1 0.0 0.0 0.0 ... 3 138285 1.0 0.0 4.1 0.0 0.0 0.0 ... 1 131522 1.0 0.0 4.1 0.0 0.0 0.0 ... 0 12533 1.0 0.0 6.0 0.0 0.0 0.0 ... 2 13568 20.4 0.4 4.1 0.0 0.0 0.0 ...... AVG_COL_LRD AVG_COL_PRD AVG_DIR_R_RQS AVG_DIR_W_RQS STMT_TEXT ... ------------ ------------ ------------- ------------- -------------------------- ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Se1ect Count(Distinct S_I_] ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Update ORDER_LINE set OL_DE ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect S_QUANTITY, S_DIST_0 ... 0.0 0.0 0.0 0.0 Update STOCK set S_QUANTITY ... 0.0 0.0 0.0 0.0 Se1ect I_NAME, I_PRICE, I_D ... 0.0 0.0 0.0 0.0 Se1ect sum(OL_AMOUNT) from ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDER_LINE valu ... 0.0 0.0 0.0 0.0 Insert into ORDERS va1ues ( ... 0.0 0.0 0.0 0.0 Update ORDER_LINE set OL_DE 21 record(s) selected.I/O 信息可以指示某个语句是否正在使用索引。 AVG_I_LRD 表示每次执行的平均索引逻辑读取数。 AVG_D_LRD 表示平均数据逻辑读取数。 在以上输出中，前四个条目的 AVG_I_LRD 值偏高，而 AVG_D_LRD 值为零。 此值组合表示基于索引的计划。 如果某个语句具有较高数据逻辑读取数和较低索引逻辑读取数，那么对索引的更改可能会提高性能。
- 使用“Database log write times”部分来检查日志磁盘性能。
执行时间相对高于其他语句的语句可能会建议使用优化程度较低的存取方案。 如果添加索引但未提供解决方案，请比较数据库级别和语句级别的最长等待时间。 此信息确定消耗最多等待时间的对象，然后查看相应报告部分以了解更多详细信息。
在 db2mon 中，各个等待时间百分比（例如，日志磁盘等待时间）在计算时显示为总请求时间的百分比，而不是总等待时间的百分比。 可以通过使用 monreport.dbsummary 过程来计算总等待时间（在此情况下，所有项加在一起达到等待时间的 100%）。
对于事务应用程序，在 "数据库级别的等待时间" 部分 (来自示例 3) 的 PCT_LG_DSK 列中报告的日志磁盘等待时间百分比较高。
来自报告的输出（续）：========================== Database log write times ========================== select member, num_log_write_io, case when ts_delta > 0 then decimal( double(num_log_write_io) / ts_delta, 10, 4 ) else null end as ... MEMBER NUM_LOG_WRITE_IO LOG_WRITE_IO_PER_S LOG_WRITE_MB_PER_S ... ------ ---------------- ------------------ ------------------ ... 0 57237 1788.6562 7.0000 ... 1 68286 2133.9375 8.3437 ... 2 69373 2167.9062 8.5312 ... 3 69286 2165.1875 8.4687 ...... LOG_WRITE_TIME LOG_WRITE_TIME_PER_IO_MS NUM_LOG_BUFFER_FULL ... -------------- ------------------------ -------------------- ... 25306 0.4421 0 ... 26345 0.3858 0 ... 26669 0.3894 0 ... 26741 0.3859 0 4 record(s) selected.在以上输出中，每个 I/O 的日志写入时间 (LOG_WRITE_TIME_PER_IO_MS) 大约为 0.4 毫秒，这是最佳表现。 根据系统不同，这些值会有所变化，但日志写入百分比时间高于 4.0 毫秒时指示可能需要更改存储配置。 重新配置包括更改每个文件系统的高速缓存、RAID 和 LUN 数。
- 使用“Bufferpool read statistics”部分和“Disk read and write I/O times”部分来检查读取时间。注: "缓冲池读统计信息" 部分中的输出包含以下缩写:
- POOL_DATA_L_READS：缓冲池数据页逻辑读取数（基本表 ORGANIZE BY ROW 访问）
- POOL_DATA_P_READS：缓冲池数据页物理读取数
- POOL_INDEX_LREADS：缓冲池索引页逻辑读取数（索引访问）
- POOL_INDEX_P_READS：缓冲池索引页物理读取数
- POOL_COL_L_READS：缓冲池的按列组织数据页逻辑读取数（基本表 ORGANIZE BY COLUMN 访问）
- POOL_COL_P_READS：缓冲池的按列组织的数据页物理读取数
来自报告的输出（续）：============================ Bufferpool read statistics ============================ select member, substr(bp_name,1,20) as bp_name, pool_data_l_reads, pool_data_p_reads, pool_index_l_reads, pool_index_p_reads, pool_col_l_reads, pool_col_p_reads, pool_read_time, case when ... MEMBER BP_NAME POOL_DATA_L_READS POOL_DATA_P_READS POOL_INDEX_L_READS ... ------ ------------- ------------------ ------------------ ------------------- ... 2 IBMDEFAULTBP 3037899 44159 45043859 ... 3 IBMDEFAULTBP 2841993 41020 42586533 ... 1 IBMDEFAULTBP 2696917 38268 40018451 ... 0 IBMDEFAULTBP 2518978 38610 37512769 ...... POOL_INDEX_P_READS POOL_COL_L_READS POOL_COL_P_READS POOL_READ_TIME AVG_READ_TIME ... ------------------- ----------------- ----------------- -------------- ------------- ... 27427 0 0 19619 0.27 ... 34728 0 0 21063 0.27 ... 23941 0 0 17030 0.27 ... 10298 0 0 28304 0.57 4 record(s) selected.很长的池读取时间是一个常见问题。 在 PCT_POOL_RD 列中的 "按执行时间列出的排名靠前 SQL 语句的等待时间细分" 部分 (来自示例 4) 中报告了池读取时间较长的情况。 系统将磁盘中的许多页读取至缓冲池时，此问题尤其常见。 这种类型的大量页读取活动通常在数据库激活后很快发生，或在新应用程序开始建立连接时发生。 平均池读取时间 (AVG_READ_TIME) 是在缓冲池级别和表空间级别报告的。 同样，大对象的高百分比直接 I/O 时间可记录在 AVG_DRCT_READ_TIME 和 AVG_DRCT_WRITE_TIME 中。
来自报告的输出（续）：=============================== Disk read and write I/O times =============================== select member, substr(tbsp_name,1,20) as tbsp_name, (pool_data_p_reads + pool_index_p_reads+ pool_col_p_reads) as num_reads, case when ((pool_data_p_reads + pool_index_p_reads+ pool ... MEMBER TBSP_NAME NUM_READS AVG_READ_TIME DIRECT_READ_REQS AVG_DRCT_READ_TIME ... ------ ---------- ---------- ------------- ---------------- ------------------ ... 3 TBS_OM 29235 0.27 0 - ... 2 TBS_OM 22195 0.26 0 - ... 2 TBS_CST 21312 0.27 0 - ... 3 TBS_CST 19700 0.28 0 - ... 1 TBS_OM 19201 0.26 0 - ... 1 TBS_CST 18485 0.27 0 - ... 0 TBS_CST 17705 0.56 0 - ... 2 TBS_STK 16568 0.27 0 - ... 0 TBS_STK 16127 0.59 0 - ... 3 TBS_STK 15559 0.27 0 - ...... NUM_WRITES AVG_WRITE_TIME DIRECT_WRITE_REQS AVG_DRCT_WRITE_TIME ... ----------- -------------- ------------------ ------------------- ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - ... 0 - 0 - 10 record(s) selected. - 使用“Round-trip CF”部分来确定成员与 CF 之间的消息的往返时间。
在 PCT_CF 中的 "数据库级别的等待时间" (示例 3) 和 "等待时间细分" (示例 4) 中报告了 CF 等待时间百分比。 如果报告中的 PCT_CF 值很高，那么 "双向 CF" 部分将显示 Db2 成员与 CF 之间交换的消息的性能数据。
=================================================================== Round-trip CF command execution counts and average response times =================================================================== select member, id, cast(substr(cf_cmd_name,1,30) as varchar(30)) as cf_cmd_name, total_cf_requests, decimal( doub... MEMBER ID CF_CMD_NAME TOTAL_CF_REQUESTS AVG_CF_REQUEST_TIME_MICRO ------ ------ --------------------- ------------------ ------------------------- 2 128 SetLockState 1016554 60.11 3 128 SetLockState 955295 65.82 1 128 SetLockState 905310 62.04 0 128 SetLockState 851689 223.05 3 128 ReadAndRegister 682169 88._8 2 128 ReadAndRegister 671832 83.39 1 128 ReadAndRegister 662450 84.51 0 128 ReadAndRegister 627922 282.94 2 128 SetLockStateMultiple 413551 70.50 3 128 SetLockStateMultiple 387168 77.93 1 128 SetLockStateMultiple 367427 73.74 0 128 SetLockStateMultiple 345954 252.11 12 record(s) selected. - 使用“Page reclaim metrics”部分来检查索引页和数据页的页回收指标。
在 PCT_RCLM 中的 "数据库级别的等待时间" (示例 3) 和 "等待时间细分" (示例 4) 中报告了回收等待时间。 如果报告中的 PCT_RCLM 值大于零，那么以下部分显示哪个表的回收活动最多，以及该表或该表的索引是否已回收：
=============================================== Page reclaim metrics for index and data pages =============================================== select member, substr(tabschema,1,20) as tabschema, substr(tabname,1,40) as tabname, substr(objtype,1,10) as objtype, data_partition_id, iid, (page ... MEMBER TABSCHEMA TABNAME OBJTYPE DATA_PARTITION_ID IID PAGE_RECLAIMS RECLAIM_WAIT_TIME ------ ---------- --------------- -------- ----------------- ---- -------------- ------------------ 0 DTW ORDERS INDEX - - 4334 3357 2 DTW ORDER_LINE INDEX - - 3870 3096 2 DTW ORDERS INDEX - - 3652 2732 3 DTW ORDERS INDEX - - 3638 2724 1 DTW ORDER_LINE INDEX - - 3634 2666 3 DTW ORDER_LINE INDEX - - 3577 2391 1 DTW ORDERS INDEX - - 3502 2326 0 DTW ORDER_LINE INDEX - - 4169 2286 0 DTW STOCK_501_750 INDEX - - 165 983 0 DTW STOCK_751_1000 INDEX - - 199 952 1 DTW NEW_ORDER INDEX - - 441 880 11 record(s) selected.样本输出显示所有成员上 ORDERS 和 ORDER_LINE 索引的最高回收活动。 但是，这些 RECLAIM_WAIT_TIME 值不高，这可以通过检查“Wait times at database level”部分中的 PCT_RCLM（回收等待时间百分比）来确认。 索引页的高回收活动最常见，并且可通过使用 RANDOM 索引、CURRENT MEMBER 分区和范围分区来改进。
- 使用“Page reclaim metrics for SMP pages”部分来确定空间映射页 (SMP) 的回收活动。 有关空间映射页面回收度量的详细信息，请参阅 spacemappage_reclaim_wait_time-"空间映射页面回收等待时间" 监视元素 。
以下输出显示回收的 SMP 页数，这些页通常因为在表空间扩展数据块大小太小的表中进行大量插入而被回收的。
==================================== Page reclaim metrics for SMP pages ==================================== select member, substr(tabschema,1,20) as tabschema, substr(tabname,1,40) as tabname, substr(objtype,1,10) as objtype, data_partition_id, iid, (spacemapp ... MEMBER TABSCHEMA TABNAME OBJTYPE DATA_PARTITION_ID IID SMP_PAGE_RECLAIMS SMP_PAGE_RECLAIM_WAIT_TIME ------ --------- ---------- ------- ----------------- --- ----------------- -------------------------- 3 DTW ORDER_LINE TABLE - - 9 254 2 DTW ORDER_LINE INDEX - - 57 241 0 DTW ORDER_LINE INDEX - - 90 192 0 DTW ORDER_LINE TABLE - - 9 170 3 DTW ORDER_LINE INDEX - - 67 169 1 DTW ORDER_LINE INDEX - - 57 76 1 DTW ORDER_LINE TABLE - - 3 10 2 DTW ORDER_LINE TABLE - - 4 3 3 DTW NEW_ORDER TABLE - - 2 3 1 DTW NEW_ORDER TABLE - - 1 2 10 record(s) se1ected. - 使用“Latch wait metrics”部分来确定锁存器等待指标。
在 PCT_LTCH 中， "数据库级别的等待时间" (示例 3) 和 "等待时间细分" (示例 4) 报告了锁存器等待时间百分比。 锁存器等待时间百分比 (PCT_LTCH) 在高于 15% 到 20% 时被视为高。 以下部分按类型显示锁存器等待指标的详细信息：
来自报告的输出（续）：==================== Latch wait metrics ==================== select member, substr(latch_name,1,60) as latch_name, total_extended_latch_wait_time as tot_ext_latch_wait_time_ms, total_extended_latch_waits ... MEMBER LATCH_NAME TOT_EXT_LATCH_WAIT_TIME_MS ... ------ ------------------------------------- -------------------------- ... 0 SQLO_LT_SQLB_BPD_bpdLatch_SX 7182 ... 3 SQLO_LT_SQLB_BPD_bpdLatch_SX 4085 ... 2 SQLO_LT_SQLB_BPD_bpdLatch_SX 3086 ... 1 SQLO_LT_SQLB_BPD_bpdLatch_SX 1764 ... 0 SQLO_LT_SQLB_BPD_WARLatch 1272 ... 2 SQLO_LT_SQLB_BPD_WARLatch 1168 ... 3 SQLO_LT_SQLB_BPD_WARLatch 706 ... 1 SQLO_LT_SQLB_BPD_WARLatch 509 ... 0 SQLO_LT_SQLP_LHSH_hshlatch 263 ... 3 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 240 ... 2 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 221 ... 1 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 193 ... 0 SQLO_LT_SQLI_INX_PAGE_CACHE_ipcLatch 175 ...... TOT_EXT_LATCH_WAITS TIME_PER_LATCH_WAIT_MS ... -------------------- ---------------------- ... 4454 1.61 ... 1965 2.07 ... 2088 1.47 ... 1724 1.02 ... 1783 0.71 ... 2637 0.44 ... 2110 0.33 ... 1870 0.27 ... 758 0.34 ... 36 6.66 ... 45 4.91 ... 21 9.19 ... 25 7.00 13 record(s) selected.对于系统上操作的所有代理程序，以 30 秒为周期进行测量时，TIME_PER_LATCH_WAIT_MS 的大多数值不同几秒。 因此，此系统不会显示任何显著的延迟问题。
高锁存等待时间百分比可能因为各种原因而导致。 使用以下方法来解决锁存器等待指标较高的场景中的问题：- 在 Db2 pureScale中，锁存器等待时间与页面回收时间之间存在很强的关联。 即使 2% 到 5% 的回收等待时间，在某些情况下，也可能导致 20% 到 40% 的锁存器等待时间。 检查 "索引和数据页面的页面回收度量" 部分 (示例 8) 可能指示表或索引需要更改。 相同 SQL 语句上的锁存器等待时间和回收等待时间都很高时，尤其如此。
- 在 Db2 V 11.1中对锁定进行了重大改进。 如果锁存器等待时间
SQLO_LT_SQLB_HASH_BUCKET_GROUP_HEADER__groupLatch在“Latch wait metrics”部分中具有最长锁存器等待时间，那么升级至 V11 可能会减少保留锁存器所消耗的时间。 SQLB_BPD__bpdLatch类型与具有大量处理的缓冲池页相关联。 通过查看具有很长锁存等待时间的语句来确定所涉及的表。 减少锁存器争用的一种方法是对表进行范围分区并使用分区索引。