db2MON_GET_PKG_CACHE_STMT表函数抓取分析SQL 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 12db2 +w "SELECT MEMBER,
NUM_EXECUTIONS,db2数据库sql语句
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 语句⽤了较多的排序，所以有⼀些排序溢出应该不是主要问题。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。