MON_GET_PKG_CACHE_STMT 表函数
还可以使用 MON_GET_PKG_CACHE_STMT 表函数来查询当前 PACKAGE CACHE 中 SQL 语句（包括动态 SQL 和静态 SQL）的执行信息，这是一个非常强大的工具，能够返回非常多的信息包括各种时间信息，例如语句执行过程总的等待时间、等待锁的时间、等待排序的时间等等。当发现语句执行时间长时，可以用这个表函数来分析时间的分布情况，是消耗在等待上还是读数据上或者其他因素。查询语句如清单 2 所示，结果在图 4 中。清单 2 的语句并不是直接查询表函数来显示结果，而是计算了每个语句的平均执行时间，以及各项等待时间在总的执行时间的百分比，这样结果更直观一些，但需要注意的是示例查询中只选择了一部分字段，还可以根据情况增加更多的字段，例如增加 TOTAL_EXTENDED_LATCH_WAIT_TIME 来查看 LATCH 等待时间。
清单 2. 使用 MON_GET_PKG_CACHE_STMT 表函数
|
1
2
3
4
5
6
7
8
9
10
11
12
|
db2 +w "SELECT MEMBER,
NUM_EXECUTIONS,
STMT_EXEC_TIME,
decimal((TOTAL_ACT_WAIT_TIME / double(STMT_EXEC_TIME)) * 100, 5, 2) as pct_wait,
decimal((POOL_READ_TIME / double(STMT_EXEC_TIME)) * 100, 5, 2) as pct_read,
decimal((LOCK_WAIT_TIME/double(STMT_EXEC_TIME)) * 100, 5, 2) as pct_lock,
decimal((LOG_DISK_WAIT_TIME / double(STMT_EXEC_TIME)) * 100, 5, 2) as pct_log,
decimal((TOTAL_SECTION_SORT_TIME / double(STMT_EXEC_TIME)) * 100, 5, 2) as pct_sort,
CAST(FLOAT(STMT_EXEC_TIME)/FLOAT(NUM_EXECUTIONS) as decimal(10,3)) as AVG_EXEC_TIME,
VARCHAR(STMT_TEXT,500) AS STMT_TEXT
FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL,NULL,NULL,-2))
WHERE NUM_EXECUTIONS >1 and STMT_EXEC_TIME>0
|
图 4. MON_GET_PKG_CACHE_STMT 查询结果
在图 4 中可以看到，这些语句的 AVG_EXEC_TIME（平均执行时间）在 2~6 秒不等，其中有 5 条语句（with 开头的语句）的 PCT_WAIT 在 95%以上，也就是说这 5 条的执行时间花在了等待上，但是等待的不是 READ、Lock、写事务日志或者排序，而且别的原因。在清单 2 语句的基础上继续增加查询字段，会发现这些语句是在等待 LATCH 上。另外 5 条语句都是调用存储过程的，从这里看不出来时间分布。
结合多种方式获取的 SQL 语句来看，有多条 SQL 语句执行时间为 3~6 秒，对于 OLTP 系统这已经是非常慢了，在并发量稍大的情况就会出现 ACTIVE SESSION 数量高。这些慢的语句中有一部分是因为 LATCH 等待，还有一部分没有等待。这时候可以开始着手优化 SQL，作者也确实这样做了，先是快速的通过创建索引解决了几个有全表扫描的 SQL，然后又去梳理并且尝试优化那些很长且逻辑复杂的 SQL 语句。但是，那些逻辑复杂的长 SQL 并不是最近才上线的啊，会不会以前也是这么慢，最近没有应用程序变更啊（也没有数据库变更），现在努力的方向不对吧。。。及时的打住，进行思考。
快速排除法
可以快速的排除数据库服务器资源问题，CPU 利用率在正常范围内，操作系统内存使用量正常。根据 db2top 结果（如图 1）快速的判断数据库缓冲池命中率（HitRatio）正常，没有 LOCK WAIT，从右下角四个参数 AvgPRdTime（Average Physical Read time），AvgDRdTime（Average Direct Read Time），AvgPWrTime（Average Physical Write time）和 AvgDWrTime（Average Direct Write time）可以判断 I/O 正常。注意到 Deadlocks 为 218，但这是一个累计值而且不会影响性能，还注意到有 SortOvf（Sort Overflow）为 10，有点儿高但考虑到应用程序的 SQL 语句用了较多的排序，所以有一些排序溢出应该不是主要问题。